|
|
| Author |
Message |
trancequility
|
|
Funky unixisms going on.
| 
Sep 9 14:08 UTC 2007 |
There is something funky going on with party that I really don't quite
understand yet.
djdoboy 25600 0.0 0.3 984 1552 px Is+ 8:51AM 0:00.04 -bash (bash)
djdoboy 14220 0.0 0.4 1168 1904 px T 8:59AM 0:00.02
/usr/local/bin/ruby ./whore.rb
Welcome to PARTY! Type '?' for help:
---- djdoboy joining (Sep 9 08:59)
User Started Channel
djdoboy Sep 9 08:59:22 party
trancequility Sep 9 10:01:25 party
djdoboy px 67-150-245-84.oa 8:52AM 1:02 -bash
As you can see, djdoboy has been idle in party for over an hour. Ie, there
has been no login/logout from party. The only thing party logs show is me
logging in and out of party.
I tried to duplicate this by doing
party &
but it doesn't work.
|
| 10 responses total. |
trancequility
|
|
response 1 of 10:
|
Sep 9 18:26 UTC 2007 |
part of the ruby code that is used to execute this engineering wonder is
2.times do |i|
threads[i]=Thread.new do
%x{/usr/local/bin/party}
end
end
I'm assuming that since djdoboy never logs out of party, that this line of
code created some kind of deadlock.
|
nharmon
|
|
response 2 of 10:
|
Sep 9 21:13 UTC 2007 |
It's strange that you don't understand that > party & < is creating a
child process of whatever shell you're using. A child process that is
going to receive sighup when you exit. But when you create a new thread
in a ruby script, that process is not a child of the shell so it isn't
going to receive the hangup signal. That's why it stays running, not
because it's in "deadlock"...whatever that means.
nharmon@grex ~ > pico &
[1] 7375
[1] + suspended (tty output) pico
nharmon@grex ~ > ps -j
USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
nharmon 9240 22519 9240 d6bd1540 0 Is pi 0:00.07 -zsh (zsh)
nharmon 7375 9240 7375 d6bd1540 1 TN pi 0:00.00 pico
nharmon 2071 9240 2071 d6bd1540 1 R+ pi 0:00.00 ps -j
See how pico's PPID is the PID of zsh? When zsh exits its going to send
a SIGHUP to every process whose PPID is the same is zsh's PID. Now let's
start pico using an adaptation of your script:
nharmon@grex ~ > ruby ./test.rb
nharmon@grex ~ > ps -j
USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
nharmon 9240 22519 9240 d6bd1540 0 Is pi 0:00.15 -zsh (zsh)
nharmon 16735 1 21302 d6bd1540 0 I pi 0:00.00
/usr/local/bin/pic
nharmon 27759 9240 27759 d6bd1540 1 R+ pi 0:00.00 ps -j
Woah!, pico's PPID is now 1, not 9240.
I don't feel like going any further seeing as there is a script in your
homedir to execute getty 100 times, in a desperate attempt to DoS grex.
|
trancequility
|
|
response 3 of 10:
|
Sep 9 22:38 UTC 2007 |
"A child process that is
going to receive sighup when you exit. But when you create a new thread
in a ruby script, that process is not a child of the shell so it isn't
going to receive the hangup signal."
I don't think so nate.
-bash-3.2$ shopt huponexit
huponexit off
and now from bash(1)
"If the huponexit shell option has been set with shopt,
bash sends a SIGHUP to all jobs when an interactive login
shell exits."
In other words, sighup isn't set because the option isn't enabled on my shell
(by default). Nice try rookie. Now please shut the fuck up on this forum. You
once again don't know what you are talking about.
|
nharmon
|
|
response 4 of 10:
|
Sep 9 22:45 UTC 2007 |
This response has been erased.
|
nharmon
|
|
response 5 of 10:
|
Sep 9 22:47 UTC 2007 |
Woah, you totally ripped that off from the guy responding your exact
question in comp.lang.ruby: http://tinyurl.com/3x72u4
Setting huponexit causes the shell to send a sighup to all processes
under your uid when you exit the shell.
|
trancequility
|
|
response 6 of 10:
|
Sep 9 22:52 UTC 2007 |
"But when you create a new thread
in a ruby script, that process is not a child of the shell so it isn't
going to receive the hangup signal.'
You are once again wrong nate.
huponexit on
-bash-3.2$ ./whore.rb &
[1] 28137
-bash-3.2$ ps waux | grep djdoboy
djdoboy 554 0.0 0.3 836 1612 pc Ss 6:28PM 0:00.06 -bash (bash)
djdoboy 28137 0.0 0.4 1368 1992 pc S 6:48PM 0:00.02
/usr/local/bin/ruby ./whore.rb
djdoboy 27744 0.0 0.1 404 560 pc S 6:48PM 0:00.01
/usr/libexec/getty std.19200 tty00
djdoboy 3610 0.0 0.1 368 544 pc S 6:48PM 0:00.01
/usr/libexec/getty std.19200 tty00
djdoboy 32117 0.0 0.1 348 556 pc S 6:48PM 0:00.00
/usr/libexec/getty std.19200 tty00
djdoboy 24581 0.0 0.1 328 548 pc S 6:48PM 0:00.01
/usr/libexec/getty std.19200 tty00
djdoboy 23267 0.0 0.1 448 556 pc S 6:48PM 0:00.00
/usr/libexec/getty std.19200 tty00
djdoboy 1943 0.0 0.1 328 552 pc S 6:48PM 0:00.01
/usr/libexec/getty std.19200 tty00
djdoboy 22936 0.0 0.1 320 580 pc S 6:48PM 0:00.00
/usr/libexec/getty std.19200 tty00
djdoboy 28695 0.0 0.1 380 556 pc S 6:48PM 0:00.00
/usr/libexec/getty std.19200 tty00
djdoboy 25585 0.0 0.1 288 536 pc S 6:48PM 0:00.00
/usr/libexec/getty std.19200 tty00
djdoboy 22280 0.0 0.1 368 560 pc S 6:48PM 0:00.00
/usr/libexec/getty std.19200 tty00
djdoboy 26495 0.0 0.1 328 536 pc S+ 6:48PM 0:00.00 grep djdoboy
djdoboy 3258 0.0 0.1 664 412 pc R+ 6:48PM 0:00.00 ps -waux
-bash-3.2$ exit
now I log back in
-bash-3.2$ ps -p 81327
PID TT STAT TIME COMMAND
-bash-3.2$ ps -p 28137
PID TT STAT TIME COMMAND
-bash-3.2$ ps waux | grep djdoboy
djdoboy 32047 0.0 0.3 1008 1544 pc Ss 6:49PM 0:00.02 -bash (bash)
djdoboy 13764 0.0 0.0 1008 4 pc R+ 6:50PM 0:00.00 grep djdoboy
(bash)
djdoboy 19327 0.0 0.1 444 408 pc R+ 6:50PM 0:00.00 ps -waux
-bash-3.2$
OMFG, MY RUBY THREADS ARE GONE!
|
nharmon
|
|
response 7 of 10:
|
Sep 9 23:09 UTC 2007 |
Instead of setting huponexit I would recommend adding lines to your ruby
script to wait and then do a Process.kill on everything with the same
process group id when the script exits. Even better would be to do a
trap("HUP") in ruby to trap sighup and then do the Process.kill.
Now that you understand how huponexit works, maybe you can think of why
it would be a bad idea to enable huponexit on accounts you log in
multiple sessions, or on accounts that need to have processes running
under them (like say, root).
|
nharmon
|
|
response 8 of 10:
|
Sep 9 23:27 UTC 2007 |
Maybe this will demonstrate my point better:
#!/usr/bin/ruby
pid = fork do
Signal.trap('HUP') do
Process.kill(-1, Process.getpgrp())
end
threads=[]
threads[0]=Thread.new %x{/usr/local/bin/pico}
loop do
sleep 20
end
end
Process.detach(pid)
Without setting huponexit, this will cause the ruby script's child
processes to exit shortly after logoff. I think the 'sleep 20' causes
the delay, maybe cross can elaborate.
|
trancequility
|
|
response 9 of 10:
|
Sep 9 23:43 UTC 2007 |
Chirst, nate. First off, you don't need to create a single thread in this
case. Second, even if I did need to create a single thread in this case, it
really wouldn't work because you don't fucking let the thread exit properly.
Third, using sleep to synchronize a process is vivek move. Just stick to what
you know best. Butt fucking mcnally.
|
trancequility
|
|
response 10 of 10:
|
Sep 10 00:08 UTC 2007 |
I think the reason nate is seeing 1 is because this dumbass did a fork in his
code.
|