Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Russ Allbery]

Kel Modderman  writes:
> On Saturday 14 February 2009 14:01:40 Russ Allbery wrote:

>> I went to write the patch for this, but I paused when I saw that the
>> other part of this sentence (explicitly running such scripts with sh at
>> other run levels) is implemented.  The current /etc/init.d/rc runs the
>> script directly if it doesn't end in .sh but runs it with sh if it
>> does.

> That's not an interface that has much merit either, it would be nice if
> we didn't have to support it and we had the freedom to execute the
> scripts directly.

Agreed.  I just wanted to be sure that this was the intention.

> I think all scripts in /etc/init.d/ must have a shebang line and be
> executable, and be able to be executed directly. Executing .sh scripts
> explicitly by sh is not something I see much value in supporting, Petter
> expressed similar sentiment when I poked him on IRC.

Good enough for me.

This change will be in the next release of Policy.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Kel Modderman]

On Saturday 14 February 2009 14:01:40 Russ Allbery wrote:
> Kel Modderman  writes:
> 
> > It is the opinion of myself and Petter Reinholdtsen, maintainers of the
> > sysvinit package, that the last sentence of §9.3.1 of policy is no
> > longer relevant and should be removed:
> >
> > """Also, if the script name ends in .sh, the script will be sourced in
> > runlevel S rather than being run in a forked subprocess, but will be
> > explicitly run by sh in all other runlevels."""
> 
> I went to write the patch for this, but I paused when I saw that the other
> part of this sentence (explicitly running such scripts with sh at other
> run levels) is implemented.  The current /etc/init.d/rc runs the script
> directly if it doesn't end in .sh but runs it with sh if it does.

That's not an interface that has much merit either, it would be nice if we
didn't have to support it and we had the freedom to execute the scripts
directly.

> 
> At least on my system, all of the scripts ending in .sh have a proper #!
> line and are executable, so this wouldn't make any difference there, but I
> wanted to double-check first before also removing that since it appears to
> be implemented.
> 

I think all scripts in /etc/init.d/ must have a shebang line and be executable,
and be able to be executed directly. Executing .sh scripts explicitly by sh is
not something I see much value in supporting, Petter expressed similar
sentiment when I poked him on IRC.

Thanks, Kel.



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: [Pkg-sysvinit-devel] Bug#339955: Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Henrique de Moraes Holschuh]

On Fri, 13 Feb 2009, Russ Allbery wrote:
> I went to write the patch for this, but I paused when I saw that the other
> part of this sentence (explicitly running such scripts with sh at other
> run levels) is implemented.  The current /etc/init.d/rc runs the script
> directly if it doesn't end in .sh but runs it with sh if it does.
> 
> At least on my system, all of the scripts ending in .sh have a proper #!
> line and are executable, so this wouldn't make any difference there, but I
> wanted to double-check first before also removing that since it appears to
> be implemented.

Non-executable shell initscripts are NOT supported.  While rc might handle
them, invoke-rc.d will refuse to run them, and it also breaks the
well-understood and standard "call /etc/init.d/ 
directly" which everything under the sun expects to work.

It is something left over from the ancient past that we can and should get
rid of.  At most, it deserves a note on the NEWS.Debian file, if that much.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Bill Allombert]

On Mon, Feb 16, 2009 at 10:01:37AM +0100, Giacomo A. Catenazzi wrote:
> Russ Allbery wrote:
> >Kel Modderman  writes:
> >
> >>It is the opinion of myself and Petter Reinholdtsen, maintainers of the
> >>sysvinit package, that the last sentence of §9.3.1 of policy is no
> >>longer relevant and should be removed:
> >>
> >>"""Also, if the script name ends in .sh, the script will be sourced in
> >>runlevel S rather than being run in a forked subprocess, but will be
> >>explicitly run by sh in all other runlevels."""
> >
> >I went to write the patch for this, but I paused when I saw that the other
> >part of this sentence (explicitly running such scripts with sh at other
> >run levels) is implemented.  The current /etc/init.d/rc runs the script
> >directly if it doesn't end in .sh but runs it with sh if it does.
> >
> 
> As alternative, I propose not to use the suffix .sh:
> - now we change /will be sourced/could be sourced/ , with a footnote that
>   deprecated such feature
> - we bugs package, to remove the suffix .sh
> - after most of the most important packages removed the .sh suffix,
>   the policy remove the exception, maybe introducing a footnote which
>   shortly explain the past rules (this will simplify the writing of
>   rationale in the new doc)
> 
> Rationale:
>   users could be confused by the .sh suffix.

