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 <[EMAIL PROTECTED]> <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
pgpNkUspnlLID.pgp
Description: PGP signature