Russ Allbery <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> It seems there is a bug in the IPv6 listening code, listening to socket >> 0 sounds like listening on stdin, which would explain the Ctrl-D thing. >> I'll look into this. > >> I think shishid should not start by default. Users should enable it >> manually so they are sure they know what they are doing. When shishid >> is more widely tested, we can revert this behaviour. > > Okay, I'm going to add an /etc/default/shishid file that sets a variable > saying not to start the daemon by default and that users can change to > enable automated starting.
Sounds good. >>> Also, if shishid isn't running, the init script stop action fails > >> That sounds bad -- IMHO, the stop action shouldn't fail because the >> process had already died. > >> Should we fix the init script here? > > Yes. --oknodo is needed; I'll add it. Ah, I didn't know about --oknodo. It seems appropriate. >> I used the template init script from some Debian manual, so if there is >> a problem in it, perhaps we should forward this. > > Yeah, I'm pondering that. I can see cases where this is desirable (if, > for instance, failure to cleanly stop a daemon before upgrading would > result in data loss); we just don't happen to have any of those cases. With --background and --oknodo being available, I'm less sure there is a problem in the example, it is just an example. >>> which then causes all sorts of strange problems for the upgrade >>> process. In fact, if the old shishid package is installed, it appears >>> to be impossible to upgrade the system; the package is so broken that >>> there doesn't appear to be any way to get rid of it without manually >>> removing the init script and then using dpkg --purge >>> --force-remove-reinstreq. I think some of this may be due to a >>> debhelper bug; I'm investigating. > >> Yikes, that's really bad. > >> Disabling shishid by default might fix similar problems in the future. > >> Removing the init script and invoking the dpkg command works here, so >> maybe this should go into the changelog? If we can't find a cleaner >> upgrade path, that is. > > With the help of the debhelper maintainer I have a fix that should work > and will be committing to CVS shortly. Great! /Simon _______________________________________________ Help-shishi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-shishi
