Subject: Bug#3290 acknowledged by developer (was: sysvinit path doesn't include /usr/local/{,s}bin)

From: [email-masked]
Date: 14 Jun 1996 21:10:49 -0000

Raul Miller
> > > /etc/init.d/boot sets up a path that doesn't include /usr/local/bin
> > > nor /usr/local/sbin.  In my opinion, the PATH= from /etc/profile
> > > (supplied by the bash package) should be used here as well.  It's
> > > rather silly to have two different default paths for root.
 
Dominik Kubla:
> > No it is not.  It is the basic law of system administration that during
> > system setup the PATH should be as short as possible and only include
> > _MACHINE_LOCAL_ path names (/usr/local might be shared over NFS!).

Miquel van Smoorenburg:
> OK, so I'm closing this bug report.

I think there's a very big opportunity here that's being missed.

We have a large problem of configuring the default path for shells
and such that don't use /etc/profile.  It's fine to have a restricted
path during boot, but this path setting persists long after boot, and
is inherited by everything that init inherits.

Here's another suggestion: include an action 'environment'.  This is
a process that would be run when entering a run level, and would be
run before any other actions at that runlevel.  It will be exec'd by
process 1, rather like the sysinit entry.

Yes, this introduces more possibilities to shoot yourself in the foot,
but init's already that way.

-- 
Raul

---

From: Bill Mitchell <[email-masked]>
Date: Sat, 15 Jun 1996 08:43:36 -0700 (PDT)

On Sat, 15 Jun 1996, Miquel van Smoorenburg wrote:

>If you really want to set an environment or ulimits or whatever for
>everything that is spawned by init use "initscript" - see man
>initscript(8). It does everything you're talking about.

My system is probably not up to date, so I'm not casting this as
a bug report against sysvinit.  I have sysvinit-2.60-1 installed,
and I can't currently get on master or ftp.debian.org to check
if I'm current.  tsx-11 doesn't seem to have a sysvinit package
in pub/linux/distributions/debian/unstable/binary.

I have no initscript(8) man page.  I do have an initscript(5)
man page which says, in part:

DESCRIPTION
       When  the  shell  script  /etc/initscript is present, init
       will use it to execute the commands  from  inittab.   This
       script  can  be  used  to set things like ulimit and umask
       default values for every process.

If initscript is an executable shell script, shouldn't it go in /sbin?

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Sat, 15 Jun 1996 12:41:03 +0200 (MET DST)

> is inherited by everything that init inherits.

Nope, if a daemon started by init needs its PATH set it's probably
broken, and the rest goes through login which clears the environment
anyway (most logins reset the PATH - I don't know what the Debian login
does). So you should fix login.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Sun, 16 Jun 1996 12:33:58 +0200 (MET DST)

> man page which says, in part:

Okay, that's what I meant. Sorry.

> If initscript is an executable shell script, shouldn't it go in /sbin?

Hmmm. I don't think so, it is more a configuration file than a
shell script. Like the scripts in /etc/init.d/. However if these
scripts would be "static" and got their configuration from a
file in /etc (what I would prefer) there is something to be said
to move them into /sbin. But it would break a lot of existing
systems and would make upgrades very difficult.

Mike.

---

From: [email-masked] (Ian Jackson)
Date: Sat, 15 Jun 96 20:48 PDT

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers' mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
Miquel van Smoorenburg <[email-masked]>

If you wish to continue to submit further information on your problem,
please do the same thing again: send it to [email-masked], ensuring
that the Subject line starts with "Bug#3290" or "Re: Bug#3290" so that
we can identify it as relating to the same problem.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.

Ian Jackson
(maintainer, debian-bugs)

---

From: [email-masked] (Ian Jackson)
Date: Sat, 15 Jun 96 20:48 PDT

Ian Jackson