Discussion:
/etc/rc.d/rc.M stops at /etc/rc.d/rc.dhcpd, why?
(too old to reply)
'Ndoko Yokojo
2017-10-23 20:54:41 UTC
Permalink
Raw Message
I activated dhcpd on my server. After a reboot I realized that
/etc/rc.d/rc.local didn't execute any more. After a few checks, I
realized that anything in /etc/rc.d/rc.M that came after these lines


# Start the dhcp server:
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi

failed to execute. /etc/rc.d/rc.local comes last in rc.M.

I moved the dhcpd lines to the bottom, and everything was back to
normal after reboot. Dhcpd works fine on my LAN.

Why did this happen? Thank you.
John McCue
2017-10-24 00:37:10 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
I activated dhcpd on my server. After a reboot I realized that
/etc/rc.d/rc.local didn't execute any more. After a few checks, I
realized that anything in /etc/rc.d/rc.M that came after these lines
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi
My Slackware 14.2 does not have a /etc/rc.d/rc.dhcpd,
did you create one ?
Post by 'Ndoko Yokojo
failed to execute. /etc/rc.d/rc.local comes last in rc.M.
<snip>
Post by 'Ndoko Yokojo
Why did this happen? Thank you.
Did you create a /etc/rc.d/rc.dhcpd ?
Does it have an 'exit', if so that is why.

John
Rich
2017-10-24 03:03:35 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
I activated dhcpd on my server. After a reboot I realized that
/etc/rc.d/rc.local didn't execute any more. After a few checks, I
realized that anything in /etc/rc.d/rc.M that came after these lines
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi
failed to execute. /etc/rc.d/rc.local comes last in rc.M.
I moved the dhcpd lines to the bottom, and everything was back to
normal after reboot. Dhcpd works fine on my LAN.
Why did this happen? Thank you.
Slackware does not appear to contain a rc.dhcpd file, so did you create
one yourself (this would have been useful info for you to provide up
front).

Beyond the other answer you received (rc.dhcpd executing "exit")
another likely possibility is that your home-brew rc.dhcpd is failing
to start dhcpd in the background. In which case, things stop because
bash never gets returned two after starting dhcpd. So either start
dhcpd in the background (hint, the & operator can be useful here), turn
off the "stay in foreground" switch to dhcpd, or launch your rc.dhcpd
script in the background.
'Ndoko Yokojo
2017-10-24 07:13:21 UTC
Permalink
Raw Message
Post by Rich
Slackware does not appear to contain a rc.dhcpd file, so did you
create one yourself (this would have been useful info for you to
provide up front).
My Slackware 14.2 does not have a /etc/rc.d/rc.dhcpd, did you
create one ?
Thank you Rich and John McCue, you are right. I forgot that I
downloaded AlienBob's
http://www.slackware.com/~alien/rc_scripts/other_rc_scripts/rc.dhcpd

It does have an "exit 0" at the end, isn't that enough to let rc.M
resume its activity?
Rich
2017-10-24 10:22:31 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
Post by Rich
Slackware does not appear to contain a rc.dhcpd file, so did you
create one yourself (this would have been useful info for you to
provide up front).
My Slackware 14.2 does not have a /etc/rc.d/rc.dhcpd, did you
create one ?
Thank you Rich and John McCue, you are right. I forgot that I
downloaded AlienBob's
http://www.slackware.com/~alien/rc_scripts/other_rc_scripts/rc.dhcpd
It does have an "exit 0" at the end, isn't that enough to let rc.M
resume its activity?
That should work, so since you are seeing something different it would
seem that something else is wrong.

You could try adding "set -x" to the top of the rc.dhcpd file, which
will print out to the console during boot the lines of the dhcpd file
as they are executed. You might be able to determine what line it
stops at that way.

You can also try the same with rc.M to see if it continues but stops
elsewhere.

I don't recommend leaving the "set -x" on all the time, it is very
verbose.
Sylvain Robitaille
2017-10-24 17:39:08 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
Thank you Rich and John McCue, you are right. I forgot that I
downloaded AlienBob's
http://www.slackware.com/~alien/rc_scripts/other_rc_scripts/rc.dhcpd
It does have an "exit 0" at the end, isn't that enough to let rc.M
resume its activity?
It is, except you're "sourcing" the script, rather than executing it in
a subshell:

# Start the dhcp server:
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi

That's essentially the same as inserting the contents of
/etc/rc.d/rc.dhcpd, including the "exit 0" statement, right at that
point, so of course, when /etc/rc.d/rc.dhcpd calls exit, rc.M exits.

I hope that helps ...
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
'Ndoko Yokojo
2017-10-25 09:32:26 UTC
Permalink
Raw Message
Post by Sylvain Robitaille
It is, except you're "sourcing" the script, rather than executing it in
...
Post by Sylvain Robitaille
I hope that helps ...
Sounds like it does, but how should I "not source" the script?
Should I remove the "exit 0" from the called script, or is there
some fancier way to go?

Thanks.
Eef Hartman
2017-10-25 11:45:17 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
Sounds like it does, but how should I "not source" the script?
Remove the ". " in rc.M for the script.
The . command is the equivalent in sh for the (t)csh source command
and bash even allows the . to be replaced BY the word "source".
Post by 'Ndoko Yokojo
Should I remove the "exit 0" from the called script, or is there
some fancier way to go?
As it's not all that functional you can do that too, but it normally
shouldn't be the problem. The official solution is to replace "exit"
with "return", that is, return with THAT value to the calling script.
Sylvain Robitaille
2017-10-25 17:02:12 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
Sounds like it does, but how should I "not source" the script?
Should I remove the "exit 0" from the called script, or is there
some fancier way to go?
As Eef suggested, I would simply remove the ". " from:

