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:
a+X
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.
pidfile=/var/run/testinotify.pid
daemon=/usr/local/bin/testinotify
logfile=/var/log/testinotify.log
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
interpreter.
Later...
Bob
Attachment:
signature.asc
Description: Digital signature