/etc/rc.d startup not starting?

kailun · 09-17-2006, 03:33 PM

I've just added a couple of extra startup scripts to the /etc/rc.d directory:

rc.httpd2 (for apache 2)
rc.squid (squid proxy)

They are both chmodded +x and they both work if invoked manually. However, for some reason, they aren't starting up when I reboot. Is there any reason for this? The other startup scripts appear to work ok.

TIA

edit: Thought I'd include the actual contents of the startup scripts just in case:

Code:

#!/bin/sh
#
# /etc/rc.d/rc.httpd2
#
# Start/stop/restart the Apache2 web server.
#
# To make Apache2 start automatically at boot, make this
# file executable:  chmod 755 /etc/rc.d/rc.httpd2
#

case "$1" in
   'start')
      /usr/local/apache2/bin/apachectl startssl ;;
   'stop')
      /usr/local/apache2/bin/apachectl stop ;;
   'restart')
      /usr/local/apache2/bin/apachectl restart ;;
   *)
      echo "usage $0 start|stop|restart" ;;
esac

Code:

#/etc/rc.d/rc.squid
#!/bin/sh
# Controls squid process
echo -n ' squid '
case "$1" in
start)
/usr/sbin/squid -D
;;
stop)
/usr/sbin/squid -k shutdown
;;
restart)
/usr/sbin/squid -k reconfigure
;;
*)
echo "Usage: `basename $0` {start|stop|restart}"
;;
esac
#

I'm actually in the middle of migrating from one machine to another and these startup scripts work on the old machine (Slack 9.1 I think).

kailun · 09-17-2006, 04:25 PM

Nevermind, I just figured out some kind of solution for this problem.

For those of you in the same boat, check out /etc/rc.d/rc.M and all the scripts seem to be called from there.

Doh..

Franklin · 09-17-2006, 04:27 PM

Don't edit that file. Use rc.local instead.

Right idea, wrong file.

kailun · 09-17-2006, 07:26 PM

Quote:

Originally Posted by Franklin

Don't edit that file. Use rc.local instead.

Right idea, wrong file.

Are you sure that's the correct way to do it? I'm aware of using rc.local for things like calling simple programs or services.

However, if you look at rc.M, the startup scripts are all called up neatly there, what's more is that there is also a corresponding rc.K script which neatly shuts down the scripts invoked by rc.M, I'm guessing when the system is shutting down. For now, I've manually edited rc.M to add the above scripts using the same format (checking if it's executable, etc) and also the corresponding rc.K so hopefully it will shutdown the processes gracefully too.

drumz · 09-17-2006, 08:40 PM

If you edit rc.M and rc.K, then you'll have to manually check the changes between each upgrade and merge the old and new files. If you put them in rc.local and rc.local_shutdown, then you'll be fine between upgrades. Basically you're creating more work for yourself. If that's what you want, then fine, but we're just pointing out an easier way.

drkstr · 09-17-2006, 11:48 PM

drumz is 100% right. rc.local is meant for custom startup commands (or calling helper scripts which runs the commands)

...drkstr

Woodsman · 09-18-2006, 12:38 AM

Quote:

Are you sure that's the correct way to do it? I'm aware of using rc.local for things like calling simple programs or services.

There is no "correct" way other than the method that works best for you! I am no fan of priesthood ideology, so do what pleases you. Life is always a balancing act of potential risk versus the perceived benefits you believe you might receive.

With that said, however, franklin, drumz, and drkstr raise a valid point if you decide to remain with the Slackware distro. With every Slackware release, or at least, every time you update to a newer release, you bear the responsibility of comparing the new rc.d scripts with your existing rc.d scripts. The fewer modifications you make in the current versions, the less work for you when you update.

With that said, one person's concept of work is another person's concept of leisure. I have modified my rc.d scripts. Primarily to colorize the scripts, but I also have added a few tweaks of my own. Not many---just a few. Yes, when I update to a new Slackware release I have to manually compare all of the scripts. I accept and cheerfully bear the responsibility for my decision.

I use Kompare in KDE because of the nice visual feedback. Should there be any new differences between scripts, I then modify my scripts to accommodate those new additions.

I maintain a separate set of partitions for testing. I can botch those partitions and not touch my production partitions.

Yes, for me there remains some "extra" manual labor to update Slackware because I decided to modify the existing rc.d scripts. Yet, despite my willingness to modify those scripts, I nonetheless place all of my user-based additions in rc.local. As a general principle, I prefer to modify the rc.d scripts as little as possible. Other than my colorization effort, the few mods I have made are minor tweaks only. Additionally, just about anything I want to add does not depend upon any booting order or preference within the boot sequence. Therefore rc.local is a fine place for my additions.

Similar to drumz, I created an rc.shutdown script to manage various shutdown tasks not directly addressed by the existing rc.d scripts.

Although my modified rc.d scripts all run without a hitch, I maintain an /etc/rc.d.orig directory where I maintain the original scripts. Thus, I easily can compare scripts if the need arises, but that hasn't happened in a long time.

One of the wonderful aspects about free software is Freedom No. 1: The freedom to study how the program works, and adapt it to your needs. So do as you see fit, but bear in mind that the folks here are merely trying to help you.

drumz · 09-18-2006, 12:59 AM

Don't give me credit for creating a local shutdown script. In current's rc.K:

Code:

...
# Try to turn off accounting:
if [ -x /sbin/accton -a -r /var/log/pacct ]; then
  echo "Turning off accounting."
  /sbin/accton
fi

# Run any local shutdown scripts:
if [ -x /etc/rc.d/rc.local_shutdown ]; then
  /etc/rc.d/rc.local_shutdown stop
fi

# Stop the Apache web server:
if [ -x /etc/rc.d/rc.httpd ]; then
  /etc/rc.d/rc.httpd stop
fi
...

It was added a while back.

Franklin · 09-18-2006, 05:18 AM

Quote:

There is no "correct" way other than the method that works best for you! I am no fan of priesthood ideology, so do what pleases you. Life is always a balancing act of potential risk versus the perceived benefits you believe you might receive.

With that said, however, franklin, drumz, and drkstr raise a valid point if you decide to remain with the Slackware distro. With every Slackware release, or at least, every time you update to a newer release, you bear the responsibility of comparing the new rc.d scripts with your existing rc.d scripts. The fewer modifications you make in the current versions, the less work for you when you update.

I lump this rc.d sript issue in with the "do not run as root" concept. Yes you can do it and everything will work just fine, but it can be dangerous. If a newbie decides to edit rc.M, makes a mistake, deletes stuff accidently etc., he may wind up with a non bootable box, or things not working correctly and no idea why.

If you consider this priesthood ideology, so be it. I think it's just being careful. The OP stated in post number 2 that he solved his problem. I wanted to point out to later readers that there may be reasons to do things differently.

Alien Bob · 09-18-2006, 05:29 AM

Quote:

Originally Posted by Franklin

I lump this rc.d sript issue in with the "do not run as root" concept. Yes you can do it and everything will work just fine, but it can be dangerous. If a newbie decides to edit rc.M, makes a mistake, deletes stuff accidently etc., he may wind up with a non bootable box, or things not working correctly and no idea why.

This is Slackware and you're allowed to screw up and learn from your mistakes. People who don't want to learn and just want to "use" a Linux (and yes, these exist in great numbers) should be running Linspire or Xandros.
No flame intended. It's just that people are more and more getting used to the Desktop Manager doing the thinking for them, and Slackware makes you go down hard if you stop thinking for yourself.

Eric