Hi, Dmitry Bogatov schrob: > [2019-08-24 16:03] Jan Braun <janbr...@gmx.de> > > That means they'll get a conffile prompt if/whe the maintainer changes > > the run file. > > This can be solved in /lib/runit/invoke-run. Something like running > /etc/service/foo/run.pre before "run". > > Feel free to file wishlist. With heavy heart, but I will implement it.
Eww, no.
> > Personally, I'd prefer linking /etc/sv/foo/supervise to a place of my
> > choosing and expect that link to be preserved. Not sure how others
> > would feel, or how they'd try to deal with the issue.
>
> Why would you need it? Content of 'supervise' directory is transient,
> there is nothing valuable in it.
Except the permissions, if non-default.
> While I understand desire to make things as configurable as possible, it
> will put burden of /properly/ purging things from dpkg to me, which I'd
> rather avoid.
Are you saying "me" as in the Debian maintianier of runit, or "me" as in
the local admin of the machine in question?
When I add files in non-default locations, I expect dpkg/maintainer
scripts not to touch them, and possibly dpkg to message me "directory
/some/path not empty, not removed" when purging the package, alerting me
that I might need to clean up manually. I think that kind of behaviour
is required by debian policy, it has worked whenever I needed it in the
past, and AFAICT it works with the runit* packages right now. So there
should be no additional burden on you, the Debian maintainer.
If you, the local admin of your own machine(s), don't like that
behaviour, then just don't add files. :-P It's fine if you edit
/etc/sv/foo/run while I change the symlink /etc/sv/foo/supervise and
create /some/where/supervise-foo . Both will achieve the same result:
persisting non-default permissions of the supervise dir. You will get
bothered by dpkg when the runscript changes, I will need to manually
clean up when I purge foo. Valid tradeoff, and nothing that needs to be
resolved IMHO.
If you meant the purging of /var/lib/runit/supervise/foo in case the
runit* packages decide to put things there by default, that's an
unconditional "rm -rf" in the appropriate maintainer script and not much
of a burden. Or am I missing something there?
As to where Debian's runit should point the symlink by default:
/var/lib/runit/supervise/foo:
+ persists non-default supervise dir permissions at no cost to the
local admin.
- unneccessarily persists the rest of the supervise dir.
/run/runit/supervise/foo:
- requires admin effort to get persistent non-default supervise dir
permissions.
+ saves writes to a durable medium during operation.
I don't really have a preference here.
And I don't need to. :) Because on my machines, I'm back to a ramdisk on
/etc/service, which:
+ persists exactly what it's told to (by placing it in /etc/sv )
+ saves writes to durable storage
- requires a reboot or other admin action to apply their /etc/sv
changes to the ramdisk. :(
I doubt that's an acceptable default configuration for Debian, but it's
implemented as an option with very little effort:
* a few lines setting up the ramdisk in /etc/runit/2 (conditional on
/etc/service being a symlink to /run/service),
* a one-line change preventing /lib/runit/invoke-run from dying to
the changed path¹,
* a new script (or patch to update-service) to implement said
admin action without rebooting.
Holler if you're interested in adding it to Debian. (Which would be
nice, but I can live very well on my local modifications too.) Not sure
if having this as an option should tilt the /run vs. /var decision.
cheers,
Jan
¹I don't like that aspect of invoke-run at all. I'll probably file a
separate bug for it.
signature.asc
Description: PGP signature
