[PATCH] Make start-stop-daemon handle sending signals better
Rob Landley
rob at landley.net
Wed Aug 30 22:53:14 UTC 2006
On Wednesday 30 August 2006 6:43 pm, Natanael Copa wrote:
> On Wed, 2006-08-30 at 17:42 -0400, Rob Landley wrote:
> > On Wednesday 30 August 2006 4:25 pm, Natanael Copa wrote:
> > > > So why doesn't start-stop-daemon --name work then? (The name it uses
> > > > dereferences the symlink?)
> > >
> > > AFAIK --name works fine with busybox.
> > >
> > > The more common used --exec does not.
> >
> > So telling people to use "--name" instead of exec isn't a solution?
>
> It is a possible solution.
>
> Somebody complained and even produced a bug report, I just propsed a
> solution to the bug report.
Ok.
> > (I haven't got anything against changing start-stop-daemon, I just don't
use
> > it. And unlike most applets where I'm not familiar with what it does, I'm
> > not particularly motivated to learn this one if it's debian-only, so I'm
> > about to check in a fix blind...)
>
> The reason I don't like the solution:
>
> nat at studio:~$ grep -- --exec /etc/init.d/* | wc -l
> 60
> nat at studio:~$ grep -- --name /etc/init.d/* | wc -l
> 17
>
> Thats an ubuntu box. Something similar would be found in gentoo and
> debian.
>
> So the people who actually use ssd seems to prefer to use --exec.
By the same logic, people who actually use ssd prefer to use the non-busybox
versions of all the daemons.
> its kind of
>
> Q: "killall don't work with busybox applets"
> A: "use kill <pid> then"
We're not asking them to lookup the pid, we're still working by name.
Now that you pointed out that ubuntu and gentoo use this and not just debian,
I've acknowledged it as real, and I just looked at the start-stop-daemon man
page.
-n|--name process-name
Check for processes with the name process-name (according to
/proc/pid/stat).
-x|--exec executable
Check for processes that are instances of this executable
(according to /proc/pid/exe ).
Your patch changes it to use /proc/pod/cmdline, which is a _third_ option, and
doesn't match what the man page says. (And isn't necessarily superior to
the --name option since a running process can edit its command line after
launch, which makes false positives much easier.)
It sounds like the problem is we're being too clever. ls -l /proc/self/exe
says that "/proc/self/exe" is a symlink to "/bin/ls", and we really don't
care if /bin/ls is a symlink to a shared executable. The check for device
and inode is what's screwing us up, because the heuristic is wrong and we
should not do that. If the same executable is called by two names, it may be
performing two functions. We are. Call readlink once, use the result in a
string comparison, and stop trying to be too clever for our own good.
Does this sound reasonable? I'll happily apply a patch to simplify the code
and be _less_ clever, if it fixes the problem.
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list