Hi, Michael Grant <mgr...@grant.org> writes: > On Tue, Feb 3, 2015 at 6:26 PM, Ansgar Burchardt <ans...@debian.org> wrote: >> Could you try restarting sendmail (systemctl restart sendmail) and show >> the output of `systemctl status sendmail'? It also shows the most recent >> log entries, but the output of journalctl --unit sendmail --since -5min >> might also be useful (if it shows more messages). > > So, this is interesting. 'systemctl restart sendmail' with no other > changes to the system does start sendmail manually. However, 'systemctl > start sendmail' does not, at least, not without Reco's line in > /etc/default/sendmail.
Okay, this is a limitation in systemd's compatability layer for init scripts: systemd keeps track of the current state of services. Some services (daemons) can only be "active" when the daemon process is around, but there are also services that only run some commands and then exit, i.e. a service setting up the keyboard layout. For native systemd services there is an option RemainAfterExit= which can be used to specify this (see man:systemd.service(5)). For init scripts systemd cannot know this and defaults to RemainAfterExit=true. So systemd considers the sendmail service running as RemainAfterExit is set for init scripts and "/etc/init.d/sendmail start" did *not* return an error, even though it failed to actually start the daemon (see below). "systemctl start" is thus not doing anything as systemd will not start the same service twice. "systemctl restart" will mark the service stopped first and then start it again; this is not a noop for services already running. > When I run systemctl status sendmail just after rebooting, this is what it > looks like: > > # systemctl status sendmail > ● sendmail.service - LSB: powerful, efficient, and scalable Mail Transport > Agent > Loaded: loaded (/etc/init.d/sendmail) > Active: active (exited) since Tue 2015-02-03 18:23:25 EST; 1min 27s ago > Process: 2604 ExecStart=/etc/init.d/sendmail start (code=exited, > status=0/SUCCESS) This is a bug in the init script: it should not return success if there was an error starting the service (though it cannot always find out if there was an error easily). > Feb 03 18:23:24 bottom.networkguild.org sendmail[2604]: Starting Mail > Transpo... > Feb 03 18:23:24 bottom.networkguild.org sm-mta[2822]: NOQUEUE: > SYSERR(root): ... This looks like an error, but the interesting part is cut off. You might want to run "systemctl status -l sendmail" as suggested below, or "journalctl -b --unit sendmail" to show all log messages for the "sendmail" service since the last reboot (or check /var/log if a syslog daemon is running). > Feb 03 18:23:25 bottom.networkguild.org sendmail[2604]: . > Feb 03 18:23:25 bottom.networkguild.org systemd[1]: Started LSB: powerful, > ef... > Hint: Some lines were ellipsized, use -l to show in full. I suspect that sendmail misses some dependency information in its init script, that is it expects some other parts of the system to be already brought up when it starts. As systemd starts more parts in parallel, it's more likely to uncover such issues than booting with sysvinit. Ansgar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4oefqlh....@deep-thought.43-1.org
