On Fri, May 9, 2014 at 2:25 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> Other than that, i can't comment: i've only seen such behaviour in 'ping'
> on Solaris, where it can cause a backlog of cronjobs, which causes all
> other jobs to queue up until you kill the pings, at which point _all_
> queued jobs, since the queue limit was reached (several days in my case),
> run in rapid succession!
>
(Changed subject line to reflect new topic)
Well, it's happened again.
This time I have the cron logging on. I get a mail message every time a
cronjob completes, and it's distinctly missing the one for the fossil sync
session that is hung. If I look at processes, I get this (notice it
executed at 9:05am, about 5 minutes after cronjob started and the entire
cronjob, if successful, only takes about 30 seconds):
$ uname -a
Darwin mycomp.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
$ ps auxww | grep fossil
USER PID %CPU %MEM VSZ RSS TT STAT STARTED
TIME COMMAND
xxx 7619 0.0 0.2 2490036 29836 ?? S 9:05AM
0:13.80 /usr/local/bin/fossil commit --no-warnings -m Fri May 9 09:05:41
PDT 2014
The cronjob log for the cronjob executing AFTER the one that hung says this:
added 3 files, deleted 0 files
/usr/local/bin/fossil: database is locked: {REPLACE INTO
config(name,value,mtime)
VALUES('last-sync-url','<my repo url>',now())}
If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
So, there is definitely a problem here. It doesn't happen all the time, but
enough that it occurs at least once a day.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
