Hide Forgot
Description of problem: I've a PC where sendmail should not be started at boot, while it should still be available (it is actually started by xinetd). After boot there is always a "sendmail" running (PID around 1000), even if two configuration files of systemd, "/etc/systemd/system/sendmail.service" and "/etc/systemd/system/multi-user.target.wants/sm-client.service", point to "/dev/null". Version-Release number of selected component (if applicable): systemd-37-3.fc16.i686 How reproducible: It seems always Steps to Reproduce: 1. Change the above links to "/dev/null" 2. Reboot Actual results: "sendmail" runs Expected results: "sendmail" should not be running Additional info: Deleting the above links seems to lead to same results. I also have the impression, even if not confirmed, that the second link is somehow re-created sometimes (after upgrade/install maybe).
What happens after "systemctl disable sendmail.service sm-client.service"?
(In reply to comment #1) > What happens after "systemctl disable sendmail.service sm-client.service"? After that command, the links are still pointing to /dev/null, but after reboot still "sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue" is visible with "ps". Hope this helps, bye, pg
Could you paste the output of these commands?: find /etc/systemd/system -name 'sendmail*' -o -name 'sm-client*' | xargs ls -l systemctl status sendmail.service sm-client.service
Here they are: -- -- -- $> find /etc/systemd/system -name 'sendmail*' -o -name 'sm-client*' | xargs ls -l lrwxrwxrwx 1 root root 9 Jan 13 19:01 /etc/systemd/system/multi-user.target.wants/sm-client.service -> /dev/null lrwxrwxrwx 1 root root 9 Nov 26 20:01 /etc/systemd/system/sendmail.service -> /dev/null $> systemctl status sendmail.service sm-client.service sendmail.service Loaded: masked (/dev/null) Active: inactive (dead) Warning: Unit file changed on disk, 'systemctl --system daemon-reload' recommended. sm-client.service - Sendmail Mail Transport Client Loaded: loaded (/lib/systemd/system/sm-client.service; enabled) Active: active (running) since Sat, 14 Jan 2012 23:40:19 +0100; 29s ago Process: 1062 ExecStart=/usr/sbin/sendmail -L sm-msp-queue -Ac $SENDMAIL_OPTS $SENDMAIL_OPTARG (code=exited, status=0/SUCCESS) Process: 1057 ExecStartPre=/etc/mail/make (code=exited, status=0/SUCCESS) Process: 1055 ExecStartPre=/sbin/restorecon /run/sm-client.pid (code=exited, status=0/SUCCESS) Process: 1052 ExecStartPre=/bin/chown smmsp:smmsp /run/sm-client.pid (code=exited, status=0/SUCCESS) Process: 1049 ExecStartPre=/bin/touch /run/sm-client.pid (code=exited, status=0/SUCCESS) Main PID: 1070 (sendmail) CGroup: name=systemd:/system/sm-client.service └ 1070 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue -- -- -- I'm under the impression "sm-client" is started by default... Hope this helps, bye, pg
> lrwxrwxrwx 1 root root 9 Jan 13 19:01 > /etc/systemd/system/multi-user.target.wants/sm-client.service -> /dev/null This symlink is weird. It looks like someone attempted to mask the service, but did it incorrectly. Masking is not done by putting links in *.target.wants directories. Delete it and try to find out what creates it. > lrwxrwxrwx 1 root root 9 Nov 26 20:01 /etc/systemd/system/sendmail.service -> > /dev/null This causes the service to be masked properly, but masking should not be necessary once both services are disabled normally.
Hi again, I moved the "sm-client.service" link from "multi-user.target.wants" to the same place where "sendmail.service" link is. After reboot "sendmail" does not appear to be running anymore. The story of the link is the following. I first tried to "disable" the "sendmail" service, but it did not prevented it to run. Then I masked it, with same result. After, I tried to disable "sm-client.service", but somehow the link was re-created (maybe an update, as I wrote before). In the end I tried to mask it (by hand) by just exchanging the original link with "/dev/null". That's the reason of the wrong link. I understood that "masking" is necessary in order to prevent the service to be "accidentally" re-enabled, which I suspect can happen, at least with "sendmail", since it seems to be required by other services. In any case, the problem seems to be solved, I guess you can close the bug. Thanks a lot for the support, bye, pg
OK, closing.