# Start the dhcp server:
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi

I hope that helps ...
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Giovanni
2017-10-25 15:22:19 UTC
Permalink
Raw Message
Post by Sylvain Robitaille
It is, except you're "sourcing" the script, rather than executing
...
Post by Sylvain Robitaille
I hope that helps ...
Sounds like it does, but how should I "not source" the script? Should
I remove the "exit 0" from the called script, or is there some
fancier way to go?
Most of the old (very old) scripts where "sourced" using the '.' (dot)
keyword and didn't have the "exit" statement to avoid ending of the
process. A sourced script just terminates after the last statement is
executed and processing resumes at the sourcing script.

An exit statement may bi used when processing the script directly from
the shell.


#!/bin/sh
## Sample script

dhcpdStart(){ ... }
dhcpdStop() { ... }
dhcpdStatus() { ... }
## Main < do the work >
case $1 in
'start') dhcpdStart ;;
'stop') dhcpdStop ;;
'status') dhcpdStatus; exit 0 ;;
'restart') dhcpdStop; /bin/sleep 1; dhcpdStart; exit 0 ;;
*) echo "usage: $(basename $0) start|stop|status|restart";
exit 1 ;;
esac

In the example above the 'start' and 'stop' cases are used for system
start/stop while 'restart' and 'status' are used directly from the shell
as in:
$ /etc/rc.d/rc.dhcpd restart


Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >
'Ndoko Yokojo
2017-10-25 16:39:51 UTC
Permalink
Raw Message
Thanks everybody!
From a little stupid glitch I've learned a lot about bash scripts.
Giovanni
2017-10-26 06:26:04 UTC
Permalink
Raw Message
Post by 'Ndoko Yokojo
Post by 'Ndoko Yokojo
Sounds like it does, but how should I "not source" the script?
Should I remove the "exit 0" from the called script, or is there
some fancier way to go?
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi
I hope that helps ...
Your solution starts a new process and nowadays, with tons of available
RAM and fast processors, may not be a problem, but older scripts used to
source files using '.'. I assume that the process is faster and
requires less resources that in the past were very limited -- my first
slackware installation was back in 1996 on a 486 with 4MB RAM.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >
Eef Hartman
2017-10-27 11:30:20 UTC
Permalink
Raw Message
Post by Giovanni
Your solution starts a new process and nowadays, with tons of available
RAM and fast processors, may not be a problem, but older scripts used to
source files using '.'.
That is more because they can then set environment for the whole
startup process. An extra shell doesn't make all that much difference
in memory requirements.
Post by Giovanni
my first slackware installation was back in 1996 on a 486 with 4MB RAM.
1994, 486dx2/66, but it already did have 8 MB of RAM (and 1 MB of
video memory). This was with Slackware release 1.1.2
Rich
2017-10-27 12:58:11 UTC
Permalink
Raw Message
Post by Eef Hartman
Post by Giovanni
Your solution starts a new process and nowadays, with tons of available
RAM and fast processors, may not be a problem, but older scripts used to
source files using '.'.
That is more because they can then set environment for the whole
startup process. An extra shell doesn't make all that much difference
in memory requirements.
Post by Giovanni
my first slackware installation was back in 1996 on a 486 with 4MB RAM.
1994, 486dx2/66, but it already did have 8 MB of RAM (and 1 MB of
video memory). This was with Slackware release 1.1.2
I started out with SLS (Slackware's logical precursor) sometime in the
1992-1993 timeframe (I forget exactly now) on a 386DX-33 with 4MB ram.
When SLS folded and Slackware appeared (both were relatively
concurrent) I switched to Slackware (still on the 386DX-33, and still
with 4MB ram).
Sylvain Robitaille
2017-11-08 19:09:39 UTC
Permalink
Raw Message
On 2017-10-26, Giovanni wrote:

(quoting me ...)
Post by Giovanni
Post by 'Ndoko Yokojo
if [ -x /etc/rc.d/rc.dhcpd ]; then
. /etc/rc.d/rc.dhcpd start
fi
I hope that helps ...
Your solution starts a new process and nowadays, with tons of
available RAM and fast processors, may not be a problem, but older
scripts used to source files using '.'.
Sure and performance, or keeping from spawning a new process isn't
the only reason for sourcing a file, rather than executing it as a
separate script. I don't think that's relevant in this case, though.
Post by Giovanni
I assume that the process is faster and requires less resources that
in the past were very limited
It probably *doesn't* require fewer resources than it did in the past,
though as you say resources now are much more plentiful than they
were some years ago. That said, this is a startup script. Does it
really matter (now, and did it really matter 25+ years ago) if it
takes as much as an extra few seconds for the startup to complete
because init had to fork a child for the dhcpd process?
Post by Giovanni
my first slackware installation was back in 1996 on a 486 with 4MB RAM.
Me too. On a 120MB hard disk. I don't understand the relevance of
that to this problem, though.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Eef Hartman
2017-11-19 17:13:48 UTC
Permalink
Raw Message
Post by Giovanni
Your solution starts a new process and nowadays, with tons of available
RAM and fast processors, may not be a problem, but older scripts used to
source files using '.'.
Pat has now removed all ". " and most "sh " prefixes from the startups
in rc.? scripts, as to prevent those (previous sourced) scripts from
terminating the whole init process.

I.e.
# Start the system logger.
if [ -x /etc/rc.d/rc.syslog -a -x /usr/sbin/syslogd -a -d /var/log ];
then
/etc/rc.d/rc.syslog start
fi
used to have a ". " in fromt of the /etc line.

This is in the 2.1 version of "sysvinit-scripts" in slackware-current.
Loading...