"waitfortmsu" script

14 views
Skip to first unread message

D Gowers

unread,
Sep 1, 2014, 11:14:14 PM9/1/14
to tm...@googlegroups.com
When I'm cleaning up tmsu stuff(missing files, mass tagging, etc) I often have a few different operations that need to be queued up, in separate terminals. This script monitors whether any tmsu operations are running that lock the db, and returns when there are none.


So running it before tmsu commands (as in 'waitfortmsu; tmsu repair --remove some/file') will mostly (99% -- there is still a small possibility of race conditions occurring) prevent 'database is locked' errors.
Maybe instead there should be a global TMSU option to wait for the database to be unlocked before trying to run whatever operation is selected?

Anyhow, here's the 'waitfortmsu' script:

#!/bin/sh
# wait for TMSU operations that lock the db to complete
#
# These operations are: copy delete imply merge rename tag untag repair
#
# Newer versions may contain other operation modes which write to the db; these should be added to the list below.
#
INSTANCES=10
while [ "$INSTANCES" -gt 0 ]; do
  INSTANCES=$(ps aux | fgrep 'tmsu copy
tmsu delete
tmsu imply
tmsu merge
tmsu rename
tmsu tag
tmsu untag
tmsu repair' | fgrep -v "grep" | wc -l)
  if [ "$INSTANCES" -gt 0 ]; then sleep 2; fi
done

Paul Ruane

unread,
Sep 4, 2014, 10:29:51 AM9/4/14
to tm...@googlegroups.com

Thanks for sharing your script. I hadn't considered the possibility of database locks to be a problem in every day use, but in the case of scripting you're right that it's a problem.

Perhaps TMSU should retry it's operation for a period of time in the case of a database lock?

Thanks
Paul

--
You received this message because you are subscribed to the Google Groups "tmsu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tmsu+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

D Gowers

unread,
Sep 5, 2014, 8:20:56 AM9/5/14
to tm...@googlegroups.com
Thanks for your response.

Retry sounds good. Personally, I find that blocking operations may take up to 90 seconds, according to their scope, but I recognize that my database is unusually large, so the appropriate 'typical' timeout value is probably more like 30s.


Reply all
Reply to author
Forward
0 new messages