Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 08:43:32 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. That said, switching /sbin/init is the reasonable way. If it fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without unexpectedly switching init system to something else just because it was around. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. Thus this eselect init will let the user confirm and then trigger reboot. I do not think that users will change init all the time, thus make it better safe and more complex in this change is better than check and wrap in all the boots. Otherwise interesting is preinit handler in OpenWrt: http://wiki.openwrt.org/doc/techref/process.boot http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit http://wiki.openwrt.org/doc/techref/preinit_mount Robert. - init gets effectively switched only at boot/reboot, eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots, if we use the wrapper approach, it would pick up what's the new init at boot and that would be enough for simple cases, hooks on reboot are still needed for more complex ones. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. - we could try to not have the changes to the current init systems ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. # FOCUS My interest is mostly if not all on bb-init-openrc and slightly on runit-openrc. There are enough people involved in systemd and since I still consider it a dangerously frail implementation of a bad idea is better if I do not touch it at all. You've been able to keep this thread on topic very long. Good job!
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:20:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 10:58:23 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 08:43:32 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. That said, switching /sbin/init is the reasonable way. If it fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without unexpectedly switching init system to something else just because it was around. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). It is *easy*. ln -s /sbin/newinit /sbin/init.new mv /sbin/init.new /sbin/init Easy and atomic. The inconsistency potential is similar to one given by init upgrades. Yet we don't do anything magical to defer init upgrade until reboot, and that's why the upgrades go smoothly. You are right. Even though, it is highly appreciated to inform user on urgent reboot. I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. This can be done two ways. One is hacking into init (RC) reboot procedure. It's fragile, it needs to be fit into the right moment and I'm not sure if all inits will handle this without actually needing to patch the code. And in the end, the init gets replaced before init stops working anyway. The other is going beside init and directly into the reboot. This either requires kernel hacking (please don't!) or hacking the reboot procedure in init code. And of course remounting R/W, then writing, remounting back... I did not say it will be easy. Still I think there is space to investigate deeply how to handle that more cleanly (eg: onetime late shutdonw initscript/unit). No one will be hacking kernel:) Robert.
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:21:25 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 10:58:23 +0200 Robert David robert.david.pub...@gmail.com wrote: Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months.. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. Thus this eselect init will let the user confirm and then trigger reboot. I do not think that users will change init all the time, thus make it better safe and more complex in this change is better than check and wrap in all the boots. Otherwise interesting is preinit handler in OpenWrt: http://wiki.openwrt.org/doc/techref/process.boot http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit http://wiki.openwrt.org/doc/techref/preinit_mount In other words, if you go for the symlink approach you're just moving complexity to your system instead of into the boot; I don't see why a wrapper would grow to openrc size, that's just a bold exaggeration. Newer say that wrapper will grow openrc size, and also dont know why it would be bad. The point is somewhere else. I really dont know how many user will switch inits and how many of them will do this regularly. But the wrapper will be executed every boot. So even a tiny mistake can produce booting problems even for those who did not wanted to change anything in init process. On the other hand mistake in some system process will affect only those who would actually switching. It is only calculation of possible risks. I also did not say it must be done the reboot way I mentioned, this is only and different point what can be though about. I'd rather have a clean wrapper that just works than an unclean way to cover the reboot madness that comes along; forcing a reboot, really? I do not see point not forcing reboot when I'm switching init, or let say suggesting. When you update your kernel config, rebuild and install you also can stay working, but you have to be prepared to have nonworking modules that was not inserted before.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. Rich +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. Robert.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 1) we waste disk space. Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. If someone update iniscript, must be prepared to be outofsync with package version. Thus CONFIG_PROTECT. 3) if user modifies systemd unit, init.d script is out-of-sync. Why someone will modify systemd unit when will be using init.d scripts. And for those few people doing this, the same script as portage use for converting can be used. Robert.
