Re: s6 bites noob
On Fri, Feb 01, 2019 at 04:18:50AM +, Kelly Dean wrote: > Thanks for the fix. Longrun works now, though oneshot still fails, this time > with a different message: > s6-sudoc: fatal: connect to the s6-sudod server - check that you have > appropriate permissions. > > I guess that's related to my running all this (including svscan) as non-root. > s6rc-oneshot-runner is running now, though. > > Should I run it as root? But then you'll be able to erase a lot more than > just the contents of my home dir. ;-) It's actually that you need to run your s6-rc call as an allowed user. See the s6-rc-compile -u and -v options. But more about this in a sec. > > I do prefer that my software recognize that I'm an idiot, and refuse to do > dubious things unless I specify some --force option. I've been saved > countless times by programs designed with users' mental frailty in mind, and > bitten countless times by the opposite. It actually is recognizing that you're an idiot :) At least, it's recognizing that you've misconfigured something. The s6-sudo program connects to a s6-sudod socket (really an s6-ipcserverd socket, but that's an implementation detail) and sends it's argv to s6-sudod. Anyway, s6-ipcserver does ACL checks, and the problem that you're running into is that you haven't set your rules correctly and s6-ipcserver-access is giving you the finger. > > The doc for rc says its diff's view diverges from s6's view only when the > service fails permanently. I suggest adding there that downing the service > using svc instead of rc qualifies as a permanent failure from rc's point of > view. I guess this also means that if rc is used, then svc isn't supposed to > be part of the normal user interface. That requires that s6-rc be permanently running and monitoring a lot of stuff. As an aside, it's actually very, very handy that you can fake out s6-rc and make changes to stuff temporarily without having to deal with the state engine. Don't get me wrong, the state engine is really nice, but it's a pretty heavy hand sometimes. > > In the docs, I see no way to ask svc whether a service is up, or ask > svscanctl which services are up. But obviously rc must be able to ask, in > order to do the diff. I also see no straightforward way to ask rc whether a > particular service is up, other than > s6-rc -a list | grep "^servicename$" To get the actual state of the system I use: `for svc in /path/to/scandir/* ; do s6-svstat "$svc" ; done' For the state of the system as far as the state engine is concerned: `s6-rc -a list' or `s6-rc -da list' depending on what I'm going for. > > If inotify were portable, would you still consider svscanctl -a to be the > best design, or would you omit the -a option and auto-rescan when the scan > directory changed? `s6-svscanctl -an' is by far the nicest mechanism, not just because of the portability, but also because it lets you stage changes and then kick the modifications all in one go. If you need auto updating, you can either use `s6-svscan -t MSECTIMEOUT' (I suggest five seconds, that's the daemontools / runit way). If you want something a little fancier, set an ionotify trigger (say, in a longrun so you know it's always going to be around) that watches the directory and issues an `s6-svscanctl -an' when it gets nudged. -- Colin Booth
Re: s6 bites noob
On Fri, Feb 01, 2019 at 04:18:50AM +, Kelly Dean wrote: > > Thanks for the fix. Longrun works now, though oneshot still fails, this time > with a different message: > s6-sudoc: fatal: connect to the s6-sudod server - check that you have > appropriate permissions. > > I guess that's related to my running all this (including svscan) as non-root. > s6rc-oneshot-runner is running now, though. > > Should I run it as root? But then you'll be able to erase a lot more than > just the contents of my home dir. ;-) It's actually that you need to run your s6-rc call as an allowed user. See the s6-rc-compile -u and -v options. But more about this in a sec. > > I do prefer that my software recognize that I'm an idiot, and refuse to do > dubious things unless I specify some --force option. I've been saved > countless times by programs designed with users' mental frailty in mind, and > bitten countless times by the opposite. It actually is recognizing that you're an idiot :) At least, it's recognizing that you've misconfigured something. The s6-sudo program connects to a s6-sudod socket (really an s6-ipcserverd socket, but that's an implementation detail) and sends it's argv to s6-sudod. Anyway, s6-ipcserver does ACL checks, and the problem that you're running into is that you haven't set your rules correctly and s6-ipcserver-access is giving you the finger. > > The doc for rc says its diff's view diverges from s6's view only when the > service fails permanently. I suggest adding there that downing the service > using svc instead of rc qualifies as a permanent failure from rc's point of > view. I guess this also means that if rc is used, then svc isn't supposed to > be part of the normal user interface. That requires that s6-rc be permanently running and monitoring a lot of stuff. As an aside, it's actually very, very handy that you can fake out s6-rc and make changes to stuff temporarily without having to deal with the state engine. Don't get me wrong, the state engine is really nice, but it's a pretty heavy hand sometimes. > > In the docs, I see no way to ask svc whether a service is up, or ask > svscanctl which services are up. But obviously rc must be able to ask, in > order to do the diff. I also see no straightforward way to ask rc whether a > particular service is up, other than > s6-rc -a list | grep "^servicename$" To get the actual state of the system I use: `for svc in /path/to/scandir/* ; do s6-svstat "$svc" ; done' For the state of the system as far as the state engine is concerned: `s6-rc -a list' or `s6-rc -da list' depending on what I'm going for. > > If inotify were portable, would you still consider svscanctl -a to be the > best design, or would you omit the -a option and auto-rescan when the scan > directory changed? `s6-svscanctl -an' is by far the nicest mechanism, not just because of the portability, but also because it lets you stage changes and then kick the modifications all in one go. If you need auto updating, you can either use `s6-svscan -t MSECTIMEOUT' (I suggest five seconds, that's the daemontools / runit way). If you want something a little fancier, set an ionotify trigger (say, in a longrun so you know it's always going to be around) that watches the directory and issues an `s6-svscanctl -an' when it gets nudged. -- Colin Booth
Re: s6 bites noob
Thanks for the fix. Longrun works now, though oneshot still fails, this time with a different message: s6-sudoc: fatal: connect to the s6-sudod server - check that you have appropriate permissions. I guess that's related to my running all this (including svscan) as non-root. s6rc-oneshot-runner is running now, though. Should I run it as root? But then you'll be able to erase a lot more than just the contents of my home dir. ;-) I do prefer that my software recognize that I'm an idiot, and refuse to do dubious things unless I specify some --force option. I've been saved countless times by programs designed with users' mental frailty in mind, and bitten countless times by the opposite. The doc for rc says its diff's view diverges from s6's view only when the service fails permanently. I suggest adding there that downing the service using svc instead of rc qualifies as a permanent failure from rc's point of view. I guess this also means that if rc is used, then svc isn't supposed to be part of the normal user interface. In the docs, I see no way to ask svc whether a service is up, or ask svscanctl which services are up. But obviously rc must be able to ask, in order to do the diff. I also see no straightforward way to ask rc whether a particular service is up, other than s6-rc -a list | grep "^servicename$" If inotify were portable, would you still consider svscanctl -a to be the best design, or would you omit the -a option and auto-rescan when the scan directory changed?
Re: s6 bites noob
s6-svc -wu -u serv/foo/ will start it, but never exits. Likewise, s6-svc -wd -d serv/foo/ will stop it, but never exits. Now that is probably due to your setup, because yours is the only report I have of it not working. Update: just tonight I received another report of the exact same symptoms, so I investigated, and indeed it's a bug I had introduced a few commits ago. Sorry about that! It is now fixed in the current s6 git head, so if you git pull and rebuild s6, everything should now work flawlessly. (No need to rebuild s6-rc.) -- Laurent
svscan --help
Laurent Bercot:
s6-svscan is pretty mild in that aspect.
In fairness, the original Bernstein program was somewhat more forgiving:
> /package/admin/djbwares % command/svscan --help
> svscan: fatal: unable to chdir to --help: file does not exist
> /package/admin/djbwares %
People used this program wrongly so often with the Bernstein tools that
I gained a Frequently Given Answer about it in 2002.
* http://jdebp.eu./FGA/daemontools-spurious-supervise-directories.html
I take the view that if the user gives a command that takes a specific
number of arguments the wrong number of arguments, that's an error. A
quick if (1 != args.size()) test saves this support pain, and having to
explain this *yet again*.
> /package/admin/nosh % command/svscan 1 2
> svscan: FATAL: One directory name is required.
> /package/admin/nosh % command/svscan
> svscan: FATAL: One directory name is required.
> /package/admin/nosh % command/svscan /dev/null
> svscan: FATAL: /dev/null: Not a directory
> /package/admin/nosh %
I defined the directory argument as mandatory in service-dt-scanner,
a.k.a. svscan, though.
> /package/admin/nosh % command/svscan --help
> Usage: svscan [-?] [--help] [--usage] [--input-activation] {directory}
>
> Main options:
> --input-activation Use input activation for log services.
> /package/admin/nosh %
It's not exactly the same program, after all.
* http://jdebp.eu./Softwares/nosh/guide/commands/service-dt-scanner.xml
* http://jdebp.eu./Softwares/djbwares/guide/commands/svscan.xml
Users should indeed read the doco. It is written to be read. (-:
Re: s6 bites noob
mkdir test s6-svscan --help Well, that was surprising and unpleasant. It ignores unknown arguments, blithely starts a supervision tree in the current dir (my home dir), and spams me with a bunch of supervise errors. Ok, kill it. Next test: s6-svscan test Do you always run programs you don't know in your home directory with random arguments before reading the documentation? Because if you do, then yes, you're bound to experience a few unpleasant surprises, and s6-svscan is pretty mild in that aspect. I think you should be thankful that it didn't erase all the files in your home directory. :) What purpose is served by supervise automatically creating the supervise and event subdirs if there's no run file? It seems to accomplish nothing but errors and confusion. Instead of creating the subdirs, and then barfing on the absence of a run file, why not just create nothing until a run file appears? It is impossible to portably wait for the appearance of a file. And testing the existence of the file first, before creating the subdirs, wouldn't help, because it would be a TOCTOU. As you have noticed and very clearly reported, s6 is not user-friendly - or rather, its friendliness is not expressed in a way you have been lulled into thinking was good by other programs. Its friendliness comes from the fact that it does not mistake you for an idiot; it assumes that you know what you are doing, and does not waste code in performing redundant checks. That's how it avoids bloat, among other things. You may find it unpleasant that s6 does not hold your hand. That is understandable. But I assure you that as soon as you get a little experience with it (and that can even be achieved by just reading the documentation *before* launching a command ;)), all the hand-holding becomes entirely unnecessary because you know what to do. The doc for svscan at least says that it creates the .s6-svscan subdir. The doc for supervise says nothing about creating the supervise subdir, though the doc for servicedir does say it. I agree, the documentation isn't perfect. I'll make sure to add a note in the s6-supervise page to mention the creation of subdirs. Next problem. The doc for s6-svc indicates that s6-svc -wu serv/foo will wait until it's up. But that's not what happens. Instead, it exits immediately. Right. I know why this happens, and it's not exactly a bug, but I can understand why it's confusing - and your expectation is legitimate. So I will change the behaviour so "s6-svc -wu serv/foo" does what you thought it would do. It also doesn't even try to start the service unless -u is also given, which is surprising, but technically not in contradiction of the doc. Well *that* is perfectly intentional. And if -u is given, then -wu waits forever, even after the service is up. In serv/foo/run I have: #/bin/bash echo starting; sleep 2; echo dying s6-svc -wu -u serv/foo/ will start it, but never exits. Likewise, s6-svc -wd -d serv/foo/ will stop it, but never exits. Now that is probably due to your setup, because yours is the only report I have of it not working. Please pastebin the output of "strace -vf -s 256 s6-svc -uwu serv/foo" somewhere, and post the URL: I, or other people here, will be able to tell you exactly what's going wrong. Also, just in case, please also pastebin your sysdeps (by default: /usr/lib/skalibs/sysdeps/sysdeps). So, I tried s6-rc. Set up service definition dir, compile database, create link, run s6-rc-init, etc, then finally s6-rc -u change foo It starts immediately, but rc then waits while foo goes through 12 to 15 start/sleep/die cycles before rc finally exits with code 0. (And foo continues cycling.) But if I press ^C on rc before it exits on its own, then it kills foo, writes a warning that it was unable to start the service because foo crashed with signal 2, and exits with code 1. This is directly related to your issue with s6-svc above. "s6-rc -u change foo" precisely calls "s6-svc -uwu" on foo's service directory, and waits for it to return. Fixing s6-svc's behaviour in your installation will also fix s6-rc's behaviour. So I tried it again, and this time pressed ^C on rc immediately after running it, before foo had a chance to die for the first time. It reported the same warning! The prophecy is impressive, but still, shouldn't rc just exit immediately after foo starts, and let the supervision tree independently handle foo's future death? That is normally what happens, except that in your case s6-svc never returns, so from s6-rc's point of view, the service is still starting. It's the exact same issue. Next test: I moved run to up, changed type to oneshot, recompiled, created new link, ran s6-rc-update, and tried foo again. This time, rc hangs forever, and up is never executed at all. When I eventually press ^C on rc, though, it doesn't say unable to start foo; it says unable to start s6rc-oneshot-runner. Related to the same issue as well.
Re: s6 bites noob
Kelly Dean writes: > In serv/foo/run I have: > #/bin/bash > echo starting; sleep 2; echo dying Just a typo in my message. Actual file does have #!/bin/bash
s6 bites noob
mkdir test s6-svscan --help Well, that was surprising and unpleasant. It ignores unknown arguments, blithely starts a supervision tree in the current dir (my home dir), and spams me with a bunch of supervise errors. Ok, kill it. Next test: s6-svscan test It gives errors about supervise being unable to spawn ./run, and the child dying. What? On an empty scan dir? Oh, the previous test's accidental supervision tree ran supervise on all the current dir's subdirs--and each instance of supervise automatically created a supervise subdir of its service dir. So, now there's test/supervise, which svscan now interprets as a service dir, and starts supervise on it, which barfs. What purpose is served by supervise automatically creating the supervise and event subdirs if there's no run file? It seems to accomplish nothing but errors and confusion. Instead of creating the subdirs, and then barfing on the absence of a run file, why not just create nothing until a run file appears? The doc for svscan at least says that it creates the .s6-svscan subdir. The doc for supervise says nothing about creating the supervise subdir, though the doc for servicedir does say it. Next problem. The doc for s6-svc indicates that s6-svc -wu serv/foo will wait until it's up. But that's not what happens. Instead, it exits immediately. It also doesn't even try to start the service unless -u is also given, which is surprising, but technically not in contradiction of the doc. And if -u is given, then -wu waits forever, even after the service is up. In serv/foo/run I have: #/bin/bash echo starting; sleep 2; echo dying s6-svc -wu -u serv/foo/ will start it, but never exits. Likewise, s6-svc -wd -d serv/foo/ will stop it, but never exits. supervise itself does do its job though, and perpetually restarts run after run dies while the service is set to be up. So, I tried s6-rc. Set up service definition dir, compile database, create link, run s6-rc-init, etc, then finally s6-rc -u change foo It starts immediately, but rc then waits while foo goes through 12 to 15 start/sleep/die cycles before rc finally exits with code 0. (And foo continues cycling.) But if I press ^C on rc before it exits on its own, then it kills foo, writes a warning that it was unable to start the service because foo crashed with signal 2, and exits with code 1. So I tried it again, and this time pressed ^C on rc immediately after running it, before foo had a chance to die for the first time. It reported the same warning! The prophecy is impressive, but still, shouldn't rc just exit immediately after foo starts, and let the supervision tree independently handle foo's future death? Next test: I moved run to up, changed type to oneshot, recompiled, created new link, ran s6-rc-update, and tried foo again. This time, rc hangs forever, and up is never executed at all. When I eventually press ^C on rc, though, it doesn't say unable to start foo; it says unable to start s6rc-oneshot-runner. This is all with default configuration for skalibs, execline, s6, and s6-rc, sourced from Github, running on Debian 9, in my home directory as a non-root user (with -c option for rc-init and -l for rc-init, rc, and rc-update, to avoid polluting system dirs while testing). s6-rc doesn't understand a --version option, but s6-rc/NEWS says 0.4.1.1. And s6/NEWS says 2.8.0.0. And there appears to be an option missing for s6-rc: s6-rc -d list # List all s6-rc -a list # List all up s6-rc -d change foo # Bring foo down s6-rc -u change foo # Bring foo up s6-rc -da change # Bring all down How to bring all up? The examples above suggest it would be s6-rc -ua change But that does nothing. (And the doc does indicate that it would do nothing, since there's no selection.) And a question about the advice in the docs. if svscan's rescan is 0, and /tmp is RAM, what's the advantage of having the scan directory be /tmp/service with symlinks to service directory copies in /tmp/services, instead of simply having /tmp/services directly be the scan directory? I guess an answer might be that there can be a race between svscan's initial scan at system startup and the populating of /tmp/services, so it sees partially copied service directories. But wouldn't a simpler solution be to either delay svscan's start until the populating is complete, or add an option to disable its initial scan? With no initial scan, then you have to run svscanctl -a after the /tmp/services populating is complete, but you have to run that anyway even if you're using symlinks from a separate /tmp/service directory.
