Your message dated Tue, 22 Nov 2016 12:54:27 -0500
with message-id <[email protected]>
and subject line Re: Bug#845350: sks no longer creates pidfile
has caused the Debian Bug report #845350,
regarding sks no longer creates pidfile
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
845350: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845350
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: sks
Version: 1.1.6-3
Severity: normal
Dear Maintainer,
It appears sks no longer (since 1.1.6) creates a pidfile. This means that a
standard
cron job such as 'kill -USR2 $(</var/run/sks/sksdb.pid)' no longer works. The
init
script still contains the arguments '--pidfile $SKSDBPID' and '--pidfile
$SKSRECONPID'
but these appear to have no effect.
Andrew.
-- System Information:
Debian Release: 8.6
APT prefers stable-updates
APT policy: (900, 'stable-updates'), (900, 'stable'), (800, 'testing'), (700,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sks depends on:
ii adduser 3.113+nmu3
ii db-util 5.3.0
ii db5.3-util 5.3.28-9
ii libc6 2.19-18+deb8u6
ii libdb5.3 5.3.28-9
ii zlib1g 1:1.2.8.dfsg-2+b1
sks recommends no packages.
Versions of packages sks suggests:
ii exim4-daemon-light [mail-transport-agent] 4.84.2-2+deb8u1
ii logrotate 3.8.7-1+b1
ii procmail 3.22-24
-- Configuration Files:
/etc/default/sks changed:
initstart=yes
/etc/sks/membership changed:
skspub.ward.ie 11370 # Andrew Gallagher <[email protected]>
0xFB73E21AF1163937
keys.bonus-communis.eu 11370 # Pascal Levasseur
<[email protected]> 0xB81EE352 http://37hyu2hzynpjwuaw.onion/
keyserver.miniskipper.at 11370 # Sven Kocksch
<[email protected]> 0x90D94808
key1.dock23.de 11370 # Ramón Goeden <[email protected]>
0xb7c51fd6
key2.dock23.de 11370 # Ramón Goeden <[email protected]>
0xb7c51fd6
sks.static.lu 11370 # Martin Albus <[email protected]> 0xEF3D2226
pgpkeys.urown.net 11370 # Alain Wolf <[email protected]>
0x27A69FC9A1744242
pgpkeys.ch 11370 # Julien Sansonnens
<[email protected]> 0xf714cda06b1c2b3b
sks.srv.dumain.com 11370 # William Hay <[email protected]>
0xA0B31F88E8123356
keyserver.syseleven.de 11370 # Lars Weiler <[email protected]>
0x3567AE7FD7AE9CED
keyserver.nbg-ha.de 11370 # David Mjoelnir <[email protected]>
0x607E2861
pgp.ohai.su 11370 # Lukas Martini <[email protected]>
0xC9E1BD2C
keys.void.gr 11370 # George K. <[email protected]>
#0x721006E470459C9C
sks.mj2.uk 11370 # Michael Jones <[email protected]>
0x129BAF74
sks.okoyono.de 11370 # Fabian 'otih' Fingerle
<[email protected]> 0xAB41AB85
keys.alderwick.co.uk 11370 # Andrew Alderwick
<[email protected]> 0x6E4730742E01FC54
keys2.alderwick.co.uk 11370 # Andrew Alderwick
<[email protected]> 0x6E4730742E01FC54
/etc/sks/sksconf changed:
hostname: whippet.andrewg.com
recon_address: 0.0.0.0
recon_port: 11370
hkp_address: 127.0.0.1
hkp_port: 11371
from_addr: "PGP Key Server Administrator <[email protected]>"
pagesize: 16
ptree_pagesize: 16
debuglevel: 3
server_contact: 0xFB73E21AF1163937
disable_mailsync:
membership_reload_interval: 1
stat_hour: 12
max_matches: 500
-- no debconf information
--- End Message ---
--- Begin Message ---
On Tue 2016-11-22 12:21:57 -0500, Andrew Gallagher wrote:
> It appears sks no longer (since 1.1.6) creates a pidfile. This means that a
> standard
> cron job such as 'kill -USR2 $(</var/run/sks/sksdb.pid)' no longer works. The
> init
> script still contains the arguments '--pidfile $SKSDBPID' and '--pidfile
> $SKSRECONPID'
> but these appear to have no effect.
[…]
> Init: systemd (via /run/systemd/system)
pidfiles are a (traditional) gross hack and are sloppy and insecure.
For example, a process ID can be easily accidentally reused if the
process dies for some reason, and the pidfile remains. then you'd be
sending a signal to who-knows-what process!
That said, what you want to do is reasonable; it's just that pidfiles
aren't a great way to do it.
You're using systemd, and sks should be running under the control of
systemd. If you want to send a signal to the "sks db" process
supervised by systemd, you should do:
systemctl kill --signal=SIGUSR2 sks
That avoids all possible problems with pidfiles, and it doesn't clutter
the filesystem.
I'm closing this bug report because i consider it not a bug that no
pidfile is created.
If you have other concerns, feel free to reopen this report with an
explanation, or just open a different report.
Regards,
--dkg
signature.asc
Description: PGP signature
--- End Message ---
