On Sat, Oct 02, 1999 at 10:35:10PM +1000, Herbert Xu wrote:
> No, during the upgrade, inetd should not try to start new copies of telnetd
> because it may not be there or it may not be executable (e.g., shlibs that
> it depends on may be missing). Thus it must be disabled as is done with all
> daemons per the policy. However, this does not stop any existing telnet
> connections so it should not be a problem.
> AFAIK ssh does exactly the same thing in its prerm.
So it does. (/etc/init.d/ssh stop, unconditionally)
Hmmm. I can't actually find any mention of this in policy. In fact,
discussion of what should be done when in prerm and postrm seems pretty
bare, period.
Is this proper behaviour? It seems like it'd avoid errors, but it does
introduce `unnecessary' downtime. Should I do /etc/init.d/inetd stop
in netbase's prerm?
(On my system, there are about half a dozen (incl. xdm, apache, netbase,
pcmcia) that try to keep the service running during the upgrade, about
a dozen that just stop it)
What sequence of events is actually going to cause problems? I'd have
thought dpkg would generally manage to keep dependencies pretty reliable
while upgrading.
Did anything come of the `locally-essential' thing that apt was going
to support at one point? So that you could say "telnetd is Essential
to this machine --- I do remote maintenance", and have Apt configure
telnetd (and any dependents) ASAP. That would solve the original problem
pretty well, it seems to me.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpLxEAl2KJkK.pgp
Description: PGP signature