Package: sks
Version: 1.1.5-2
Severity: normal
Hi.
This is basically a follow up to #766943.
Apparently sks' initscript doesn't fail, even when sks couldn't
bind to an address, e.g.:
# systemctl -l status sks.service
● sks.service - (null)
Loaded: loaded (/etc/init.d/sks)
Active: active (running) since Mon 2014-10-27 06:52:22 CET; 4min 21s ago
Process: 1991 ExecStart=/etc/init.d/sks start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/sks.service
├─2043 /usr/sbin/sks db
└─2046 /usr/sbin/sks recon
Oct 27 06:52:22 kronecker systemd[1]: sks.service changed dead -> start
Oct 27 06:52:22 kronecker systemd[1991]: Executing: /etc/init.d/sks start
Oct 27 06:52:22 kronecker sks[1991]: Starting sks daemons: sksdb.. sksrecon..
done.
Oct 27 06:52:22 kronecker systemd[1]: Child 1991 belongs to sks.service
Oct 27 06:52:22 kronecker systemd[1]: sks.service: control process exited,
code=exited status=0
Oct 27 06:52:22 kronecker systemd[1]: sks.service got final SIGCHLD for state
start
Oct 27 06:52:22 kronecker systemd[1]: sks.service changed start -> running
Oct 27 06:52:22 kronecker systemd[1]: Job sks.service/start finished,
result=done
Oct 27 06:52:22 kronecker systemd[1]: Started (null).
Oct 27 06:52:23 kronecker sks[1991]: 2014-10-27 06:52:23 Failed to listen on
2a01:4f8:a0:4024::2:2:11370: Failure("Failure while binding socket. Probably
another socket bound to this address")
Now I think it's quite clear, that having failed to bind to an iface
should be considered a critical errror (since the service
won't be usable) and thus the init-script should fail as well
and not let e.g. systemd believe that everything got right.
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
