Hi,
On 02/14/2011 08:00 AM, Guillem Jover wrote:
This feature could be used in two scenarios:
1) the program forks itself but it cannot output its PID into a file
Why? If it's because it does not have such option, then the correct
fix is to add it, it should not amount to more than 10-15 lines of C.
Yes, the correct fix would be to add the support to that daemon indeed.
However, adding this support is usually not the difficult part, but
maintaining it is: either you have to push it upstream and wait until it
floats back to the distro or you have to maintain a separate branch
which you have to update and recompile every time it needs to be
upgraded (eg. because of security patches). Although that'd be the
proper solution, it is time-consuming and tedious, while adapting the
init script is quick and can be done/maintained easily until pidfile
support is added to the daemon itself.
2) it is not feasible to call the program a way that makes it output its
pidfile (OK, I admit this does not sound so common, but it was actually
this case that made me write this addition -- see
http://gyp.blogs.balabit.com/2011/01/using-upstart-in-a-chroot/
for details, if you're interested, but it's 99% unrelated to
start-stop-daemon)
Why not fix upstart so that it can work on a chroot? or is that not
possible given its design (which would be odd).
I'd say that it wouldn't have been a trivial fix, or at least much more
complicated than adding this hack to S-S-D. Scott James Remnant has
started adding this feature to Upstart, but it's not in mainline
upstart yet AFAIK:
https://code.launchpad.net/~canonical-scott/upstart/session-support
In both cases, start-stop-daemon can now be used to save the PID of the
process, and so --stop can work reliably.
I've found a proposed patch in bug #35117 back from 1999 that seems to
address the same problem, although in a different way, but it seems like
it's been pretty much abandoned since then.
That patch become the current --background and --make-pidfile options,
which to be frank are already bad as they are, as people tend to use
them when they should be adding the code into the daemon properly. So
I'd rather not add more such options, if no really strong reasons are
put forward.
Well, I think we're looking at this from different points of view :)
You're looking at it -- at least partially -- from an OS
maintainer/creator point of view while I'm looking at it from the system
integrator side. From where you stand, it's totally understandable not
wanting to have yet another tool that package maintainers/developers can
abuse to create hack-ish initscripts instead of solving things properly.
But from the other side, it's often simply not feasible to do the Right
Thing -- you don't want to start fixing complex problems in upstream
packages, you just want a simple but working solution for your problem.
(This was my scenario -- I was simply not willing to spend weeks
understanding/patching/testing upstart to add proper chroot support that
is robust enough to be accepted upstream.)
I have no strong arguments in favor of adding this other than "it's a
feature that might be useful for lots of people". I can understand your
point of view, but I'm not entirely convinced that keeping a feature out
of a tool is the right way to educate people about writing proper,
well-behaved daemons.
greets,
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
