Hi, I'd like to request some kind of soft-dependency for init scripts. Lemme give you some kind of example what I want to have it for: I'm using kde with kdm as login manager and kde needs dbus to work correctly (at least when starting kde. Later it works fine without dbus). On some of my systems kde is the only application needing dbus. Of course I could add rc_need="dbus" to my /etc/conf.d/xdm file but this would mean each time I stop/restart dbus my X-server would be killed as openrc woud stop/restart xdm as well. So I'd like to have some way to make openrc start dbus if available when I start xdm but not stop/restart xdm when I stop/restart dbus.
Per discussion in bug 390609, "use dbus" was added to the xdm init script. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4_sect3 Is there some case which is not covered by this yet?
rc_use="dbus" (the same as "use dbus" in the init script) does not start dbus when xdm gets started. I've tested this on all my ~arch systems and it didn't work on even one of them. So either rc_use needs fixing or we need a new soft-dependency as in my initial request.
Which runlevel are dbus and xdm added to?
dbus is not added to the runlevel because I only want it to be started when xdm gets started (kdm/kde is the only software on my system that needs dbus). xdm is in runlevel 5 but I usually boot my system into runlevel 3 and start xdm manually later. But it doesn't matter if I boot into runlevel 5 or start xdm manually. dbus doesn't get started in both cases.
(In reply to comment #4) > dbus is not added to the runlevel because I only want it to be started when xdm > gets started (kdm/kde is the only software on my system that needs dbus). xdm > is in runlevel 5 but I usually boot my system into runlevel 3 and start xdm > manually later. Have you tried adding dbus to runlevel 5 along with xdm? It sounds like that might do what you want.
Since you have a separate runlevel for xdm, I recommend that you add dbus to that runlevel as well. Once that is done, you can use the rc command to switch in and out of that runlevel, as follows: Suppose you call the new runlevel directory "gui". # rc gui would switch you to the gui, then # rc default would bring you back to the default runlevel. That should cover what you are requesting. Let me know what you think and if it works.
Alright, lemme rephrase this... This is not about runlevels here. Please keep in mind that there are services people avoid adding to runlevels for a reason. What I tried to request for the whole time now is some kind of dependency that can start other services _without_ hard-depending on them. With hard-depending I mean a service getting stopped that forces other services to stop when they depend on it. Or in other words... a dependency that starts a service if the service is available but has no other influence.
Ok, after re-thinking about it... Why do we have "use" and what shall it do and what does it do? "use" should IMHO start a services regardless of any runlevel but it shouldn't care that much if the dependency has been stopped as it "just uses" it but it doesn't need it. While "need" really needs it and thus the dependency will be stopped/restarted as well. This is somewhat tricky right now and I don't know if we should consider changing the "use" behaviour or adding a new keyword for it...
(In reply to comment #7) > Alright, lemme rephrase this... > > This is not about runlevels here. Please keep in mind that there are > services people avoid adding to runlevels for a reason. > > What I tried to request for the whole time now is some kind of dependency > that can start other services _without_ hard-depending on them. > With hard-depending I mean a service getting stopped that forces other > services to stop when they depend on it. > > Or in other words... a dependency that starts a service if the service is > available but has no other influence. The key phrase here is a dependency that starts a service "if the service is available". IMO "available" should have another meaning besides installed in the init.d directory. The use dependency comes closest to this because it starts a service if it is in the same runlevel. That's why I think the best fix for this is to make a custom runlevel.
(In reply to comment #9) > (In reply to comment #7) > > Alright, lemme rephrase this... > > > > This is not about runlevels here. Please keep in mind that there are > > services people avoid adding to runlevels for a reason. > > > > What I tried to request for the whole time now is some kind of dependency > > that can start other services _without_ hard-depending on them. > > With hard-depending I mean a service getting stopped that forces other > > services to stop when they depend on it. > > > > Or in other words... a dependency that starts a service if the service is > > available but has no other influence. > > The key phrase here is a dependency that starts a service "if the service is > available". > > IMO "available" should have another meaning besides installed in the init.d > directory. The use dependency comes closest to this because it starts a > service if it is in the same runlevel. > > That's why I think the best fix for this is to make a custom runlevel. No, this is exactly what available means. A service is available when it has a valid runscript in the init.d directory - at least from a rc-script's POV. On a sidenote: at least up to the openrc-0.8.x releases this was exactly the way rc_use used to work. I really have no idea why that was changed meanwhile.
(In reply to comment #10) > No, this is exactly what available means. A service is available when it has > a valid runscript in the init.d directory - at least from a rc-script's POV. > > On a sidenote: at least up to the openrc-0.8.x releases this was exactly the > way rc_use used to work. I really have no idea why that was changed > meanwhile. If this is the case, we should be able to go through the history and find where it was changed and possibly why.
Hi Roy, I would like to ask you a question about this bug. The issue is that if service bar has "use foo", we require that foo and bar be added to the same runlevel. The request in this bug is that we drop the runlevel requirement so that use will attempt to start the used service if it isn't started regardless of runlevel. Can you advise me how to change this? Thanks, William
(In reply to comment #11) > (In reply to comment #10) > > No, this is exactly what available means. A service is available when it has > > a valid runscript in the init.d directory - at least from a rc-script's POV. > > > > On a sidenote: at least up to the openrc-0.8.x releases this was exactly the > > way rc_use used to work. I really have no idea why that was changed > > meanwhile. > > If this is the case, we should be able to go through the history and find > where it was changed and possibly why. Thinking about this more, there is definitely another issue involved. Remember that we can use virtuals, so if you have something like: use logger where logger is a virtual provided by multiple services that happen to be installed, what should we do?
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > No, this is exactly what available means. A service is available when it has > > > a valid runscript in the init.d directory - at least from a rc-script's POV. > > > > > > On a sidenote: at least up to the openrc-0.8.x releases this was exactly the > > > way rc_use used to work. I really have no idea why that was changed > > > meanwhile. > > > > If this is the case, we should be able to go through the history and find > > where it was changed and possibly why. > > Thinking about this more, there is definitely another issue involved. > Remember that we can use virtuals, so if you have something like: > > use logger > > where logger is a virtual provided by multiple services that happen to be > installed, what should we do? Looking into this further, need uses the first provider it finds regardless of runlevel, so I think it is reasonable for use to do the same.
(In reply to comment #12) > The issue is that if service bar has "use foo", we require that foo and > bar be added to the same runlevel. The request in this bug is that we > drop the runlevel requirement so that use will attempt to start the used > service if it isn't started regardless of runlevel. I disagree as "need foo" makes it work regardless of runlevel, which is the required outcome. The problem is that he only wants "need foo" to apply when starting bar and not when stopping it. OpenRC was never designed to support that (neither was baselayout fwiw). So I suggest a new keyword is introduced so he can "need_start foo" in bar.
(In reply to comment #14) > > Thinking about this more, there is definitely another issue involved. > > Remember that we can use virtuals, so if you have something like: > > > > use logger > > > > where logger is a virtual provided by multiple services that happen to be > > installed, what should we do? > > Looking into this further, need uses the first provider it finds regardless > of runlevel, so I think it is reasonable for use to do the same. Incorrect. Need uses the first provider in the runlevel. If no match, any provider currently running. If no match, first provider found in lexical order. Infact, all the keyword matching should use the above logic.
(In reply to comment #16) > Incorrect. > > Need uses the first provider in the runlevel. > If no match, any provider currently running. > If no match, first provider found in lexical order. > > Infact, all the keyword matching should use the above logic. It seems that use only concerns itself with services in the runlevel. I just set up the following on my box: service w and service x both provide y. service z has the following in depend: use w y Starting z manually starts neither w nor x. Adding z to the default runlevel then running "rc default" starts neither w nor x. I'm thinking that w should have been started since it provides y in both cases. Correct?
@polynomial-c: If the use keyword should consider services that are not in the runlevel, I believe that fixing it will fix the issue raised by this bug. Correct?
(In reply to comment #18) > @polynomial-c: > If the use keyword should consider services that are not in the > runlevel, I believe that fixing it will fix the issue raised by this > bug. Correct? Yes, I think this would fix my current issue.
(In reply to comment #18) > @polynomial-c: > If the use keyword should consider services that are not in the > runlevel, I believe that fixing it will fix the issue raised by this > bug. Correct? If you do this, please then explain the difference between need and use keywords?
(In reply to comment #20) > (In reply to comment #18) > > @polynomial-c: > > If the use keyword should consider services that are not in the > > runlevel, I believe that fixing it will fix the issue raised by this > > bug. Correct? > > If you do this, please then explain the difference between need and use > keywords? Thinking about it, modifying use may not be the way to do this. In your email to me, you pointed out that use is working as designed. I agree. The reporter wants a way to have dbus start when he starts xdm manually, but not stop xdm when he stops dbus. Neither service is in any runlevel. So, the closest dependency is need, but the rools are different for it. If foo needs bar, then stopping bar stops foo, and that's how it should be.
Exactly. That's why I proposed the need_start keyword.
There is a bug in proceedings of this bug. For ages I have runlevels/default/xdm which has "use consolekit" but without any consolekit in any runlevels but this starts consolekit. This is not possible with dbus because of my runlevels/boot/dbus I suspect Lars Wendler having a hidden dbus in some runlevels/his_special_runlevel perhaps as a soft dependency of net: after net.lo net.lo0 dbus
Any progress here? I am still interested in getting this solved. Right now I have the following in my /etc/conf.d/xdm file: rc_after="alsasound dbus ntpd pure-ftpd rsyncd sshd" rc_use="dbus" I'd love to help out testing this if someone implements it.
(In reply to comment #24) > Any progress here? > > I am still interested in getting this solved. Not yet, but patches are always welcome. :-) If you come up with something feel free to attach it to this bug and we'll take a look.
This is an edited transcript from #gentoo-dev 2015/02/01, where a good usage case for this came up with netmount/nfsmount issue of bug 537996. 16:36 <@_robbat2|irssi> 1. introduce a dependency type that says try hard, but we wouldn't block on you failing 16:37 <@WilliamH> _robbat2|irssi: use? 16:37 <@Zero_Chaos> WilliamH: I'm amenable to either of _robbat2|irssi's suggestions. 16:37 <@Zero_Chaos> WilliamH: maybe "want"? 16:37 <@WilliamH> _robbat2|irssi: but that also means that we would have to depend on all distros to name the scripts the same. 16:38 <@_robbat2|irssi> WilliamH: let's call it "want" for the moment 16:39 <@_robbat2|irssi> if we have "want"; in conf.d/nfsclient, you can put this: rc_netmount_want=nfsclient 16:40 <@_robbat2|irssi> if another distro has a different name for it, they can specify it there 16:40 <@_robbat2|irssi> more importantly, any other network-fs that has wants some weird dependency 16:40 <@_robbat2|irssi> can do the same 16:40 <@Zero_Chaos> _robbat2|irssi: harder to detect if we actually need it if it's in a conf file, plus, that's more work for users. 16:40 <@WilliamH> _robbat2|irssi: I'm a bit confused about this dependency type though... want vs use... 16:41 <@Zero_Chaos> WilliamH: english words, "need" means I have to have it, "want" means it would be nice 16:41 <@WilliamH> _robbat2|irssi: use means "start this before we start, if it is in the runlevel with us". 16:41 <@Zero_Chaos> WilliamH: we already have use? 16:41 <@WilliamH> Zero_Chaos: yes 16:42 <@Zero_Chaos> WilliamH: what is the downside to using a patch similar to mine with use instead of need then? 16:42 <@_robbat2|irssi> i'd like want to be "start this before we start, regardless of the runlevel; but don't let failure block me" 16:42 <@_robbat2|irssi> this has an implication: 16:42 <@WilliamH> Zero_Chaos: you can do: rc_use="nfsclient" in /etc/conf.d/net, without the patch. 16:43 <@Zero_Chaos> WilliamH: oh, use needs it to be in the same runlevel already, that doesn't make sense 16:43 <@_robbat2|irssi> any init script using "want" needs to be prepared to handle the dependency being failed 16:43 <@Zero_Chaos> _robbat2|irssi: I think I agree with you 16:43 <@_robbat2|irssi> "need" propogates failure, handling the blocking state for you 16:43 <@_robbat2|irssi> "want" says you're willign to handle it yourself 16:44 <@Zero_Chaos> WilliamH: if "use" requires the init script to be in the same run level that won't work for what I want here. I think that a concept of "want" which means "try hard but failure is okay" would be a great addition to openrc 16:44 <@Zero_Chaos> WilliamH: I can even rewrite the my patch to properly handle failures if you agree to add "want" to openrc 16:45 <@_robbat2|irssi> "want" also means we should have a consistent way to tell the script using it that the dependency failed 16:45 <@Zero_Chaos> _robbat2|irssi: yeah, that would be nice 16:45 <@WilliamH> _robbat2|irssi: I don't see how that could happen with the dependency structure we have. 16:45 <@WilliamH> depend() { 16:45 <@WilliamH> want foo 16:45 <@WilliamH> } 16:46 <@WilliamH> We don't even have a way to know whether foo started if "use foo" is used. 6:47 <@_robbat2|irssi> openrc knows, in it's state if a service is started, why not just add a function to query that? 16:47 <@_robbat2|irssi> depend() { want foo } start() { if rc_started foo; ...; else ... ; fi 16:47 <@_robbat2|irssi> s/$/}/ 16:47 <@WilliamH> Actually there is one... 16:48 <@WilliamH> but again that depends on everyone using the same name for the service... 16:48 <@_robbat2|irssi> that's their configurability problem 16:49 <@_robbat2|irssi> is debian going to use our netmount script as-is in their system? probably not 16:49 <@WilliamH> In netmount, I really don't feel comfortable querrying for services that distros control... because I have no idea what they will call them. 16:50 <@WilliamH> That's also true in localmount. 16:50 <@_robbat2|irssi> WilliamH: at a conceptual level, do you agree that "want" would solve this problem? 16:50 <@_robbat2|irssi> besides the service-naming cross-distro concern, which is going to happen with services regardless 16:51 <@Zero_Chaos> _robbat2|irssi: he (up until now anyway) has held that "openrc has no deps and adding deps is wrong" 16:51 <@Zero_Chaos> _robbat2|irssi: so that solves his cross distro problem in his mind. 16:51 <@WilliamH> I can agree that a dependency like "want" would be useful; actually there is a bug like that. 16:51 <@WilliamH> I just haven't figured out that part of the code wrt how to ade it. 16:52 <@WilliamH> add * 16:52 <@WilliamH> bug 406021 maybe? 16:52 <+willikins> WilliamH: https://bugs.gentoo.org/406021 "sys-apps/openrc - Please implement some kind of soft-dependency for init scripts"; Gentoo Hosted Projects, OpenRC; CONF; polynomial-c:openrc 16:53 <@WilliamH> I just haven't gotten into that part of the code. 16:53 <@WilliamH> yet 16:53 <@WilliamH> There hasn't been an attempt by me to block this it just hasn't happened. 16:54 <@WilliamH> So for now I think my solution on bug 537996 is the best we can do. 16:54 <+willikins> WilliamH: https://bugs.gentoo.org/537996 ">=sys-apps/openrc-0.13 netmount script cannot properly mount nfs shares"; Gentoo Hosted Projects, OpenRC; CONF; zerochaos:qa
https://github.com/openrc/openrc/commit/33d3f33 This will be in OpenRC-0.19. Thanks, Ian, for your work on this.
