Currently, running OpenRC init.d scripts when OpenRC is not used results in random behaviour -- including actually starting services. This is a severe issue when systemd (or any other rc alternative) is used and udev rules installed with services run OpenRC scripts. Thus, OpenRC shall ensure it is used before allowing to run any service. Or at least it should ensure sysvinit is used.
What do you propose to check for at runtime then?
(In reply to comment #1) > What do you propose to check for at runtime then? That's up to you. AFAIR openrc mounted /lib/rc/init.d or something like that as tmpfs. That might be a good location for openrc to set up some kind of 'openrc is here' file, or any other state information.
Openrc is not meant to require you to use sysvinit or any specific init system, so I don't want to force that. It is hooked into sysvinit through inittab, so you would want to do something similar with systemd, however I can't tell you how since I'm not familiar with systemd.
(In reply to comment #3) > It is hooked into sysvinit through inittab, so you would want to do > something similar with systemd, however I can't tell you how since I'm > not familiar with systemd. It is also hooked into a few udev scripts, which is the problem. systemd replaces sysvinit completely, and systemd users tend to like to have systemd controlling things like bluetooth. However, with current udev rules openrc bluetooth scripts are started as well. My point is that OpenRC should check if it has been initialized properly before running any script. And it has to do some specific inits during the boot (like marking all services 'stopped'), I guess it's a good place to hook in some checks.
(In reply to comment #4) > (In reply to comment #3) > > It is hooked into sysvinit through inittab, so you would want to do > > something similar with systemd, however I can't tell you how since I'm > > not familiar with systemd. > It is also hooked into a few udev scripts, which is the problem. > systemd replaces sysvinit completely, and systemd users tend to like to have > systemd controlling things like bluetooth. However, with current udev rules > openrc bluetooth scripts are started as well. After a brief look, it looks like the bluez package is installing udev rules that force this behaviour, not openrc. The bug here is that the bluez package installs udev rules which assume you are running openrc. I think this should be fixed in the bluez package. If other packages are doing this, I think they should be fixed as well. I'm not sure there is anything for us to do in openrc.
It looks to me as though net-wireless/bluez installs udev rules which run openrc services. As you can see from the comments in this bug, that causes issues for people who are using systemd for example. I think there should be a way for users to opt out of those udev rules. Thanks, William
Is using a "systemd" USE flag for not installing that udev rules "allowed" in the tree?
I was thinking of a use flag, but I was thinking more like an "openrc" use flag, which would be on by default, so you would have: IUSE="... +openrc ..." And you wouldn't install the rules if the user turns off that flag.
I still think some kind of runtime check would be better. Users shouldn't be forced to remove OpenRC support when running systemd. OpenRC and systemd can easily co-exist and user is free to switch between one and the another at any point in time.
Ah, and I still think OpenRC/runscript is the best place to do it. Otherwise, we allow random behaviour to happen when scripts are run without actually using OpenRC. For example, last boot I started hostname. This boot OpenRC assumes it's already started because noone has cleaned the statedir. I think OpenRC should simply refuse to start the service in such a case.
(In reply to comment #9) > I still think some kind of runtime check would be better. Users shouldn't be > forced to remove OpenRC support when running systemd. OpenRC and systemd can > easily co-exist and user is free to switch between one and the another at any > point in time. I guess the user does this by using init= on the kernel command line right? (In reply to comment #10) > Ah, and I still think OpenRC/runscript is the best place to do it. Otherwise, > we allow random behaviour to happen when scripts are run without actually using > OpenRC. > For example, last boot I started hostname. This boot OpenRC assumes it's > already started because noone has cleaned the statedir. I think OpenRC should > simply refuse to start the service in such a case. Ok, this bug actually has two pieces to it: 1) Packages automatically installing udev rules which assume that openrc is being used. I think this should not be happening, but I'm not sure of another way to fix this besides a use flag. That means that switching between systemd and sysv/openrc would consist of setting the "openrc" use flag correctly, running "emerge --newuse world" and rebooting with the proper init= command line switch. 2) a possible error message if you try to run an openrc service when openrc was not used to boot the system. This would be very low priority for me, since I am not in a position where I could test it. I think the best approach for this for now would be to just make sure that packages are not force installing udev rules which run openrc services. I'll bring this up on the dev list soon to see if we should do this in the main tree or not.
1) is irrelevant here, as is the systemd overlay. I'm working on systemd independently of the old approach used in that overlay, and the point is to support it without turning everything in Gentoo upside down. Introducing unnecessary USEflags is annoying to users. Especially if they require complete package rebuild just to install/remove a single file. Thus, we're back at the original request which matches 2). I myself have an ability to test it, so I'll provide a patch soon.
Created attachment 270657 [details, diff] Conceptual patch How about this? It uses the softlevel file for the check. I've tested it with sysvinit+openrc & systemd. In the first case, it works just fine; in the second, it refuses to run scripts as expected.
(In reply to comment #13) > Created attachment 270657 [details, diff] > Conceptual patch > How about this? It uses the softlevel file for the check. I've tested it with > sysvinit+openrc & systemd. In the first case, it works just fine; in the > second, it refuses to run scripts as expected. The other test case is prefix systems. In that environment, it is possible to want to run some services without using openrc to boot the system, since a prefix system isn't actually booted. I don't know for certain, but I think if I apply this, it will break for prefix users. I would need to find some way to check this out.
Created attachment 270823 [details] warn-not-boot.patch Hi Mgorny, What happens if you drop your patch but put this one in its place? Due to a suggestion on the dev list, it just warns you but allows things to continue. Let me know what you think.
(In reply to comment #15) > What happens if you drop your patch but put this one in its place? > > Due to a suggestion on the dev list, it just warns you but allows things > to continue. > > Let me know what you think. This patch is useful only in interactive mode. udev-engaged services will still start anyway, and user wouldn't probably even notice the warning anywhere. How about separating some kind of 'init RC_SVCDIR' script, which would mount it, 'stop' all services and set softlevel to anything (maybe something like 'manual' or so) and quitting with notice that user could run that to enable OpenRC services.
we already have an `rc-service` program, but i dont think making that a gate keeper is necessary. adding a "softlevel" check is probably fine, as long as we also add -f/--force options to let people bypass it. thus most people "just work" and in the cases of odd setups (like prefix), they can --force things.
(In reply to comment #17) > adding a "softlevel" check is probably fine, as long as we also add -f/--force > options to let people bypass it. thus most people "just work" and in the cases > of odd setups (like prefix), they can --force things. --force won't apply to scripts launched by udev rules. How about just saying 'echo foobar > ${RC_SVCDIR}/softlevel'? This should have a similar effect to the current behaviour.
Created attachment 272575 [details, diff] Fail but inform about the workaround
(In reply to comment #19) > Created attachment 272575 [details, diff] > Fail but inform about the workaround How about this one? It is alike my first one but says how to force the old behaviour.
commit 40341fc applies a patch for this issue. This will be included in openrc-0.8.3.
