help with a startup script for monitorix

graysky · 2011-09-25 14:04:16

How can I deal with a perl script that doesn't acknowledge a query for pidof?

$ ps aux | grep monitorix
root      1089  0.0  1.2  16280  6556 ?        Ss   09:54   0:00 /usr/bin/monitorix -c /etc/monitorix.conf

So it's running... but I can't find it with pidof:

$ pidof /usr/bin/monitorix

Here is the /etc/rc.d/monitorix I've been using but that doesn't stop the program (since it has no PID).

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

PID=`pidof -o %PPID /usr/bin/monitorix`
MARGS="-c /etc/monitorix.conf"

case "$1" in
  start)
   stat_busy "Starting Monitorix"
    if [ -z "$PID" ]; then
       /usr/bin/monitorix $MARGS
    fi
    if [ ! -z "$PID" -o $? -gt 0 ]; then
      stat_fail
    else
      PID=`pidof -o %PPID /usr/bin/monitorix`
      echo $PID > /var/run/monitorix.pid
      add_daemon monitorix
      stat_done
    fi
    ;;

  stop)
    stat_busy "Stopping Monitorix"
    [ ! -z "$PID" ]  && kill $PID &> /dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      rm_daemon monitorix
    else
      rm_daemon monitorix
      stat_done
    fi
    ;;

  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac

falconindy · 2011-09-25 15:01:37

According to the man page, the -p flag will let you generate a PID file.

You have a few logical errors in your rc.d script and a syntax error (double else in stop). I've been using a template similar to the below in cleaning up a few of the packages I maintain...

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

pidfile=/run/monitorix.pid
if [[ -r $pidfile ]]; then
  read -r PID < "$pidfile"
  if [[ ! -d /proc/$PID ]]; then
    # stale pidfile
    unset PID
    rm -f "$pidfile"
  fi
fi

args=(-c /etc/monitorix.conf -p "$pidfile")

case "$1" in
  start)
   stat_busy "Starting Monitorix"
    if [[ -z $PID ]] && /usr/bin/monitorix "${args[@]}"; then
      add_daemon monitorix
      stat_done
    else
      stat_fail
      exit 1
    fi
    ;;

  stop)
    stat_busy "Stopping Monitorix"
    if [[ $PID ]] && kill $PID &> /dev/null; then
      rm_daemon monitorix
      stat_done
    else
      stat_fail
      exit 1
    fi
    ;;

  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac

please also fix the PKGBUILD:

install=('readme.install')

This is not valid, and pacman 4 will not let you declare install as an array.

Last edited by falconindy (2011-09-25 15:05:02)

graysky · 2011-09-25 17:30:34

thanks falconindy - I think you have two mistakes. One in line 6 and don't you need a line under the "stop" case where you [[ -f $pidfile ]] && rm -f $pidfile for it to work correctly?

Line 6:
pidfile=/var/run/monitorix.pid

Last edited by graysky (2011-09-25 18:05:01)

falconindy · 2011-09-25 17:51:37

No, /run/monitorix.pid is intentional. Looking at the source, there's no evidence of monitorix killing off its own PID file on exit, so sure... rm would be a nice addition. The stale pidfile check at the top of the script would be sufficient if it checked the process name on finding an existant directory in /proc...

/me makes a note

graysky · 2011-09-25 18:01:15

Why is the /run/monitorix.pid intentional? I'm confused.

FYI - I edited post #3 to include a check then rm.

Last edited by graysky (2011-09-25 18:06:03)

falconindy · 2011-09-25 18:06:28

/run is the new /var/run. The idea is that /var can be a separate partition, but programs might be started which want to write to /var/run before /var is mounted. Therefore, /run should be a tmpfs which is mounted early. We currently do this, but we don't take the additional extra step (yet) of making /var/run a symlink back to /run, or bind mounting /run onto /var/run.

graysky · 2011-09-25 18:11:28

