Hide Forgot
Description of problem: # systemctl start sendmail.service Job failed. See system logs and 'systemctl status' for details. # systemctl status sendmail.service sendmail.service - LSB: start and stop sendmail Loaded: loaded (/etc/rc.d/init.d/sendmail) Active: failed since Sat, 16 Jul 2011 12:53:48 +1000; 35s ago Process: 2646 ExecStart=/etc/rc.d/init.d/sendmail start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/sendmail.service Version-Release number of selected component (if applicable): rpm -qa: systemd-units-26-8.fc15.i686 systemd-sysv-26-8.fc15.i686 systemd-26-8.fc15.i686 wine-systemd-1.3.20-1.fc15.noarch kernel-PAE-2.6.38.8-35.fc15.i686 sendmail-8.14.5-1.fc15.i686 sendmail-cf-8.14.5-1.fc15.noarch How reproducible: Highly - will not start Sendmail at all. Steps to Reproduce: 1. Boot PC. Check sendmail started - it won't be. 2. # service sendmail start Error: Starting sendmail (via systemctl): Job failed. See system logs and 'systemctl status' for details. [FAILED] 3. Errors shown under description - sendmail will not start. Actual results: This was working fine with a fresh installation of FC15 from about a month ago - this has only stopped in the last 7-10 days. Sendmail was working perfectly until then. Expected results: Work-around solution or updated rpms owing to the fact I have followed the previous bug reports on this issue that will not work for me. Additional info: As an aside, I am not using dovecot on this box but thought I would try the same setup for it under systemd. It worked without issue putting the relevant entries under /lib/systemd/system, and the dovecot binary is running. chkconfig --list entry for sendmail: sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
(In reply to comment #0) > Process: 2646 ExecStart=/etc/rc.d/init.d/sendmail start (code=exited, > status=1/FAILURE) systemd attempted to start sendmail but the initscript failed for some reason. Are there any error messages in /var/log/maillog? If not, edit /etc/systemd/system.conf, add the line: DefaultStandardOutput=syslog Then do: systemctl daemon-reexec systemctl restart sendmail.service And then look into /var/log/messages for logs from the sendmail initscript.
Thanks Michal. I have run the commands above and Sendmail errors persist with the following in /var/log/messages: Jul 19 08:44:33 hosanna sendmail[19666]: /etc/rc.d/init.d/functions: line 58: /dev/stderr: No such device or address Jul 19 08:44:33 hosanna sendmail[19666]: Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 93: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory Jul 19 08:44:33 hosanna sendmail[19666]: 451 4.0.0 /etc/mail/sendmail.cf: line 605: fileclass: cannot open '/etc/mail/trusted-users': Group writable directory Jul 19 08:44:33 hosanna sendmail[19666]: #033[60G[#033[0;31mFAILED#033[0;39m] Jul 19 08:44:33 hosanna systemd[1]: sendmail.service: control process exited, code=exited status=1 Jul 19 08:44:33 hosanna systemd[1]: Unit sendmail.service entered failed state. I can confirm that /dev/stderr is present and symlinked to /proc/self/fd/2. The local-host-names and trusted-users are 644 and are the same /etc/mail directory ownerships etc as per my FC10 server which I am comparing the environment to just to make sure traditional perms etc are correct. I have not modified the sendmail setup since the day I installed it and it has worked for some weeks before just deciding to fail out of the blue - perhaps the auto-update process may have killed something? Also in /var/log/maillog: Jul 19 08:44:33 hosanna sendmail[19678]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 605: fileclass: cannot open '/etc/mail/trusted-users': Group writable directory
(In reply to comment #2) > Jul 19 08:44:33 hosanna sendmail[19666]: /etc/rc.d/init.d/functions: line 58: > /dev/stderr: No such device or address This one is harmless. > Jul 19 08:44:33 hosanna sendmail[19666]: Starting sendmail: 451 4.0.0 > /etc/mail/sendmail.cf: line 93: fileclass: cannot open > '/etc/mail/local-host-names': Group writable directory > Jul 19 08:44:33 hosanna sendmail[19666]: 451 4.0.0 /etc/mail/sendmail.cf: line > 605: fileclass: cannot open '/etc/mail/trusted-users': Group writable directory Looks like sendmail does not like the permissions on the /etc/mail directory. "rpm -V sendmail" will point it out. Fix it. The mode should be 755.
# rpm -V sendmail 5S.T..... c /etc/mail/local-host-names 5S.T..... c /etc/mail/sendmail.cf 5S.T..... c /etc/mail/sendmail.mc and: ls -ld /etc/mail shows: shows: drwxr-xr-x. 3 root root 4096 Jul 16 12:02 /etc/mail It was already set to 755 and the command: rpm --setperms sendmail did not re-set anything or give errors. An attempted: systemctl restart sendmail.service produced these in the /var/log/maillog: Jul 20 09:12:12 hosanna sendmail[26519]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 93: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory Jul 20 09:12:12 hosanna sendmail[26519]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 605: fileclass: cannot open '/etc/mail/trusted-users': Group writable directory and these files show "ls -l" listings as: -rw-r--r-- 1 root root 91 Jun 9 09:00 /etc/mail/local-host-names -rw-r--r-- 1 root root 127 May 18 02:28 /etc/mail/trusted-users and these match, along with /etc/mail, all of the other setups on other Fedora boxes I have and look after. Following the alternatives mta link leads me to the same permissions as other systems for: -rwxr-sr-x 1 root smmsp 848440 May 18 02:31 /usr/sbin/sendmail.sendmail
Also tried a: yum -y remove sendmail and then a: yum -y install sendmail and everything went perfectly: rpm -V sendmail now returns no files in its display but: # systemctl status sendmail.service sendmail.service - LSB: start and stop sendmail Loaded: loaded (/etc/rc.d/init.d/sendmail) Active: failed since Wed, 20 Jul 2011 09:28:18 +1000; 17s ago Process: 2012 ExecStart=/etc/rc.d/init.d/sendmail start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/sendmail.service So something is inherently broken in systemctl with regards to its integration with sendmail - I have never had this issue before and sendmail is what I do for all customers. Lucky I test Fedora releases before I put them on live e-mail servers as my last install was FC14 for a customer (and no problems to date as expected). I tried the same approaches listed in another bug on this that worked for the person who reported it in the end. The same work-arounds and yum updates have not worked for me.
I am unable to reproduce. Are there anything in the logs after sendmail reinstall?
Reopening, because my guess about the permissions was wrong. > So something is inherently broken in systemctl with regards to its integration > with sendmail I don't think so. sendmail refused to start for whatever reason and systemctl just reports the failure code.
sendmail checks the permissions of all parent directories of the files, so let's also check: ls -ld / /etc
Michal thanks for analysis. David please also check: # rpm -qV filesystem
Nothing in the logs after re-installing sendmail, just gives the startup failure. ls -ld / /etc output: drwxrwxr-x. 28 root root 4096 Jul 23 08:10 / drwxrwxr-x. 163 root root 12288 Jul 23 08:10 /etc ls -la in /: drwxrwxr-x. 28 root root 4096 Jul 23 08:10 . drwxrwxr-x. 28 root root 4096 Jul 23 08:10 .. I am almost at the re-install stage and then ensure updates are turned off as it just stopped working one morning - but will check what I have installed again. Still has errors with the files in /etc/mail. Has to be permission-ish - will keep digging.
(In reply to comment #10) > ls -ld / /etc output: > > drwxrwxr-x. 28 root root 4096 Jul 23 08:10 / > drwxrwxr-x. 163 root root 12288 Jul 23 08:10 /etc Well, this is it. These are the group-writable directories that sendmail complains about. chmod g-w / /etc
Thanks Michal - that did it. Sendmail started perfectly. Now I just need to find out what changed from the system default settings as I naturally know quite well not to touch these. Many thanks again - I knew it had to be something simple.
Possible suspect. I was trying to get minidlna to work so I could store on-line TV shows etc to a directory and watch them on our family TV (needs more stuff for the TV so have since shelved this idea). What I did notice was the /usr/share directory had been changed to uid/gid 500:500 as well as /etc/minidlna.conf - and I changed these to root:root. Maybe it did more that just set these to the machine owner ID? Will see if I can find a bug in their install. Thanks again.