| Summary: | sendmail will not startup at boot in spite of chkconfig settings | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | George Walsh <gjwalsh> |
| Component: | sendmail | Assignee: | Jaroslav Škarvada <jskarvad> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | ADent123, bulk, jskarvad, kmassare, mlichvar, mschmidt, rbugz, roddrix |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-14 18:23:13 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
George Walsh
2011-05-13 01:18:17 UTC
I am unable to reproduce with fresh (and default) F15 install: sendmail-8.14.4-20.fc15.x86_64 kernel-2.6.38.5-24.fc15.x86_64 systemd-26-1.fc15.x86_64 My reproducer: # telnet localhost 25 ... > quit # reboot # telnet localhost 25 ... > quit My check of systemctl settings (after reboot): # systemctl is-enabled sendmail.service; echo $? sendmail.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig sendmail --level=5 0 0 means enabled # systemctl status sendmail.service | grep sendmail: ├ 1378 sendmail: Queue runner@01:00:00 for /var/spool/cli... └ 1379 sendmail: accepting connections My check of chkconfig (after reboot): # chkconfig --list sendmail |& grep sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off My alternatives: alternatives --display mta mta - status is auto. link currently points to /usr/sbin/sendmail.sendmail /usr/sbin/sendmail.sendmail - priority 90 slave mta-mailq: /usr/bin/mailq.sendmail slave mta-newaliases: /usr/bin/newaliases.sendmail slave mta-rmail: /usr/bin/rmail.sendmail slave mta-sendmail: /usr/lib/sendmail.sendmail slave mta-pam: /etc/pam.d/smtp.sendmail slave mta-sendmailman: /usr/share/man/man8/sendmail.sendmail.8.gz slave mta-mailqman: /usr/share/man/man1/mailq.sendmail.1.gz slave mta-newaliasesman: /usr/share/man/man1/newaliases.sendmail.1.gz slave mta-aliasesman: /usr/share/man/man5/aliases.sendmail.5.gz slave mta-rmailman: /usr/share/man/man8/rmail.sendmail.8.gz Current `best' version is /usr/sbin/sendmail.sendmail. Is there anything in the log that the service is attempting to start? >>>Confirming package release levels agree with yours: # rpm -qa sendmail sendmail-8.14.4-20.fc15.x86_64 # rpm -qa kernel kernel-2.6.38.5-24.fc15.x86_64 # rpm -qa systemd systemd-26-1.fc15.x86_64 >>>Following a fresh reboot of the system: chkconfig --list sendmail Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off >>>This overriding must be what is happening, because: # systemctl status sendmail.service sendmail.service - LSB: start and stop sendmail Loaded: loaded (/etc/rc.d/init.d/sendmail) Active: inactive (dead) CGroup: name=systemd:/system/sendmail.service >>> I can replicate your systemctl settings command: [root@access ~]# systemctl is-enabled sendmail.service; echo $? sendmail.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig sendmail --level=5 0 >>> But NOT your status command: [root@access ~]# systemctl status sendmail.service | grep sendmail sendmail.service - LSB: start and stop sendmail Loaded: loaded (/etc/rc.d/init.d/sendmail) CGroup: name=systemd:/system/sendmail.service >>> Service in log which failed: >>> /var/log/messages complains about avahi (I had always disabled this under Mandriva for the past few years but not yet in Fedora.) [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service failed to load: No such file or directory. See system logs and 'systemctl status' for details. (There is no mention of 'sendmail' in the 'messages' log. >>> /var/log/maillog, after the reboot, reports: May 13 12:58:44 access spamd[1169]: logger: removing stderr method May 13 12:58:46 access spamd[1171]: spamd: server started on port 783/tcp (running version 3.3.2-r929478) May 13 12:58:46 access spamd[1171]: spamd: server pid: 1171 May 13 12:58:46 access spamd[1171]: spamd: server successfully spawned child process, pid 1172 May 13 12:58:46 access spamd[1171]: spamd: server successfully spawned child process, pid 1173 May 13 12:58:46 access spamd[1171]: prefork: child states: IS May 13 12:58:46 access spamd[1171]: prefork: child states: II >>> Which says spamassassin is running, but not sendmail, and this is also what systemctl says: # systemctl status sendmail.service sendmail.service - LSB: start and stop sendmail Loaded: loaded (/etc/rc.d/init.d/sendmail) Active: inactive (dead) CGroup: name=systemd:/system/sendmail.service >>> while chkconfig continues to talk the talk but not walk the walk # chkconfig --list sendmail |& grep sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off >>> My alternatives listing agrees with yours: # alternatives --display mta mta - status is auto. link currently points to /usr/sbin/sendmail.sendmail /usr/sbin/sendmail.sendmail - priority 90 slave mta-mailq: /usr/bin/mailq.sendmail slave mta-newaliases: /usr/bin/newaliases.sendmail slave mta-rmail: /usr/bin/rmail.sendmail slave mta-sendmail: /usr/lib/sendmail.sendmail slave mta-pam: /etc/pam.d/smtp.sendmail slave mta-sendmailman: /usr/share/man/man8/sendmail.sendmail.8.gz slave mta-mailqman: /usr/share/man/man1/mailq.sendmail.1.gz slave mta-newaliasesman: /usr/share/man/man1/newaliases.sendmail.1.gz slave mta-aliasesman: /usr/share/man/man5/aliases.sendmail.5.gz slave mta-rmailman: /usr/share/man/man8/rmail.sendmail.8.gz Current `best' version is /usr/sbin/sendmail.sendmail. ........................ >>> we have to start sendmail at the command line (if we to receive a reply) # systemctl start sendmail.service >>> and check its status [root@access ~]# systemctl status sendmail.service sendmail.service - LSB: start and stop sendmail Loaded: loaded (/etc/rc.d/init.d/sendmail) Active: active (running) since Fri, 13 May 2011 14:02:20 -0700; 1min 35s ago Process: 3125 ExecStart=/etc/rc.d/init.d/sendmail start (code=exited, status=0/SUCCESS) Main PID: 3138 (sendmail) CGroup: name=systemd:/system/sendmail.service ├ 3138 sendmail: accepting connections └ 3146 sendmail: Queue runner@01:00:00 for /var/spool/cli... >>> as well as noting the added lines in /var/log/maillog: May 13 14:02:20 access sendmail[3138]: starting daemon (8.14.4): SMTP+queueing@01:00:00 May 13 14:02:20 access sm-msp-queue[3146]: starting daemon (8.14.4): queueing@01:00:00 1,1 Top (In reply to comment #0) > Description of problem: > > Each time a new system boot-up is required, and regardless of whether a new > kernel is also being installed or not, sendmail is not started. There is no > error reported and nothing in the logs. > > Running: chkconfig --list sendmail clearly shows sendmail is set to 'on' for > levels 2,3,4 and 5. That is not the case. > > Running systemctl status sendmail.service, on the other hand, correctly reports > the service is not active. > > Once sendmail is started at the command line with: systemctl start > sendmail.service everything proceeds normally - until the next boot. > > Version-Release number of selected component (if applicable): > sendmail version is 8.14.4-20.fc15.x86_64. > kernel is at 2.6.38.5-24.fc15.x86_64 > > How reproducible: > > Simply reboot the system and confirm by running chkconfig and systemctl status > sendmail.service to confirm the situation. I can confirm this with kernel-2.6.38.6-27.fc15.x86_64 and systemd-26-1.fc15.x86_64 So I use a workaround as a line "service sendmail start" in /etc/rc.local > Each time a new system boot-up is required, and regardless of whether a new
> kernel is also being installed or not, sendmail is not started. There is no
> error reported and nothing in the logs.
>
> Running: chkconfig --list sendmail clearly shows sendmail is set to 'on' for
> levels 2,3,4 and 5. That is not the case.
>
> Running systemctl status sendmail.service, on the other hand, correctly reports
> the service is not active.
>
> Once sendmail is started at the command line with: systemctl start
> sendmail.service everything proceeds normally - until the next boot.
Can also confirm this bug with:
kernel-2.6.38.6-27.fc15.x86_64
systemd-26-2.fc15.x86_64
I have this problem with sendmail starting up on F15. However, the problem only happens if: a) yum install spamassassin b) chkconfig spamassassin on c) reboot The sendmail process reappears after a 'chkconfig spamassassin off' and reboot. This is likely a duplicate of bug 633774 I have also reproduced this problem in Fedora 15 x86 version with: kernel-2.6.38.8-32.fc15.i686.PAE systemd-26-5.fc15.i686 spamassassin-3.3.2-1.fc15.i686 spamass-milter-0.3.2-1.fc15.i686 I have another box running Fedora 15 x86 that has spamassassin not configured to run where sendmail does start up on boot. Maybe the bug 719931 is related to this. Could you retest the fix? Just minutes ago I commented out our in-house work-around for this, ie: the line added to /etc/rc.local reading 'systemctl restrat sendmail.service' and rebooted the system. The result? failure - sendmail is inactive. Once again I removed the comment, rebooted, and all is well so the work-around is now a 'permanent' part of our server configuration guide. .... and yes, the command actually given includes 'restart', not 'restrat" which is a typo on my part but a good play on words if an unintended one. George, have you given systemd-26-8.fc15 from updates-testing a try? I haven't, no, Michal. I'm trying to refocus on building some application software now after some 10 years of working with the 'old' Mandriva cooker environment. That being the case, I have heeded the usual fedora warnings not to use updates-testing in order to have a reasonably stable server. Otherwise, I would have no problem executing your suggestion but I imagine systemd is not exactly a 'stand-alone' package and, of course, the present work around is simple and effective. Still, it is interesting this bug has persisted under both distros for so long. But I can say I am VERY impressed with my year of experience with fedora 14 and 15. Thanks for your comment. (In reply to comment #12) > I have heeded the usual fedora warnings not to use updates-testing in > order to have a reasonably stable server. Otherwise, I would have no problem > executing your suggestion but I imagine systemd is not exactly a 'stand-alone' > package I understand your worry about updates-testing. I'd just like to point that you can update only the selected package without updating everything to the versions from updates-testing: yum --enablerepo=updates-testing update systemd To see why I suggested you to try the updated systemd, see the first item of the update description: https://admin.fedoraproject.org/updates/systemd-26-8.fc15 Sure admire your thoroughness, Michal. Refreshing these days. I updated systemd, removed the 'fix' in rc.local, rebooted the system and everything is first class. Have to admit I forgot about --enablerepo for specific instances. I had used that last year while working through the nvidia problems in 14. Thank you again. Its wonderful working with you guys, knowing there are real people working hard to make a distro strive toward perfection. George |