Bug 5777

Summary: service crond not starting
Product: Mageia Reporter: Dave Hodgins <davidwhodgins>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: Normal CC: pterjan
Version: 1   
Target Milestone: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Source RPM: cronie-1.4.7-1.mga1 CVE:
Status comment:
Attachments: prcsys.log
Output of prcsys --test S /etc/rc5.d/
prcsys.log

Description Dave Hodgins 2012-05-06 23:51:15 CEST
Something very strange is going on with my Mageia 1 system, that I don't
understand.  The crond service has not been starting at boot on my system
since April 28th.  I'm guessing as to which rpm package is involved.

# service crond status
crond is stopped

# chkconfig --list crond
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off   7:off

# ll /etc/rc.d/rc5.d/S90crond
lrwxrwxrwx 1 root root 15 Jun 10  2011 /etc/rc.d/rc5.d/S90crond -> ../init.d/crond*

# ll /etc/rc.d/init.d/crond
-rwxr-xr-x 1 root root 2840 May  6 17:05 /etc/rc.d/init.d/crond*

[root@hodgins ~]# ps -A|grep cron
[root@hodgins ~]# service crond start
Starting crond                                             [  OK  ]
[root@hodgins ~]# ps -A|grep cron
 9428 ?        00:00:00 crond

I ran into a similar problem with xinetd previously, which was fixed
by fixing the Default-Start run levels as described in
https://www.mageia.org/pipermail/mageia-dev/2012-April/014400.html
Comment 1 Dave Hodgins 2012-05-06 23:53:08 CEST
Created attachment 2204 [details]
prcsys.log
Comment 2 Dave Hodgins 2012-05-06 23:56:02 CEST
Created attachment 2205 [details]
Output of prcsys --test S /etc/rc5.d/
Comment 3 Dave Hodgins 2012-05-07 00:27:25 CEST
Created attachment 2206 [details]
prcsys.log

Here is the prcsys.log after running
chkconfig kolab off
chkconfig watchquagga off
reboot

Note that crond is now being started.  So it looks like installing
kolab on the 28th, put prcsys into compat mode, and it seems to
be dropping services with invalid lsb info.
Dave Hodgins 2012-05-07 00:35:19 CEST

Attachment 2206 mime type: application/octet-stream => text/plain

Manuel Hiebel 2012-05-07 19:32:13 CEST

CC: (none) => pterjan

Comment 4 Pascal Terjan 2012-05-07 19:47:09 CEST
crond initscript seems broken.
It has "Default-Start:  2345" and "Default-Stop: 90" instead of "Default-Start:  2 3 4 5" (and no Default-Stop line) meaning it will only get started on level 2345.

Source RPM: prcsys-0.0.3-7.mga1.src.rpm => cronie-1.4.7-1.mga1

Comment 5 Pascal Terjan 2012-05-07 20:28:30 CEST
I have committed a fix in cauldron (but not tested it and not requested a submit). I will do an update for 1 after testing it, maybe tomorrow evening (for sure not earlier).
Comment 6 Dave Hodgins 2012-05-08 00:11:28 CEST
Looking at other packages I have installed on this Mageia 1 system ...
/etc/init.d/couchdb:# Default-Start: 
/etc/init.d/kadmin:# Default-Start:
/etc/init.d/kprop:# Default-Start:
/etc/init.d/krb5kdc:# Default-Start:
/etc/init.d/pptp:# Default-Start: 
/etc/init.d/squid:# Default-Start: $named
/etc/init.d/tomcat6:# Default-Start:
/etc/init.d/udev-post:# Default-Start: 12345
/etc/init.d/vncserver:# Default-Start:
/etc/init.d/xinetd:# Default-Start: 345

Should a bug report be opened for each of these (as well as cronie)?

With kolab and watchquagga off, so that prcsys is not in compat mode,
I then find some services such as named not being started, while
it was when in compat mode.
Comment 7 Dave Hodgins 2012-05-08 00:47:10 CEST
I've added --debug to prcsys in /etc/rc.d/rc.  On a reboot, this time
named started bug xinetd did not.

[root@hodgins ~]# service xinetd status
xinetd is stopped
[root@hodgins ~]# ps -A|grep xin
[root@hodgins ~]# grep xin /var/log/prcsys.log
Hi, I'm xinetd thread
xinetd: Waiting on rsyslog
xinetd: Finished waiting on rsyslog
xinetd: Waiting on network-up
xinetd: Finished waiting on network-up
Running /etc/rc5.d//S56xinetd start > /tmp/init.gUTDlf 2>&1
xinetd: Setting as ready
xinetd: Calling rc_splash
xinetd: Grabbing console mutex
xinetd: releasing console mutex
rc.local: Waiting on xinetd
rc.local: Finished waiting on xinetd
[root@hodgins ~]# service xin
xinetd           xinetd.original
[root@hodgins ~]# service xinetd start
Starting xinetd                                                                                     [  OK  ]
[root@hodgins ~]# service xinetd status
xinetd (pid  8582) is running...

This, despite the fact, I've changed init.d/xinetd to have
# Default-Start: 3 4 5

Based on /var/log/prcsys.log, it should have started xinetd, but
for some reason didn't.  There was nothing in syslog about xinetd.

Very strange.
Comment 8 Pascal Terjan 2012-05-09 00:09:16 CEST
I have fixed in cauldron:

autofs
backuppc
clamav
courier-authlib
courier-imap
cronie
freeradius
mailman
openafs
oar
squid
sympa
xinetd
zabbix
Comment 9 Manuel Hiebel 2012-11-05 16:53:17 CET
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Comment 10 Manuel Hiebel 2012-12-02 14:32:35 CET
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX