Re: About /etc/rcS.d/*.sh being sourced
In article <[🔎] 199803091738.SAA00239@ppp37.a2points.com>,
Yann Dirson <ydirson@a2points.com> wrote:
>Hi Miquel,
>
>You told me some time ago that the /etc/rcS.d/*.sh files get
>*sourced*, and not exec'd. However, as it's not documented anywhere
>AFAIK, I wanted to be sure of this.
Yes, it's true.
>S20test.sh: Testing who I am: /etc/init.d/rcS
>Testing argument 1:
>====
>
>I'd like to outline problems that seems quite big to me:
>
>As all init.d script, the scripts to be put in /etc/init.d/ and
>referenced from /etc/rcS.d/ should be call-able from any other rc?.d,
>if I remember your explanation well enough. Then their use is ruled
>by section 3.4 of the policy, which demands that they answer to
>"start/stop/etc." arguments, which is IMHO not doable in a sourced
>script.
Yes it is, and in fact this is a bug which will be fixed in sysvinit-2.74.
Arguments are handled by sourced scripts without any problem.
>It also causes big problems with flow control, especially about
>"exit", and about shell settings: one may use "set +e" or "exit" in
>such a script, and this will break the system badly.
Yes, that's true.
>You'll notice that most scripts written for rc[0-9].d/ make use of set
>and exit, and thus developpers are quite likely to shoot themselves in
>the foot while experimenting.
So? Most of the time it's very useful to shoot yourself in then foot while
experimenting. Those who make no mistakes usually make nothing at all :)
But seriously, there are not a whole lot of packages that are going to
use /etc/rcS.d/. About 5, I guess. And the maintainers of those packages
already know about the possible pittfals.
I know a lot of people use /etc/rc.boot/ as a sort of /etc/rc.local,
but that's plain *wrong*. They shouldn't do that.
>In this case, I'd suggest that this feature gets removed, whatever
>delay this may introduce at boot-time.
Well Solaris has it too. But ofcourse if we can do better we should.
Basically the problems are:
1. Unforeseen exit because of set -e.
2. Unforeseen exit because of exit in the .sh script.
Both can be easily worked around by putting ( ) around the source action
in /etc/init.d/rcS, and that's what I will do. Then the .sh script will be
executed in a subshell, but in bash this does not require a fork - it's
handled by bash internally without forking if it isn't needed.
Other sh shells _may_ fork but that won't influence the working of the
script and it won't influence performance much either.
Problem solved :)
Mike.
--
Miquel van Smoorenburg |
miquels@cistron.nl | Luck is when preparation meets opportunity
--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@debian.org .
Reply to: