Re: [gentoo-dev] eselect init
If we're to support sysvinit and systemd at the same time, let each use their upstream paths. This means sysvinit gets /sbin/init. This also means that business can continue as usual, and nobody is forced to install eselect-init. The current system works for users who don't care or aren't aware of this innovation. Motivated users who want the ability to change back and forth can emerge eselect-init and modify their init= line in the bootloader. This is cleaner because it keeps things more in lockstep with upstream. This is also politically easier, as it doesn't require any notable changes or new ebulds to openrc folks, which I can imagine might be met with opposition here and there.
Re: [gentoo-dev] eselect init
On 06/22/2013 01:23 PM, Jason A. Donenfeld wrote: and nobody is forced to install eselect-init That was already demanded earlier in this discussion, but I don't see any response from the initiators of this idea (possible I just missed it). Anyway... if they do such a global change without discussing this particular problem, then it will cause someone to revert it or ask for QA/council intervention.
Re: [gentoo-dev] eselect init
Dnia 2013-06-20, o godz. 23:16:00 William Hubbs willi...@gentoo.org napisał(a): On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote: Dnia 2013-06-20, o godz. 15:56:09 William Hubbs willi...@gentoo.org napisał(a): On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) Why do we need to mess with /sbin/init at all? Yes, we do because we don't want sysvinit randomly getting run as fallback and messing with our systems. I don't understand what you are saying here. If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. But *if* the wrapper fails to run somehow, e.g. becomes broken, the kernel will fallback to the standard location. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2013 04:39 AM, Michał Górny wrote: Dnia 2013-06-20, o godz. 15:56:09 William Hubbs willi...@gentoo.org napisał(a): On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) Why do we need to mess with /sbin/init at all? Yes, we do because we don't want sysvinit randomly getting run as fallback and messing with our systems. So what's the point in having it optional, if sysvinit would just mess around with it. You'd only hit this, if you start your userland with an foreign kernel. Forgotten bootloader arguments can be defaulted with ... I like the suggestion that came up here on the list a while back, have the eselect init module install its own symlink at, say, /sbin/einit. You would still have to have the user edit their boot loader configuration file one time if they want to use this, but this makes it completely opt-in. Plus hacking kernel sources to disable /sbin/init fallback. CONFIG_CMDLINE=/sbin/whatever works, i use it for root=, crypt_dev, ... CONFIG_CMDLINE_OVERRIDE should stay off to respect bootloader cmdline. [ working with foreign init systems (runit-musl based ignite on archlinux, NoUpgrade=sbin/init aka CONFIG_PROTECT does work, too.] - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHEKzMACgkQknrdDGLu8JA6AwD+MyTTKeHlNN/1Nud/G0L7XnA+ hdJl4qATOU3MkyqDQw0A+wao6tYrHTFWCt4MmTOxl3gsBvUvE/w4sQyZcPTElg3h =XwPu -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
For me, the big selling points of eselect-init are: 1. as release engineer, i can prepare images that use either systemd or openrc (at present time these are the two supported options) and do it reliably, programmatically. 2. as distro maintainer, i can roll out a migration path from openrc to systemd (or vice versa). The properties of this migration path I am looking for are reliability and atomicity. Basically, once you move logind/consolekit detection to runtime (and believe it or not, many upstream just get it wrong), and have feature parity in the systemd units available (wrt openrc initscripts), switching over is a matter of 2 (soon 1) commands. Both of them are quite important, because there are scenarios in where systemd fits better than openrc, and scenarios in where openrc is a better fit (older kernels, production system with custom init scripts that are not worth the porting, etc). Making the switch between openrc and systemd easy is a big win (for both developers, distro maintainers, users) and makes Gentoo more attractive, but this is another topic... -- Fabio Erculiani
Re: [gentoo-dev] eselect init
El vie, 21-06-2013 a las 13:19 +0200, Fabio Erculiani escribió: For me, the big selling points of eselect-init are: 1. as release engineer, i can prepare images that use either systemd or openrc (at present time these are the two supported options) and do it reliably, programmatically. 2. as distro maintainer, i can roll out a migration path from openrc to systemd (or vice versa). The properties of this migration path I am looking for are reliability and atomicity. Basically, once you move logind/consolekit detection to runtime (and believe it or not, many upstream just get it wrong), and have feature parity in the systemd units available (wrt openrc initscripts), switching over is a matter of 2 (soon 1) commands. Both of them are quite important, because there are scenarios in where systemd fits better than openrc, and scenarios in where openrc is a better fit (older kernels, production system with custom init scripts that are not worth the porting, etc). Making the switch between openrc and systemd easy is a big win (for both developers, distro maintainers, users) and makes Gentoo more attractive, but this is another topic... Thanks for the explanation. But I think that, currently, the only remaining objection is whether play with /sbin/init (that needs sysvinit to be changed if I don't misremember) or with /sbin/einit. Looks like mgorny has shown some problems on relying on einit instead of plain init regarding to fallback :/
Re: [gentoo-dev] eselect init
On 06/21/2013 01:26 PM, Pacho Ramos wrote: Thanks for the explanation. But I think that, currently, the only remaining objection is whether play with /sbin/init (that needs sysvinit to be changed if I don't misremember) or with /sbin/einit. Looks like mgorny has shown some problems on relying on einit instead of plain init regarding to fallback :/ I prefer having /sbin/init used for the pivot since /sbin/einit is a bit more brittle and as Fabio did the whole machinery is _still_ opt-in. lu
Re: [gentoo-dev] eselect init
On Fri, Jun 21, 2013 at 01:50:02PM +0200, Luca Barbato wrote: On 06/21/2013 01:26 PM, Pacho Ramos wrote: Thanks for the explanation. But I think that, currently, the only remaining objection is whether play with /sbin/init (that needs sysvinit to be changed if I don't misremember) or with /sbin/einit. Looks like mgorny has shown some problems on relying on einit instead of plain init regarding to fallback :/ I prefer having /sbin/init used for the pivot since /sbin/einit is a bit more brittle and as Fabio did the whole machinery is _still_ opt-in. No, he has his own versions of the systemd and sysvinit ebuilds which move some of the installation to non-standard places as part of this machinery, so it is not opt-in. Also, there was an email on this thread showing that using init=/sbin/einit works, so I'm not seeing what mgorny's objections are. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote: If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. But *if* the wrapper fails to run somehow, e.g. becomes broken, the kernel will fallback to the standard location. Yes, but if the wrapper replaces /sbin/init, like it does now, and the wrapper gets broken, I think you are left with an unbootable system. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
Dnia 2013-06-21, o godz. 10:16:10 William Hubbs willi...@gentoo.org napisał(a): On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote: If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. But *if* the wrapper fails to run somehow, e.g. becomes broken, the kernel will fallback to the standard location. Yes, but if the wrapper replaces /sbin/init, like it does now, and the wrapper gets broken, I think you are left with an unbootable system. Then kernel falls back to safe /bin/sh which is a minimal safe fallback. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
Fix the reason why the wrapper got broken then. If the wrapper broke, it is most likely a symptom of a bigger problem. I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit (or /bin/sysvinit?), anyway... -- Fabio Erculiani
Re: [gentoo-dev] eselect init
El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió: [...] No, he has his own versions of the systemd and sysvinit ebuilds which move some of the installation to non-standard places as part of this machinery, so it is not opt-in. Also, there was an email on this thread showing that using init=/sbin/einit works, so I'm not seeing what mgorny's objections are. William I think mgorny was referring to a case where einit fails to work and, then, kernel will fallback to using /sbin/init, that could cause problems as it would always run /sbin/init from sysvinit... but maybe he was referring to something else :|
Re: [gentoo-dev] eselect init
On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote:
Dnia 2013-06-21, o godz. 10:16:10
William Hubbs willi...@gentoo.org napisał(a):
On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
If eselect-init installs the wrapper as /sbin/einit, we don't have to
touch /sbin/init at all, then, the only thing someone would have to do
is to add an entry to their boot loader with init=/sbin/einit on the kcl
to use it.
But *if* the wrapper fails to run somehow, e.g. becomes broken,
the kernel will fallback to the standard location.
Yes, but if the wrapper replaces /sbin/init, like it does now, and the
wrapper gets broken, I think you are left with an unbootable system.
Then kernel falls back to safe /bin/sh which is a minimal safe fallback.
--
Best regards,
Michał Górny
Correct. Even if your init end up being broken you end up with a shell
so you can fix things yourself.
(from init/main.c)
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
if (!run_init_process(execute_command))
return 0;
pr_err(Failed to execute %s. Attempting defaults...\n,
execute_command);
}
if (!run_init_process(/sbin/init) ||
!run_init_process(/etc/init) ||
!run_init_process(/bin/init) ||
!run_init_process(/bin/sh))
return 0;
But this is not pretty. Not everyone knows how to recover from a
broken init. The eselect module aims to offer an elegant way to
switch init systems but if that fails then you need some advanced
knowledge to fix your system. So my opinion is that before such
thing is introduce to the wild, we need to be confident that it will
never fail but even if it does, you need to provide a documented way
on how to recover. Maybe a bold warning with post-mortem instructions
when you first invoke the eselect module is one way to do it.
--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] eselect init
On Fri, Jun 21, 2013 at 05:23:51PM +0200, Fabio Erculiani wrote: I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit (or /bin/sysvinit?), anyway... Feel free to file a request with sysvinit upstream to see if they will do this; I don't think we should be randomly renaming files at the distro level. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote: On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-06-21, o godz. 10:16:10 William Hubbs willi...@gentoo.org napisał(a): On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote: If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. But *if* the wrapper fails to run somehow, e.g. becomes broken, the kernel will fallback to the standard location. Yes, but if the wrapper replaces /sbin/init, like it does now, and the wrapper gets broken, I think you are left with an unbootable system. Then kernel falls back to safe /bin/sh which is a minimal safe fallback. -- Best regards, Michał Górny Correct. Even if your init end up being broken you end up with a shell so you can fix things yourself. The case we are ignoring here is the indirection in the wrapper. e.g. the wrapper, /sbin/init is a valid process, but the process it tries to run, say /bin/foobar, is not. I'm thinking that no matter where we put the wrapper, either as a custom version of /sbin/init or as something like /bin/einit, once the kernel hands things off to the wrapper, if the wrapper fails to run the executable it is directed to run, we are hosed. If there is a separate boot loader entry to run the wrapper, users are able to opt in to using the wrapper, but they can recover if it fails. That is why I'm against having the wrapper replace the standard init. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On 06/21/2013 05:23 PM, Fabio Erculiani wrote: Fix the reason why the wrapper got broken then. If the wrapper broke, it is most likely a symptom of a bigger problem. I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit (or /bin/sysvinit?), anyway... /bin/init lu
Re: [gentoo-dev] eselect init
On 06/21/2013 06:50 PM, William Hubbs wrote: On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote: On 21 June 2013 16:29, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-06-21, o godz. 10:16:10 William Hubbs willi...@gentoo.org napisał(a): On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote: If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. But *if* the wrapper fails to run somehow, e.g. becomes broken, the kernel will fallback to the standard location. Yes, but if the wrapper replaces /sbin/init, like it does now, and the wrapper gets broken, I think you are left with an unbootable system. Then kernel falls back to safe /bin/sh which is a minimal safe fallback. -- Best regards, Michał Górny Correct. Even if your init end up being broken you end up with a shell so you can fix things yourself. The case we are ignoring here is the indirection in the wrapper. e.g. the wrapper, /sbin/init is a valid process, but the process it tries to run, say /bin/foobar, is not. I'm thinking that no matter where we put the wrapper, either as a custom version of /sbin/init or as something like /bin/einit, once the kernel hands things off to the wrapper, if the wrapper fails to run the executable it is directed to run, we are hosed. I asked to mgorny to try that already, and he did and reported already, you can try for yourself and see what happens. lu - no, I won't tell what happens so you will try for yourself
Re: [gentoo-dev] eselect init
On Fri, 21 Jun 2013, Luca Barbato wrote: /bin/init Why /bin? It shouldn't be in users' PATH. Ulrich
Re: [gentoo-dev] eselect init
On 06/22/2013 03:27 AM, Ulrich Mueller wrote: On Fri, 21 Jun 2013, Luca Barbato wrote: /bin/init Why /bin? It shouldn't be in users' PATH. users' PATH, a joyful blast from the past, if I'm allowed to say that. But it's all /usr/bin now [1]. Off topic -- I always have sbins in my non-root path to use non-root features of e.g. /sbin/ip. [1] https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] eselect init
There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init [2] - the wrapper and its code paths are now documented in the eselect-init eclass [2] [3] You need systemd and sysvinit from the same overlay for it to work. If you intend to use switch between systemd to openrc (and vice versa), make sure to install the rest of the packages in that overlay. At the moment, if you want to switch, you also need to use eselect-settingsd. However, I am planning to drop eselect-settingsd: openrc-settingsd and systemd share the same settingsd dbus interface while they call different executables, systemd initializes its dbus services without relying on dbus activation, so the Exec= part of the service descriptor file is currently set to /bin/false, this rings a bell :D, because it is possible to replace /bin/false with a script that starts the respective services when dbus activation is used (which means that systemd hasn't booted the system). This would make possible to remove the blocker dependency in openrc-settingsd and systemd somehow. [1] https://github.com/Sabayon/systemd-love/commit/ced29311348a81a2573b030b1316f1c3a0335c5b [2] https://github.com/Sabayon/systemd-love/commit/9eea3ff713c8fa0391e7b1bfa494d533dc21c0be [3] https://github.com/Sabayon/systemd-love/blob/master/eclass/eselect-init.eclass -- Fabio Erculiani
Re: [gentoo-dev] eselect init
On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) Why do we need to mess with /sbin/init at all? I like the suggestion that came up here on the list a while back, have the eselect init module install its own symlink at, say, /sbin/einit. You would still have to have the user edit their boot loader configuration file one time if they want to use this, but this makes it completely opt-in. The other advantage of this is you don't have to mess with any init system ebuilds at all. - the wrapper and its code paths are now documented in the eselect-init eclass [2] [3] This eclass could go away entirely if you don't try to control /sbin/init. If you intend to use switch between systemd to openrc (and vice versa), make sure to install the rest of the packages in that overlay. At the moment, if you want to switch, you also need to use eselect-settingsd. However, I am planning to drop eselect-settingsd: openrc-settingsd and systemd share the same settingsd dbus interface while they call different executables, systemd initializes its dbus services without relying on dbus activation, so the Exec= part of the service descriptor file is currently set to /bin/false, this rings a bell :D, because it is possible to replace /bin/false with a script that starts the respective services when dbus activation is used (which means that systemd hasn't booted the system). This would make possible to remove the blocker dependency in openrc-settingsd and systemd somehow. Keep up the good work; the more simple we can make the integration the better it will be. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
Dnia 2013-06-20, o godz. 15:56:09 William Hubbs willi...@gentoo.org napisał(a): On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) Why do we need to mess with /sbin/init at all? Yes, we do because we don't want sysvinit randomly getting run as fallback and messing with our systems. I like the suggestion that came up here on the list a while back, have the eselect init module install its own symlink at, say, /sbin/einit. You would still have to have the user edit their boot loader configuration file one time if they want to use this, but this makes it completely opt-in. Plus hacking kernel sources to disable /sbin/init fallback. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote: Dnia 2013-06-20, o godz. 15:56:09 William Hubbs willi...@gentoo.org napisał(a): On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote: There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) Why do we need to mess with /sbin/init at all? Yes, we do because we don't want sysvinit randomly getting run as fallback and messing with our systems. I don't understand what you are saying here. If eselect-init installs the wrapper as /sbin/einit, we don't have to touch /sbin/init at all, then, the only thing someone would have to do is to add an entry to their boot loader with init=/sbin/einit on the kcl to use it. I like the suggestion that came up here on the list a while back, have the eselect init module install its own symlink at, say, /sbin/einit. You would still have to have the user edit their boot loader configuration file one time if they want to use this, but this makes it completely opt-in. Plus hacking kernel sources to disable /sbin/init fallback. No, there is no reason we would have to hack anything in the kernel sources. William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/13 12:43 AM, Luca Barbato wrote: OK -- so, given how very simple this wrapper is, and likewise how simple the switcher script would probably be to write, what's the goal of this whole thread, exactly? It doesn't sound like this is something complicated that we'd need to actually provide via an ebuild or integrating patches in other init-system ebuilds anymore... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGkn9QACgkQ2ugaI38ACPDo5gD/aObV6+JWdkb+qK4jR0ukh1p5 M3ITzlLVjayvAV6pixwA/2KdUeXK1xcHESVfXLcD1b7+iE75+SOKsQBZz/9S78lO =4NET -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/05/13 12:43 AM, Luca Barbato wrote: On 5/28/13 6:19 AM, Michał Górny wrote: And you actually make the boot depend on: 1) valid /bin/sh If it doesn't exist you have a few order of magnitude bigger problem. 2) valid /etc/switch-init which would not interfere with boot process. I guess if you want to switch init system you need that =) With switch-init being executed as a shell script, it can do anything. Yes and that's the beauty of it. And I wouldn't be surprised if you made it do various things you'd like to be done. I would be surprised if I'd make it do various things I won't like to be done, surely a possibility, albeit unlikely. OK -- so, given how very simple this wrapper is, and likewise how simple the switcher script would probably be to write, what's the goal of this whole thread, exactly? It doesn't sound like this is something complicated that we'd need to actually provide via an ebuild or integrating patches in other init-system ebuilds anymore... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGkn9kACgkQ2ugaI38ACPD1bwD+IaoJ0yM2nyTt8vhICF+nzhQN CjnLL3yU1LV9qWmwbfUA/jwO4RiTTFKHzoKLn0NHZV2ZqO1y2dbXfzWyuoxz17Lc =oVXb -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)
The really minimal wrapper would be something like
#!/bin/sh
INIT=/bin/init
if [[ -e /etc/switch-init ]]; then
. /etc/switch-init
fi
exec ${INIT}
With switch-init doing stuff needed, including remounting the rootfs rw
if there are stuff to be changed and if we want stick to symlinks it
could replace itself by a symlink.
Yes, it would be that simple.
lu
Re: [gentoo-dev] eselect init
On Tue, 28 May 2013 05:55:39 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)
The really minimal wrapper would be something like
#!/bin/sh
INIT=/bin/init
if [[ -e /etc/switch-init ]]; then
. /etc/switch-init
fi
exec ${INIT}
With switch-init doing stuff needed, including remounting the rootfs rw
if there are stuff to be changed and if we want stick to symlinks it
could replace itself by a symlink.
Yes, it would be that simple.
And you actually make the boot depend on:
1) valid /bin/sh,
2) valid /etc/switch-init which would not interfere with boot process.
With switch-init being executed as a shell script, it can do anything.
And I wouldn't be surprised if you made it do various things you'd like
to be done. Not to mention what would happen if it gets corrupted into
binary mess and shell tries to execute that.
There's no fallback that could handle shell failures, you know.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] eselect init
On 5/28/13 6:19 AM, Michał Górny wrote: And you actually make the boot depend on: 1) valid /bin/sh If it doesn't exist you have a few order of magnitude bigger problem. 2) valid /etc/switch-init which would not interfere with boot process. I guess if you want to switch init system you need that =) With switch-init being executed as a shell script, it can do anything. Yes and that's the beauty of it. And I wouldn't be surprised if you made it do various things you'd like to be done. I would be surprised if I'd make it do various things I won't like to be done, surely a possibility, albeit unlikely. Not to mention what would happen if it gets corrupted into binary mess and shell tries to execute that. Having your rootfs corrupted is quite bad, even horrible if an ephemeral file gets corrupted through reboot. There's no fallback that could handle shell failures, you know. I guess your knowledge of shell needs to be expanded, beside that it is easier to write an example using shell pseudocode to explain how it could work. That said, here a friendly suggestion: try to be less destructive in your comments and fix your mailer. Both can be annoying in the long run. lu
Re: [gentoo-dev] eselect init
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. - 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! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 21:52:28 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote It has to be done *VERY* early at boot, or else we're back to the problem you described above. Not sure what you mean with very early, you don't really have control over this anyway; the earliest point at which you can reliably do this is to turning init itself into a wrapper. It's almost like a brain surgeon operating on himself. That's if externally you turn it into a symlink, not with a wrapper. 1) boot into single mode before doing the changeover. Both grub and lilo support single mode boot as per... http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode And EFI? This sounds a bit of an overkill. What's wrong with a wrapper? 2) have the setup/switchover mechanism built into the Gentoo minimal install ISO. The advantage here is that if the system ends up no longer bootable off the harddrive, you can still boot from the ISO, chroot into the system on the harddrive, and send emails to the gentoo-user list asking for help G. Users can already use eselect in their chroot. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 04:02:56 +0200 Peter Stuge pe...@stuge.se wrote: By take effect I mean that the filesystem should be modified in such a way that the next boot will use what I selected. No further action which could fail should be required beyond the eselect command. Unless the eselect command has successfully modified the filesystem I can't really know that my system will boot with what I have selected, ie. eselect does not provide any useful feedback, because it can not. That's exactly what I've described in another mail in another subthread. http://thread.gmane.org/gmane.linux.gentoo.devel/85778/focus=85789 Snippet of what I said: Sounds like we would have two files like 'current_init' and 'boot_init' and `eselect init ...` would update 'boot_init'. Then, the first `init` invocation on boot would update 'current_init' with the value of 'boot_init'; latter `init` invocations can then read out 'current_init', which is not to be touched by `eselect init ...`. This assumes that you would be working with a wrapper, not a symlink. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
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 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. 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... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
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. 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? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
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:20:25 +0200 Michał Górny mgo...@gentoo.org wrote: 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. Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. 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. You're making things way more complex than a wrapper would do. I'm not a fan of using the words hacking, fragile and not sure for selling an approach; so, why were you suggesting the symlink approach? The other is going beside init and directly into the reboot. This either requires kernel hacking (please don't!) Yes, please don't, it's against our general objectives. http://www.gentoo.org/proj/en/kernel/maintenance.xml#doc_chap3 Furthermore, even if you would consider this then you can't be guaranteed that everyone uses genpatches; and I don't think we would want this in the eclass either, its users will very likely object. or hacking the reboot procedure in init code. And of course remounting R/W, then writing, remounting back... I don't think patching them is a reliable approach; it steps away from being loosely coupled and therefore makes it harder to understand, you are changing multiple things at once and introduce a maintenance burden. With a wrapper, you don't have a problem with any of those... Loose coupling, high cohesion. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 5/26/13 8:43 AM, Michał Górny 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... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. 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. Have you tested it? Do you know what is the reaction of do_exec on a dangling symlink? 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*. openrc is *simpler* much *simpler* than systemd, stop with that. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. 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. Check your facts, systemd either understands a flavour of inittab or the other or none at all. Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. It is not dangerous beside for those that have an inittab with rm -fR / lu
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] eselect init
On Sun, May 26, 2013 at 6:01 AM, Robert David robert.david.pub...@gmail.com wrote: 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. You can have your cake and eat it too. Just don't call the wrapper init. Somebody else already suggested leaving the init implementations alone and stick the wrapper in a new binary that would need to be enabled specifically in the boot/kernel configuration. So if grub points to /sbin/einit then it runs the wrapper. If it just points to openrc/systemd then it directly executes them and bypasses the wrapper. That means that this whole thing only impacts those who install it, which is the best way to implement something experimental in the first place. Granted, I don't know the limitations of the EFI bootloaders that are out there, but this still seems like something better solved via grub configuration. When I implemented systemd in one of my VMs I just added a grub line to boot back to openrc. Rich
Re: [gentoo-dev] eselect init
Rich Freeman schrieb: Granted, I don't know the limitations of the EFI bootloaders that are out there, but this still seems like something better solved via grub configuration. When I implemented systemd in one of my VMs I just added a grub line to boot back to openrc. EFI stub kernels just need init=/sbin/wrappername in CONFIG_CMDLINE in order to use the wrapper. However, in case of breakage in the wrapper, you would need to boot a fallback kernel or access the EFI shell (not all UEFI implementations allow the latter). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: Openrc is small, but the wrapper really needs to know which is which It doesn't need to, it just needs to kick off the right init process. If you think it does need to, please elaborate. and worst case switch inittab. You could keep this kind of logic outside the wrapper, specific to the init system; such that the wrapper and therefore the shared part of the boot regardless of init system stays as small as possible. This could be even something you could let the eselect script change, the inittab is only needed at boot time as far as I can recall. openrc is *simpler* much *simpler* than systemd, stop with that. Simpler is not necessarily better, stop with flames you don't back up; and if you do back them up, then please keep it outside of the ML. You're contributing to sidetracking your own discussion. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. If we're really going to have this discussion and you really care about wc -l, maybe we should compress init scripts and service units; perhaps we could then combine them into one file to spare inodes too. Joke aside; the other reason, maintainability, is a good one. It is not dangerous beside for those that have an inittab with rm -fR / Root preservation should make this safe. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 8:43 AM, Michał Górny 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... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. 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. Have you tested it? Do you know what is the reaction of do_exec on a dangling symlink? And did you? You keep repeating this and jumping straight to developing work-arounds without even waiting for an answer. And I think William has already spoken that the code supports it. In any case, I've just tested it. Replaced /sbin/init with a dangling symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh as a fallback. 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*. openrc is *simpler* much *simpler* than systemd, stop with that. OpenRC relies on a few layers of various tools plus a lot of init scripts written by different people. Those init scripts include tasks such as parsing configuration files (well, more of grepping them) and manipulating runtime files. The complexity of OpenRC is the sum of all that. To make this point cleaner to you: what if the fallback ran systemd instead? As in, init gets broken somehow and kernel falls back to starting systemd on your unprepared OpenRC system. Is this a behavior you'd like? What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. 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. Check your facts, systemd either understands a flavour of inittab or the other or none at all. What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:45:38 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 11:20:25 +0200 Michał Górny mgo...@gentoo.org wrote: 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. Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. Can't you? How come? 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. You're making things way more complex than a wrapper would do. I'm not a fan of using the words hacking, fragile and not sure for selling an approach; so, why were you suggesting the symlink approach? Don't mix the two mails. I am showing how fragile the solution suggested by Robert is. While you seem to be replying to every mail possible to repeatedly advocate your idea. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 05/26/2013 12:11 PM, Rich Freeman wrote: That means that this whole thing only impacts those who install it, which is the best way to implement something experimental in the first place. +1 I and probably a lot of other people have zero interest in this approach, so we should not be bothered with testing/configuring/using it.
Re: [gentoo-dev] eselect init
On 5/26/13 12:57 PM, Michał Górny wrote: On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 8:43 AM, Michał Górny 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... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. I need it for my purpose, bb-init syntax isn't the same as sysv. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. Noticed and known issue, I merely stated which are the options on the plate, keep in mind that init addons people use and we distribute do even more evil stuff. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. You can: - consider rolling back - drop to a shell Nothing so terrible. And did you? You keep repeating this and jumping straight to developing work-arounds without even waiting for an answer. And I think William has already spoken that the code supports it. I read the code up to do_exec, given for me it would require have a roundtrip to the efi shell I was hoping those proposing that would do that basic homework =) In any case, I've just tested it. Replaced /sbin/init with a dangling symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh as a fallback. That's all I wanted everybody knows, thanks for helping. OpenRC relies on a few layers of various tools plus a lot of init scripts written by different people. Those init scripts include tasks such as parsing configuration files (well, more of grepping them) and manipulating runtime files. The complexity of OpenRC is the sum of all that. I read it as as complex as the user wants. To make this point cleaner to you: what if the fallback ran systemd instead? As in, init gets broken somehow and kernel falls back to starting systemd on your unprepared OpenRC system. Is this a behavior you'd like? I would expect any sane init would get me at least to their single mode. What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. The safest would be dropping to a shell in your scenario. As I stated from start the switch on boot would work so the wrapper checks a switch had been requested, it knows the current init, that must work since worked the previous boot, the next init, that supposedly should work, does the pivoting, shuffling and such and the next boot it just hands over to the current init. The wrapper could even install and uninstall itself. Again, my object of interest is being able to use bb-init and runit. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. A single fragile script can be fixed I guess, which is the one you have in mind that is concerning? What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like 'telinit' should be *enough* to keep the current init running and rebooting. You are focused on systemd, I'm focused on bb-init among the rest, it uses a different syntax for the inittab, so if you want to switch from one or another you either prepare a
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 12:09:21 +0200 Michał Górny mgo...@gentoo.org wrote: Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. Can't you? How come? Because it expects the init system you boot with to be present. 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. You're making things way more complex than a wrapper would do. I'm not a fan of using the words hacking, fragile and not sure for selling an approach; so, why were you suggesting the symlink approach? Don't mix the two mails. Don't read it as mixed, it is not; I take it that you agree with me as you choose not to answer to it. If you meant to advocate your own solution, expanding the other solutions is going to make us forget about what you were suggesting; you're creating your own mixture. I am showing how fragile the solution suggested by Robert is. While you seem to be replying to every mail possible to repeatedly advocate your idea. And I am showing how fragile your expansions to Robert's solution are; thanks for clarifying you meant to point out its fragile, that was not entirely clear from your response and I assumed another intention. We are on the same line here, in fact you have replied more in this sub thread than I did. The wrapper is not my idea; despites my advocation... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. The wrapper only needs to read stuff, I see no reason for it to write stuff. It needs to read which init it needs to kick off, nothing more than that; if more is needed, please elaborate in full detail. And what will happen if moving the files fail? Which files? Since eselect would move them, we would be aware that it failed and could possibly rollback. What if half of configuration belongs to old init, and half to new? Given a rollback, I don't see this happen; unless the rollback fails... And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. Barely anything needs to happen on boot, stop adding complexity; the wrapper is meant to be simple, not another init system on its own. People are having way to different ideas about the wrapper, this is not good; I think people should start to express their ideas in documents, same with the symlink solutions. These everything in the wrapper, everything on reboot assumptions are running out of hand. 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*. openrc is *simpler* much *simpler* than systemd, stop with that. [SNIP] To make this point cleaner to you: what if the fallback ran systemd instead? [SNIP] Why should the fallback be different from what stage3 provides? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 13:45:43 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 12:09:21 +0200 Michał Górny mgo...@gentoo.org wrote: Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. Can't you? How come? Because it expects the init system you boot with to be present. And it is present. It's just the symlink what differs. The symlink should be used just to boot the init and for nothing more. The booted init should be able to find itself. If it isn't, it's the init's what needs to be fixed. Really. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 13:40:03 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 12:57 PM, Michał Górny wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. I need it for my purpose, bb-init syntax isn't the same as sysv. Then you need to use a different file. Feel free to rename either inittab but don't even think of switching files like this. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. Well, that makes it a bit less destructive. Though I still don't like the idea. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. You can: - consider rolling back - drop to a shell Nothing so terrible. Sounds like an initramfs... What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. The safest would be dropping to a shell in your scenario. As I stated from start the switch on boot would work so the wrapper checks a switch had been requested, it knows the current init, that must work since worked the previous boot, the next init, that supposedly should work, does the pivoting, shuffling and such and the next boot it just hands over to the current init. It all depends on how it is implemented. If we decide not to touch /sbin/init, then sysvinit will be the effective fallback at some earlier or later point, depending on what will fail. This is what I really dislike. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. A single fragile script can be fixed I guess, which is the one you have in mind that is concerning? You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like 'telinit' should be *enough* to keep the current init running and rebooting. You are focused on systemd, I'm focused on bb-init among the rest, it uses a different syntax for the inittab, so if you want to switch from one or another you either prepare a least-action script that switch the inittab on reboot or a first-action script that does that on boot. For your needs probably just pivoting a symlink should work almost fine, as long your stay sysvinit compatible, yet doing that as early init or as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 12:01:19 +0200 Robert David robert.david.pub...@gmail.com wrote: Newer say that wrapper will grow openrc size, and also dont know why it would be bad. That's what I'd like to know from him, I was quoting both of you, I really dont know how many user will switch inits and how many of them will do this regularly. Users that would like to compare things, users that are bothered by one init system and try to try an alternative one; developers that want to test both init scripts and service units and thus need to change often, people that would want a specific init system but haven't found out how to switch properly to it yet. I think there are more than a hand full. 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. One would properly test the wrapper, perhaps even have multiple members of arch teams test it, before bringing this out to the user base; it's a very critical matter and we can indeed not afford a mistake here. That being said, once the wrapper is in place and works; I don't think we need to touch it often, it's just a wrapper after all. Do other wrappers, desktop files and files of similar nature we use around Gentoo change often; I think not. On the other hand mistake in some system process will affect only those who would actually switching. It is only calculation of possible risks. If you do risk assessment, you should count in all risks; that therefore also means to take maintainability into account. See my other mail about what it takes to step away from a loosely coupled approach. 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. And we're thinking it through, I don't see why you mention this; I can understand that you don't necessarily stand behind it though, that's OK. 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. My point was that with a wrapper you don't need to force this; the modules problem is irrelevant to this discussion, I don't see any problem in that light with the approaches we are discussing here. PS: If this message ends up in a separate thread, it's because I'm forwarding it from my Sent mail because there was no reply-to present. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 5/26/13 2:08 PM, Michał Górny wrote: You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. Worth investigation, not by you, but those that loathe systemd should have a look and see if they could fix some. For your needs probably just pivoting a symlink should work almost fine, as long your stay sysvinit compatible, yet doing that as early init or as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. Hopefully not =) I just stated what's the problem and the possible solutions. As said from start I want the whole thing to be an opt-in and to cause the least amount of disruption on current setups. Patching sysvinit and bb-init to accept a -c filename would make the whole thing much simpler if we pick a wrapper solution for my most complex case. lu
Re: [gentoo-dev] eselect init
On Sat, May 25, 2013 21:55, Tom Wijsman wrote: On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: How will the stop/start part of services/init-scripts/... be done? Not sure what you mean here; if you keep init function the same as the init you boot with, this should continue to work. As an example. Lets say I want to test a new init-system. To do this, I follow the (still to be written) guide on eselect init and boot into new-and-shiny-init-system. I am still used to stopping/starting services using /etc/init.d/service start/stop And using the rc command to add/remove services from the runlevel(s). If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't been started by any means yet. What will happen? I would assume that openrc will try to start xyz? This is, I believe, something that could cause issues as dependencies might also try to start and I then have a service running not managed by the new-and-shiny-init-system that I was testing. I am assuming that should be for the user to keep in mind, but will it be possible to add something that will make init.d-scripts not work when systemd is running and unit-files not work when systemd is not running? They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else See above, what about if ntpd wasn't running yet? hooks on reboot are still needed for more complex ones. Which complex cases would these hooks be needed on? I think one of these would be the stopping/starting of services (see above) No, if you keep the init system the same as the one you boot with there should be no problems. See above, what about trying to start services using the method of the not-running init? [[ Below is my ONLY remark on that, please feel free to mentally paste it as a response any email trying to explain why it's important to reduce the boottime ]] My intention was not to advocate optimizing boot times; I know, that bit was meant generic, not just as a reply to you. as a kernel maintainer / developer I need to test new releases, run git bisects, do Nouveau reclocking work. I really need this, the average person that keeps his PC running, not so much; I care for it because I can't wait 2 minutes, not because I think it's shiny to have such a short boot... PS: I'm also a mobile laptop user that no longer has a battery. :/ I believe you can still use hibernate there? :) -- Joost
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 21:55:20 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: +1 for wrapper, from my understanding, symlinks for init-systems can't be altered on a running system without risking strange behaviour. Exactly... # shutdown -h now The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41 2013): Excess arguments. I don't know what is the state of your system when testing this but on my system /sbin/telinit is a symlink to /sbin/init. So replacing the latter also replaces telinit with something unexpected. Of course, the solution is to make telinit point to the real sysvinit executable. Not sure how well it will reboot then, however. It may be necessary to also change 'halt' to use 'telinit' if it uses 'init' directly. I am assuming that should be for the user to keep in mind, but will it be possible to add something that will make init.d-scripts not work when systemd is running and unit-files not work when systemd is not running? They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else I think we fixed this already... well, not exactly this because openrc used to try to actually start stuff. I would consider this a regression since it had explanatory error messages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 14:59:28 +0200 J. Roeleveld jo...@antarean.org wrote: As an example. Lets say I want to test a new init-system. [SNIP] If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't been started by any means yet. What will happen? I would assume that openrc will try to start xyz? As I said before: They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else See above, what about if ntpd wasn't running yet? ntpd isn't running on my system and wasn't when I did that. No, if you keep the init system the same as the one you boot with there should be no problems. See above, what about trying to start services using the method of the not-running init? The same, feel free to emerge systemd and try to start a service; I expect this to bail out since its dependencies aren't started, for its dependencies to start the init system itself should be in use. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 15:15:26 +0200
Michał Górny mgo...@gentoo.org wrote:
Cc: tom...@gentoo.org
Please don't CC me, this causes duplicate mails; one of both does not
include reply-to. Nobody else that has responded to me did this before.
Unless you can give me an awesome procmail rule to process these... :)
I don't know what is the state of your system when testing this but on
my system /sbin/telinit is a symlink to /sbin/init. So replacing
the latter also replaces telinit with something unexpected.
I did something like `mv /sbin/init{,.bak} ; mv systemd /sbin/init`
Of course, the solution is to make telinit point to the real sysvinit
executable. Not sure how well it will reboot then, however. It may be
necessary to also change 'halt' to use 'telinit' if it uses 'init'
directly.
Currently I use `systemctl reboot` and `systemctl poweroff`, I
actually have no idea how to make telinit work again with systemd.
# /etc/init.d/ntpd start
ntpd | * WARNING: ntpd is already starting
# /etc/init.d/ntpd stop
ntpd | * ERROR: ntpd stopped by something else
I think we fixed this already... well, not exactly this because openrc
used to try to actually start stuff. I would consider this a
regression since it had explanatory error messages.
The stop error is reasonable I think, the start error is indeed odd.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/05/13 03:08 PM, Matthew Thode wrote: On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. First action at boot, without an initramfs, is too late isn't it? The kernel has already launched init at this point. Also, relying on something at shutdown is going to be problematic too -- openrc and systemd (and whatever others) all need the functionality to do this built into their scripts, and cases of dirty shutdowns are not going to be handled well. The only way I can think of that this is going to work, every time, reliably, is if it was done within an initramfs and therefore prior to the start of actual init (ie, initramfs would read a config file to determine what init-selector to run, calls the init-selector actions, and then exec's that init -- that config file could be eselect-controlled or just edited) And that brings back in the whole initramfs-required flamewar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGiGIMACgkQ2ugaI38ACPBw+gD6A6F5DF6fTFYibbpBjueg1rw1 SL/zUYRomTXDrfhqbDUA/3YxUCAeXrX8dDAlQKbomWnVCG9gKrZObOF5lFo/MXZs =GXEk -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 10:07 AM, Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 15:15:26 +0200 Michał Górny mgo...@gentoo.org wrote: Cc: tom...@gentoo.org Please don't CC me, this causes duplicate mails; one of both does not include reply-to. Nobody else that has responded to me did this before. Unless you can give me an awesome procmail rule to process these... :) :0 Wh: msgid.lock | formail -D 8192 msgid.cache :0 a: .duplicates/new (or /dev/null as you prefer) I'm sure it isn't perfect, but I've been running it for years. Between lists and aliases I'd be buried in dups otherwise. Apologies for the OT, but I figured this was useful, and you did ask... Rich
Re: [gentoo-dev] eselect init
On 5/26/13 1:58 PM, Tom Wijsman wrote: On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. Apparently it is read when you switch runlevel as well. lu
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/05/13 07:40 AM, Luca Barbato wrote: On 5/26/13 12:57 PM, Michał Górny wrote: You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. The way it's being proposed (and please correct me if i'm wrong), the wrapper is a direct replacement binary (small C program) for all init systems, and would based on some configuration file or whatnot determine and exec the init system it's supposed to -- and make any other necessary changes too, such as switching /etc/inittab) I don't know (outside of a script in the initramfs) how this would otherwise be handled to cover all cases. I am curious though, if you see a way to do this otherwise, what the implementation would look like? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGiIxAACgkQ2ugaI38ACPDrbAD/exZAI4utNuOBAMzdkeYj8JgB lmeOg+G892g4yYMa6cIBALEQMH3bliQ0hF3HEtJezdbzG4/XkaEdGIjM+gscxF79 =9J3a -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/05/13 08:59 AM, J. Roeleveld wrote: On Sat, May 25, 2013 21:55, Tom Wijsman wrote: On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: How will the stop/start part of services/init-scripts/... be done? Not sure what you mean here; if you keep init function the same as the init you boot with, this should continue to work. As an example. Lets say I want to test a new init-system. To do this, I follow the (still to be written) guide on eselect init and boot into new-and-shiny-init-system. I am still used to stopping/starting services using /etc/init.d/service start/stop And using the rc command to add/remove services from the runlevel(s). If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't been started by any means yet. What will happen? I would assume that openrc will try to start xyz? This is, I believe, something that could cause issues as dependencies might also try to start and I then have a service running not managed by the new-and-shiny-init-system that I was testing. Point #1 - openrc isn't init -- 'eselect init' or w/e is not necessarily going to be the same as 'eselect rc-system'. It's unlikely that you'll want to use another rc system if using systemd for your init, but that doesn't mean you can't. Point #2 - yes, this can be an issue and I believe it's already being worked on separately; WilliamH has mentioned issues like this more than once on irc, at least, although I don't know if he's implemented any solution(s). This bit should go into a separate thread or bug, and not be considered part of the overall 'eselect init' solution imo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGiIiQACgkQ2ugaI38ACPA7dwD/Y6IJo+/j2Ho4p1bM8mGMt7E8 ZglL7SvNS7g/90K6n1gA/37F0u5v2gzIoSTVi6uEmyhcPMW/2I2vr+YRv0rALO8S =PuVY -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 16:52:27 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 1:58 PM, Tom Wijsman wrote: On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. Apparently it is read when you switch runlevel as well. Ouch, that indeed makes it impossible for eselect to do this and makes the wrapper more complex; unless there is a sane way to on reboot, but then we would be implementing this in too many places. I think some of the other suggestions made here also don't take this into account. Thanks for mentioning. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote: On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Ok, sorry, I was wrong in my previous msg, now I see that bb-init has its own inittab with a different format. How about patching bb-init so that it can handle a sysvinit inittab? William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:48:30 -0500 William Hubbs willi...@gentoo.org wrote: On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote: On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Ok, sorry, I was wrong in my previous msg, now I see that bb-init has its own inittab with a different format. How about patching bb-init so that it can handle a sysvinit inittab? Er, isn't that too far to diverge from upstream? If we're to patch something, I'd rather patch it to use a different path. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 06:55:45PM +0200, Michał Górny wrote: On Sun, 26 May 2013 11:48:30 -0500 William Hubbs willi...@gentoo.org wrote: On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote: On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Ok, sorry, I was wrong in my previous msg, now I see that bb-init has its own inittab with a different format. How about patching bb-init so that it can handle a sysvinit inittab? Er, isn't that too far to diverge from upstream? If we're to patch something, I'd rather patch it to use a different path. From what I just read, the difference is that busybox init ignores the runlevels specified in sysvinit inittab. I guess it isn't an error for the runlevels to be there, it just doesn't do anything with them. Luca, If that's the only difference, do we really need to modify the inittab at all? William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On 5/27/13 12:58 AM, William Hubbs wrote: From what I just read, the difference is that busybox init ignores the runlevels specified in sysvinit inittab. Nope, it interprets the numbers in a different way. If that's the only difference, do we really need to modify the inittab at all? Yes, I tested it first and got the whole system unworkable, one single mode later I baked something to get at least the minimal functionality, supporting our xdm script properly required some more effort I hadn't time to pour that day. lu
Re: [gentoo-dev] eselect init
On 5/26/13 4:13 PM, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/05/13 03:08 PM, Matthew Thode wrote: On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. First action at boot, without an initramfs, is too late isn't it? bootchart2 shows that is quite possible and working fine for it =) The current mode to switch init manually for my use-case is to drop to single user, do your stuff, reboot or reload init if the init or the operating system supports it. Drop to single user is quite the same as rebooting anyway. lu
Re: [gentoo-dev] eselect init
Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter
Re: [gentoo-dev] eselect init
El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió: Hi, since the whole discussion got somehow sidetracked on where and if to install for everybody the rc system specific files for everybody (that should be an implementation detail for the specific dohelper IMHO), I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). I use e4rat and, for that, I need to add init=/sbin/e4rat-preload to my grub.conf, I guess this wouldn't change with this, no? :/ Thanks for the info!
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: Hi, since the whole discussion got somehow sidetracked on where and if to install for everybody the rc system specific files for everybody (that should be an implementation detail for the specific dohelper IMHO), I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). In those setup changing bootargs requires a kernel rebuild and some effort, while the eselect approach stays completely transparent. For some switch we might not have just to change the init binary bit also to do some other changes (e.g. use a different format for inittab) If you can't change options at boot time it's very simple to get unbootable system. Just curious, who does such systems and how root filesystem (+ it's mount options) is expected to be found there? I guess EFI allows you to set bootargs via EFI UI. I'd go for init=/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? # KEYPOINTS - /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. - 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. - 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) # 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. My system with stock openrc gets from linux start to graphical login in less than 6s and I'm not using Gnome so I do not have any reason to use it beside comparing. lu -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 12:25:03 +0200 Peter Stuge pe...@stuge.se wrote: I would actually expect the change to take effect immediately. Then how would you be able to shutdown / reboot your system in a clean way? The premise here is that when you boot with an init system you must shutdown with that same init system, you can't just start one init system and expect the other init system to cleanly shut down its services. Therefore implementing this would either be unclean or way to complex. From all the methods discussed doing it on boot sounds the most sane. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. If it is implemented properly, it really isn't that fragile as you would think; it doesn't take much input, so there is barely any implementation and bug fixing needed and it will work everywhere. Users that manage to break this will often know how to fix, unless we messed up from the Portage tree; but well, this mostly boils down to a proper news item and documentation _before_ bringing this out such that users are at least aware of this crucial boot process change. Anyhow, users need to be aware anyway for when they ever decide to try or switch another init system in the future. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 13:13:36 +0200 Pacho Ramos pa...@gentoo.org wrote: I use e4rat and, for that, I need to add init=/sbin/e4rat-preload to my grub.conf, I guess this wouldn't change with this, no? :/ Thanks for the info! That instead of the default will first load e4rat-preload and only after that the init symlink / wrapper will be called. So, the changes being discussed here will not prevent e4rat-preload from running, but rather change what would happen after e4rat-preload kicks off init. It is a transparent change and should not affect e4rat-preload functionality in a bad way. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
Isn't eselect for cases where I might want to reconfigure something or add configuration values such as for bash-completion, do testing with java-vm or python implementations during development, switch opengl implementation depending on the graphics driver loaded and whatnot. I don't see any of this applying to init system, nor do I see a reason to randomly switch between those. It's rather something to configure during installation, so I'd rather expect proper documentation. But I am not opposing, I just find it weird.
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 14:29:12 +0300 Sergei Trofimovich sly...@gentoo.org wrote: If you can't change options at boot time it's very simple to get unbootable system. https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 In above Bug #465236 at Comment #34 the suggestion has been made to maybe call the wrapper /sbin/einit and leave /sbin/init at a sane default. That way the user should still be able to boot the Gentoo default as long as it does not end up being removed from the system. In other words, changing init=/sbin/einit back to init/sbin/init fixes things; I don't think it's asked too much to add init=/sbin/einit in the bootloader or kernel in the alternative init systems documentation. Just curious, who does such systems and how root filesystem (+ it's mount options) is expected to be found there? I don't see how this is a problem; the kernel loads what you have set as init and after that you have root filesystem access, possibly read only at this point but you don't have to find the root fs here. I guess EFI allows you to set bootargs via EFI UI. Not so sure about this, but most people end up hardcoding it in the kernel; you can do this by setting CONFIG_CMDLINE. I'd go for init=/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? Yeah, this is what the /sbin/einit suggestion above tries to resolve. We shouldn't have our users guess at names here, all they should know is to add einit if they wish to be able to switch and that removing it will load the default init system present on Gentoo... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
El sáb, 25-05-2013 a las 14:03 +0200, Tom Wijsman escribió: On Sat, 25 May 2013 13:13:36 +0200 Pacho Ramos pa...@gentoo.org wrote: I use e4rat and, for that, I need to add init=/sbin/e4rat-preload to my grub.conf, I guess this wouldn't change with this, no? :/ Thanks for the info! That instead of the default will first load e4rat-preload and only after that the init symlink / wrapper will be called. So, the changes being discussed here will not prevent e4rat-preload from running, but rather change what would happen after e4rat-preload kicks off init. It is a transparent change and should not affect e4rat-preload functionality in a bad way. Great! :D
Re: [gentoo-dev] eselect init
On 05/25/2013 01:29 PM, Sergei Trofimovich wrote: If you can't change options at boot time it's very simple to get unbootable system. Just curious, who does such systems and how root filesystem (+ it's mount options) is expected to be found there? You write your bootargs in the kernel, if you really must you can go to the efi shell and override by hand. you can surely install an efi ui on top of your efi implementation but that's unrelated. My current setup works decently the way I mentioned and I guess more than a single person might use it. I'd go for init=/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? /bin/init is my idea (second in the list in linux fallback), otherwise we can just make the wrapper use a non-taken name and have people willing to play with it just reroll their kernel/boot system. lu
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: since the whole discussion got somehow sidetracked [SNIP], I'm back to the other part of it: switching the actual init implementation. Thank you very much. Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). In those setup changing bootargs requires a kernel rebuild and some effort, while the eselect approach stays completely transparent. When we can edit the bootloader, we really shouldn't neglect this option. There are specific situations (like you mention EFI) where this may not be possible, but in that case we can just expect our users to chroot into their system and rebuild the kernel. These users are likely more used to do that because in my own experience if you mess part of EFI up you need to do this anyway; there's one option we forget about here though, EFI users can build a second smaller minimally adjusted defconfig kernel that ends up loading the default init system if they wish to repair their system without chrooting. So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34 at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a sane alternative that allows users to load the default init system of Gentoo through their boot loader if they wish to do. This suggestion doesn't kill the eselect approach, but goes side-by-side with it; it effectively just names it /sbin/einit instead of /sbin/init to keep the default /sbin/init around. Another advantage is that users that don't want extra complexity as they don't want to compare or switch init systems will not get extra complexity added to their system. For some switch we might not have just to change the init binary bit also to do some other changes (e.g. use a different format for inittab) Is there a specific need for this? I see this as possible regardless of how we end up doing this, or are there certain approaches that would disallow this? - /sbin/init (or whatever linux currently calls by default with top priority) Correct as far as I recall from patching that part of boot in the past. should be either a symlink to the actual implementation or a wrapper such as our gcc one. Wrapper sounds more safe to me since you allow more logic to be incorporated and aren't to restricted in what you can do with it early on, on the other hand a symlink would be a much more clean approach if you don't need more logic than just the symlink; although I'm not sure if the kernel loves a symlink for /sbin/init, haven't looked at that... I like better the latter since it is overall safer. The former might or might not work since linux has some fallback capabilities but hadn't been tested. +1 I agree we should keep things safe when talking about our boot. - init gets effectively switched only at boot/reboot As stated elsewhere in this ML thread, reboot is probably a bad idea to pursue; so that only leaves us with the boot option. When talking in the boot context there is likely no actual switch happening but it rather just kicks off the right progress instead. eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots When we kick off the right init system at boot, we probably don't need to keep track of it separately; or at least not call eselect for that. Sounds like we would have two files like 'current_init' and 'boot_init' and `eselect init ...` would update 'boot_init'. Then, the first `init` invocation on boot would update 'current_init' with the value of boot_init; latter `init` invocations can then read out 'current_init', which is not to be touched by `eselect init ...`. 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 Ah, I think this is what I gave more detailed above. hooks on reboot are still needed for more complex ones. Which complex cases would these hooks be needed on? - 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) The /sbin/einit approach that I linked near the start would help here. # 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. My system with stock openrc gets from linux start to graphical login in less than 6s and I'm not using Gnome so I do not have any reason to use it beside comparing. Can we please keep information that may provoke a comparison off the ML? I'll give a neutral objective response why the init system doesn't matter for this, as I'm
Re: [gentoo-dev] eselect init
On 05/25/2013 01:13 PM, Pacho Ramos wrote: El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió: Hi, since the whole discussion got somehow sidetracked on where and if to install for everybody the rc system specific files for everybody (that should be an implementation detail for the specific dohelper IMHO), I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). I use e4rat and, for that, I need to add init=/sbin/e4rat-preload to my grub.conf, I guess this wouldn't change with this, no? :/ mostly you would be able to do # eselect init addon e4rat instead. But the whole eselect init should be an opt-in till we are 100% sure it covers the usual scenarios. The basic idea is that you would have a wrapper (shellscript or binary) that just reads from a known location what to run once and what to run the following times, something along the lines of if (switching) do_switch else exec $real_init With all the possible failovers. lu
Re: [gentoo-dev] eselect init
On 05/25/2013 02:13 PM, hasufell wrote: Isn't eselect for cases where I might want to reconfigure something or add configuration values such as for bash-completion, do testing with java-vm or python implementations during development, switch opengl implementation depending on the graphics driver loaded and whatnot. I don't see any of this applying to init system, nor do I see a reason to randomly switch between those. It's rather something to configure during installation, so I'd rather expect proper documentation. Beside switching completely init system (since there is this itch to try new toys here), you also have addons such as benchmarks such bootchart, fs layout mappers/optimizers such as ureadahead and e4rat. Some are something you want to run on-off. All this started because Fabio had enough people pestering him about systemd and he wanted some simple way so people could try it and get back once burnt or vice-versa. I have my uses for it since beside using bb-init to shave some time spent spawning ephemeral processes on complex runscript, there is also the runit integration in openrc that would feel bad having it rotting in a branch w/out making it available and it has the very same issues you have with systemd. So having an eselect applet for this kind of purposes makes sense. lu
Re: [gentoo-dev] eselect init
I'd go for init=/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? /bin/init is my idea (second in the list in linux fallback), otherwise we can just make the wrapper use a non-taken name and have people willing to play with it just reroll their kernel/boot system. Ah, cool then! If it eselect thing implemented; something like news entry on migration would educate those like me not to be that scared. -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect init
On Sat, May 25, 2013 15:38, Tom Wijsman wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: SNIPPED there's one option we forget about here though, EFI users can build a second smaller minimally adjusted defconfig kernel that ends up loading the default init system if they wish to repair their system without chrooting. Good suggestion, especially as I am trying out EFI-boot on one of my machines with intention to keep it on EFI if it works. So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34 at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a sane alternative that allows users to load the default init system of Gentoo through their boot loader if they wish to do. This suggestion doesn't kill the eselect approach, but goes side-by-side with it; it effectively just names it /sbin/einit instead of /sbin/init to keep the default /sbin/init around. Another advantage is that users that don't want extra complexity as they don't want to compare or switch init systems will not get extra complexity added to their system. I was thinking of a default option in the eselect init part that would remove init=/sbin/einit from the kernel boot parameters. Not sure how that would be best achieved as a lot (most?) users will have more then one boot-option in their grub(2)/lilo config. - /sbin/init (or whatever linux currently calls by default with top priority) Correct as far as I recall from patching that part of boot in the past. I don't have init= set on my machines and it seems to start /sbin/init. So that should be correct. should be either a symlink to the actual implementation or a wrapper such as our gcc one. Wrapper sounds more safe to me since you allow more logic to be incorporated and aren't to restricted in what you can do with it early on, on the other hand a symlink would be a much more clean approach if you don't need more logic than just the symlink; although I'm not sure if the kernel loves a symlink for /sbin/init, haven't looked at that... +1 for wrapper, from my understanding, symlinks for init-systems can't be altered on a running system without risking strange behaviour. eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots When we kick off the right init system at boot, we probably don't need to keep track of it separately; or at least not call eselect for that. Sounds like we would have two files like 'current_init' and 'boot_init' and `eselect init ...` would update 'boot_init'. Then, the first `init` invocation on boot would update 'current_init' with the value of boot_init; latter `init` invocations can then read out 'current_init', which is not to be touched by `eselect init ...`. With a case-statement in the wrapper script to handle the different init-systems? How will the stop/start part of services/init-scripts/... be done? I am assuming that should be for the user to keep in mind, but will it be possible to add something that will make init.d-scripts not work when systemd is running and unit-files not work when systemd is not running? From what I understand, the tools for the different init-systems will end up being installed simultaneously. hooks on reboot are still needed for more complex ones. Which complex cases would these hooks be needed on? I think one of these would be the stopping/starting of services (see above) - 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) The /sbin/einit approach that I linked near the start would help here. # 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. My system with stock openrc gets from linux start to graphical login in less than 6s and I'm not using Gnome so I do not have any reason to use it beside comparing. Can we please keep information that may provoke a comparison off the ML? I'll give a neutral objective response why the init system doesn't matter for this, as I'm tired of seeing people sneak in data points like this. In your case it's intended to be good, but it can catch other people off guard that don't care to stay on topic. [[ Please avoid responding to this part of my mail, don't go OT. ]] SNIPPED part about boot times I agree with the general statement here. [[ Below is my ONLY remark on that, please feel free to mentally paste it as a response any email trying to explain why it's important to reduce the boottime ]] Boot times can be optimized for most init-systems. On most of my machines, I really don't care if the boot time is 2 seconds or 2 minutes. They get started once and then they stay on till they are not needed
Re: [gentoo-dev] eselect init
Sergei Trofimovich schrieb: I guess EFI allows you to set bootargs via EFI UI. If you have an EFI shell, then you can pass additional kernel command line parameters via that. Passing parameters via the UI is not possible with any of the UEFI systems that I have come across. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: I was thinking of a default option in the eselect init part that would remove init=/sbin/einit from the kernel boot parameters. With the different boot loaders, it's not easy to do this consistently everywhere; lilo != grub != grub2 != .config with EFI. While you can support all syntaxes around there, you also need to take into account that there are multiple entries and not all entries relate to Gentoo. Or in the EFI use case the user may have an entry that explicitly has a different init value or no init value at all. It's also not only about removing init= but also about adding it again. I probably forget crucial details, but you can guess the complexity this brings. Not sure how that would be best achieved as a lot (most?) users will have more then one boot-option in their grub(2)/lilo config. Seems I skipped this paragraph, I've expanded the thoughts behind this above for more completeness; I don't think this should be achieved. I don't have init= set on my machines and it seems to start /sbin/init. So that should be correct. Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that. +1 for wrapper, from my understanding, symlinks for init-systems can't be altered on a running system without risking strange behaviour. Exactly... # shutdown -h now The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41 2013): Excess arguments. eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots When we kick off the right init system at boot, [SNIP] With a case-statement in the wrapper script to handle the different init-systems? I think so. How will the stop/start part of services/init-scripts/... be done? Not sure what you mean here; if you keep init function the same as the init you boot with, this should continue to work. I am assuming that should be for the user to keep in mind, but will it be possible to add something that will make init.d-scripts not work when systemd is running and unit-files not work when systemd is not running? They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else From what I understand, the tools for the different init-systems will end up being installed simultaneously. Correct, I don't think it makes sense to switch between things that aren't installed; eselect historically only lists options that are installed, and I think it should be kept this way. hooks on reboot are still needed for more complex ones. Which complex cases would these hooks be needed on? I think one of these would be the stopping/starting of services (see above) No, if you keep the init system the same as the one you boot with there should be no problems. [[ Below is my ONLY remark on that, please feel free to mentally paste it as a response any email trying to explain why it's important to reduce the boottime ]] My intention was not to advocate optimizing boot times; as a kernel maintainer / developer I need to test new releases, run git bisects, do Nouveau reclocking work. I really need this, the average person that keeps his PC running, not so much; I care for it because I can't wait 2 minutes, not because I think it's shiny to have such a short boot... PS: I'm also a mobile laptop user that no longer has a battery. :/ -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 25/05/13 03:55 PM, Tom Wijsman wrote:
I don't have init= set on my machines and it seems to
start /sbin/init. So that should be correct.
Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c?id=v3.9#n820
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
if (!run_init_process(execute_command))
return 0;
printk(KERN_WARNING Failed to execute %s. Attempting
defaults...\n, execute_command);
}
if (!run_init_process(/sbin/init) ||
!run_init_process(/etc/init) ||
!run_init_process(/bin/init) ||
!run_init_process(/bin/sh))
return 0;
panic(No init found. Try passing init= option to kernel.
See Linux Documentation/init.txt for guidance.);
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 16:07:51 -0400 Alex Xu alex_y...@yahoo.ca wrote: On 25/05/13 03:55 PM, Tom Wijsman wrote: I don't have init= set on my machines and it seems to start /sbin/init. So that should be correct. Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c?id=v3.9#n820 One quote level further I said correct as far as I recall from patching that part of boot in the past.; though, the above command I gave is more reliable than looking into main.c. While /sbin/init is listed first there that doesn't guarantee that it's effectively in use, though we know by now that it is. Anyhow, thanks for sharing context! :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote On Sat, 25 May 2013 12:25:03 +0200 Peter Stuge pe...@stuge.se wrote: I would actually expect the change to take effect immediately. Then how would you be able to shutdown / reboot your system in a clean way? The premise here is that when you boot with an init system you must shutdown with that same init system, you can't just start one init system and expect the other init system to cleanly shut down its services. Therefore implementing this would either be unclean or way to complex. From all the methods discussed doing it on boot sounds the most sane. It has to be done *VERY* early at boot, or else we're back to the problem you described above. It's almost like a brain surgeon operating on himself. Here are a couple of outside the box ideas that haven't been mentioned yet... 1) boot into single mode before doing the changeover. Both grub and lilo support single mode boot as per... http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode 2) have the setup/switchover mechanism built into the Gentoo minimal install ISO. The advantage here is that if the system ends up no longer bootable off the harddrive, you can still boot from the ISO, chroot into the system on the harddrive, and send emails to the gentoo-user list asking for help G. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] eselect init
Tom Wijsman wrote: I would actually expect the change to take effect immediately. Then how would you be able to shutdown / reboot your system in a clean way? The premise here is that when you boot with an init system you must shutdown with that same init system, you can't just start one init system and expect the other init system to cleanly shut down its services. Taking effect immediately of course does not mean that if I booted using systemd and switched to openrc that systemd will be killed. That idea makes absolutely no sense, it simply can not work. In theory systemd could support execl() sysvinit and vice versa, but I find that unlikely. The take effect immediately I believe that you understood me to mean is simply impossible. By take effect I mean that the filesystem should be modified in such a way that the next boot will use what I selected. No further action which could fail should be required beyond the eselect command. Unless the eselect command has successfully modified the filesystem I can't really know that my system will boot with what I have selected, ie. eselect does not provide any useful feedback, because it can not. //Peter pgpQcM2CAGwb2.pgp Description: PGP signature
