Is it safe to modify init scripts like rc.0/rc.6 on Slackware?

I need to modify the shutdown behaviour of a Slackware system, specifically I need to instruct a UPS controlled using nut to shutdown the inverter and related.

rc.local_shutdown is called to early for this to work, is it safe to modify rc.0/rc.6 directly, or will they just be overwritten on the next sysvinit update?

Thanks

I suppose you haven't installed it via SlackBuilds.org: please see README.SLACKWARE
here

https://slackbuilds.org/repository/14.2/system/nut/

Originally Posted by maxf130 is it safe to modify rc.0/rc.6 directly

"Safe" is a relative word. As long as you don't botch anything, you can make any edits you want to the startup/shutdown files. However, if you do it wrong, it is possible to prevent proper startup/shutdown procedures from occurring.

I don't say that to dissuade you from editing them, just giving you the info

The Slackware startup/shutdown scripts are good defaults and work for most people. However, there will always be cases that some users will need to edit the scripts, so don't worry about that.

Originally Posted by maxf130 or will they just be overwritten on the next sysvinit update?

If you check the SlackBuild for sysvinit-scripts, it states the following:

# Install Slackware scripts and config files from $CWD/scripts/:
mkdir -p $PKG/etc/rc.d
for file in rc.{4,6,K,M,S} rc.cpufreq rc.local rc.loop rc.sysvinit rc.modules rc.modules.local ; do
  cp -a $CWD/scripts/$file $PKG/etc/rc.d/${file}.new
  chmod 755 $PKG/etc/rc.d/${file}.new
  chown root:root $PKG/etc/rc.d/${file}.new
done

The key thing here is that they're being copied as .new files. That means that when the package is upgraded, it will check the existing files and if they aren't the same, it will keep the new files as .new and your existing files as the original. If you use slackpkg, it will prompt you to deal with these new files.

Although, in general, if you make complex edits to complex files like some of the rc scripts, I'd recommend writing down what you did (or maybe making a diff). That way, if something goes wrong, you're able to easily see what you did (whether it is to restore or revert the changes).

rc.local_shutdown is called to early for this to work, is it safe to modify rc.0/rc.6 directly, ...

Had a similar situation where rc.local is called "too soon" so used a sub process that sleeps and/or waits for the correct conditions, eg:

#!/bin/bash
( sleep 1; logger -st rc.local_shutdown "its a test" ) & disown

Otherwise comment clearly and edit away.

Cheers,

http://www.linuxquestions.org/questi...ml#post5635707

I haven't checked -current to see if anything's been done; I'd expect this to be pretty far down the to-do list.

Originally Posted by ponce I suppose you haven't installed it via SlackBuilds.org:

I did but I missed the README.SLACKWARE...

Thanks very much for everyones responses, edits are made, the ups works and I know where to check for similar info next time :-D.

I would suggest making a 'simple' edit to the script that will be easy to merge with future distro releases of the script, this will show up as a .new file as others have mention when that package is installed.

If you need something to run at the very end of the script consider adding something like:

if [ -d /etc/rc.d/shutdown_local ]; then
 for I in  /etc/rc.d/shutdown_local/*; do
   if [ -x $I ]; then
     . "$I"
   fi 
 done
fi

then create an /etc/rc.d/shutdown_local directory and put your complex logic in files located there, set to execute obviously. If nothing else it will help manage the variable scope and ensure the 'hard parts' of what you are trying to do never accidentally get overwritten.

If you're going to do that, I would probably suggest using /etc/rc.d/rc.local_shutdown.d/ as similar directories in /etc/ typically contain a .d after the name (see /etc/X11/xorg.conf.d/, /etc/profile.d/, /etc/cron.d/, /etc/modprobe.d/, etc), and the rc. follows the standard naming convention for Runtime Configuration.

But these are just my opinions. I don't know of any standardized naming conventions for this scenario.

Luckily, I don't have anything that needs this type of complexity

bassmadrigal is of course right, if you are doing this on a single personal system than it probably does not matter. If it a business system or might ever be maintained by someone else his suggestion is a good one. Even if the naming convention might not apply perfectly here it will at least give someone a general clue as to what you did.