While I agree in general that the .sh suffix should not be mentionned
unless it has a specific meaning, I am afraid that your proposal will
be technically troublesome, because the file /etc/init.d/*.sh are
conffiles and renaming conffiles is a pain. Since such files are
critical at startup, I am afraid than an attempt to rename them will make
the upgrade path to squeeze more fragile.

> > At least on my system, all of the scripts ending in .sh have a proper #!
> > line and are executable, so this wouldn't make any difference there, but I
> > wanted to double-check first before also removing that since it appears to
> > be implemented.
> 
> hmm. All init.d script should be executable, with proper #! header.
> Sysadmin are used to manually /etc/init.d/foo >stop|start|restart|reload>
> So I don't understand your commentart.

I think Russ point is that there is no reason for policy to mandate to
run them with 'sh /etc/init.d/foo' if you can just run them directly as
'/etc/init.d/foo', as you suggest.

If we are going to remove """Also, if the script name ends in .sh, the
script will be sourced in runlevel S rather than being run in a forked
subprocess""", then we can just remove any difference in handling 
a script called /etc/init.d/foo.sh versus /etc/init.d/bar.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Giacomo A. Catenazzi]

Russ Allbery wrote:

Kel Modderman  writes:


It is the opinion of myself and Petter Reinholdtsen, maintainers of the
sysvinit package, that the last sentence of §9.3.1 of policy is no
longer relevant and should be removed:

"""Also, if the script name ends in .sh, the script will be sourced in
runlevel S rather than being run in a forked subprocess, but will be
explicitly run by sh in all other runlevels."""


I went to write the patch for this, but I paused when I saw that the other
part of this sentence (explicitly running such scripts with sh at other
run levels) is implemented.  The current /etc/init.d/rc runs the script
directly if it doesn't end in .sh but runs it with sh if it does.



As alternative, I propose not to use the suffix .sh:
- now we change /will be sourced/could be sourced/ , with a footnote that
  deprecated such feature
- we bugs package, to remove the suffix .sh
- after most of the most important packages removed the .sh suffix,
  the policy remove the exception, maybe introducing a footnote which
  shortly explain the past rules (this will simplify the writing of
  rationale in the new doc)

Rationale:
  users could be confused by the .sh suffix.

> At least on my system, all of the scripts ending in .sh have a proper #!
> line and are executable, so this wouldn't make any difference there, but I
> wanted to double-check first before also removing that since it appears to
> be implemented.

hmm. All init.d script should be executable, with proper #! header.
Sysadmin are used to manually /etc/init.d/foo >stop|start|restart|reload>
So I don't understand your commentart.

ciao
cate


ciao
cate







--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Russ Allbery]

Kel Modderman  writes:

> It is the opinion of myself and Petter Reinholdtsen, maintainers of the
> sysvinit package, that the last sentence of §9.3.1 of policy is no
> longer relevant and should be removed:
>
> """Also, if the script name ends in .sh, the script will be sourced in
> runlevel S rather than being run in a forked subprocess, but will be
> explicitly run by sh in all other runlevels."""

I went to write the patch for this, but I paused when I saw that the other
part of this sentence (explicitly running such scripts with sh at other
run levels) is implemented.  The current /etc/init.d/rc runs the script
directly if it doesn't end in .sh but runs it with sh if it does.

At least on my system, all of the scripts ending in .sh have a proper #!
line and are executable, so this wouldn't make any difference there, but I
wanted to double-check first before also removing that since it appears to
be implemented.

-- 
Russ Allbery (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Jörg Sommer]

Hello Russ,

Russ Allbery hat am Mon 02. Feb, 20:36 (-0800) geschrieben:
> Kel Modderman  writes:
> 
> > It is the opinion of myself and Petter Reinholdtsen, maintainers of the
> > sysvinit package, that the last sentence of §9.3.1 of policy is no
> > longer relevant and should be removed:
> >
> > """Also, if the script name ends in .sh, the script will be sourced in
> > runlevel S rather than being run in a forked subprocess, but will be
> > explicitly run by sh in all other runlevels."""
> >
> > The reasons for which it should be removed are:
> >
> > * /etc/init.d/rc has not supported this for an extremely long time, probably
> >   never, because the system would be unbootable due to .sh scripts calling
> >   'exit' [0, 1].
> 
> Given this, I definitely agree.  There's no point in having a statement
> like this in Policy when our core packages don't implement it and no one
> has apparently cared.

I agree with you and second the proposal. As much as I like the idea to
run scripts in the context of the rc process, I see no much value for
packages and I as the administrator of a system can modify the rc script.
I follow you that such a requirement generates more problems than it
solves.

Bye, Jörg.
-- 
Prof. in der Mathematikvorlesung zu einem vergessenen φ in der
Gleichung: „Klein‐φ macht auch Mist.“


signature.asc
Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Giacomo Catenazzi]

Russ Allbery wrote:
> Kel Modderman  writes:
> 
>> It is the opinion of myself and Petter Reinholdtsen, maintainers of the
>> sysvinit package, that the last sentence of §9.3.1 of policy is no
>> longer relevant and should be removed:
>>
>> """Also, if the script name ends in .sh, the script will be sourced in
>> runlevel S rather than being run in a forked subprocess, but will be
>> explicitly run by sh in all other runlevels."""
>>
>> The reasons for which it should be removed are:
>>
>> * /etc/init.d/rc has not supported this for an extremely long time, probably
>>   never, because the system would be unbootable due to .sh scripts calling
>>   'exit' [0, 1].
> 
> Given this, I definitely agree.  There's no point in having a statement
> like this in Policy when our core packages don't implement it and no one
> has apparently cared.
> 
> Unless someone steps up to say that we should do the work to reimplement
> support for this interface (including fixing all the broken *.sh scripts
> we have now), I think it's obvious we should simply remove it.  There's no
> need to specify things no one uses and clearly can do without.

I agree.
BTW LSB doesn't have such special case, so such
proposal will converge to LSB, which is also positive.

ciao
cate



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Russ Allbery]

Kel Modderman  writes:

> It is the opinion of myself and Petter Reinholdtsen, maintainers of the
> sysvinit package, that the last sentence of §9.3.1 of policy is no
> longer relevant and should be removed:
>
> """Also, if the script name ends in .sh, the script will be sourced in
> runlevel S rather than being run in a forked subprocess, but will be
> explicitly run by sh in all other runlevels."""
>
> The reasons for which it should be removed are:
>
> * /etc/init.d/rc has not supported this for an extremely long time, probably
>   never, because the system would be unbootable due to .sh scripts calling
>   'exit' [0, 1].

Given this, I definitely agree.  There's no point in having a statement
like this in Policy when our core packages don't implement it and no one
has apparently cared.

Unless someone steps up to say that we should do the work to reimplement
support for this interface (including fixing all the broken *.sh scripts
we have now), I think it's obvious we should simply remove it.  There's no
need to specify things no one uses and clearly can do without.

-- 
Russ Allbery (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced

[Kel Modderman]

Package: debian-policy
Version: 3.8.0.1
Severity: wishlist

Hi Debian Policy maintainers,

It is the opinion of myself and Petter Reinholdtsen, maintainers of the
sysvinit package, that the last sentence of §9.3.1 of policy is no longer
relevant and should be removed:

"""Also, if the script name ends in .sh, the script will be sourced in
runlevel S rather than being run in a forked subprocess, but will be
explicitly run by sh in all other runlevels."""

The reasons for which it should be removed are:

* /etc/init.d/rc has not supported this for an extremely long time, probably
  never, because the system would be unbootable due to .sh scripts calling
  'exit' [0, 1].

* the reason why .sh scripts should be sourced is not clear. A popular
  theory is that it was an optimisation to avoid forking shells and reduce
  boot time [2]. It may have been an interface to allow scripts to "set
  an environment variable which would propogate through to subsequent
  scripts" [3].

  These days, sourcing .sh scripts instead of executing them is not so
  much of an optimisation; we have a lightweight shell dash which can be
  used as /bin/sh and has been measured to improve boot time [4]. startpar
  has been hacked on to work better with the Debian boot system and we hope
  to use it for parrallel execution of initscripts in the future without
  contradicting policy (it a C program which uses execlp() to execute
  scripts).

  Passing enviroment variables around by sourcing .sh scripts is not a
  supported interface: .sh scripts have not been sourced for years
  and nobody has cared.

* it would be nice to clean up /etc/init.d/rc in the absence of this
  requirement. Trying to support the sourcing of /etc/init.d/*.sh
  scripts makes the code much uglier to maintain.

Thanks, Kel.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339955#59
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339955#120
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339955#20
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339955#15
[4] http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/bootcharts.html



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org