skarnet / s6

The s6 supervision suite.
https://skarnet.org/software/s6/
ISC License
777 stars 35 forks source link

s6-supervise: does not follow symlinks when creating supervise directory #6

Closed CameronNemo closed 5 years ago

CameronNemo commented 5 years ago

https://github.com/skarnet/s6/blob/3ea0b28892de170c5de281529613531dfa15eaa8/src/libs6/s6_supervise_lock_mode.c#L20

XBPS packages are delivered with supervise pointing to a yet-to-exist location in /run. For example, openntpd has the following links:

/etc/sv/openntpd/log/supervise -> /run/runit/supervise.openntpd-log
/etc/sv/openntpd/supervise -> /run/runit/supervise.openntpd

Ideally, s6-supervise would resolve the link and attempt to create the directories in /run.

skarnet commented 5 years ago

Although similar, s6 and runit differ on certain details. For instance, runit only uses one writable subdirectory of a service directory, supervise. s6 uses two, supervise and event. So a dangling symlink-based configuration would require twice as many dangling symlinks.

Also, the configuration you're suggesting assumes a read-only servicedir, which is both the stock servicedir and the live one. This is not a safe configuration in the context of a package manager, because the package manager may want to modify elements of the (stock) servicedir at the same time the supervisor wants to use elements of the (live) servicedir. This is true for both runit and s6, so the current XBPS policy is unsafe even with runit.

Rather than supporting an unsound servicedir model, I would instead suggest that XBPS adopt a better packaging policy.

If you want to discuss this issue further, please do so on the supervision mailing-list (I don't want potentially interested people to feel they have to have a GitHub account in order to contribute). Thank you. :-)