Of course that you see some/many invocations without any file names when
you trigger on all directory events. All sorts of of processes go by all
sorts of directories all the time on modern desktop. Not all of them look
at files.
What your aim is, I believe/hope, to respond to print file write and close
- and send that file to a printer. Ideally deleting or backing that file
away from the print dir. You want to do that reliably and without multiple
processes acting on any given file.
If you want to debug print job spooler, I would suggest to do just that. Do
exactly what you need to do, keep it simple, and expand from there.
If you are curious about kernel interworks, I would suggest to start
looking at kernel documentation and source code - it is more systematic way
of learning. Unfortunately, I am not the right person to have meaningful
conversation about kernel and VFS events/triggers. My knowledge is too
shallow for that.
Good luck,
Tomas
On Nov 21, 2017 9:44 AM, "Denis Heidtmann" <denis.heidtm...@gmail.com>
wrote:
> It is fully my intention to use only IN_CLOSE_WRITE in the final version.
> I currently am using IN_ALL_EVENTS just to see what the print
> driver/application is doing. In fact, when I first started working on this
> I used just IN_CLOSE_WRITE and saw 4 invocations. That is what sent me
> exploring.
>
> Regarding what is in $1, I see what seems to me to indicate a file name in
> $1 *sometimes*. Why only sometimes? Here is the test script:
> #! /bin/bash
> # test of incron
> echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> echo "test: $1 $2" >> /home/denis/incronlog.log
>
> I get perhaps 270 invocations with IN_ALL_EVENTS. A sampling shows some
> responses with the file name, but no times:
>
> test: IN_ACCESS,IN_ISDIR
> time: test: IN_CLOSE_NOWRITE,IN_ISDIR
> time: test: IN_CLOSE_NOWRITE,IN_ISDIR
> time: test: tst1.PLT IN_OPEN
> time: time: test: tst1.PLT IN_OPEN
> test: tst1.PLT IN_OPEN
> time: test: tst1.PLT IN_CLOSE_NOWRITE
> time: test: tst1.PLT IN_ACCESS
> time: test: tst1.PLT IN_CLOSE_NOWRITE
> time: time: test: IN_CLOSE_NOWRITE,IN_ISDIR
> test: IN_ACCESS,IN_ISDIR
> time: test: tst1.PLT IN_CLOSE_NOWRITE
>
> There are a number of questions raised by this, but I expect that most can
> be explained by the rapid multiple invocations. Does that also explain the
> missing times?
>
> -Denis
>
>
> On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta <
> tomas.kuchta.li...@gmail.com
> > wrote:
>
> > $(some command) will simply execute the command and give return value.
> >
> > You do not see any time stamp because you are not giving stat a file. $1,
> > in
> > your case, doesn't contain file name.
> >
> > I have asked or suggested before to only use IN_CLOSE_WRITE event. That
> is
> > what you want - run the script after the file/dir was written to and is
> > closed. Not the other times when you look at it or read the file with
> your
> > script. Taking those other events off should solve the multiple
> invocation
> > problem.
> >
> > I hope it helps,
> > Tomas
> >
> >
> > On Nov 20, 2017 5:54 PM, "Denis Heidtmann" <denis.heidtm...@gmail.com>
> > wrote:
> >
> > Working my way through the script, trying to understand the behavior.
> Here
> > is a simple test:
> >
> > #! /bin/bash
> > # test of incron
> > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> > echo "test: $1 $2" >> /home/denis/incronlog.log
> > # sleep 10
> >
> > It generates what I would expect when executed from the command line:
> > ~/scripts/intest.sh examples.desktop:
> > time: 1464568514test: examples.desktop
> >
> > But when invoked by incron the line including the time is empty except
> for
> > the word "time:" The time value is absent.
> > time: time: test: IN_ACCESS,IN_ISDIR
> > test: IN_CLOSE_NOWRITE,IN_ISDIR
> > time: test: IN_ACCESS,IN_ISDIR
> > time: test: IN_OPEN,IN_ISDIR
> > time: test: IN_OPEN,IN_ISDIR
> > etc.
> >
> > My knowledge of the use of $, (, ", ', and { is lacking, so I expect
> > that is where the trouble lies.
> >
> > Is the problem obvious?
> >
> > Thanks,
> > -Denis
> >
> > On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta <
> > tomas.kuchta.li...@gmail.com
> > > wrote:
> >
> > > The script I posted does its own locking, so that other copies would
> know
> > > that it is already running and what file it is serving.
> > >
> > > See the lock file being created, checked and removed.
> > >
> > > Tomas
> > >
> > > On Nov 19, 2017 9:10 PM, "Denis Heidtmann" <denis.heidtm...@gmail.com>
> > > wrote:
> > >
> > > > Your script has things in it that stretch my knowledge of Bash, so
> > > > understanding what it does is difficult for me.
> > > >
> > > > I have no experience with file locking. Is this a standard protocol?
> > > > Since the print file is created by a Windows print driver, I wonder
> if
> > > the
> > > > locking which is described in the ubuntu docs is reliably applicable.
> > > >
> > > > This is likely a discussion that stretches what is reasonable to
> > attempt
> > > > via a forum, since I need considerable education.
> > > >
> > > > I appreciate your efforts. I will play with it in an attempt to
> learn
> > > what
> > > > you are proposing, but do not be surprised if it takes me some time.
> > > >
> > > > -Denis
> > > >
> > > >
> > > >
> > > > On Sat, Nov 18, 2017 at 9:17 PM, Tom <tomas.kuchta.li...@gmail.com>
> > > wrote:
> > > >
> > > > > Hi Denis,
> > > > >
> > > > > Try something like the script below.
> > > > > It uses a lock to detect its own invocation as well as multiple
> > > > > invocations of self. If it prints it backs up the printed file, so
> > you
> > > > > should not lose anything, should things go south.
> > > > >
> > > > > Note: I did not properly test it. So, give it good pass over and
> test
> > > > > it before calling it a day. As I said, it should not loose any
> print
> > > > > files and you should know if it prints.
> > > > >
> > > > > Please insert your own print command instead of the echo "" and
> > > > > redirect the output to a log file or /dev/null so it does not end
> up
> > > > > with incron.
> > > > >
> > > > > Beware of broken script lines by the email.
> > > > >
> > > > > I hope that it works as intended or as an example,
> > > > > Tomas
> > > > >
> > > > > #!/bin/bash
> > > > > ##########################################
> > > > > # This command submits a file to print
> > > > > # It is triggered by incron and tries to
> > > > > # gracefully deal with multiple incron invocations
> > > > > # and waits for file to be closed by the
> > > > > # print application.
> > > > > # Example incron line:
> > > > > # printDirToMonitor IN_CLOSE_WRITE submitPrinterJob.bash $#
> > > > > ##########################################
> > > > > lockDir=/tmp/
> > > > > lockFileBaseName=/tmp/submitPrinterJob
> > > > > thisPid=$$
> > > > > fileToPrint=$1
> > > > > printedFilesDir=/home/$USER/printedFilesDir
> > > > > mkdir -p $printedFilesDir
> > > > >
> > > > > searchLockPattern="${lockFileBaseName}_${fileToPrint}_*.lock"
> > > > > myLockFileName="${lockFileBaseName}_${
> fileToPrint}_${thisPid}.lock"
> > > > >
> > > > > # check if the file to print is still there
> > > > > if [ -e $fileToPrint ]; then
> > > > > # Check if another script is running and serving this file
> > > > > # Issue lock if not
> > > > > c=0
> > > > > while (( $c < 2 )); do
> > > > > if [ ! -e $searchLockPattern ]; then
> > > > > # Cannot see any other process'lock
> > > > > touch $myLockFileName
> > > > > else
> > > > > # there is a lock
> > > > > if [ ! -e $myLockFileName ]; then
> > > > > # the lock is not mine --> exit without printing,
> > > > > # make sure not to leave own lock, in case it take time to
> > > > > # show up
> > > > > rm -f $myLockFileName
> > > > > exit 0
> > > > > fi
> > > > > fi
> > > > > # There should be a lock and mine --> do nothing , just wait
> > > > > c=$(( $c + 1 ))
> > > > > sleep 2
> > > > > done
> > > > > # if I got here I got a lock --> send the file to printer
> > > > > if [ ! -e $fileToPrint ]; then
> > > > > echo "WARNING: File $fileToPrint disapeared"
> > > > > else
> > > > > echo "Printing file $fileToPrint"
> > > > > # backing up and removing printed file
> > > > > mv $fileToPrint $printedFilesDir
> > > > > sleep 1
> > > > > # removing lock file
> > > > > rm -f $myLockFileName
> > > > > fi
> > > > > fi
> > > > > exit 0
> > > > > ##########################################
> > > > >
> > > > > On Sat, 2017-11-18 at 15:01 -0800, Denis Heidtmann wrote:
> > > > > > It turns out that the multiple file closings is at least
> partially
> > > > > > attributable to the application, since another application had
> two
> > > > > > closings
> > > > > > rather than four. Using the application with the four closings I
> > > > > > tried
> > > > > > again with a much more complicated drawing. This slowed down the
> > > > > > writing
> > > > > > of the print file to 10 seconds. Those 10 seconds were taken up
> > > > > > mostly
> > > > > > between the first and second closing (4 sec.) and the third and
> > > > > > fourth (6
> > > > > > sec.) I may need to put a delay at the start of my printing
> script
> > > > > > so it
> > > > > > does not try to print an incomplete file.
> > > > > >
> > > > > > An aside: The "masks" in the incrontab are separated by comas
> but
> > no
> > > > > > spaces are allowed.
> > > > > >
> > > > > > Nothing turns out as simple as it appears initially.
> > > > > >
> > > > > > -Denis
> > > > > >
> > > > > > On Fri, Nov 17, 2017 at 11:38 PM, Tom <
> > tomas.kuchta.li...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > I am glad you worked it out. Well done.
> > > > > > >
> > > > > > > Darn fast computers!!
> > > > > > >
> > > > > > > -T
> > > > > > >
> > > > > > > On Fri, 2017-11-17 at 18:04 -0800, Denis Heidtmann wrote:
> > > > > > > >
> > > > > > > > On the "Create": this convinces me that I should take up
> > > > > > > > drinking
> > > > > > > > coffee,
> > > > > > > > so some stronger brain stimulant. Dumb.
> > > > > > > >
> > > > > > > > On the multiple entries, I think the issue is that my test
> > script
> > > > > > > > is
> > > > > > > > very
> > > > > > > > short and fast. I added a sleep 10 and I get only one
> > entry--the
> > > > > > > > first
> > > > > > > > one. Apparently the print driver (or the program calling it)
> > > > > > > > closes
> > > > > > > > the
> > > > > > > > file multiple times. I added $% to the incrontab file and %2
> > to
> > > > > > > > the
> > > > > > > > script
> > > > > > > > (but w/o the sleep in my script) I got:
> > > > > > > >
> > > > > > > > test1 create test23 IN_CLOSE_WRITE
> > > > > > > > test1 create test23.PLT IN_CLOSE_WRITE
> > > > > > > > test1 create test23.PLT IN_CLOSE_WRITE
> > > > > > > > test1 create test23.PLT IN_CLOSE_WRITE
> > > > > > > >
> > > > > > > > This behavior of the driver/application seems not the best,
> but
> > > > > > > > there
> > > > > > > > is
> > > > > > > > nothing to be done about it. I assume that my printing
> script
> > > > > > > > will
> > > > > > > > take
> > > > > > > > sufficient time it will not matter.
> > > > > > > >
> > > > > > > > I recorded the times associated with the four log entries.
> It
> > > > > > > > was
> > > > > > > > 347 msec
> > > > > > > > overall, with the last step taking most of this time at about
> > 300
> > > > > > > > msec. So
> > > > > > > > my anticipation that the multiple writes/closing will not
> > matter
> > > > > > > > seems
> > > > > > > > reasonable. Let's hope so.
> > > > > > > >
> > > > > > > > Thanks again for the suggestion.
> > > > > > > >
> > > > > > > > -Denis
> > > > > > > >
> > > > > > > > On Fri, Nov 17, 2017 at 2:02 PM, Tomas Kuchta
> > <tomas.kuchta.lists
> > > > > > > > @gma
> > > > > > > > il.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > If I recall incron details correctly, you get multiple
> > entries
> > > > > > > > > in
> > > > > > > > > your log
> > > > > > > > > because you run your script multiple times at different
> > events:
> > > > > > > > > IN_CLOSE_WRITE,IN_NO_LOOP
> > > > > > > > >
> > > > > > > > > Your other question: You see "create" in your log because
> > that
> > > > > > > > > is
> > > > > > > > > what your
> > > > > > > > > echo command puts there in your script.
> > > > > > > > >
> > > > > > > > > -Tomas
> > > > > > > > >
> > > > > > > > > On Nov 17, 2017 11:47 AM, "Denis Heidtmann"
> > <denis.heidtmann@gm
> > > > > > > > > ail.
> > > > > > > > > com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > I have pursued Tomas' advice to use incron to automatically
> > > > > > > > > send
> > > > > > > > > files
> > > > > > > > > written by the win2k print driver to the printer. I have
> > > > > > > > > everything down
> > > > > > > > > to one issue. To test, I have a simple script (intest.sh)
> > that
> > > > > > > > > just sends
> > > > > > > > > the event responded to to a log file:
> > > > > > > > >
> > > > > > > > > #! /bin/bash
> > > > > > > > > # test of incron
> > > > > > > > > echo "tes1 create " $1 >> /home/denis/incronlog.log
> > > > > > > > >
> > > > > > > > > The incron table is:
> > > > > > > > >
> > > > > > > > > /home/denis/win2kfiles/Print_files
> IN_CLOSE_WRITE,IN_NO_LOOP
> > > > > > > > > /home/denis/scripts/intest.sh $#
> > > > > > > > >
> > > > > > > > > The resulting log is:
> > > > > > > > >
> > > > > > > > > tes1 create test12
> > > > > > > > > tes1 create test12.PLT
> > > > > > > > > tes1 create test12.PLT
> > > > > > > > > tes1 create test12.PLT
> > > > > > > > >
> > > > > > > > > It generates multiple entries for one file added (i.e., one
> > > > > > > > > print
> > > > > > > > > command). I added IN_ONESHOT to the incrontab:
> > > > > > > > >
> > > > > > > > > /home/denis/win2kfiles/Print_files
> > > > > > > > > IN_CLOSE_WRITE,IN_ONESHOT,IN_NO_LOOP
> > > > > > > > > /home/denis/scripts/intest.sh $#
> > > > > > > > >
> > > > > > > > > I still got multiple entries in the log.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Questions:
> > > > > > > > > Why does the log not say "close" instead of "create"?
> > > > > > > > > Why four entries?
> > > > > > > > > What might the result be when the script intest.sh is
> > replaced
> > > > > > > > > by
> > > > > > > > > one that
> > > > > > > > > prints and deletes the files? Will it be called 4 times in
> > > > > > > > > rapid
> > > > > > > > > succession?
> > > > > > > > >
> > > > > > > > > Any suggestions for testing further?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > -Denis
> > > > > > > > > _______________________________________________
> > > > > > > > > PLUG mailing list
> > > > > > > > > PLUG@pdxlinux.org
> > > > > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > > > > > > _______________________________________________
> > > > > > > > > PLUG mailing list
> > > > > > > > > PLUG@pdxlinux.org
> > > > > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > PLUG mailing list
> > > > > > > > PLUG@pdxlinux.org
> > > > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > > > > _______________________________________________
> > > > > > > PLUG mailing list
> > > > > > > PLUG@pdxlinux.org
> > > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > > > >
> > > > > > _______________________________________________
> > > > > > PLUG mailing list
> > > > > > PLUG@pdxlinux.org
> > > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > > _______________________________________________
> > > > > PLUG mailing list
> > > > > PLUG@pdxlinux.org
> > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > >
> > > > _______________________________________________
> > > > PLUG mailing list
> > > > PLUG@pdxlinux.org
> > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > >
> > > _______________________________________________
> > > PLUG mailing list
> > > PLUG@pdxlinux.org
> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > >
> > _______________________________________________
> > PLUG mailing list
> > PLUG@pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> > _______________________________________________
> > PLUG mailing list
> > PLUG@pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> >
> _______________________________________________
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
_______________________________________________
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
