Linux sudo nohup Watchdog Primer Tutorial

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:

  1. be on the Linux path with good chmod permissions
  2. 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:
  1. program modes of access
  2. user priviledges
  3. 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 [ "${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

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

If this was interesting you may be interested in this too.

If this was interesting you may be interested in this too.