I have several init.d scripts that I'm using to start some daemons. Most of these scripts I've found on the internet and they all use start-stop-daemon. My understanding is that "start-stop-daemon" is a command that is specific to Linux or BSD distros and is not available on Solaris.
What is the best way to translate my init.d scripts from Linux to Solaris? Is there a command equivalent to start-stop-daemon that I can use, roughly?
Since I'm not much of a Solaris user, I'm willing to admit upfront that I don't even know if my question is inherently invalid or not.
start-stop-daemon is a Linux thing, and not used that much on Solaris. I guess you can port the command though, if you want to reuse your init scripts.
Otherwise it depends on what version of Solaris you are using. Starting with Solaris 10 and also OpenSolaris they use a new startup script framework "Solaris Service Management Facility", which you configure with the commands svcs, svccfg and svcadm.
See http://www.oracle.com/technetwork/server-storage/solaris/overview/servicemgmthowto-jsp-135655.html for more information.
For older Solaris releases most init scripts are written in pure shell without any helper commands like start-stop-daemon.
On Solaris 10 or later using SMF is recommended, but on an earlier release you'd create an init script in /etc/init.d and link to it from the rcX.d directories. Here's a bare-bones example of an init script for launching an rsync daemon:
#!/sbin/sh
startcmd () {
/usr/local/bin/rsync --daemon # REPLACE WITH YOUR COMMANDS
}
stopcmd () {
pkill -f "/usr/local/bin/rsync --daemon" # REPLACE WITH YOUR COMMANDS
}
case "$1" in
'start')
startcmd
;;
'stop')
stopcmd
;;
'restart')
stopcmd
sleep 1
startcmd
;;
*)
echo "Usage: $0 { start | stop | restart }"
exit 1
;;
esac
Create a link to the script from each rcX.d directory (following the "S"/"K" convention).
ln rsync /etc/rc3.d/S91rsync
for i in `ls -1d /etc/rc*.d | grep -v 3`; do ln rsync $i/K02rsync; done
See the README in each rcX.d directory and check the man page for init.d. Here's a bit of the man page:
File names in rc?.d directories are of the form
[SK]nn, where S means start this job, K means
kill this job, and nn is the relative sequence number for killing or
starting the job.
When entering a state (init S,0,2,3,etc.) the rc[S0-6] script
executes those scripts in /etc/rc[S0-6].d that are prefixed with K
followed by those scripts prefixed with S. When executing each
script in one of the /etc/rc[S0-6] directories, the /sbin/rc[S0-6]
script passes a single argu- ment. It passes the argument 'stop'
for scripts prefixed with K and the argument 'start' for scripts
prefixed with S. There is no harm in applying the same sequence
number to multiple scripts.
Related
I need to create a SSH BASH script (on Debian linux) to test if 'java' process is running.
Here how it should look like:
IF 'java' process is not running THEN run ./start.sh
to test if java process is running, I can make this test:
ps -A | grep java
This script should run every minute (I guess in a CRON)
Regards
First of all, to run a job every minute in cron, your crontab should look like this:
* * * * * /path/to/script.sh
Next, you have a few different options for detecting a Java process.
Note that each of the following is a negation: they detect the absence of Java:
With pgrep:
if [ ! $(pgrep java) ] ; then
# no java running
fi
With pidof:
if [ ! $(pidof java) ] ; then
# no java running
fi
With ps and grep:
if [ ! $(ps -A | grep 'java') ] ; then
# no java running
fi
Of these, pgrep and pidofare probably the most efficient. Don't quote me on that, though.
The check you are doing with PS and GREP doesn't look very detailed. What if other Java processes are running ? You may detect those, and come to a wrong conclusion, because you are just checking "any" Java, not some specific Java.
With pidof would be something like this:
script.sh
pidof java;
if[$? -ne 0];
then
# here put your code when errorcode of `pidof` wasn't 0, means that it didn't find process
# for example: /home/user/start.sh
# (please don't forget to use full paths if you want to use it in cron)
fi
Especially for haters:
man pidof:
EXIT STATUS
0 At least one program was found with the requested name.
1 No program was found with the requested name.
I created the script file -
#!/bin/sh
echo "my application is here"
./helloworld # helloworld is our application
after creating the script file i copied it in init.d
I gave the command chmod +x /etc/init.d/vcc_app (vcc_app is the name of script which I have created)
Then I gave the command ln -s /etc/init.d/vcc_app /etc/rc.d/vcc_app (rc.d is the run level directory)
But when i reboot the board my application is not executed automatically. Can anyone help me out?
Scripts that are in /etc/init.d need to be LSB-compliant.
If you simply want to automatically run commands at the end of the boot process, try placing them in /etc/rc.local instead.
Not all linux systems use the same init daemon (ubuntu uses upstart: http://upstart.ubuntu.com/getting-started.html), but they all use start and stop functions in the script. Other common functions are status and restart, but again, there is no true across the board standard. Eg:
!#/bin/sh
start () {
echo "application started";
./helloworld # you should use an absolute path here instead of ./
}
stop () {
}
case "$1" in
start)
start
;;
stop)
stop
;;
*)
echo "Usage start|stop";
esac
exit $?
The last bit is a switch based on the first command line arg, since init will invoke the script myrcscript start.
In order to use stop() (and the also often useful restart()) you need to keep, or be able to get, the pid of the process launched by start(); sometimes this is done with a little "pid file" in /tmp (text file containing the pid, eg, /tmp/myscript.pid created in start()).
The "upstart" init daemon used on Ubuntu has its own specific features, but unless you need to use them, just keep it stop/start minimal and it will (probably) work anywhere.
How to execute one or more commands and scripts when ubuntu shutdown? Is there any script like /etc/profile and ~/.bashrc at system starting?
I know linux shutdown may have many causes, in addition to dealing with the kill signal, where can I get for this reason?
Is there any script like /etc/profile and ~/.bashrc at system starting?
The SysV Init scripts (/etc/init.d/*) are invoked at startup. A trivial/easy way to invoke some activity at system startup is to put it into /etc/init.d/local (/etc/rc.local for some other distros). See also: RcLocalHowto.
How to execute one or more commands and scripts when ubuntu shutdown?
It sounds as if you want to create a real init script that gets started on entering runlevels X-Z and stopped on exiting them. See also: UbuntuBootupHowto.
I know linux shutdown may have many causes, in addition to dealing with the kill signal, where can I get for this reason?
To do this noninteractively is not straightforward. You can grep through the system logs, looking for indications from shutdown.
There is a ~/.bash_logout file that executes when you log out of Ubuntu 11.04
I am not sure, but assume there is a similar script in 10.04
Hope this helps.
You can put your script in /etc/rc0.d (for halt) and /etc/rc6.d/ (for reboot). Make sure script has executable permission.
There is differents run level :
* 0 System Halt
* 1 Single user
* 2 Full multi-user mode (Default)
* 3-5 Same as 2
* 6 System Reboot
Run level 0 is the system halt condition. When run level 0 is reached all scripts in /etc/rc0.d are exectute.
Run level 6 is used to signal system reboot. This is the same as run level 0 except a reboot is issued at the end of the sequence instead of a power off.
If you want to execute your script on hibernate or on sleep, put your script in /etc/pm/sleep.d/
This is a example of script :
#!/bin/sh
WLANSTATUS=`cat /sys/class/ieee80211/phy*/rfkill*/state`
test -z $WLANSTATUS && exit 1
case $1 in
hibernate)
# Do something before hibernate
;;
suspend)
# Do something before sleep
;;
thaw)
# Do something after hibernate
;;
resume)
# Do something after sleep
if [ $WLANSTATUS = 0 ]; then
echo 0 > /sys/devices/platform/asus_laptop/wlan
elif [ $WLANSTATUS = 1 ]; then
echo 1 > /sys/devices/platform/asus_laptop/wlan
fi
;;
*) echo "somebody is calling me totally wrong."
;;
esac
Have fun !
I have a script which uses killproc and procofpid commands and executes fine on a 64bit suse. But when I executed the script on 32bit redhat , I found that the above commands donot exist.
I don't have a 32bit Suse and 64bit redhat machines to test my script.
Is my guess right that on 64bit redhat the above commands should be available?
Or are the above commands specific to Suse and redhat?
Thanks
killproc is in redhat enterprise linux 5.4 as part of /etc/init.d/functions
if you need it just do
. /etc/init.d/functions
in your script to load the shell functions, its probably in other versions of redhat but thats the only one i have to hand at the moment
These commands are defined as part of the Linux Standards Base (LSB), as noted by #AndreKR.
However, on some systems like Redhat (and probably SUSE), depending on packages installed, these functions may not be defined in the location specified by the LSB, which is /lib/lsb/init-functions. Rather they are defined within /etc/init.d/functions. In addition, in some versions, the Redhat variant of /etc/init.d/functions is missing the LSB-defined function start_daemon. If you add the following snippet to the top of your script, it should be portable across most distributions/installs:
if [[ -f /lib/lsb/init-functions ]]; then
. /lib/lsb/init-functions
elif [[ -f /etc/init.d/functions ]]; then
. /etc/init.d/functions
# Pretend to be LSB-compliant
function start_daemon() {
daemon $*
}
else
echo "Linux LSB init function script or Redhat /etc/init.d/functions is required for this script."
echo "See http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html"
exit 1
fi
The commands are unlikely to be portable. Actually this is first time I hear about them - but I guess your problem is to work with process by the name, not pid.
Check the man pgrep or man pkill - they are slightly bit more portable. They are part of procps package (where ps and top come from) and should be available on all Linux variants. They are also available on Solaris.
The ones used in Ubuntu are part of the specification "Linux Standard Base" and are documented there.
I think those commands are distrib specifics: I have never seen them before.
killproc should be a kind of kill but what is procofpid supposed to do?
In the title you speak about pidofproc, you can find this command under the pidof on most linux boxes.
I had the same problem as you, it gave the warning:
pidof: invalid options on command line!
I changed the
"killproc -d 10 $cmd"
to
"kill -9 \`pidof $cmd\`"
I have this running:
if (open(PS_ELF, "/bin/ps -eLf|")) {
while (<PS_ELF>) {
if ($_ =~ m/some regex/) {
# do some stuff
}
}
}
If called locally, the loop runs just fine, once for every output line of ps -eLf
Now if the same script is called from Nagios via NRPE, PS_ELF does only contain one line (the first line output by ps).
This puzzles me; what could be the reason?
Maybe this is not limited to/caused by Nagios at all, I just included it for the sake of completeness.
I'm on SUSE Enterprise Linux 10 SP2 and perl v5.8.8.
Although this problem is very old, I experienced the exact same problem today.
So I thought I share what I found.
The problem is that processes created by the NRPE daemon (can) have a different environment than processes you execute directly in the shell as the NRPE daemon user.
I created the following bash script:
#!/bin/bash
echo `env | grep COLUMNS`
This gives me the environment variable COLUMN of the current process, which has the same environment as the parent process (the process forked by the NRPE daemon).
When I execute this script as the NRPE daemon user
$ /tmp/check_env.sh
COLUMNS=174
it gives me the value of my current shell window.
But when I execute this script via NRPE, I get:
nagios-server $ check_nrpe -H client -c check_env
COLUMNS=80
Which is why ps -eaf output is limited to 80 characters unless you use the ww parameter for unlimited width, which ignores the COLUMNS environment variable.
I changed 'ps -eLf' to 'ps -eLfww' (ww for unlimited output) and this fixed the problem even if I don't understand why there is a difference when called remotely.
It's probably more something to do with how NRPE plugins work than Perl itself.
Your plugin is working like explained here (return code + output) ?