[PATCH] start-stop-daemon: close extra fds on --background

[Rob Landley]

On Tuesday 01 July 2008 08:21:51 Denys Vlasenko wrote:
> On Tuesday 01 July 2008 12:55, Roy Marples wrote:
> > On Tuesday 01 July 2008 13:44:52 Denys Vlasenko wrote:
> > > On Tuesday 01 July 2008 12:25, Roy Marples wrote:
> > > > On Tuesday 01 July 2008 13:01:56 Denys Vlasenko wrote:
> > > > > ssd: do not stat -x EXECUTABLE, it is not needed anymore
> > > >
> > > > Then userland won't catch an error with ssd --background when the
> > > > file does not exit :/
> > > >
> > > > Please re-consider this.
> > >
> > > With that stat(), even "start-stop-daemon -S -x true" does not work.
> >
> > ssd has historically required the full path when starting daemons.
>
> As I see it:
>
> Historically, surprising percentage of Unix admins
> have no clue why $PATH is useful. Whenever they meet
> a configuration problem causing PATH search to not find their
> utility, they "fix" it by using full path.
> Whereas correct fix is to fix $PATH or copy/move/symplink
> executable to one of the directories which are in $PATH!
>
> That cluelessness is the prime cause why so many scripts
> are littered with e.g. "/usr/sbin/sendmail" instead
> of just "sendmail".

Or, in the linux kernel's scripts/mkcompile.h:

>   if [ -x /bin/dnsdomainname ]; then
>     echo \#define LINUX_COMPILE_DOMAIN \"`dnsdomainname | $UTS_TRUNCATE`\"
>   elif [ -x /bin/domainname ]; then
>     echo \#define LINUX_COMPILE_DOMAIN \"`domainname | $UTS_TRUNCATE`\"
>   else
>     echo \#define LINUX_COMPILE_DOMAIN
>   fi

I hit that earlier today: /bin/dnsdomainname is there but it's not in $PATH...

> It is not a matter of aestetics. It is a matter of making your scripts
> independent of where executables are stored on this particular machine.

To me, it's a matter of doing the right thing...

Rob

P.S.  Last time I saw a patch to compile the linux kernel under MacOS X, it 
was quite large...
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.