Linux sudo nohup Watchdog Primer Tutorial
Even though it is not good to generalize too much about the workings of a watchdog process (because of environmental differences), even so there are some features that can be pointed out for some Linux ideas, which we’ll discuss regarding Korn Shell scripting:
- we model the slightly generic approach on what we’d do to imagine the resurrection of crontab should it fall over … in researching this, found that it is very hard to knock crontab over for any length of time, because it already protects itself … this brings up the point though, that if you are writing a watchdog for crontab it should not be run via crontab … doh … so that is why there is code in our watchdog to use the Linux command at as an alternative (method) … but for our generic thinking watchdog we lean towards
sudo nohup [watchdog] > [output] 2> [errfile] &
… this also involves allowing our process that runs all the time to:
- be on the Linux path with good chmod permissions
- be written to have functionality to match that of crontab’s argument values … “start”, “restart”, “stop”
- it would be good not to need to use kill -9 [pidlist] but the watchdog is difficult to arrange without this usage … ie. great care is needed with watchdogs … doh
- in conjunction with kill -9 [pidlist] the use of Korn Shell’s $$ to represent the current process’s pid becomes important
- use of sudo to be best able to control Linux processes
- use of nohup to avoid the necessity of being logged on … even so, we are not recommending the code here for occasions when a user is not logged in
- use of & to commands to run them in the background
- ps -ef — for process list in Linux
- the watchdog restarts itself after one cycle of looking, with sudo nohup [watchdog] > [output] 2> [errfile] & rather than using crontab usage for logged in interactive mode of use, primarily … though the code is close to being okay to add two commands to /etc/profile … as discussed in previous Linux Bash Shell Login Primer Tutorial as shown below (the date and time on the prompt can be useful)
- most of watchdog work is in testing scenarios, and trying to imagine the worst, unless you have evidence to the contrary … especially regarding:
- program modes of access
- user priviledges
- file priviledges
- not done (in the code) here, but please leave comments, as required, regarding how to use the watchdog, and why, and when, and where, and who
Here is Linux Korn shell script idea for a process that runs all the time (designed for our Mac OS X Terminal application Bash environment) … we knock it over and get the watchdog to bring it back up … you could call it thing_that_runs_and_runs
Here is Linux Korn shell script idea for the proposed watchdog (just tailor its use for ideas of your own) … we knock over the process above and get this watchdog to bring it back up … you could call it cron_check.ksh
The way it went from a first watchdog concept to resurrect crontab to being a more generic watchdog for system-wide processes that run forever a bit like crontab see the differences link here … and for a good related research topic in Linux in this area look up daemon processes ( in some systems (eg. CentOS) they live in /etc/init.d/ )
A preliminary discussion about watchdog processes at this blog occurred at Linux Watchdog Primer Tutorial.
The book MySQL & mSQL by Randy Jay Yarger, George Reese & Tim King has a good section on pages 74 and 75 regarding a watchdog idea for MySQL process protection.
Please enjoy today’s tutorial ideas.
Previous relevant Linux Bash Shell Login Primer Tutorial is shown below.
Linux Bash Shell Login Primer Tutorial
When you login to Linux the operating system looks to a file called …
/etc/profile
… to perform its commands.
Within that file, if you are in a default Bash environment shell, as we are with Mac OS X application Terminal you may see a line of code, as highlighted in red like …
# System-wide .profile for sh(1)
if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
fi
if [ "${BASH-no}" != "no" ]; then
[ -r /etc/bashrc ] && . /etc/bashrc
fi
… which then proceeds to take commands from a file called …
/etc/bashrc
… which may contain code like …
# System-wide .bashrc file for interactive bash(1) shells.
if [ -z "$PS1" ]; then
return
fi
PS1='h:W u$ '
# Make bash check its window size after a process completes
shopt -s checkwinsize
# Tell the terminal about the working directory at each prompt.
if [ "$TERM_PROGRAM" == "Apple_Terminal" ] && [ -z "$INSIDE_EMACS" ]; then
update_terminal_cwd() {
# Identify the directory using a "file:" scheme URL,
# including the host name to disambiguate local vs.
# remote connections. Percent-escape spaces.
local SEARCH=' '
local REPLACE='%20'
local PWD_URL="file://$HOSTNAME${PWD//$SEARCH/$REPLACE}"
printf 'e]7;%sa' "$PWD_URL"
}
PROMPT_COMMAND="update_terminal_cwd; $PROMPT_COMMAND"
fi
Today, we change this /etc/bashrc file so that a current date and time is added to the Linux prompt (and for advice we thank this excellent link) by the amendment in orange as shown below for /etc/bashrc …
# System-wide .bashrc file for interactive bash(1) shells.
if [ -z "$PS1" ]; then
return
fi
PS1='h:W u d [t]$ '
# Make bash check its window size after a process completes
shopt -s checkwinsize
# Tell the terminal about the working directory at each prompt.
if [ "$TERM_PROGRAM" == "Apple_Terminal" ] && [ -z "$INSIDE_EMACS" ]; then
update_terminal_cwd() {
# Identify the directory using a "file:" scheme URL,
# including the host name to disambiguate local vs.
# remote connections. Percent-escape spaces.
local SEARCH=' '
local REPLACE='%20'
local PWD_URL="file://$HOSTNAME${PWD//$SEARCH/$REPLACE}"
printf 'e]7;%sa' "$PWD_URL"
}
PROMPT_COMMAND="update_terminal_cwd; $PROMPT_COMMAND"
fi
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
12 Responses to Linux sudo nohup Watchdog Primer Tutorial