Bug 815835

On further review, I actually think this is a chkconfig bug.  While /etc/init.d/autofs does not declare the PID file in the header comments, I've tried adding that with:

diff -up /etc/init.d/autofs.orig /etc/init.d/autofs
--- /etc/init.d/autofs.orig     2012-01-22 18:45:05.000000000 -0500
+++ /etc/init.d/autofs  2012-04-24 11:18:41.780806815 -0400
@@ -6,6 +6,7 @@
 # processname: /usr/sbin/automount
 # config: /etc/auto.master
 # description: Automounts filesystems on demand
+# pidfile: /var/run/autofs.pid
 #
 ### BEGIN INIT INFO
 # Provides: autofs

... and found it to be working no better.  (I did also run 'systemctl --system daemon-reload'.)

? pid files have nothing to do with whether or not the service is enabled.

I can't reproduce this on F17:

# chkconfig autofs
Note: forwarding to 'systemctl is-enabled autofs.service'.
enabled
# echo $?
0

Bill, sorry about the pid file noise -- I'd misread the puppet message earlier and have continued thinking running vs. enabled.  My brain is under-caffeinated today it seems and your absolutely right that it has nothing to do with the bug report.

I don't have an F17 box to test with but I'm seeing many with F16 having this problem.  Has the autofs service been migrated to be a native systemd service in F17?  With a legacy init script, how does chkconfig/systemd determine if a service is enabled "under the hood"?

I've tried the F16 updates autofs package on F17, and gotten the same result. What version of chkconfig do you have installed?

With a legacy init script, chkconfig uses the same code it always has - it's only with a systemd service that it forwards to 'systemctl is-enabled'.

Also, what's the output of 'runlevel'?

Okay, this just got weird.  I was seeing this with other services (puppet, yum-cron and libvirtd), so I thought I'd capture it all here in case that revealed some pattern:

$ runlevel
N 5
$ for s in $(chkconfig --list | awk '/5:on/{print $1}'); do chkconfig $s; echo "$s returned $?"; rpm -qf /etc/init.d/$s; done

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

autofs returned 0
autofs-5.0.6-5.fc16.x86_64
jexec returned 0
jdk-1.6.0_27-fcs.x86_64
libvirtd returned 0
libvirt-0.9.6-5.fc16.x86_64
netfs returned 0
initscripts-9.34.2-1.fc16.x86_64
network returned 0
initscripts-9.34.2-1.fc16.x86_64
puppet returned 0
puppet-2.6.14-1.fc16.noarch
sandbox returned 0
policycoreutils-2.1.4-13.fc16.x86_64
yum-cron returned 0
yum-cron-3.4.3-23.fc16.noarch

Notice how these all are reporting correctly ... now.

This is after rebooting and the bug report was started prior to rebooting.  I don't think the rebooting per se helped as I'd done that earlier today.  What *may* have helped was cleaning out /tmp of the 300K+ systemd-namespace-* directories that had accumulated due to a rapidly respawning mysqld.  I wound up using single-user mode to do the cleanup as find was acting very bizarre complaining that (all?) the files didn't exist when using:

find -name 'systemd-namespace*' -group mysql -exec rm -rf {} \;

Find continued complaining in single-user mode, but I confirmed the file count was going down and half-hour later it finished.  Now chkconfig seems happy too.  I wasn't out of space in /tmp, but it sure seems like that mess had something to do with the issue I was having.

Or maybe not.  Here's another F16 box that's also having the same problem.  I do see that 'runlevel' might be suggesting the root cause???

$ runlevel
unknown
$ for s in $(chkconfig --list | awk '/5:on/{print $1}'); do chkconfig $s; echo $?; rpm -qf /etc/init.d/$s; done

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

1
autofs-5.0.6-5.fc16.x86_64
1
jdk-1.6.0_30-fcs.x86_64
jdk-1.6.0_24-fcs.x86_64
1
libvirt-client-0.9.6-5.fc16.x86_64
1
libvirt-0.9.6-5.fc16.x86_64
1
initscripts-9.34.2-1.fc16.x86_64
1
initscripts-9.34.2-1.fc16.x86_64
1
puppet-2.6.14-1.fc16.noarch
1
policycoreutils-2.1.4-13.fc16.x86_64
1
yum-cron-3.4.3-23.fc16.noarch

Oh and both of these systems have:

$ rpm -q chkconfig
chkconfig-1.3.59-1.fc16.x86_64

Correct - chkconfig <foo> reports the status of the service for the current runlevel. If 'runlevel' is unknown, chkconfig will return an error.

(In reply to comment #9)
> Correct - chkconfig <foo> reports the status of the service for the current
> runlevel. If 'runlevel' is unknown, chkconfig will return an error.

That makes sense (at least for non-native systemd services), but I don't understand this:

System 1:

$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 Jan 16 08:26 /etc/systemd/system/default.target -> /lib/systemd/system/graphical.target
$ runlevel
N 5


System 2:

$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 Feb 13 09:36 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target
$ runlevel
unknown


While I can understand what I see at the file system level of systemd configuration, I don't know how utmp is affected to cause the "backwards" looking results above.

If runlevel is 'unknown' when you're booted to an actual runlevel/target (as opposed to when you're in single-user mode, or something similar), then that would be a systemd issue.

Does "systemctl list-jobs" show any unfinished jobs?

Thanks Bill for the clarification; it did seem a bit fishy.

To be perfectly clear, both systems are booted normally to their default targets.  Also, System 1 is now returning 'unknown' and can't think of any reason why it would have suddenly changed.

(In reply to comment #12)
> Does "systemctl list-jobs" show any unfinished jobs?

Nope.

System 1:
$ systemctl list-jobs
 JOB UNIT                      TYPE            STATE  

0 jobs listed.

System 2:
$  systemctl list-jobs
 JOB UNIT                      TYPE            STATE  

0 jobs listed.

Coudl you please append the outputs of "systemctl status runlevel5.target" as well as "systemctl show graphical.target" when this happens, after boot?

(In reply to comment #15)
> Coudl you please append the outputs of "systemctl status runlevel5.target"
> as well as "systemctl show graphical.target" when this happens, after boot?

Sorry Lennart, I just updated the system to F18RC1 last week.  I still have several F16 hosts around, but I can't think of any that have X installed.  I can say that I'd forgotten about this bug, so something must have gotten this fixed and IIRC, there was a chkconfig update that did the trick ... but my human memory gets swapped out too frequently to say that with any certainty.

Is there anything else I can get you?

Hmm, OK, let's close it for now. Feel free to reopen if it resurfaces and somebody can reproduce it.

I am always getting "unknown" in either F20 or Rawhide, regardless of the actual runlevel. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1002806 .

Hmm this crops up in docker centos 6 as well.

# docker run -i -t centos:centos6 /bin/bash
# yum -y install openssh-server
# chkconfig --list sshd
sshd           	0:off	1:off	2:on	3:on	4:on	5:on	6:off

# chkconfig sshd || echo "Return is non-zero"
Return is non-zero

# runlevel 
unknown

Of course a runlevel of unknown in docker sort of makes sense so am
not reopening this bug.

Steve.