Por que o Ubuntu 16.04 execle de uma imagem específica do C # pára após 90 segundos enquanto outros executam 24X7?

1

Eu gostaria de encontrar um comando Ubuntu Linux 16.04 semelhante ao strace para descobrir por que meu programa C ++, ServiceController.exe,

[execle  ("/usr/lib/mono/4.5/mono-service","/usr/lib/mono/4.5/mono-service",
         "./Debug/ComputationalImageClientServer.exe", 
          0, char const* EnvironmentPtr)]

Pare de rodar misteriosamente após 90 segundos *, onde * ComputationalImageClientServer.exe e ComputatationalImageClientServer.exe são executáveis C # /. NET 4.5

In contrast, when I run /usr/lib/mono/4.5/mono-service.exe  ./Debug/ComputatationalImageVideoServer.exe" at the command prompt,

funciona continuamente por 24 horas por 7 dias pelo menos.

Por que o primeiro exemplo não pode ser executado continuamente 24X7? Como posso diagnosticar, depurar e corrigir esse erro?

open("Delaware_Client_Server.exe", O_RDONLY) = 3
pipe2([4, 5], O_CLOEXEC)                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f743e4dca10) = 3509
close(5)                                = 0
fcntl(4, F_SETFD, 0)                    = 0
fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(4, "", 4096)                       = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3509, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---
close(4)                                = 0
wait4(3509, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 3509
write(1, "\n", 1)                       = 1
write(1, "Process returned 256\n", 21)  = 21
    
por Frank 28.05.2016 / 12:10

2 respostas

1

Use o depurador GNU, gdb ou algo semelhante.

    
por 28.05.2016 / 13:38
0

Qual é a diferença entre executar um programa como daemon e incluí-lo no plano de fundo com '&'

indica que talvez SIGHUP seja o sinal culpado que faz com que o ServiceController.exe pare de funcionar após 90 segundos. nohup command & impede que isso aconteça.

com o comando & Seu processo será morto por um sinal SIGHUP quando o pai morrer.

Os administradores de sistemas têm acesso a algumas soluções alternativas.

Em um sistema bash, você pode usar: (trap '' HUP; comando) &

Isso abre um subshell, captura o sinal HUP com um manipulador vazio e o E comercial / bifurca-o.

A saída ainda pode ser redirecionada para o tty errado. Ou se perca.  Você pode corrigir isso com & > comando.out, 1 > output.out ou 2 > errors.out

Você também pode ter acesso, na maioria dos sistemas, ao comando nohup. o nohup simplifica muito esse processo. É bastante normal, mas descobri que muitas distribuições de ARM embarcadas do busybox estão faltando. Você acabou de escrever: comando nohup &

.. e pronto. A saída é redirecionada, IIRC, para nohup.out, mas esse nome de arquivo pode ser alterado com uma opção.

    
por 30.05.2016 / 08:02