Why does this happen?
---------- Forwarded message ---------- From: Cron Daemon root@cassini.toolserver.org Date: Sat, Nov 14, 2009 at 11:35 AM Subject: Cron root@cassini /sql/diffs/load-next To: root@cassini.toolserver.org
ERROR: List of process IDs must follow -p. ********* simple selection ********* ********* selection by list ********* -A all processes -C by command name -N negate selection -G by real group ID (supports names) -a all w/ tty except session leaders -U by real user ID (supports names) -d all except session leaders -g by session OR by effective group name -e all processes -p by process ID T all processes on this terminal -s processes in the sessions given a all w/ tty, including other users -t by tty g OBSOLETE -- DO NOT USE -u by effective user ID (supports names) r only running processes U processes for specified users x processes w/o controlling ttys t by tty *********** output format ********** *********** long options *********** -o,o user-defined -f full --Group --User --pid --cols --ppid -j,j job control s signal --group --user --sid --rows --info -O,O preloaded -o v virtual memory --cumulative --format --deselect -l,l long u user-oriented --sort --tty --forest --version -F extra full X registers --heading --no-heading --context ********* misc options ********* -V,V show version L list format codes f ASCII art forest -m,m,-L,-T,H threads S children in sum -y change -l format -M,Z security data c true command name -c scheduling class -w,w wide output n numeric WCHAN,UID -H process hierarchy
Ævar Arnfjörð Bjarmason wrote:
Why does this happen?
---------- Forwarded message ---------- From: Cron Daemon root@cassini.toolserver.org Date: Sat, Nov 14, 2009 at 11:35 AM Subject: Cron root@cassini /sql/diffs/load-next To: root@cassini.toolserver.org
ERROR: List of process IDs must follow -p. ********* simple selection ********* ********* selection by list ********* -A all processes -C by command name -N negate selection -G by real group ID (supports names) -a all w/ tty except session leaders -U by real user ID (supports names) -d all except session leaders -g by session OR by effective group name -e all processes -p by process ID T all processes on this terminal -s processes in the sessions given a all w/ tty, including other users -t by tty g OBSOLETE -- DO NOT USE -u by effective user ID (supports names) r only running processes U processes for specified users x processes w/o controlling ttys t by tty *********** output format ********** *********** long options *********** -o,o user-defined -f full --Group --User --pid --cols --ppid -j,j job control s signal --group --user --sid --rows --info -O,O preloaded -o v virtual memory --cumulative --format --deselect -l,l long u user-oriented --sort --tty --forest --version -F extra full X registers --heading --no-heading --context ********* misc options ********* -V,V show version L list format codes f ASCII art forest -m,m,-L,-T,H threads S children in sum -y change -l format -M,Z security data c true command name -c scheduling class -w,w wide output n numeric WCHAN,UID -H process hierarchy
Some ps call in the script /sql/diffs/load-next run by cron uses the wrong syntax, erroring out. Cron emails you so you can fix it. ps has an odd syntax. Bsd syntax, posix syntax, and so on.
Steps in order to fix it: -Find the ps call that produces the error. -Detect the equivalent working syntax. -Change the script.
I replaced -e $PIDFILE with -s $PIDFILE per your suggestion on IRC. It seems to have stopped spewing cron emails.
Peter could you figure out if it's still applying diffs ?:)
Yes, it does. This is a bug i introduced yesterday. Sorry for that.. Something I'm also unsure about is expire.rb's runtime. I activated it friday and it took twice as long as the import into psql, so i disabled it saturday morning, so that the diff is now catching up again.
Maybe some indices are missing?
Peter
Ævar Arnfjörð Bjarmason schrieb:
I replaced -e $PIDFILE with -s $PIDFILE per your suggestion on IRC. It seems to have stopped spewing cron emails.
Peter could you figure out if it's still applying diffs ?:)
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On Sat, Nov 14, 2009 at 9:24 PM, Peter Körner osm-lists@mazdermind.de wrote:
Yes, it does. This is a bug i introduced yesterday. Sorry for that.. Something I'm also unsure about is expire.rb's runtime. I activated it friday and it took twice as long as the import into psql, so i disabled it saturday morning, so that the diff is now catching up again.
Maybe some indices are missing?
No idea:)
I've made it use kill -0 instead of ps:
avar@cassini:/sql/diffs$ diff -ru load-next~ load-next --- load-next~ 2009-11-14 21:32:41.000000000 +0000 +++ load-next 2009-11-14 21:32:41.000000000 +0000 @@ -33,7 +33,8 @@ fi
if [ -s $PIDFILE ]; then - if [ "$(ps -p `cat $PIDFILE` | wc -l)" -gt 1 ]; then + # if [ "$(ps -p `cat $PIDFILE` | wc -l)" -gt 1 ]; then + if [ kill -0 `cat $PIDFILE` 2>/dev/null ]; then m_info "pid `cat $PIDFILE` still running" exit 3 fi
When I run this:
avar@cassini:/sql/diffs$ while sleep 60; do cat load-next.pid && hexdump -C load-next.pid && ps aux | grep $(cat load-next.pid); done
I get:
root 22599 0.0 0.0 8844 1208 ? Ss 20:55 0:00 /bin/bash /sql/diffs/load-next ravar 25130 0.0 0.0 6312 772 pts/10 R+ 21:19 0:00 grep 22599 22599 00000000 32 32 35 39 39 0a |22599.| 00000006 root 22599 0.0 0.0 8844 1208 ? Ss 20:55 0:00 /bin/bash /sql/diffs/load-next ravar 25483 0.0 0.0 6312 784 pts/10 R+ 21:20 0:00 grep 22599
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. 25576 00000000 32 35 35 37 36 0a |25576.| 00000006 root 25576 0.0 0.0 8844 1204 ? Ss 21:25 0:00 /bin/bash /sql/diffs/load-next ravar 25951 0.0 0.0 6312 776 pts/10 R+ 21:25 0:00 grep 25576 25576
Which is odd.
echo > foo test -s foo
Returns false though, so I don't see how ps could have been called with -p being a non-pid.
Or we can just switch back to deleting the pid-file at the end of the script.
Peter
Ævar Arnfjörð Bjarmason schrieb:
On Sat, Nov 14, 2009 at 9:24 PM, Peter Körner osm-lists@mazdermind.de wrote:
Yes, it does. This is a bug i introduced yesterday. Sorry for that.. Something I'm also unsure about is expire.rb's runtime. I activated it friday and it took twice as long as the import into psql, so i disabled it saturday morning, so that the diff is now catching up again.
Maybe some indices are missing?
No idea:)
I've made it use kill -0 instead of ps:
avar@cassini:/sql/diffs$ diff -ru load-next~ load-next --- load-next~ 2009-11-14 21:32:41.000000000 +0000 +++ load-next 2009-11-14 21:32:41.000000000 +0000 @@ -33,7 +33,8 @@ fi
if [ -s $PIDFILE ]; then
if [ "$(ps -p `cat $PIDFILE` | wc -l)" -gt 1 ]; then
# if [ "$(ps -p `cat $PIDFILE` | wc -l)" -gt 1 ]; thenif [ kill -0 `cat $PIDFILE` 2>/dev/null ]; then m_info "pid `cat $PIDFILE` still running" exit 3 fiWhen I run this:
avar@cassini:/sql/diffs$ while sleep 60; do cat load-next.pid && hexdump -C load-next.pid && ps aux | grep $(cat load-next.pid); done
I get:
root 22599 0.0 0.0 8844 1208 ? Ss 20:55 0:00 /bin/bash /sql/diffs/load-next ravar 25130 0.0 0.0 6312 772 pts/10 R+ 21:19 0:00 grep 22599 22599 00000000 32 32 35 39 39 0a |22599.| 00000006 root 22599 0.0 0.0 8844 1208 ? Ss 20:55 0:00 /bin/bash /sql/diffs/load-next ravar 25483 0.0 0.0 6312 784 pts/10 R+ 21:20 0:00 grep 22599
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
00000000 0a |.| 00000001 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. 25576 00000000 32 35 35 37 36 0a |25576.| 00000006 root 25576 0.0 0.0 8844 1204 ? Ss 21:25 0:00 /bin/bash /sql/diffs/load-next ravar 25951 0.0 0.0 6312 776 pts/10 R+ 21:25 0:00 grep 25576 25576
Which is odd.
echo > foo test -s foo
Returns false though, so I don't see how ps could have been called with -p being a non-pid.
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
Or we can just switch back to deleting the pid-file at the end of the script.
do this instead:
trap 'rm $pidfile' 0
- river.