[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: start-stop-daemon on an inotify script

Andreas Leha wrote:
> No one?
> Is there anything, I should add to the question?

Since no one else is jumping in...
> Consider this stripped down script (placed at
> /usr/local/bin/testinotify) around inotifywait:
> #+begin_src sh
>   #!/bin/bash

You haven't used any bash specific features.  I would use #!/bin/sh
and stay generic.

>   WATCHDIR="/tmp/testinotify"
>   inotifywait -mr --timefmt '%d/%m/%y %H:%M' --format '%T %w %f' \
>       -e modify -e create -e close_write \

Why both (modify|create) and close_write?  You will get two lines for
every change that way.  Why not just close_write?

>       "$WATCHDIR"  | while read date time dir file; do

Note that by using a pipeline the while loop will occur within a
subshell.  That is perfectly okay.  But just remember that no
environment variables can be returned from it.

>       FILECHANGE=${dir}${file}

Why split dir and file into two variables with the --format only to
immediately join them together again here?

>       chgrp users "$FILECHANGE"
>       chmod g+rw "$FILECHANGE"
>       if [ -d "$FILECHANGE" ]; then
>           chmod g+x "$FILECHANGE"
>       fi

See the 'X' (capital X) mode.  Instead of the above to this:

      chgrp users "$FILECHANGE"
      chmod g+rwX "$FILECHANGE"

The documentation says:

  $ info -f coreutils --index-search 'Conditional Executability'

  27.2.4 Conditional Executability
  There is one more special type of symbolic permission: if you use `X'
  instead of `x', execute/search permission is affected only if the file
  is a directory or already had execute permission.

     For example, this mode:


  gives all users permission to search directories, or to execute files if
  anyone could execute them before.

>       echo "At ${time} on ${date}, file $FILECHANGE was chmodded" >> "$1"
>   done
> #+end_src
> If I run this "by hand" via
>   testinotify /var/log/testinotify.log
> everything works as expected.
> Here is my question: If I run this via start-stop-daemon as in
>   PIDFILE=/var/run/testinotify.pid && DAEMON=/usr/local/bin/testinotify && LOGFILE=/var/log/testinotify.log && start-stop-daemon --start --quiet --oknodo --pidfile "$PIDFILE" --make-pidfile --startas "$DAEMON" -- $LOGFILE &

Please, my eyes, my eyes!  Think of the kittens.  :-)

Why are you chaining those together into a long compound command?  Why
are you putting it in the background?  What will your script do with
the $LOGFILE argument?  It looks like it will do nothing with it to
me.  Yes, yes, I know.  If you knew those answers you wouldn't have
written it that way. :-)

Try this instead.  Because if a variable assignment fails then you
don't have an effective way of dealing with it.  so might as well make
it more readable instead.  Plus a completely new set of options to
start-stop-daemon.  Plus there won't be collisions with other
variables if you use lower case names.

  start-stop-daemon --start --quiet --background \
    --pidfile "$pidfile" --make-pidfile \
    --exec "$daemon" -- "$logfile"

And then modify your script to take a logfile argument.  The part
after the "--" part above is passed to your script.  Your script isn't
currently doing anything with it.  I lack the time to write something
up about it right now.

Hint: I would test for the presence and then just redirect everything
off to it.  All output after this statement will be redirected to the
specified file.

  exec > "$logfile" 2>&1 </dev/null

> I get two instances of my script running.
> Why is that and how can I avoid that?

I don't know.  I didn't look.  But having start-stop-daemon know that
the process isn't a true daemon and telling start-stop-daemon to
handle the backgrounding itself will I am sure improve things.

> The bad effect is, that killing the process with pid recorded by
> start-stop-script is not even stopping the inotifywait.

I didn't have time to test this so I don't know but your script may
need to handle its own cleanup better.  The kill will go to the script


Attachment: signature.asc
Description: Digital signature

Reply to: