Currently, the local service in openrc uses functions which are defined in /etc/conf.d/local to define the commands to run when local is stopped and started. Robin suggested to me that we might want to change this so that it runs scripts, similar to the way /etc/profile works. His suggestion was that when local starts we run scripts in @SYSCONFDIR@/localstart.d and when it stops we run scripts in @SYSCONFDIR@/localstop.d. I agree that this is a good approach for this. The advantage being that commands that run for the local service would be in files that are not owned by the package, so a user doesn't have to worry about them being overwritten. I am working on a change which will make /etc/init.d/local behave like /etc/profile, e.g. when the local service is started, it will run @SYSCONFDIR@/localstart.d/*.sh, and when it is stopped it will run @SYSCONFDIR@/localstop.d/*.sh. Also, this change will warn users that they need to migrate their /etc/conf.d/local files. Also, once that patch is in, we will need to modify the openrc ebuilds to migrate from baselayout 1 correctly.
i dont think this is something we want to cut out immediately. it isnt that hard to support the old style.
(In reply to comment #1) > i dont think this is something we want to cut out immediately. it isnt that > hard to support the old style. I'm not planning on making /etc/init.d/local not support the old style at this point, I just want to print messages that tell the users that they should migrate to the new style. I just meant that we might want to change the ebuilds so that they migrate to the new style for people migrating from baselayout-1.
Created attachment 260204 [details, diff] 0001-change-local-to-use-scripts.patch All, this is my proposed patch for this feature. Questions, comments, criticisms, etc are welcome. If I receive no comments by 15:00 utc tomorrow, I will commit this change.
Just a thought that I thought deserved a good, proper ignoring: How about instead of /etc/localstart.d and /etc/localstop.d, there's just /etc/local.d, which would contain scripts that define start() and stop() functions. This would have several benefits: 1. Less error-prone because configuration variables can be shared (I won't change my PIDDIR variable in the start script but forget to make the corresponding change in the stop script). 2. Minimize the chance of dependency interactions by having the stop functions be run in reverse order. If I put in A and B scripts, but B really depends on A, it would be nice if at stop time, B got stopped first. I'm not suggesting anything as robust as what rc provides, just a bare minimal predictable and sensible ordering. 3. It's simply better organized to keep the starts and stop together.
Comment on attachment 260204 [details, diff] 0001-change-local-to-use-scripts.patch "please" should be "Please" seems like "00example" should be "README" since it isnt an actual example. the word "any" in it should be "Any". the "a .sh" should be "an .sh" i think since people sound out "extension" (which is spelled incorrectly in your file). your sys.mk puts a useless space before the ${SYSCONFDIR}. same for the new Makefile's ...
i do like the suggestion of being able to keep start/stop code together in one file. in either case, i think the files should be living in /etc/conf.d/xxx/ subdir rather than /etc/xxx/.
(In reply to comment #4) > Just a thought that I thought deserved a good, proper ignoring: > How about instead of /etc/localstart.d and /etc/localstop.d, there's just > /etc/local.d, which would contain scripts that define start() and stop() > functions. This would have several benefits: > 1. Less error-prone because configuration variables can be shared (I won't > change my PIDDIR variable in the start script but forget to make the > corresponding change in the stop script). > 2. Minimize the chance of dependency interactions by having the stop functions > be run in reverse order. If I put in A and B scripts, but B really depends on > A, it would be nice if at stop time, B got stopped first. I'm not suggesting > anything as robust as what rc provides, just a bare minimal predictable and > sensible ordering. > 3. It's simply better organized to keep the starts and stop together. My next patch proposes a /etc/local.d directory which will contain script fragments named *start.sh to run when local starts and *stop.sh to run when local stops. If a depends on b, you can name start scripts 01bstart.sh and 02astart.sh; stop scripts would be named in reverse order e.g. 01astop.sh and 02bstop.sh. This is meant to work like /etc/profile.d, so I'm not sure that we want to define start() and stop() functions and have one script fragment per service. (In reply to comment #5) > (From update of attachment 260204 [details, diff]) > "please" should be "Please" > seems like "00example" should be "README" since it isnt an actual example. the > word "any" in it should be "Any". the "a .sh" should be "an .sh" i think since > people sound out "extension" (which is spelled incorrectly in your file). > your sys.mk puts a useless space before the ${SYSCONFDIR}. same for the new > Makefile's ... Ok, I believe my next patch, which I will post shortly, will have all of these fixed. (In reply to comment #6) > i do like the suggestion of being able to keep start/stop code together in one > file. in either case, i think the files should be living in /etc/conf.d/xxx/ > subdir rather than /etc/xxx/. My reason for putting local.d in @sysconfdir@ is that we have profile.d there, and the contents of local.d and profile.d are both script fragments. I'm curious about why you think it would fit better somewhere under @sysconfdir@/conf.d?
Created attachment 260216 [details, diff] 0001-change-local-to-use-script-fragments.patch Here is the updated version of my proposed feature. Let me know what you think, again, before 15:00 UTC tomorrow if possible.
Created attachment 260224 [details, diff] 0001-change-local-to-use-script-fragments.patch All, I had a discussion with robbat2 wrt this patch and he pointed out some inconsistencies. This is the current version. I'll commit this around 1800 UTC today if I do not receive any more comments.
i dont think the fact it operates like profile.d is justification for putting it into /etc/. /etc/profile.d/ is meant for login scripts to run. this new local.d is meant for boot scripts to run. all the boot scripts have been living in /etc/init.d/ and /etc/conf.d/. along those lines, i think /etc/conf.d/local/ makes more sense -- it's user config files that get run during boot.
1. Can we make it a full exec rather than a sourcing? With the sourcing, all it takes is a 'exit $N' or a 'exec' line, and suddenly the rest of the scripts don't run. This also allows the file to be something OTHER than shell scripts (compiled binaries, perl scripts, symlinks etc). 2. We most certainly cannot make it /etc/conf.d/local/ trivially, because gendepends expects a matching entry to every init.d to be a file, NOT a directory. # mv /etc/conf.d/local{,.tmp} # /etc/init.d/local zap start local | * Caching service dependencies ... /lib64/rc/sh/gendepends.sh: line 79: .: /etc/init.d/../conf.d/local: is a directory [ ok ] local |/lib64/rc/sh/runscript.sh: line 13: .: /etc/init.d/../conf.d/local: is a directory local | * local: error loading /etc/init.d/../conf.d/local local | * ERROR: local failed to start
For reference, here is what I use for the infra stuff that I filed this request because of: start: /bin/run-parts /etc/localstart.d/ stop: /bin/run-parts --reverse /etc/localstop.d/
(In reply to comment #11) > 1. Can we make it a full exec rather than a sourcing? With the sourcing, all it > takes is a 'exit $N' or a 'exec' line, and suddenly the rest of the scripts > don't run. This also allows the file to be something OTHER than shell scripts > (compiled binaries, perl scripts, symlinks etc). Yes, I will rework the code to do this. > 2. We most certainly cannot make it /etc/conf.d/local/ trivially, because > gendepends expects a matching entry to every init.d to be a file, NOT a > directory. > # mv /etc/conf.d/local{,.tmp} > # /etc/init.d/local zap start > local | * Caching service dependencies ... > /lib64/rc/sh/gendepends.sh: line 79: .: /etc/init.d/../conf.d/local: is a > directory [ ok ] > local |/lib64/rc/sh/runscript.sh: line 13: .: > /etc/init.d/../conf.d/local: is a directory > local | * local: error loading /etc/init.d/../conf.d/local > local | * ERROR: local failed to start This is more reason for keeping this in @sysconfdir@/local.d instead of moving it to @sysconfdir@/conf.d/local.
Created attachment 260281 [details, diff] 0001-change-local-to-run-programs.patch All, here is my latest proposed patch for this feature. This version exec's programs in @sysconfdir@/local.d instead of just sourcing them. This means that they can be binaries, scripts, or anything you prefer. Also, I changed the ebegin..eend pairs to just an einfo call since there is really no way for the local service itself to fail to start or stop. I want to commit this 24 hours from now (around 18:00 utc tomorrow) if there are no criticisms/suggestions.
Another two cents: I hate the layout as described in comment #7. It puts the starts and stops in one directory, but they won't even be adjacent to each other unless the user has only one such pair or doesn't do a proper (for some definition of "proper") ordering during the stop phase. It's just ugly, and feels like old-school init scripts.
(In reply to comment #15) > Another two cents: I hate the layout as described in comment #7. It puts the > starts and stops in one directory, but they won't even be adjacent to each > other unless the user has only one such pair or doesn't do a proper (for some > definition of "proper") ordering during the stop phase. > > It's just ugly, and feels like old-school init scripts. What other name variants can you suggest then?
(In reply to comment #15) > Another two cents: I hate the layout as described in comment #7. It puts the > starts and stops in one directory, but they won't even be adjacent to each > other unless the user has only one such pair or doesn't do a proper (for some > definition of "proper") ordering during the stop phase. This is the trade off when all of the start/stop programs are stored in the same directory; it forces us to adopt a strict naming convention so that we know which programs should be run when local is started vs which ones should run when local is stopped. What naming convention would you prefer?
I don't really think it's a matter of naming convention. If they're not in the same file, none of the benefits of my proposal in comment #4 are preserved (well, number 3 is arguable, but I think the sloppiness of the ordering negates any organization benefit derived from being in the same directory). IMHO, if my proposal is out, I'd prefer your original implementation as in comment #3 over the later one (i.e. the patch in comment #14 as described in comment #7).
(In reply to comment #18) > I don't really think it's a matter of naming convention. If they're not in the > same file, none of the benefits of my proposal in comment #4 are preserved > (well, number 3 is arguable, but I think the sloppiness of the ordering negates > any organization benefit derived from being in the same directory). IMHO, if my > proposal is out, I'd prefer your original implementation as in comment #3 over > the later one (i.e. the patch in comment #14 as described in comment #7). They could only be in the same file if we required the file to be sourcable, and sourced it. In my existing infra deployment, I have some compiled binaries (doing IOCTLs) in the localstart.d directory, which are clearly not sourcable, so you have to rely on file or directory naming for them.
Provide a skeleton that includes at the top something like: if [ "$1" -eq "stop" ]; then # Put your stop action here if one is required. exit fi Then, during stop phase, call run-parts like: /bin/run-parts --reverse --arg=stop /etc/local.d/ This adds a little bit of boilerplate, but preserves exec-ability as well as the other benefits I mentioned. If you guys don't like this (which I could understand), then my vote would be for williamh's original layout, in which case sorry for all this noise. :P
All, I would like to make one small change if there are no objections. Currently, the names of the programs in @sysconfdir@/local.d must end in "start" or "stop". I want to make this more like an extension, and change it to ".start" and ".stop". If there is a concern about doing that let me know. If not, I'll make that change and commit around 18:00 utc.
(In reply to comment #19) > They could only be in the same file if we required the file to be sourcable, > and sourced it. In my existing infra deployment, I have some compiled binaries > (doing IOCTLs) in the localstart.d directory, which are clearly not sourcable, > so you have to rely on file or directory naming for them. There is another problem with making things sourceable. If you are using a posix compliant shell and there is a syntax error such as a missing quote in a file that is sourced, the entire script that did the sourcing is aborted. That means that one error like this would cause the entire local service to abort instead of affecting only the specific script fragment that had the issue.
Yep, I get that. My compromise suggestion in comment #20 would allow exec instead of source.
(In reply to comment #20) > Provide a skeleton that includes at the top something like: > if [ "$1" -eq "stop" ]; then > # Put your stop action here if one is required. > exit > fi > Then, during stop phase, call run-parts like: > /bin/run-parts --reverse --arg=stop /etc/local.d/ > This adds a little bit of boilerplate, but preserves exec-ability as well as > the other benefits I mentioned. I'm not quite following you. Are you suggesting that openrc's local service use run-parts to run the programs in local.d? If so, I'm not comfortable with doing that, because that would force a dependency for everyone on sys-apps/debianutils.
I'm sorry, I think I misunderstood comment #12. I thought we *wanted* to use run-parts. Forget run-parts. :) The same technique is still viable (script can assume it's a start unless the "stop" argument is passed in), just do it without run-parts.
Hi again Mike, (In reply to comment #25) > I'm sorry, I think I misunderstood comment #12. I thought we *wanted* to use > run-parts. Forget run-parts. :) The same technique is still viable (script can > assume it's a start unless the "stop" argument is passed in), just do it > without run-parts. I see two concerns with combining the start/stop code for each program into one file in the local.d directory. First, it would take away the ability of the user to specify the order programs should be executed. Since we have no way of knowing what the user is going to run in local, there is not a way to have the user specify order other than by the order of the file names. Second, _every_ program in local.d would have to be run when local is started or stopped. So, suppose I have 20 programs in local.d. I need to run all 20 of them when local starts, but I only need to run 3 of them when local stops because 17 of them are one-shot processes that do not need to be stopped. Under your proposal, I must run all 20 programs when local stops, even though 17 of them will do nothing. This seems inefficient. Under my proposal, I would have 23 files in local.d and would only run the 3 I need to run when local stops. Also, I would know the order in which things would start or stop, and I don't see a way to specify that under your proposal. Another reason I want to see a change to the local service go through is that currently every time a user upgrades openrc, they have to be careful with updating /etc/conf.d/local if they are using the local service, but if we can resolve this, /etc/conf.d/local will no longer be a concern. What do you think?
(In reply to comment #26) > First, it would take away the ability of the user to specify the order programs > should be executed. Since we have no way of knowing what the user is going to > run in local, there is not a way to have the user specify order other than by > the order of the file names. Unless I'm missing something, that's the case with any of these schemes. I never meant to imply that there's a rule against putting some digits at the front of the filename to control ordering if desired. Again, though, I do think the scripts should be run in the opposite order during a stop. > Second, _every_ program in local.d would have to be run when local is started > or stopped. So, suppose I have 20 programs in local.d. I need to run all 20 of > them when local starts, but I only need to run 3 of them when local stops > because 17 of them are one-shot processes that do not need to be stopped. Under > your proposal, I must run all 20 programs when local stops, even though 17 of > them will do nothing. This seems inefficient. > ... That's valid philosophically, though someone having 20 local boot scripts seems pretty unlikely. More likely two or three tops. Even the hit from 20 no-op execs seems negligible, though. > Another reason I want to see a change to the local service go through is that > currently every time a user upgrades openrc, they have to be careful with > updating /etc/conf.d/local if they are using the local service, but if we can > resolve this, /etc/conf.d/local will no longer be a concern. Totally agreed. I think any of these schemes would accomplish that particular goal, right?
Hi again Mike, (In reply to comment #27) > (In reply to comment #26) > > First, it would take away the ability of the user to specify the order programs > > should be executed. Since we have no way of knowing what the user is going to > > run in local, there is not a way to have the user specify order other than by > > the order of the file names. > Unless I'm missing something, that's the case with any of these schemes. I > never meant to imply that there's a rule against putting some digits at the > front of the filename to control ordering if desired. Again, though, I do think > the scripts should be run in the opposite order during a stop. I don't see a reason to force this to be a hard requirement. In my scheme, you could set up your scripts so that this could happen, but another user could set them up so that they run in which ever order he wants as well. > > Second, _every_ program in local.d would have to be run when local is started > > or stopped. So, suppose I have 20 programs in local.d. I need to run all 20 of > > them when local starts, but I only need to run 3 of them when local stops > > because 17 of them are one-shot processes that do not need to be stopped. Under > > your proposal, I must run all 20 programs when local stops, even though 17 of > > them will do nothing. This seems inefficient. > > ... > That's valid philosophically, though someone having 20 local boot scripts seems > pretty unlikely. More likely two or three tops. Even the hit from 20 no-op > execs seems negligible, though. I would rather take the more efficient route and give the user control of what is run when. > > Another reason I want to see a change to the local service go through is that > > currently every time a user upgrades openrc, they have to be careful with > > updating /etc/conf.d/local if they are using the local service, but if we can > > resolve this, /etc/conf.d/local will no longer be a concern. > Totally agreed. I think any of these schemes would accomplish that particular > goal, right? Yes, they would. I like my scheme, because it gives the user full control of the local service. It allows the user to specify both which scripts will run when local starts and stops, and their order of execution. Your scheme would force all scripts in the local.d directory to be run when local is started or stopped as well as force an order of execution when local is stopped. Also, you would have to have a way to remember the order you started things so that you could reverse it when you stop them. As I said above, I feel that forcing a stop to run everything in the reverse order of a start is arbitrary and not necessary when we can allow the user to set the order. We need to make a decision so I can commit the fix to the tree. We both agree that what we have now isn't good. I propose commiting my scheme to the tree, because it will allow you to do what you want, but it will also give other users the option to set up the local service differently if they want. Is that ok for you?
(In reply to comment #28) > > Unless I'm missing something, that's the case with any of these schemes. I > > never meant to imply that there's a rule against putting some digits at the > > front of the filename to control ordering if desired. Again, though, I do think > > the scripts should be run in the opposite order during a stop. > > I don't see a reason to force this to be a hard requirement. In my scheme, you > could set up your scripts so that this could happen, but another user could set > them up so that they run in which ever order he wants as well. I think you're referring to the reverse-order thing. My version doesn't really make it a hard requirement, but it's a convenient default. 95% of the time, reversed stop is what you want. 95% of the rest of the time, it doesn't hurt. For the 0.25% that's left - some weird case where you need A to start before B but *also* need A to stop before B (I can't even think of such a case off the top of my head), the user can work around it by going ahead and splitting the start and stop into to scripts, one of which no-ops *if* the "stop" argument is present, and the other of which no-ops *unless* the "stop" argument is present. > > ... > > I would rather take the more efficient route and give the user control of what > is run when. Gotcha. > ... > Your scheme would force all scripts in the local.d directory to be run when > local is started or stopped as well as force an order of execution when local > is stopped. That's convenient and easily worked around as described above, but you haven't had a chance to read that yet. > Also, you would have to have a way to remember the order you > started things so that you could reverse it when you stop them. That's too heavy - what I meant was just to run the stops in reversed sort order. No need to "remember" the start order - just calculate the stop order at stop time in the same way you calculate the start order at start time, except reverse the list. > As I said > above, I feel that forcing a stop to run everything in the reverse order of a > start is arbitrary and not necessary when we can allow the user to set the > order. Not arbitrary - what one wants almost every time. > We need to make a decision so I can commit the fix to the tree. > > We both agree that what we have now isn't good. > > I propose commiting my scheme to the tree, because it will allow you to do what > you want, but it will also give other users the option to set up the local > service differently if they want. > > Is that ok for you? My above points aside, yeah, that's really ok with me. My suggestion (which I, not surprisingly, like) already got more consideration than I expected. :D One more twist, then: In your scheme, no arguments are passed to the scripts at all, so those scripts would normally ignore any arguments. Therefore, there's no harm in passing a "stop" argument. If you go ahead and do that, it would let someone do it a bit more my-way-ish *if* they prefer (benefiting from shared config variables and such) by putting the scripts in the start dir and symlinking them appropriately in the stop dir.
My scheme is in the tree, commit 10ce67. > > Also, you would have to have a way to remember the order you > > started things so that you could reverse it when you stop them. > That's too heavy - what I meant was just to run the stops in reversed sort > order. No need to "remember" the start order - just calculate the stop order at > stop time in the same way you calculate the start order at start time, except > reverse the list. You have to use rev(1) or sort(1) too do that though, and that would force a dependency on linux-utils or coreutils, and I'm not sure whether gnu coreutils runs on the bsds. > One more twist, then: In your scheme, no arguments are passed to the scripts at > all, so those scripts would normally ignore any arguments. Therefore, there's > no harm in passing a "stop" argument. If you go ahead and do that, it would let > someone do it a bit more my-way-ish *if* they prefer (benefiting from shared > config variables and such) by putting the scripts in the start dir and > symlinking them appropriately in the stop dir. We can't pass arguments to the programs, because we don't know for sure that they will always be scripts. Someone might put a binary or symlink a binary into local.d. Mike, I very much appreciate your input on this. Thanks, William
