path: keepalived_1:2.3.4-1/doc/samples/keepalived.conf.vrrp.localcheck
vrrp_script chk_haproxy {
       script "killall -0 haproxy"     # cheaper than pidof
       interval 2                      # check every 2 seconds
}


path: keepalived_1:2.3.4-1/doc/samples/keepalived.conf.vrrp.localcheck
vrrp_script chk_sshd {
       script "killall -0 sshd"        # cheaper than pidof
       interval 2                      # check every 2 seconds
       weight -4                       # default prio: -4 if KO


path: keepalived_1:2.3.4-1/TODO
	    Add PROCESS_CHECK for checkers
	    - Find PID and remember it. If PID has gone, try and find new pid
	    Look at how pidof/killall find processes
	* Allow dynamic definitions, e.g. $_VI_NAME
	    Also $*_INSTANCE net_namspace $_INSTANCE


path: keepalived_1:2.3.4-1/ChangeLog
	  Configurations frequently include a track_script to check that a process
	  is running, often haproxy or nginx. Using any of pgrep, pkill, killall,
	  pidof, etc, has an overhead of reading all /proc/[1-9]*/status and/or
	  /proc/[1-9]*/cmdline files. In particular reading the cmdline files
	  has a significant overhead on a system that is swapping, since the


path: keepalived_1:2.3.4-1/ChangeLog
	* Preserve filename in script path name resolution.
	  Some executables change their behaviour depending on the name by
	  which they are invoked (e.g. /usr/sbin/pidof when it is a link to
	  /usr/sbin/killall5). Using realpath() changes the file name part
	  if it is a symbolic link. This commit resolves all symbolic links


path: keepalived_1:2.3.4-1/doc/man/man5/keepalived.conf.5.in
.PP
On a busy system with a high number of process creations/terminations, using a
track_script with pgrep/pidof/killall may be more efficient, although those processes
are inefficient compared to the minimum that keepalived needs.
.PP


path: keepalived_1:2.3.4-1/doc/man/man5/keepalived.conf.5.in
Likewise, if the vrrp instance is the address owner, weight 0 must also be set.
.PP
Rational for not using pgrep/pidof/killall and the likes:
.PP
Every time pgrep or its equivalent is run, it iterates though the /proc/[1-9][0-9]*