reassign 822248 sks thanks On Fri, Apr 22, 2016 at 03:33:23PM +0200, Christoph Anton Mitterer wrote:
> Since quite a while already (but after we've discussed that in another bug)
> I have one particular case again in which a daemon, that is configured to
> bind to particular addresses fails to start, because when it does, the
> address is apparently configured.
>
> Apr 22 15:25:28 kronecker sks[825]: Starting sks daemons: sksdb.. sksrecon..
> done.
> Apr 22 15:25:28 kronecker systemd[1]: Started sks.service.
> ...
> Apr 22 15:25:28 kronecker sks[825]: 2016-04-22 15:25:28 Failed to listen on
> 1.2.3.4:11370: Failure("Failure while binding socket. Probably another
> socket bound to this address")
> Apr 22 15:25:28 kronecker sks[825]: 2016-04-22 15:25:28 Failed to listen on
> a:b:c:d::1:2:11370: Failure("Failure while binding socket. Probably another
> socket bound to this address")
> Apr 22 15:25:28 kronecker sks[825]: Fatal error: exception Failure("Could not
> listen on any address.")
The sks package contains an init script that does not depend on $network
in its LSB header, so it is likely that it is being started before the
network is brought up.
Since it is a network daemon, it really should depend on $network. Also,
it should get a systemd service file before the next stable release, and
then it should have the following statement in its service file:
After = network.target
Therefore I'm reassigning this to the sks package. Christoph, as a
workaround you can just configure sks to bind to 0.0.0.0 and ::.
> Interestingly, sks runs two daemons (or better said the same one in two modes,
> db and recon)... db always succeeds to start up, while recon always fails.
Are they both binding to specific addresses, or just recon? Maybe it
helps if you send us your /etc/sks/sksconf.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
signature.asc
Description: Digital signature
