On Thu, 2010-11-25 at 09:52 +0100, Stefan Seyfried wrote:
On Thu, 25 Nov 2010 08:27:45 +0100 Kay Sievers <kay.sievers@vrfy.org> wrote:
- systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly
Is there a cheap way to find out if systemd is used? An environment variable probably?
The existence of /sys/fs/cgroup/systemd/ is usually used.
- Fedora's systemd calls 'chkconfig' for SYSV scripts, so all services can be managed with 'systemctl'.
I don't get the connection between chkconfig and "services can be manages with systemctl", or, in other words: -vvv please :-)
I case you have only: /etc/init.d/foo but no: /lib/systemd/system/foo.service you can still do: systemctl start foo.service
- some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default"
This is surely already in some draft of LSB, or do we have to change this 3 months from now, again?
No, it was decided not to care about the shell script mess LSB likes to establish: a script to parse a simple config file. It just does not make much sense what they already have. If all the new cross-distro config works out, it will be proposed to LSB. What they will do with in after many years, nobody knows. :)
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird - on Fedora NM can always be started and just leaves interfaces alone, that are configured in the "old scripts", all unconfigured interfaces are managed by NM. That way, NM can always run, without interfering with static config, or it just be entirely disabled with its own initscript/systemd service.
sounds like a viable approach to me.
Yeah, that's something that makes at least a bit of sense, in contrast to what we do now.
One thing from the Wiki page: * bluez-coldplug This is just a workaround to replay the bluez udev events once dbus is up (bluetoothd itself is started by dbus activation), so it probably is not needed at all with systemd. I'll try disabling it here and will check with next kernel update if bluetooth still works :-)
It should just flow-in from upstream, that's why it's not listed in this mail, which is mostly about SUSE issues. Here is the patch: http://www.spinics.net/lists/linux-bluetooth/msg08554.html Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org