Re: start-stop-daemon on an inotify script
Hi Bob,
thanks a lot for stepping in and all your comments on the script and its
usage.
I did not want to have too much attention on my inotify script, so I
stripped it down to something simpler, that still is doing something
useful. It seems I failed in the simplification...
Bob Proulx <bob@proulx.com> writes:
> 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.
>
True. Will do.
>> 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?
>
Yes, you are right. I did not notice, as I do not actually run that
exact script.
>> "$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.
>
I do not see any alternative to that pipe. Setting up the recursive
watches takes some time, and I think the piping is the intended use of
inotifywait if put into monitoring mode.
Your comment, however, prompted me to play more with my script and this
subshell is indeed responsible for the tho 'instances' I am seeing.
>> FILECHANGE=${dir}${file}
>
> Why split dir and file into two variables with the --format only to
> immediately join them together again here?
>
True again. This also stems from my 'simplification'. In the longer
script, that I run, I need both.
>> 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.
>
That I did not know, indeed. Thanks for that.
>> 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
Of course I do not intend to use it that way. I want to use
start-stop-daemon in an init script.
I just made it a one-liner to make it more copy-paste-able for the
readers of this list.
I could have sent my init script. But then the attention would have
been on my poor init-script-writing instead of the question on the
behaviour of start-stop-daemon.
> 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. :-)
Here again, the LOGFILE was used in my original script and while stripping
the script I did not revise that command line.
>
> 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
>
Thanks. Very handy. I do something like this in the original script.
But not as elegant as this.
>> 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.
>
Unfortunately, the new arguments to start-stop-daemon do not improve
things for me. This is the effect I get -- regardless of the way I use
start-stop-daemon on the script:
,----
| > ps -A | grep inoti
| 9027 pts/5 00:00:00 testinotify
| 9028 pts/5 00:00:00 inotifywait
| 9029 pts/5 00:00:00 testinotify
`----
>> 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.
Thanks for that. Together with your comment on the subshell, this was
the way to go. I was able to solve my problem.
Thanks again for all your comments.
Regards,
Andreas
Reply to: