Os arquivos em /proc/<PID>/fd/<FD> são links simbólicos para os seus objetos de arquivo correspondentes. Portanto, se um programa com o PID 45920 estiver lendo de um arquivo em /home/hypnotoad/all_glory_to_the_hypnotoad e esse arquivo estiver mapeado para o descritor de arquivo 3 , a execução de ls -l /proc/45920/fd/3 resultará em:
lrwx------. 1 root root 64 Mar 15 18:33 /proc/45920/fd/3 -> /home/hypnotoad/all_glory_to_the_hypnotoad
Então, se você tem o PID do processo daemon, você pode ver quais descritores de arquivos ele tem aberto (e quais arquivos esses descritores mapeiam) usando ls -l /proc/<PID>/fd/ e você pode descobrir um pouco mais sobre esses descritores usando find /proc/<PID>/fdinfo/ | xargs -n 1 cat .
Claro, ele terá os descritores de arquivos 0 (stdin), 1 (stdout) e 2 (stderr) abertos, e pode ter um descritor de arquivo 255 open (para um tty) . Se fdinfo indicar um valor de pos diferente de zero, isso significa que o descritor de arquivo está quase certamente em uso (porque ele fornece a posição do ponteiro no arquivo / stream / what-have-you).
Se realmente não estiver registrando em nenhum arquivo no disco, esta resposta no redirecionamento de saída de um processo em execução pode ser útil para você. Vale a pena notar que é possível ter gdb executar comandos a partir de um arquivo, em vez de interativamente, para que você possa minimizar o tempo de interrupção do daemon.
Também vale a pena observar que o processo que você usa para executar gdb estará sujeito às restrições usuais em torno do ptrace syscall , então você vai querer ter certeza de que seu processo está rodando como root, ou rodando em algum outro contexto que possa ser anexado ao daemon.
Alternativamente, é claro, se você não se importa em ter o daemon em baixo por um tempo, você pode executá-lo dentro de um contêiner docker e capturar a saída dessa maneira.