| Summary: | systemd seems to unconditionally start sendmail | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Piergiorgio Sartor <piergiorgio.sartor> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | johannbg, metherid, mschmidt, notting, plautrba, systemd-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-15 01:10:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Piergiorgio Sartor
2012-01-14 11:57:00 UTC
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. |