On Sat, Jan 26, 2019 at 10:17:05AM +0000, Dmitry Bogatov wrote:
Hi,
> > I believe instead of
> >
> > rm /etc/service/getty-@TTY@
> >
> > you should do
> >
> > rm "$(pwd)"
> >
> > because then it won't matter what the service is called and where the
> > runsvdir root is (/etc/service or somewhere else).
> I find it unsafe. Explicit is better implicit.
Except when it doesn't work, because the service directory is somewhere
else... But whatever.
> > While invoke-run, as an interpreter, is an original idea, I'd make it a
> > scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
> > wouldn't be necessary to export all variables the configuration sets and
> > thereby clutter the environment of the daemon.
> >
> > The envdir bit could be handled by a construct like
> >
> > if [ -z "$1" ]; then
> > SVDIR="$(dirname $(readlink -f "$0")"
> > if [ -e "$SVDIR/conf" ]; then
> > exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
> > fi
>
> Complicated. And depends on $0 trickery. We, at sysvinit team, had
> problems with $0 trickery.
How is this trickery? We're just obtaining the name of the script being
executed, and its path.
> What is so bad about cluttering environment of daemon?
Normally you'd want to avoid passing unnecessary environment variables to
daemons. Maybe they'll affect its operation in some way; maybe they'll
affect a child process of the daemon that inherits them. It's relying on
undefined behaviour.
> > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > because the /etc/default/foo variables would be lost during the exec since
> > we want to avoid exporting them.)
>
> This too. I want daemontools-style take precedence over sysvinit style.
FWIW, I think the whole thing is creeping featurism, but if you think you
must do it, I'd prefer it being done sensibly -- i.e. not depending on
undefined behaviour, not leaking environment variables. I think this is a
stronger argument than personal preference (yours or mine).
> > > Please,
> > >
> > > * build it (it will build runit-2.1.2-22, sorry for version havoc)
> > > * install bin:runit
> > > * install bin:getty-run
> > > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
> >
> > While this would work, it doesn't improve my situation: you're making me
> > jump through hoops to get sensible behaviour. Creating these files isn't
> > less effort than deleting the getty services on installation, so it just
> > adds complexity and abstraction with no real benefit.
>
> Not exactly. You mentioned that option to pre-seed debconf would help
> you.
Yes; I already preseed debconf with much other stuff. Adding one more
preseed response doesn't add appreciable complexity.
> I provide you with way to pre-provision system -- create
> /etc/default/getty-tty{1..6} before installing runit.
But this is a different mechanism than debconf. Like I said, it would work,
but it's not easier or more comfortable than removing the /service/getty*
symlinks after runit install. It adds complexity to the package without
improving the use-case it is aimed at.
> > I still think the postinst modification I suggested (not installing
> > getty services for non-existing tty devices) would be the cleanest
> > solution.
>
> And what if there were no tty on installation time, and after that they
> appeared? (No idea, why, never dealt with devices without tty.)
That's a pathological hypothetical case; I'd say we wait until it happens,
and then deal with it. (You might also ask: what about hypothetical systems
where /dev/tty* devices keep disappearing and reappearing in a rhythm that
always prevents getty from starting?)
If you're so worried about providing a way to log in even in pathological
cases, you could start a getty on, say, tty7 from /etc/runit/1. (I have at
least one system where I do that.)
> As you can understand, I am wary about defaulting on behavior, that can
> leave user without means to login.
I understand and approve in general, but I think in this case you're taking
it too far, to cover a corner case that doesn't exist.
András
--
Quantum Mechanics: The dreams stuff is made of.