Nice, thanks. I just updated the AUR package.

One related question: what's wrong with my backup syntax? I just updated the PKG on my machine but pacman didn't install "$srcdir"/monitorix.conf to /etc/monitorix.conf.pacnew -- it took no action at all.

Last edited by graysky (2011-09-25 18:12:20)

falconindy · 2011-09-25 18:14:36

Looks fine to me... When in doubt, check the .PKGINFO file created (just inside the $pkgdir):

...
backup = etc/monitorix.conf
...

Which is correct. You should only get a .pacnew if a backup file changes in the package. If you modify your config file on disk and upgrade the package (without modifying the backup file in the package), no new config file will be installed. The full behavior of this is documented in pacman's manpage.

Last edited by falconindy (2011-09-25 18:16:21)

graysky · 2011-09-25 18:38:53

@falconindy - I read those man pages particularly the lines showing the examples, X Y and Z. Problem is that local *is* different from PKG in my case (I defined my hostname therein and some other stuff), but the pacnew didn't get written.

falconindy · 2011-09-25 18:52:46

Your scenario falls under the 3rd situation described by the manpage, and mirrors what I wrote earlier (#8):

original=X, current=Y, new=X
    Both package versions contain the exact same file, but the one on the filesystem has been modified. Leave the
    current file in place.

You've changed the local file on disk, but the package still provides the same file. There's no need to create a pacnew.

graysky · 2011-09-25 19:23:13

@falconindy - I don't think this is true. This situation != the 3rd situation in the manpage. There should never be a case where the local copy is the same as either of the other files because the user should have defined variables inside it such as hostname, and specifics to his/her hardware. In this situation v2.2.0 --> 2.3.0, and the author has added changes to this file; the user needs to merge them. So here all three are different. Am I wrong or confused?

original=X, current=Y, new=Z
All three files are different, so install the new file with a .pacnew extension and warn the user.
The user must then manually merge any necessary changes into the original file.

falconindy · 2011-09-25 19:38:52

Then you failed to accurately describe your scenario

Yes. The conf file varies between 2.2 and 2.3. I can only tell you the following:

1) Install 2.2.0-1. No pacnew is created because the file didn't exist.
2) Change the config file.
3) Install 2.2.0-2. No pacnew is created because the config file from the package hasn't changed.
4) Install 2.3.0-1. A pacnew will be created. The config file between 2.2 and 2.3 is different, and the new one will be installed as ${rootdir}etc/monitorix.conf.
5) Merge the files or don't. Make changes or don't.
5) Install 2.3.0-2. No pacnew is created. Same as #3.

So the only case where a pacnew is created is in the upgrade to 2.2.0 to 2.3.0, and only because you made changes to the config file for 2.2.0.

This functionality is working as intended. We have numerous tests as part of our test suite which ensure that this behavior is correct whenever we make changes (or Dan gets the hose again). I'm not sure what it is you're seeing, but nothing in the PKGBUILD is wrongly stated.

Arch Linux

#1 2011-09-25 14:04:16

help with a startup script for monitorix

#2 2011-09-25 15:01:37

Re: help with a startup script for monitorix

#3 2011-09-25 17:30:34

Re: help with a startup script for monitorix

#4 2011-09-25 17:51:37

Re: help with a startup script for monitorix

#5 2011-09-25 18:01:15

Re: help with a startup script for monitorix

#6 2011-09-25 18:06:28

Re: help with a startup script for monitorix

#7 2011-09-25 18:11:28

Re: help with a startup script for monitorix

#8 2011-09-25 18:14:36

Re: help with a startup script for monitorix

#9 2011-09-25 18:38:53

Re: help with a startup script for monitorix

#10 2011-09-25 18:52:46

Re: help with a startup script for monitorix

#11 2011-09-25 19:23:13

Re: help with a startup script for monitorix

#12 2011-09-25 19:38:52

Re: help with a startup script for monitorix

Board footer