O serviço Postfix está ativado, mas não será iniciado na reinicialização

Question

Como o título menciona, o serviço postfix não será iniciado após a reinicialização do sistema. Estamos usando nosso próprio sistema operacional Linux baseado no OpenSuse 12.1 e, recentemente, o departamento de verificação descobriu que o repositório /var está ficando cada vez maior devido a mensagens não enviadas na fila maildrop de postfix .

Quem envia esses e-mails? Temos alguns aplicativos que compartilham alguns logs entre sistemas.

Eu estava pesquisando diferentes tipos de fórum para minha resposta sem sucesso.

Após o rebote:

$systemctl status postfix.service
postfix.service - Postfix Mail Transport Agent
          Loaded: loaded (/etc/systemd/system/postfix.service; enabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/postfix.service

Encontrei aqui O postfix não inicia na reinicialização de que o problema pode ser um possível conflito com sendmail . Para certificar-se de que o programa sendmail está bem vinculado a postfix :

$ ldd /usr/sbin/sendmail
        linux-vdso.so.1 =>  (0x00007fffa25ff000)
        libpostfix-global.so.1 => /usr/lib64/libpostfix-global.so.1 (0x00007fdb174d2000)
        libpostfix-util.so.1 => /usr/lib64/libpostfix-util.so.1 (0x00007fdb1729a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fdb16f0a000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fdb16d06000)
        libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x00007fdb1698a000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fdb16772000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdb1770b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdb16555000)

Eu também verifico em /var/log/messages e não há informações sobre sendmail ou mesmo postfix de falha.

Vamos começar o serviço:

$ systemctl start postfix.service
$ systemctl status postfix.service
postfix.service - Postfix Mail Transport Agent
          Loaded: loaded (/etc/systemd/system/postfix.service; enabled)
          Active: active (running) since Sat, 28 Jan 2017 21:49:37 +0300; 41s ago
         Process: 3450 ExecStartPost=/etc/postfix/system/cond_slp register (code=exited, status=0/SUCCESS)
         Process: 3444 ExecStartPost=/etc/postfix/system/wait_qmgr 60 (code=exited, status=0/SUCCESS)
         Process: 3368 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
         Process: 3366 ExecStartPre=/etc/postfix/system/update_chroot (code=exited, status=0/SUCCESS)
         Process: 3363 ExecStartPre=/bin/echo Starting mail service (Postfix) (code=exited, status=0/SUCCESS)
        Main PID: 3443 (master)
          CGroup: name=systemd:/system/postfix.service
                  ├ 3443 /usr/lib/postfix/master
                  ├ 3445 pickup -l -t fifo -u
                  ├ 3446 qmgr -l -t fifo -u
                  ├ 3447 cleanup -z -t unix -u
                  ├ 3466 trivial-rewrite -n rewrite -t unix -u
                  ├ 3467 local -t unix
                  ├ 3468 local -t unix
                  └ 3469 local -t unix

Bom. Reinicie o sistema e o serviço ficará inativo (inativo) (morto). Retornando para /var/log , encontrei este arquivo mail.warn

$ cat mail.info
Jan 28 03:13:55 msx postfix/postfix-script[2527]: warning: not owned by group maildrop: /usr/sbin/postqueue
Jan 28 03:13:55 msx postfix/postfix-script[2528]: warning: not owned by group maildrop: /usr/sbin/postdrop
Jan 28 03:13:55 msx postfix/postfix-script[2530]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postqueue
Jan 28 03:13:55 msx postfix/postfix-script[2531]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postdrop
Jan 28 21:49:37 msx postfix/postfix-script[3430]: warning: not owned by group maildrop: /usr/sbin/postqueue
Jan 28 21:49:37 msx postfix/postfix-script[3431]: warning: not owned by group maildrop: /usr/sbin/postdrop
Jan 28 21:49:37 msx postfix/postfix-script[3434]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postqueue
Jan 28 21:49:37 msx postfix/postfix-script[3435]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postdrop

Não sei se isso não ajuda a resolver meu problema.

Informações extras

Dentro do arquivo postfix.service :

$ cat /etc/systemd/system/postfix.service
[Unit]
Description=Postfix Mail Transport Agent
Requires=var-run.mount nss-lookup.target network.target remote-fs.target syslog.target time-sync.target
After=var-run.mount nss-lookup.target network.target remote-fs.target syslog.target time-sync.target
After=amavis.service mysql.service cyrus.service ldap.service openslp.service ypbind.service
Before=mail-transfer-agent.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
ExecStartPre=-/bin/echo 'Starting mail service (Postfix)'
EnvironmentFile=-/etc/sysconfig/postfix
ExecStartPre=/etc/postfix/system/update_chroot
ExecStart=/usr/sbin/postfix start
ExecStartPost=/etc/postfix/system/wait_qmgr 60
ExecStartPost=/etc/postfix/system/cond_slp register
ExecReload=/usr/sbin/postfix reload
ExecReload=/usr/sbin/postfix flush
ExecStop=/usr/sbin/postfix stop
ExecStopPost=/etc/postfix/system/cond_slp deregister

[Install]
WantedBy=multi-user.target

Liste todos os serviços após a reinicialização sem iniciar o postfix service.

$systemctl list-unit-files --type=service
...
klog.service              disabled
klogd.service             masked
ldconfig.service          masked
loadmodules.service       masked
local.service             static
localfs.service           static
openhpid.service          enabled
postfix.service           enabled
postgresql.service        static
poweroff.service          static
proc.service              masked
...

Como estamos rodando no sistema operacional OpenSuse 12.1, journalctl ainda não foi introduzido em systemd

UPDATE

Depois de definir LogLevel=debug em /etc/systemd/system.conf , pude ter mais dados relacionados a esse problema. Em /var/log/messages/ , encontrei isto:

Jan 31 19:17:00 msx kernel:   10.111126] systemd[1]: -.mount changed dead -> mounted
Jan 31 19:17:00 msx kernel:   10.111147] systemd[1]: Activating default unit: default.target
Jan 31 19:17:00 msx kernel:   10.111153] systemd[1]: Trying to enqueue job multi-user.target/start/replace
Jan 31 19:17:00 msx kernel:   10.111204] systemd[1]: Cannot add dependency job for unit hpiwdt.service, ignoring: Unit hpiwdt.service failed to load: No such file or directory. See system logs and 'systemctl status hpiwdt.service' for details.
Jan 31 19:17:00 msx kernel:   10.111276] systemd[1]: Found ordering cycle on lwresd.service/start
Jan 31 19:17:00 msx kernel:   10.111279] systemd[1]: Walked on cycle path to nss-lookup.target/start
Jan 31 19:17:00 msx kernel:   10.111281] systemd[1]: Walked on cycle path to lwresd.service/start
Jan 31 19:17:00 msx kernel:   10.111284] systemd[1]: Breaking ordering cycle by deleting job nss-lookup.target/start
Jan 31 19:17:00 msx kernel:   10.111286] systemd[1]: Deleting job postfix.service/start as dependency of job nss-lookup.target/start

Eu nem sei o que é ou faz nss-lookup . Se alguém tiver alguma ideia. Obrigado.

    

Answer 1

nss-lookup.target é um dos alvos especiais systemd opcionais. Ele está essencialmente agindo como um marco virtual no processo de inicialização. Especificamente, os serviços do sistema que afetam a pesquisa de DNS (como lwresd provavelmente faz) devem especificar em seu arquivo .service que precisam iniciar antes de nss-lookup.target :

[Unit]
Wants=nss-lookup.target
Before=nss-lookup.target

... e quaisquer serviços que precisem de resolução de DNS funcionando antes de poderem iniciar podem especificar isso simplesmente como:

[Unit]
After=nss-lookup.target

Pode ser que o pacote lwresd não tenha seguido esse esquema ou que sua distribuição personalizada tenha uma versão mais antiga de systemd , em que há algum motivo para usar Requires= em vez de Wants= , que é a maneira recomendada atual.

Quando o systemd detecta um conflito de ordenação (um "ciclo de ordenação") em sua configuração, ele é resolvido de maneira muito mecânica, o que nem sempre é ideal no grande esquema das coisas. Nesse caso, o problema estava na ordem entre lwresd e nss-lookup.target , mas o Postfix foi ignorado no processo como um dano colateral.

Como nss-lookup.target é opcional, defini-lo como uma dependência de Requires= para o Postfix é muito strong e pode causar problemas ... exatamente como o que você tinha.

    

Answer 2

Primeiro, adicionar LogLevel=debug on /etc/systemd/system.conf fornece log útil para entender o que realmente acontece nos serviços no tempo de execução da inicialização. Conforme mencionado em minha pergunta atualizada, houve uma ordem conflitante com nss-lookup.target . Removendo nss-lookup.target diretamente em /etc/systemd/system/postfix.service nas duas variáveis [Requires] e [After] o sistema pôde iniciar postfix no processo de inicialização.

Espero que isso possa ajudar.

Obrigado