On Fri, Jul 17, 2015 at 10:13 AM, Claes Wallin (韋嘉誠)
<skarnet_at_clacke.user.lysator.liu.se> wrote:
> On 17-Jul-2015 12:49 am, "Colin Booth" <cathexis_at_gmail.com> wrote:
>
> Depending on your cron, users might be able to simply put an _at_reboot
> s6-svscan in their user crontab. I don't see many drawbacks with that.
>
There's nothing managing the per-user s6-svscan if it dies during
normal system runtime, which defeats the entire purpose of using a
supervision framework in the first place. With process suprevision, at
some point your supervision tree must have PID 1 bringing the tree
back up (be it an inittab entry, s6-svscan running as init, runit
managing runsvdir and so on) otherwise you're only playing tricks with
daemonization. Using _at_reboot crontab entries is a clever way around
the reboot case, but like I said above, it doesn't protect the
supervision root process outside of that event.
I actually think that systemd based systems can have a correctly
supervised non-privileged supervision tree through the use of loginctl
enable-linger and daemon-ish unit files. So you could bring up your
supervision tree that way, or just forego the process supervisor and
write directly against systemd. I however don't have any systemd hosts
laying around to test that on, and even if I did s6-rc and systemd
both cover the same operational space.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Mon Jul 20 2015 - 05:43:25 UTC