> -----Original Message----- > From: devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx On Behalf > Of Lennart Poettering > Sent: Wednesday, July 14, 2010 8:43 AM > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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@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@test-f13 jcleaver]# On *EL5 variants, I get: [root@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@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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
