Re: update-translator script for review
On Sun, Sep 19, 1999 at 02:22:16PM -0400, Roland McGrath wrote:
> > Should we use --recursive by default, or leave it to the package to decide
> > if stacked translators make sense on this node? [update-translator will
> > probably not manage file systems like ext2fs, so we only need to consider
> > stacked translators]
>
> I am not sure exactly what the question is here; what do you mean "by default"?
In the command line in the update-translator script, so that this option is
always given to settrans. You wrote last year:
If there are any active translators
running as child filesystems of this translator, and you do not use
-R, then even if there are no open files in the normal sense, those
active translators will probably count as live clients and this
translator will refuse to go away without -f.
and;
Note that a translator does not need to provide a directory to have
child filesystems. A translator providing a single-file filesystem
can have another translator stacked on top of it (put there with
`settrans -L'). In such a case, the -R issues above all still apply
to this single child filesystem (and recursively to any children it
might have, and its children's children).
> Stacking translators is definitely not what you want for most cases.
> I am imagining that the translators installed by packages will mostly be
> service naming points (such as /servers/*).
Yes of course. So we can probably leave it to the package to provide "-R" if
necessary.
> > What should we do if we install a new translator, but the node exists
> > already (probably with a translator attached to it)? Should we act as if
> > we upgrade (see next item)? Or should we fail with an error code (causing
> > the package installation to abort and leaving the package in an unconfigured
> > state)? Or should we ask the user? [note that asking the user must be
> > minimzed for unattended installation]
>
> My whole point was that how to deal with these situations is something that
> debian policy should specify. This is not greatly different from any other
> preexisting file that installing a package might clobber.
Yes. What we are doing here is writing policy. Whatever comes out of this
discussion I will write up as a policy amendment to how treat Hurd
translators in Debian packages.
> Personally, I hate having it ask the user (I won't tell you how many times
> now I have left dpkg running overnight and come back in the morning to see
> it waiting at some prompt with 99% of the work still left to do). I wish
> all packagers would refuse to clobber unknown files of any kind, but that
> is a policy issue.
Joey Hess implemented a configuration proposal by Wichert Ackermann which
allows to defer all questions to post installation as well as getting the
info from a (network-shared if you want) database. This will make unattended
installs possible, as well as sharing configurations over a farm. The tool
has several frontends, too (term, slang, gtk ...). We only have to make all
packages use this tool now.
> > I think we should leave it to the package maintainer to decide between the
> > following cases on upgrade:
> > "-k"eep active translator,
> > "-g"o away (ask nicely),
> > "-fg" force to go away.
>
> Is it left to the package maintainer to decide what to do about a daemon also?
Yes, I think so. I searched the policy and packaging manual and could find
no instructions for how to start/stop daemons during installation/upgrade
etc. We could investigate current packages, but most just stop it and
restart it, I think.
And, translators have sometimes different requirements (for example, it is
untested if exec can be replaced currently), so I don't know if we can
provide more than a guideline for this.
> > Should we fall back to "-k" if "-gf" or "-g" is aksed for but fails?
>
> In fact, `-g' asks nicely and `-gf' asks "pretty please", but nothing in
> fact forces an uncooperative translator. (I think we should perhaps change
> this.) Consider goaway equivalent to sending a SIGTERM to a daemon; if the
> daemon doesn't die after that, do you start a new one or do you leave the
> old one running? -k leaves the old one running.
I don't know, that's why I asked. With "-k", at least the next time the
translator comes up gets the new options (which may be important if the
syntax changed!).
> > Or should we look for the process and kill it if "-fg" is asked for and the
> > translator doesn't want to die?
>
> I hesitate to suggest this. It is error-prone, because there is no sure
> way to know which process it is. I'm inclined to think we should beef up
> settrans with a more forceful option.
Yes, I figured that.
> > Or should we ask the user?
>
> You are asking me policy questions again.
Yes, I know :) Seriously, this is because we are making policy here.
> > On package removal, the script should be called with the additional
> > options "-fg", okay? (at least one easy case ;) [ in some cases, package
> > may want to prefer "-k" or "-g", but it should be noted that at least the
> > purging issues a "rm $node" and implies "-g". This can be circumvented by
> > using a bogus $node as argument.]
>
> Note that `settrans -g NODE' will make the translator go away happily if
> it's running, but `rm NODE' will get EISDIR if the translator wouldn't mind
> going away but is providing a directory as the visible file. So I would
> say always clear the translator before removing the node. Also, it depends
> on `rm' not doing `stat' or anything on the node before trying to unlink
> it--if `rm' does call `stat' or suchlike on the node, it will start up the
> passive translator!
Argh, yes. We will always kill active and passive translator before deleting
the inode then.
> It might be desireable to use `-g' and just fail if the translator won't go
> away (i.e. refuse to remove the package).
Yes, failing is another option. However, no need for that if settrans gets
the "--kill-no-matter-what" option. Are there circumstances where leaving
the active translator in place is desirable even when all files (the
translator binary, supporting files) are removed?
I am sorry to ask all these questions, but it is not easy to figure out what
is the correct behaviour in all cases.
I hope some people on this list will do some tests with various combinations
of translators running (passive/active) and removing them! Everybody can do
this, so there's no excuse :)
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Reply to: