Por que o rsyslog não está listado quando eu executo o serviço?

Question

Estou tentando aprender sobre o rsyslog. Em uma das minhas caixas de linux, eu acho que rsyslog foi configurado para rodar através do systemd baseado nesta saída:

>systemctl status rsyslog
rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)
   Active: active (running) since Tue 2017-01-10 11:28:07 PST; 3 months 19 days ago
 Main PID: 954 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           L954 /sbin/rsyslogd -n

>ps ax | grep syslog
  954 ?        Ssl    6:22 /sbin/rsyslogd -n

Na outra caixa linux, no entanto, systemv (systemctl não está presente) parece não saber que rsyslogd está em execução:

[root@box ~]# service --status-all | grep -i syslog 2>&1
[root@box ~]# ps ax | grep -i syslog
 7866 ?        Sl     1:49 /sbin/rsyslogd -n -c5 -i /var/run/syslogd.pid

Por que essa disparidade?

Na segunda caixa, está o fato de o rsyslogd estar em execução, mas não "encontrado" pela evidência service de que ele foi gerado "manualmente" da linha de comando e não configurado por meio do init de service . d scripts? (Desculpe se minha terminologia é primitiva).

O que eu realmente queria alcançar era: na segunda caixa, eu queria reiniciar o rsyslog, e esperava fazê-lo executando algo como service rsyslog restart . Mas não encontrando o rsyslog quando corri o service --status-all me direcionou para esse desvio.

Configuração da caixa 1:

>uname -a
Linux box1 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 20 (Heisenbug)
Release:        20
Codename:       Heisenbug

Configuração da caixa 2:

Linux box2 2.6.37+ #2 Tue Apr 18 03:07:09 PDT 2017 armv7l GNU/Linux

    

Answer 1

Não da linha de comando, mas talvez de outro script de inicialização. Nos velhos e maus dias, um comando como

 $ sudo bash -c "find / -xdev -type f -print0 -size -1M | xargs -0 grep rsyslog"

ou, mais provavelmente

$ sudo bash
# find / -xdev -type f -print0 -size -1M | xargs -0 grep rsyslog

passará por todos os arquivos no sistema procurando arquivos simples que contenham a string desejada. A opção -mount em find mantém-na fora de / proc, e atualmente o grep é inteligente o suficiente para notar quando o arquivo parece ser um arquivo binário que contém a string. -print0 e a opção -0 para xargs trabalham juntos e asseguram que arquivos com caracteres ímpares, espaços, por exemplo, que poderiam confundir o analisador, sejam tratados apropriadamente. E "-size -1M" garante que apenas arquivos com um megabyte ou menores sejam vistos - arquivos maiores que o que você não está interessado - o rsyslog provavelmente será iniciado a partir de um script.

Existe uma outra possibilidade, é claro, e é que o programa é iniciado remotamente. Eu posso facilmente imaginar alguém iniciando o rsyslog a partir de um script ssh que está ligado a uma chave em particular, que faz apenas essa coisa, pode até não permitir que você obtenha um shell, pois você executa o syslogd quando a máquina é suposta para receber os syslogs está lá para levá-los.

Um comando como pstree pode mostrar o que é o que é filho, e embora seja fácil sair do seu pai para que você seja herdado pelo init,