|
|
|
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.
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.
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.
"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.
This response has been erased.
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.
"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!
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).
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.
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.
I think the reason nate is seeing 1 is because this dumbass did a fork in his code.
Response not possible - You must register and login before posting.
|
|
|
- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss