I'm not sure how this could happen, but when I enabled sourcing of the
.sh scripts in rcS.d/, the boot failed because /etc/rcS.d/S01glibc.sh
uses 'exit 0' at the end of the script, and thus terminates the S
runlevel. This script was added in glibc version 2.3.5-5 uploaded
2005-08-27. The
[Petter Reinholdtsen]
The patch look good, but will be equivalent to a forked subprocess
when running the scripts in parallel.
Here is a possible patch to avoid running .sh scripts in the
background when using CONCURRENCY=shell.
Index: debian/sysv-rc/etc/init.d/rc
On Sun, Nov 20, 2005 at 08:20:59AM +0100, Petter Reinholdtsen wrote:
[Steve Langasek]
It's perfectly sensible: if the scripts were meant to be run in
parallel, they shouldn't have the .sh extension...
Eh, are you claiming that policy mention sourcing of .sh scripts to
make sure those
[Brendan O'Dea]
Debian Policy states (§9.3.1):
Also, if the script name ends `.sh', the script will be sourced
in runlevel `S' rather that being run in a forked subprocess, but
will be explicitly run by `sh' in all other runlevels.
What a strange thing for policy to specify. :)
On Sat, Nov 19, 2005 at 11:33:44PM +0100, Petter Reinholdtsen wrote:
[Brendan O'Dea]
Debian Policy states (§9.3.1):
Also, if the script name ends `.sh', the script will be sourced
in runlevel `S' rather that being run in a forked subprocess, but
will be explicitly run by `sh' in all
On Sat, Nov 19, 2005 at 11:33:44PM +0100, Petter Reinholdtsen wrote:
Also, if the script name ends `.sh', the script will be sourced
in runlevel `S' rather that being run in a forked subprocess, but
will be explicitly run by `sh' in all other runlevels.
What a strange thing for
[Steve Langasek]
It's perfectly sensible: if the scripts were meant to be run in
parallel, they shouldn't have the .sh extension...
Eh, are you claiming that policy mention sourcing of .sh scripts to
make sure those scripts are not run in paralell? It does not sounds
reasonable to me, as the
7 matches
Mail list logo
