I just ran into the same problem and think I found something.
The program I am running supervised by daemon runs under an
unprivilileged user. The pid files are located in /var/run/<daemon-name>
which is owned by and writable for said user.
So to start, stop and restart the daemon one either neeads to be root
and provide --user=<unpriv. username>[:<unpriv. user´s group] or be that
user theirselves.
But if you just want to check if the program supervised by daemon is
running it should be sufficient to just provide the location of the
pidfile(s) and ask if it is (--)running. And it works but not in an
arbitrary order of command line argument as the man page suggests:
$ daemon --name=<name-of-daemon> --pidfiles=/path/to/pid/directory --running
Invalid --pidfiles argument: '/path/to/pid/directory' (Directory is not
writable)
usage: daemon [options] [--] [cmd arg...]
[...]
$ echo $?
1
but
$ daemon --name=<name-of-daemon> --running --pidfiles=/path/to/pid/directory
$ echo $?
0
So the latter works and seemingly only because of the difference in
argument ordering. I don´t think that this is the intended behaviour
since the man page and --help don´t mention any particular ordering of
options. (see above, usage info after command failure).
Plus, I don´t consider a non-writable --pidfiles directory an invalid
argument (even for starting or --stop, --restart), it´s a directory
after all but the user simply has insufficient permissions. But I guess
since daemon considers this an invalid argument it also outputs the
"usage:" info, which in my eyes it shouldn´t. It shoulc just exit with
an appropriate error message like "insufficient permissions" and exit code.
I think generally there seems something off with the checking of
permissions and the ordering of that, because in case of
starting/stopping/restarting with --user supplied it will also complain
about non-writable --pidfiles directory first. But if that directory
were to be writable, only then would daemon complain about insufficient
permissions. I don´t understand why it doesn´t just check the calling
user:group-ids and base it´s decision making solely on those values,
because even if the PID directory/file was writable a user other than
root or the user provided by --user shouldn´t be allowed to carry out
those actions. Or maybe I am missing something.
Oh, now I dirfted of a little I guess. Should I open a seperate bug for
the last two paragraphs? Anyways, I hope I could provide some more info
and at least a workaround.
Regards
Marcus Blumhagen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
