Runlevel subsys re-verification via /etc/rc (was RE: [HEADS-UP] systemd for F14 - the next steps)

[Cleaver, Japheth]

> -----Original Message-----
> From: devel-bounces at lists.fedoraproject.org On Behalf
> Of Lennart Poettering
> Sent: Wednesday, July 14, 2010 8:43 AM
> To: devel at lists.fedoraproject.org
> Subject: Re: [HEADS-UP] systemd for F14 - the next steps
> 
> 
> 2) You parse some configuration files or similar to figure out whether
> you want iscsid to be started. This we believe is just wrong. That's not
> how things work on Linux. Whether you want to start a daemon on boot
> should be controlled by something like chkconfig or systemd-install
> (which is basically chkconfig for systemd), not via some per-daemon
> configuration file switch. I mean, what iscsid is doing there would be
> like if Apache (and similarly all other daemons we have) would have an
> apache.conf config switch StartDaemon=yes or so, and only when that is
> set apache would be started by the init script. Or in other words: the
> central place where services are enabled or disabled for SysV is
> /etc/rc?.d/, not your configuration files. And for systemd the
> equivalent is /etc/systemd/systemd. If you add another layer for
> enabling/disabling you just complicate things, and slow down things. And
> the admins will hate you because they cannot figure why iscsid doesn't
> start if they run /etc/init.d/iscsid start. Have a single on/off switch,
> in a well known place where everybody else has it too. Don't add more
> on/off switches in line there, to confuse people so that they have to
> flip them all if they want something started. And don't parse
> configuration files from shell, that's just evil.

A little apropos, something that's been around in SysV for a while, and is also a symptom with upstart in F13, is that the /var/lock/subsys/ state doesn't always match what init scripts have actually started, especially if there's a reason they've exited successfully but w/o a persistent daemon.

You can test this by simply running /etc/rc on any running system and watch as it re-execs things that already started on boot but didn't set a lock file. On a fresh F13 desktop install

[root at test-f13 jcleaver]# /etc/rc
Entering non-interactive startup
Starting monitoring for VG vg_jctestf13:   2 logical volume(s) in volume group "vg_testf13" monitored [  OK  ]
Starting portreserve: [  OK  ]
Starting system logger: 
Starting irqbalance: [  OK  ]
Starting cups: 
Enabling Bluetooth devices:
[root at test-f13 jcleaver]# 

On *EL5 variants, I get:
[root at el5-x86-64 ~]# /etc/rc
Entering non-interactive startup
Applying Intel CPU microcode update: [FAILED]
Starting sysstat:  Calling the system activity data collector (sadc): 
[  OK  ]
Starting background readahead: [  OK  ]
Starting anacron: [  OK  ]
[root at el5-x86-64 ~]#


Questions:

1) Should I submit these as bugs on the individual packages? (This seems like a great use for the "/var/lock/subsys/$subsys.init" case in /etc/rc, where an initscript has been called at boot to do setup and doesn't need to be run again unless a 'stop' has occurred.)

2) How will systemd handle telinit/runlevel cases with the existing runlevel? Is there a way to verify (from a logical init/subsys perspective only) that what should be running in your runlevel is?

Regards,

-jc