17 Čen
2013
17 Čen
'13
16:18
Dear knot users/developers,
I'm testing Knot 1.3.0-rc2. One issue I've run into is when knot exits
uncleanly. In this case, it leaves its PID file behind in
/var/lib/knot/knot.pid.
On the following attempt to start knot, it sees the PID file, and
refuses to start, so I have to remove the stale PID file by hand. If I
run knot under a supervisor, such as upstart, then it tries to run knot,
fails, tries again rapidly in succession, and eventually gives up, at
which point knot isn't running.
My first observation is that in cases where knot is running under a
supervisor, the PID file is not necessary. The supervisor knows knot's
PID, and can signal it directly (to reload, or stop). Could you consider
making the PID file optional? As in, if in knot.conf, I have:
pidfile "";
then knot should not attempt to write (or read or delete) a PID file at all.
Alternatively, could you make knot a bit smarter so that if it detects a
PID file at startup, but that PID is either not in use, or the process
using it is not knot, then it should remove the PID file?
Without either of these possibilities, I have to add logic in my startup
scripts or supervisor scripts to remove any stale PID files. If I only
had one instance of knot, I could do that simply with "rm -f
/var/lib/knot/knot.pid", but I'd like to run multiple instances of knot,
and so I would have multiple PID files, whose locations I would have to
extract from the config file first in order to delete them reliably.
This starts to get hairy...
I hope I have made a reasonable case for providing an option to not
record a PID file, or clean up one before starting. My preference is for
the first option, ie. not writing a PID file.
Regards,
Anand Buddhdev
RIPE NCC
17 Čen
17 Čen
16:41
Hi,
the problem with cleaning after itself is when Knot is run under different
user.
After the privileges are dropped, the ownership of the file changes as well
- so far no problems.
But what happens is, that this file is usually in a directory where that
user has no write access to, so it can
read the file,update it, but it can't remove it from that directory.
Therefore, it should be up to script ultimately to remove the PID file
after that happens.
Alternatively, you could force delete the PID file with 'knotc -f start'.
When that approach is not so usable (supervised run), I agree that the PID
file shouldn't be mandatory,
although 'knotc restart|stop' wouldn't work then for apparent reason.
And yes, it could check the PID file for liveness at startup as well.
I'll add both to the 1.3 final then, you made the case :)
Kind regards,
Marek
On 17 June 2013 16:18, Anand Buddhdev <anandb(a)ripe.net> wrote:
Dear knot users/developers,
I'm testing Knot 1.3.0-rc2. One issue I've run into is when knot exits
uncleanly. In this case, it leaves its PID file behind in
/var/lib/knot/knot.pid.
On the following attempt to start knot, it sees the PID file, and
refuses to start, so I have to remove the stale PID file by hand. If I
run knot under a supervisor, such as upstart, then it tries to run knot,
fails, tries again rapidly in succession, and eventually gives up, at
which point knot isn't running.
My first observation is that in cases where knot is running under a
supervisor, the PID file is not necessary. The supervisor knows knot's
PID, and can signal it directly (to reload, or stop). Could you consider
making the PID file optional? As in, if in knot.conf, I have:
pidfile "";
then knot should not attempt to write (or read or delete) a PID file at
all.
Alternatively, could you make knot a bit smarter so that if it detects a
PID file at startup, but that PID is either not in use, or the process
using it is not knot, then it should remove the PID file?
Without either of these possibilities, I have to add logic in my startup
scripts or supervisor scripts to remove any stale PID files. If I only
had one instance of knot, I could do that simply with "rm -f
/var/lib/knot/knot.pid", but I'd like to run multiple instances of knot,
and so I would have multiple PID files, whose locations I would have to
extract from the config file first in order to delete them reliably.
This starts to get hairy...
I hope I have made a reasonable case for providing an option to not
record a PID file, or clean up one before starting. My preference is for
the first option, ie. not writing a PID file.
Regards,
Anand Buddhdev
RIPE NCC
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
18:00
Anand Buddhdev wrote:
I'm testing Knot 1.3.0-rc2. One issue I've run
into is when knot exits
uncleanly. In this case, it leaves its PID file behind in
/var/lib/knot/knot.pid.
side note: PID files *must* be placed in /var/run, not /var/lib, on
systems that comply with the filesystem hierarchy standard. some
non-FHS systems (e.g., freebsd) do not even have /var/lib.
in general i would recommend using /var/run/${DAEMON}/${DAEMON}.pid for
pidfiles, creating /var/run/${DAEMON}/ if necessary, owned by the
daemon's uid/gid. then you can use the same directory for lock files,
control sockets, etc.
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
/var/run : Run-time variable data
Purpose
This directory contains system information data describing the
system since it was booted. Files under this directory must be
cleared (removed or truncated as appropriate) at the beginning of
the boot process. Programs may have a subdirectory of /var/run; this
is encouraged for programs that use more than one run-time file.
[42] Process identifier (PID) files, which were originally placed in
/etc, must be placed in /var/run. The naming convention for PID
files is <program-name>.pid. For example, the crond PID file is
named /var/run/crond.pid.
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
/var/lib : Variable state information
Purpose
This hierarchy holds state information pertaining to an application
or the system. State information is data that programs modify while
they run, and that pertains to one specific host. Users must never
need to modify files in /var/lib to configure a package's operation.
State information is generally used to preserve the condition of an
application (or a group of inter-related applications) between
invocations and between different instances of the same application.
State information should generally remain valid after a reboot,
should not be logging output, and should not be spooled data.
An application (or a group of inter-related applications) must use a
subdirectory of /var/lib for its data. There is one required
subdirectory, /var/lib/misc, which is intended for state files that
don't need a subdirectory; the other subdirectories should only be
present if the application in question is included in the
distribution. [38]
/var/lib/<name> is the location that must be used for all
distribution packaging support. Different distributions may use
different names, of course.
--
Robert Edmonds
edmonds(a)debian.org
18:26
Robert Edmonds wrote:
in general i would recommend using
/var/run/${DAEMON}/${DAEMON}.pid for
pidfiles, creating /var/run/${DAEMON}/ if necessary, owned by the
daemon's uid/gid. then you can use the same directory for lock files,
control sockets, etc.
another tangent: speaking of control sockets, i see that knot uses port
5553 (TCP) for its control socket, which according to IANA is
registered to:
sgi-eventmond 5553 tcp SGI Eventmond Port
BIND8/BIND9 (ndc/rndc) use port 953 for its control socket, which is in
the "well-known" range but appears not to be registered, while unbound
uses port 8953, which is registered:
ub-dns-control 8953 tcp unbound dns nameserver
this is one of the reasons i like AF_UNIX sockets for control sockets :)
--
Robert Edmonds
edmonds(a)debian.org
18 Čen
18 Čen
3:00
On 17/06/2013 18:00, Robert Edmonds wrote:
side note: PID files *must* be placed in /var/run, not
/var/lib, on
systems that comply with the filesystem hierarchy standard. some
non-FHS systems (e.g., freebsd) do not even have /var/lib.
in general i would recommend using /var/run/${DAEMON}/${DAEMON}.pid for
pidfiles, creating /var/run/${DAEMON}/ if necessary, owned by the
daemon's uid/gid. then you can use the same directory for lock files,
control sockets, etc.
I agree with Robert here. It would be useful if knot's configure script
provided two options such as "--with-dbdir=" and "--with-piddir=" so
that when compiling for Linux systems, I can do:
./configure --with-dbdir=/var/lib/knot --with-piddir=/var/run/knot
Knot could then use $piddir as the default base directory for creating
its PID file in, whereas the zones and journals would go into $dbdir. Of
course, a user can override any of these settings in knot.conf, but the
defaults would be sane, and compliant with FHS.
An RPM or DEB package maintainer could then have the package create
/var/lib/knot and /var/run/knot with the correct ownership and
permissions. At least, that's what I do with my BIND and NSD packages.
Regards,
Anand
4:05
Anand Buddhdev wrote:
On 17/06/2013 18:00, Robert Edmonds wrote:
a slightly different way to do this would be what unbound does, which is
to have separate configure settings for the "run-dir" (e.g.,
/var/run/unbound) and files that default to being placed within the
"run-dir" like the pidfile.
side note: PID files *must* be placed in
/var/run, not /var/lib, on
systems that comply with the filesystem hierarchy standard. some
non-FHS systems (e.g., freebsd) do not even have /var/lib.
in general i would recommend using /var/run/${DAEMON}/${DAEMON}.pid for
pidfiles, creating /var/run/${DAEMON}/ if necessary, owned by the
daemon's uid/gid. then you can use the same directory for lock files,
control sockets, etc.
I agree with Robert here. It would be useful if knot's configure script
provided two options such as "--with-dbdir=" and "--with-piddir=" so
that when compiling for Linux systems, I can do:
./configure --with-dbdir=/var/lib/knot --with-piddir=/var/run/knot
Knot could then use $piddir as the default base directory for creating
its PID file in, whereas the zones and journals would go into $dbdir. Of
course, a user can override any of these settings in knot.conf, but the
defaults would be sane, and compliant with FHS. An RPM or DEB package maintainer could then have the
package create
/var/lib/knot and /var/run/knot with the correct ownership and
permissions. At least, that's what I do with my BIND and NSD packages.
directories under /var/run should be created in the daemon's init
script, not in the package. on many systems /var/run is a tmpfs.
--
Robert Edmonds
edmonds(a)debian.org
6:56
I see, excellent write up. Well the idea of using AF_UNIX has been a long
time in my backlog,
maybe it's time to finally push it forward. I prefer that to a loopback as
well.
I wouldn't want SGI running for my head, would I?
Kind regards,
Marek
On 17 June 2013 18:26, Robert Edmonds <edmonds(a)debian.org> wrote:
Robert Edmonds wrote:
in general i would recommend using
/var/run/${DAEMON}/${DAEMON}.pid for
pidfiles, creating /var/run/${DAEMON}/ if necessary, owned by the
daemon's uid/gid. then you can use the same directory for lock files,
control sockets, etc.
another tangent: speaking of control sockets, i see that knot uses port
5553 (TCP) for its control socket, which according to IANA is
registered to:
sgi-eventmond 5553 tcp SGI Eventmond Port
BIND8/BIND9 (ndc/rndc) use port 953 for its control socket, which is in
the "well-known" range but appears not to be registered, while unbound
uses port 8953, which is registered:
ub-dns-control 8953 tcp unbound dns nameserver
this is one of the reasons i like AF_UNIX sockets for control sockets :)
--
Robert Edmonds
edmonds(a)debian.org
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
7:10
On 18 June 2013 04:05, Robert Edmonds <edmonds(a)debian.org> wrote:
Anand Buddhdev wrote:
That we already do as Anand described. The 'storage' config option is a
default for where the things like file locks, PID files and slave zones go.
The 'pidfile' can override that and also zones
can override their file location. I believe the point was to be able to run
without creating a
PID file (although it brings several limitations to how a control tool
could be used).
But I guess it's probably more correct to have pidfile/socks in one
directory and data storage in a separate one.
Many thanks.
Marek
On 17/06/2013 18:00, Robert Edmonds wrote:
a slightly different way to do this would be what unbound does, which is
to have separate configure settings for the "run-dir" (e.g.,
/var/run/unbound) and files that default to being placed within the
"run-dir" like the pidfile.
side note: PID files *must* be placed in
/var/run, not /var/lib, on
systems that comply with the filesystem hierarchy standard. some
non-FHS systems (e.g., freebsd) do not even have /var/lib.
in general i would recommend using /var/run/${DAEMON}/${DAEMON}.pid for
pidfiles, creating /var/run/${DAEMON}/ if necessary, owned by the
daemon's uid/gid. then you can use the same directory for lock files,
control sockets, etc.
I agree with Robert here. It would be useful if knot's configure script
provided two options such as "--with-dbdir=" and "--with-piddir=" so
that when compiling for Linux systems, I can do:
./configure --with-dbdir=/var/lib/knot --with-piddir=/var/run/knot
Knot could then use $piddir as the default base directory for creating
its PID file in, whereas the zones and journals would go into $dbdir. Of
course, a user can override any of these settings in knot.conf, but the
defaults would be sane, and compliant with FHS. An RPM or DEB package maintainer could then have
the package create
/var/lib/knot and /var/run/knot with the correct ownership and
permissions. At least, that's what I do with my BIND and NSD packages.
directories under /var/run should be created in the daemon's init
script, not in the package. on many systems /var/run is a tmpfs.
--
Robert Edmonds
edmonds(a)debian.org
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
11:20
On 18/06/2013 04:05, Robert Edmonds wrote:
Okay, but this can be left to packagers. On RedHat/CentOS, /var/run is
not a tmpfs, but is created as part of the system installation. Most
RPMs then install their own /var/run/$DAEMON directory. For any systems
where /var/run is on tmpfs, the packager can build the appropriate logic
in knot's startup script.
Regards,
Anand
a slightly different way to do this would be what
unbound does, which is
to have separate configure settings for the "run-dir" (e.g.,
/var/run/unbound) and files that default to being placed within the
"run-dir" like the pidfile.
Yes, that's an even better suggestion. Thanks Robert.
An RPM or DEB
package maintainer could then have the package create
/var/lib/knot and /var/run/knot with the correct ownership and
permissions. At least, that's what I do with my BIND and NSD packages.
directories under /var/run should be created in the daemon's init
script, not in the package. on many systems /var/run is a tmpfs.
3987
days inactive
3988
days old
8 comments
3 participants
participants (3)
-
Anand Buddhdev -
Marek Vavruša -
Robert Edmonds