SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Been looking around, majority of these answers are around 2004-2008 and even so, they are rather confusing. Do I put a command in rc.M or rc.local ? At the moment I just put a command like this in rc.local "/etc/rc.d/rc.vsftpd &" without "" and that seems to work...but is this correct? Will Slackware properly shutdown the process when shutting down?
As you've probably already figured out, rc.M will attempt to execute rc.local so you can use either.
I also put mine in to rc.local, as that seems to be exactly what it was meant for.
For shutdown, if your app does not respond to the sighup/kill signal before shutdown, you can put your 'stop the app' command in to "rc.local_shutdown".
(You may have to create rc.local_shutdown and make it executable.)
The rc.K script will attempt to execute rc.local_shutdown if it exists & is executable.
Been looking around, majority of these answers are around 2004-2008 and even so, they are rather confusing. Do I put a command in rc.M or rc.local ? At the moment I just put a command like this in rc.local "/etc/rc.d/rc.vsftpd &" without "" and that seems to work...but is this correct? Will Slackware properly shutdown the process when shutting down?
Uncomment the following line in /etc/inetd.conf:
Code:
# Very Secure File Transfer Protocol (FTP) server.
#ftp stream tcp nowait root /usr/sbin/tcpd vsftpd
I realize your specific situation was answered by kikinovak, but since you were confused, the below is to try an un-muddy the waters (hopefully I don't make it worse).
For anything that isn't already built into Slackware (like kikinovak showed you with vsftpd), the general consensus is to add any additional commands to your rc.local (if you add it to rc.M, it can cause issues with system upgrades or Slackware patches if there's changes made to rc.M). It is generally preferred that any new program installed on the system that needs to start at bootup (commonly called a daemon) should have it's own rc.program_name in /etc/rc.d that supports the start/stop/restart commands (most of these types of programs on SBo will have the needed rc.program_name file included). With these, it's preferred to call them in rc.local after checking to see if they're executable (this makes it follow the Slackware way of only needing to make the file executable to have it run, and if it isn't executable, you won't get an error because of it):
Code:
# Start program_name
if [ -x /etc/rc.d/rc.program_name ]; then
/etc/rc.d/rc.program_name start
fi
If the program doesn't have an rc.program_name, you can either insert the command directly in rc.local, or you can create your own rc.program_name file. The below is a simple example, depending on the startup/shutdown procedure of your program, it can be more complicated (if the program just needs to be run to start, you might just be able to replace program_name with the name of the program and save the file -- if it is more complicated, it might take a bit more editing).
As for correctly shutting down the process, unless it is called somewhere else (like the rc.shutdown_local that Hangaber mentioned), Slackware will just send a SIGNAL code to close the program (I think it's actually two codes, with the second one being more severe to force it to close if the first one didn't do it -- but I can't remember which ones). If you want the program to actually shut down properly (if your program has that option), you can input the command in rc.shutdown_local just like rc.local file, but change it to the command to shut down the program (if you made your own rc.program_name, I would suggest putting the shutdown command in there, replacing the killall command under the stop), then, in the rc.shutdown_local, you could just add the if check to see if the rc.program_name is executable and then just add /etc/rc.d/rc.program_name stop, which will properly shut down the program rather than have Slackware manually killing it.
Here is a practical example of bassmadrigal's statement. It illustrates that you can display inconsistencies (like trying to start a service already running, or stop a non started service) and also the service' status.
Code:
#!/bin/sh
#
# Start/stop brltty
#
brltty_start() {
if [ ! "`ps -C brltty --noheaders|wc -l`" = "0" ]; then
echo "brltty is already started."
brltty_status
exit
fi
if [ -x /bin/brltty ]; then
echo "Starting brltty daemon: /bin/brltty "
/bin/brltty
fi
}
brltty_stop() {
NBPROC="`ps -C brltty --noheaders|wc -l`"
if [ "$NBPROC" = "1" ]; then
echo "Stopping brltty..."
PID="`ps -C brltty --noheaders -o pid`"
kill $PID
elif [ "$NBPROC" = "0" ]; then
echo "brltty is not started."
else
echo "I can't stop brltty, several daemons are running:"
brltty_status
fi
}
brltty_status () {
NBPROC="`ps -C brltty --noheaders|wc -l`"
if [ "$NBPROC" = "0" ]; then
echo "No active brltty daemon."
elif [ "$NBPROC" = "1" ]; then
echo "A brltty daemon is running, PID: `ps -C brltty --no-headers -o pid`"
else
ps -C brltty -o pid,args
fi
}
case "$1" in
'start')
brltty_start
;;
'stop')
brltty_stop
;;
'restart')
brltty_stop
sleep 3
brltty_start
;;
'status')
brltty_status
;;
*)
echo "usage $0 restart|start|status|stop|"
esac
Last edited by Didier Spaier; 06-30-2015 at 01:01 PM.
Reason: Typo
I realize your specific situation was answered by kikinovak, but since you were confused, the below is to try an un-muddy the waters (hopefully I don't make it worse).
For anything that isn't already built into Slackware (like kikinovak showed you with vsftpd), the general consensus is to add any additional commands to your rc.local (if you add it to rc.M, it can cause issues with system upgrades or Slackware patches if there's changes made to rc.M). It is generally preferred that any new program installed on the system that needs to start at bootup (commonly called a daemon) should have it's own rc.program_name in /etc/rc.d that supports the start/stop/restart commands (most of these types of programs on SBo will have the needed rc.program_name file included). With these, it's preferred to call them in rc.local after checking to see if they're executable (this makes it follow the Slackware way of only needing to make the file executable to have it run, and if it isn't executable, you won't get an error because of it):
Code:
# Start program_name
if [ -x /etc/rc.d/rc.program_name ]; then
/etc/rc.d/rc.program_name start
fi
If the program doesn't have an rc.program_name, you can either insert the command directly in rc.local, or you can create your own rc.program_name file. The below is a simple example, depending on the startup/shutdown procedure of your program, it can be more complicated (if the program just needs to be run to start, you might just be able to replace program_name with the name of the program and save the file -- if it is more complicated, it might take a bit more editing).
As for correctly shutting down the process, unless it is called somewhere else (like the rc.shutdown_local that Hangaber mentioned), Slackware will just send a SIGNAL code to close the program (I think it's actually two codes, with the second one being more severe to force it to close if the first one didn't do it -- but I can't remember which ones). If you want the program to actually shut down properly (if your program has that option), you can input the command in rc.shutdown_local just like rc.local file, but change it to the command to shut down the program (if you made your own rc.program_name, I would suggest putting the shutdown command in there, replacing the killall command under the stop), then, in the rc.shutdown_local, you could just add the if check to see if the rc.program_name is executable and then just add /etc/rc.d/rc.program_name stop, which will properly shut down the program rather than have Slackware manually killing it.
Slackware's init system is SysV compatible, isn't it?
So, I usually create one universal starter/stopper script in /etc/rc.d/ or /etc/rc.d/init.d (or whereever you like) and setup symlinks from /etc/rc.d/rc[0123456].d/ (or /etc/rc[0123456].d/ which are symlinks to former locations).
Such scheme allows Package.t?z to install service control scripts as files, not as patches to system scripts(in doinst.sh). And when package is being removed, service control scripts will be cleanly removed from system. No more edit conflicts, startup sequence control.
Slackware's init system is SysV compatible, isn't it?
So, I usually create one universal starter/stopper script in /etc/rc.d/ or /etc/rc.d/init.d (or whereever you like) and setup symlinks from /etc/rc.d/rc[0123456].d/ (or /etc/rc[0123456].d/ which are symlinks to former locations).
Such scheme allows Package.t?z to install service control scripts as files, not as patches to system scripts(in doinst.sh). And when package is being removed, service control scripts will be cleanly removed from system. No more edit conflicts, startup sequence control.
Each one is entitled to one's way.
But be careful: knowing how same folks react on this forum, maybe you just opened a can of worms or Pandora's box or <your preferred metaphor here>
Last edited by Didier Spaier; 06-30-2015 at 07:53 AM.
i think it is
i do remember seeing something ugly about it in the init scripts
Nothing ugly.
/etc/rc.d/init.d/README.functions says:
Code:
If you're reading this in /etc/init.d/, Slackware's real init directory is
/etc/rc.d/. Maybe you already knew this, but it never hurts to say. :-)
This script was taken from Fedora (and is presumably licensed under the GPL).
While I don't see Slackware init scripts making much use of it (but use it
if you wish), some third party init scripts (such as for commercial software
designed to run on Red Hat based systems) expect this script and use it in
their own init scripts, so it's a good idea to make it available here.
These functions are provided solely for commercial (or other) software that
expects to find "Red Hat-isms". I wouldn't use them to write new init
scripts (personally), but if you've had experience with them in the past
and like them, by all means feel free.
It's planned to continue support for them.
Of course "this script" refers to /etc/rc.d/init.d/functions.
Last edited by Didier Spaier; 06-30-2015 at 09:49 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.