Laurent Bercot writes: > foo/run not existing is a temporary error condition that can happen > at any time, not only at the start of s6-supervise. This is a very > different case: the supervisor is already running and the user is > relying on its monitoring foo.
But run not existing when supervise starts is a different case from run disappearing after supervise is already running. Even though supervise should continue running if run disappears, that doesn't imply that it shouldn't abort on startup if run doesn't exist in the first place. Another example of orneriness: supervise automatically does its own initialization, but the s6-rc program (not the eponymous suite) doesn't. Instead, the suite has a separate init program, s6-rc-init, that's normally run at boot time. But if it isn't run at boot time (which is a policy decision), s6-rc doesn't automatically run it if necessary. If rc shouldn't auto-initialize, neither should supervise. Another one: the -d option to s6-rc is overloaded. When used with change, it means to down the selected services. But when used with list, it means to invert the selection. I'm going to repeatedly forget this. One more: the doc for the s6-rc program says it's meant to be the one-stop shop of service management, after compilation and initialization are done. It has subcommands list, listall, diff, and change. But s6-rc-update is a separate program, not a subcommand of s6-rc. I suppose there's a reason for this, but it complicates the user interface with a seemingly arbitrary distinction of whether to put a dash between "s6-rc" and the subcommand depending on what the particular subcommand is. The docs advise entirely copying the service repository to a ramdisk, then using (a link to) the copy as the scan directory. This makes the running system independent of the original repo. But the doc for s6-rc-init says the rc system remains dependent on the original compiled database, and there's no explanation of why it isn't also copied in order to make the running system independent. I tried to test the logger. Set up a service repo with foo and bar, each with a run like #!/bin/bash echo foo starting sleep 2 echo foo dying foo and bar are funneled to a logger that has this run file: s6-log -l 10000 s1000000 T /home/user/testlogs Try to start the bundle. Hangs. Press ^C. Get: s6-rc: warning: unable to start service s6rc-fdholder: command crashed with signal 2. Ok, Colin Booth mentioned permission issues when running as non-root. It shouldn't be a problem, since all of this (including svscan) is running as the same user. Permission problems should only come into play when trying to do things inter-user. Anyway, I checked the s6-rc-compile doc. Looks like -h won't be necessary, since it defaults to the owner of the svscan proc. But -u is needed, since it defaults to allowing only root--even though I've never run any of this as root, and I've never asked it to try to do anything as root, and I've never told it that it should expect to be root, or even mentioned root at all. And I'm not really sure the doc is right, because it says -u controls who's allowed to start and stop services, yet I've already used rc to start and stop regular (longrun) services as my non-root user before, with no problem (I had a problem only with oneshot), even though the doc says that since I didn't compile with -u, it should have disallowed that. Anyway, recompile with -u 1000, re-update, and try again. Now, I can't even do s6-rc -a list; I get: s6-rc fatal: unable to take locks: Permission denied Maybe I missed an essential step, and screwed something up? I'm bewildered, tired, and going to bed. After reading more of the docs than I expected to be necessary, I'm still unable to get s6 to do the basic job I need: manage a small group of services, and funnel and log their output. It's especially frustrating having to fight with software that generates gratuitous intra-user permission errors. I'll try again in the morning, with replenished willpower.
