[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