Re: Debian shishi package bug

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

> Russ Allbery <address@hidden> writes:
>
>> I'll take a look and see about getting the packages uploaded tomorrow.
>
> shishid appears to be broken, at least on my system, and I'm not sure how
> to fix it.  In the current package, the init script starts the daemon in
> the foreground and it just hangs until one types Ctrl-D.  It then dies and
> the boot process continues.  Using --background fixes this, but shishid
> just starts and immediately exits.  It spits out the following in syslog:
>
> Apr 20 19:09:08 wanderer /usr/sbin/shishid: Starting (GNUTLS `1.2.9')
> Apr 20 19:09:08 wanderer /usr/sbin/shishid: Listening on IPv6:*:kerberos/udp 
> socket 0 
> Apr 20 19:09:08 wanderer /usr/sbin/shishid: Listening on IPv4:*:kerberos/tcp 
> socket 4 
> Apr 20 19:09:08 wanderer /usr/sbin/shishid: Listening on IPv4:*:kerberos/udp 
> socket 5 
> Apr 20 19:09:08 wanderer /usr/sbin/shishid: Error reading from 
> IPv6:*:kerberos/udp on socket 0 (-1): Unknown error 4294967295
> Apr 20 19:09:08 wanderer /usr/sbin/shishid: Closing IPv6:*:kerberos/udp 
> socket 0
>
> before it disappears.

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.

> 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?

I used the template init script from some Debian manual, so if there
is a problem in it, perhaps we should forward this.

> 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.

Thanks.