* [sup-talk] sup ignoring SIGTERM?
@ 2009-08-05 14:09 Adeodato Simó
2009-08-05 20:03 ` William Morgan
0 siblings, 1 reply; 14+ messages in thread
From: Adeodato Simó @ 2009-08-05 14:09 UTC (permalink / raw)
Hello,
it is my impression that sup is ignoring SIGTERM, whereas I would be
expecting for sup to clean up (including removal of the lock file) and
exit normally upon receiving this signal.
Any clues about this? (I tried inserting a "trap", but it didn't seem to
help.)
Thanks,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 14:09 [sup-talk] sup ignoring SIGTERM? Adeodato Simó
@ 2009-08-05 20:03 ` William Morgan
2009-08-05 20:25 ` Nicolas Pouillard
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: William Morgan @ 2009-08-05 20:03 UTC (permalink / raw)
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
> it is my impression that sup is ignoring SIGTERM, whereas I would be
> expecting for sup to clean up (including removal of the lock file) and
> exit normally upon receiving this signal.
Good point. I've fixed that in branch ncurses-fixes, which I've merged
into next. Let me know if it works for you.
I'm also happy to report that I've finally managed to get Sup to deal
with screen resizes, which, oddly enough, was a related problem. Go me!
Steps closer to curses-induced insanity: 4!
Available on next or ncurses-fixes branches.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 20:03 ` William Morgan
@ 2009-08-05 20:25 ` Nicolas Pouillard
2009-08-05 21:24 ` William Morgan
2009-08-05 20:35 ` Ben Walton
` (2 subsequent siblings)
3 siblings, 1 reply; 14+ messages in thread
From: Nicolas Pouillard @ 2009-08-05 20:25 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Aug 05 22:03:09 +0200 2009:
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
> > it is my impression that sup is ignoring SIGTERM, whereas I would be
> > expecting for sup to clean up (including removal of the lock file) and
> > exit normally upon receiving this signal.
>
> Good point. I've fixed that in branch ncurses-fixes, which I've merged
> into next. Let me know if it works for you.
>
> I'm also happy to report that I've finally managed to get Sup to deal
> with screen resizes, which, oddly enough, was a related problem. Go me!
> Steps closer to curses-induced insanity: 4!
>
> Available on next or ncurses-fixes branches.
With the ncurses-fixes branch (even with the last patch), when I launch sup
I get a blank screen (with the status bar saying "Searching for threads...".
--
Nicolas Pouillard
http://nicolaspouillard.fr
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 20:03 ` William Morgan
2009-08-05 20:25 ` Nicolas Pouillard
@ 2009-08-05 20:35 ` Ben Walton
2009-08-05 21:28 ` Edward Z. Yang
2009-08-06 18:37 ` Adeodato Simó
3 siblings, 0 replies; 14+ messages in thread
From: Ben Walton @ 2009-08-05 20:35 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009:
> Good point. I've fixed that in branch ncurses-fixes, which I've merged
> into next. Let me know if it works for you.
I just pulled next and fired it up. It was _hoooooribly_,
_bruuuutallly_ slow to load the index. I git bisected between my
previous running ORIG_HEAD and HEAD. I came up with 75d9f5e3db as the
offender. It seems to do what you intend but (for me, anyway) at the
expense of really bad interactivity. [We're talking 10+ minutes to
load the index part way...]
This doesn't help identify the problem, but I'd be looking at the
Ncurses.nodelay bits...
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090805/b4062212/attachment.bin>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 20:25 ` Nicolas Pouillard
@ 2009-08-05 21:24 ` William Morgan
2009-08-06 17:53 ` William Morgan
0 siblings, 1 reply; 14+ messages in thread
From: William Morgan @ 2009-08-05 21:24 UTC (permalink / raw)
Reformatted excerpts from Nicolas Pouillard's message of 2009-08-05:
> With the ncurses-fixes branch (even with the last patch), when I
> launch sup I get a blank screen (with the status bar saying "Searching
> for threads...".
Dammit. I see that too, on some computers. The problem is that
Ncurses.getch is actually blocking the background threads from working.
(You can tell because threads will start loading when you press lots of
keys.)
I've unmerged the branch from next for the time being.
The problem is the removal of the select() in nonblocking_getch
(buffer.rb circa line 25). With it in, resizes don't work right. With it
removed, background threads are blocked on some computers. Not sure what
makes the difference. Sigh...
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 20:03 ` William Morgan
2009-08-05 20:25 ` Nicolas Pouillard
2009-08-05 20:35 ` Ben Walton
@ 2009-08-05 21:28 ` Edward Z. Yang
2009-08-06 18:37 ` Adeodato Simó
3 siblings, 0 replies; 14+ messages in thread
From: Edward Z. Yang @ 2009-08-05 21:28 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009:
> I'm also happy to report that I've finally managed to get Sup to deal
> with screen resizes, which, oddly enough, was a related problem. Go me!
> Steps closer to curses-induced insanity: 4!
Sounds exciting. What was the fix?
Cheers,
Edward
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 21:24 ` William Morgan
@ 2009-08-06 17:53 ` William Morgan
2009-08-06 18:09 ` Nicolas Pouillard
2009-08-06 23:56 ` Ben Walton
0 siblings, 2 replies; 14+ messages in thread
From: William Morgan @ 2009-08-06 17:53 UTC (permalink / raw)
Reformatted excerpts from William Morgan's message of 2009-08-05:
> The problem is the removal of the select() in nonblocking_getch
> (buffer.rb circa line 25). With it in, resizes don't work right. With
> it removed, background threads are blocked on some computers. Not sure
> what makes the difference. Sigh...
Ok, I've tracked this down. FWIW, this is a problem that's been around
in ruby ncurses libraries since at least 2005, when I complained about
it on ruby-core.
In many ruby ncurses libraries, including the most recent gem,
Ncurses.getch blocks all Ruby threads from running. That's a bug. The
workaround is to wrap it in a select() call. But then you have to handle
sigwinch manually (i.e via Kernel#trap), because getch won't return a
resize "keystroke" until the user hits an actual key.
The libncurses-ruby library on modern Ubuntu systems actually doesn't
have this problem. You can set nodelay false, throw out the select call,
and everything works the way it's supposed to: background threads run,
and you get a resize keystroke when a sigwinch happens without you
having to install your own handler. And that's the library I had been
developing against, which is why everything worked on one computer but
didn't work on the others.
Anyways, for those who were having problems with this branch before,
please try the most recent version and confirm that:
1. Email threads load as normal, i.e. in the background.
2. Resizing the terminal refreshes the screen without you having to
press any keys.
3. Ctrl-l still works.
4. Ctrl-c still works (prompts you, and y/n do the right thing).
5. Killing Sup works.
If everyone's happy, I'll merge this branch into next.
If you're curious about whether you have a good or bad ncurses library,
run this program: (But either should work correctly with Sup.)
require 'rubygems'
require 'ncurses'
require 'thread'
Ncurses.initscr
Ncurses.noecho
Ncurses.cbreak
Ncurses.curs_set 0
Thread.new do
sleep 0.1
Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is GOOD."
end
begin
Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is BAD."
Ncurses.getch
ensure
Ncurses.curs_set 1
Ncurses.endwin
puts "bye"
end
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-06 17:53 ` William Morgan
@ 2009-08-06 18:09 ` Nicolas Pouillard
2009-08-06 23:56 ` Ben Walton
1 sibling, 0 replies; 14+ messages in thread
From: Nicolas Pouillard @ 2009-08-06 18:09 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu Aug 06 19:53:43 +0200 2009:
> Reformatted excerpts from William Morgan's message of 2009-08-05:
> > The problem is the removal of the select() in nonblocking_getch
> > (buffer.rb circa line 25). With it in, resizes don't work right. With
> > it removed, background threads are blocked on some computers. Not sure
> > what makes the difference. Sigh...
[...]
> If everyone's happy, I'll merge this branch into next.
Works just great! Thanks.
--
Nicolas Pouillard
http://nicolaspouillard.fr
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-05 20:03 ` William Morgan
` (2 preceding siblings ...)
2009-08-05 21:28 ` Edward Z. Yang
@ 2009-08-06 18:37 ` Adeodato Simó
2009-08-07 1:38 ` William Morgan
3 siblings, 1 reply; 14+ messages in thread
From: Adeodato Simó @ 2009-08-06 18:37 UTC (permalink / raw)
+ William Morgan (Wed, 05 Aug 2009 13:03:09 -0700):
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
> > it is my impression that sup is ignoring SIGTERM, whereas I would be
> > expecting for sup to clean up (including removal of the lock file) and
> > exit normally upon receiving this signal.
> Good point. I've fixed that in branch ncurses-fixes, which I've merged
> into next. Let me know if it works for you.
Everything seems to work fine as of 3478e40, including sup terminating
upon SIGTERM. If I may, I'd suggest normal termination instead of
raising an exception. IMHO, it is expected that programs that capture
SIGTERM, will do cleanup and exit normally, rather than behave as if an
error had happened. (Perhaps it'd be difficult to exit sup cleanly from
the handler in any other way than an exception: that, I don't know.)
Thanks, in any case.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-06 17:53 ` William Morgan
2009-08-06 18:09 ` Nicolas Pouillard
@ 2009-08-06 23:56 ` Ben Walton
1 sibling, 0 replies; 14+ messages in thread
From: Ben Walton @ 2009-08-06 23:56 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu Aug 06 13:53:43 -0400 2009:
> Ok, I've tracked this down. FWIW, this is a problem that's been around
> in ruby ncurses libraries since at least 2005, when I complained about
> it on ruby-core.
...yup, looks like you stuck the landing this time! :)
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090806/72c6f045/attachment.bin>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-06 18:37 ` Adeodato Simó
@ 2009-08-07 1:38 ` William Morgan
2009-08-07 10:31 ` Adeodato Simó
0 siblings, 1 reply; 14+ messages in thread
From: William Morgan @ 2009-08-07 1:38 UTC (permalink / raw)
Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06:
> Everything seems to work fine as of 3478e40, including sup terminating
> upon SIGTERM. If I may, I'd suggest normal termination instead of
> raising an exception. IMHO, it is expected that programs that capture
> SIGTERM, will do cleanup and exit normally, rather than behave as if
> an error had happened.
Good idea. Try it now.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-07 1:38 ` William Morgan
@ 2009-08-07 10:31 ` Adeodato Simó
2009-08-07 16:40 ` Rich Lane
0 siblings, 1 reply; 14+ messages in thread
From: Adeodato Simó @ 2009-08-07 10:31 UTC (permalink / raw)
+ William Morgan (Thu, 06 Aug 2009 18:38:53 -0700):
> Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06:
> > Everything seems to work fine as of 3478e40, including sup terminating
> > upon SIGTERM. If I may, I'd suggest normal termination instead of
> > raising an exception. IMHO, it is expected that programs that capture
> > SIGTERM, will do cleanup and exit normally, rather than behave as if
> > an error had happened.
> Good idea. Try it now.
Ah, excellent: works as suggested now.
Regarding 57dea7a (refactor index locking interaction and replace
suicidemanager), I'll note that at least on my system, and after having
moved to Xapian, those codepaths no longer execute. That is, if a sup is
running and a second one is started, it never gets to ask whether to
suggest dieing to the first one, because this second one dies with:
[Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
[Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
[Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
[Fri Aug 07 12:31:05 +0200 2009] setting locale...
.../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
from .../lib/sup/xapian_index.rb:24:in `new'
from .../lib/sup/xapian_index.rb:24:in `initialize'
from .../bin/sup:132:in `new'
from .../bin/sup:132
Thanks!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-07 10:31 ` Adeodato Simó
@ 2009-08-07 16:40 ` Rich Lane
2009-08-08 9:23 ` Adeodato Simó
0 siblings, 1 reply; 14+ messages in thread
From: Rich Lane @ 2009-08-07 16:40 UTC (permalink / raw)
Excerpts from Adeodato Sim?'s message of Fri Aug 07 06:31:51 -0400 2009:
> Regarding 57dea7a (refactor index locking interaction and replace
> suicidemanager), I'll note that at least on my system, and after having
> moved to Xapian, those codepaths no longer execute. That is, if a sup is
> running and a second one is started, it never gets to ask whether to
> suggest dieing to the first one, because this second one dies with:
>
> [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
> [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
> [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
> [Fri Aug 07 12:31:05 +0200 2009] setting locale...
> .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily
> unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
> from .../lib/sup/xapian_index.rb:24:in `new'
> from .../lib/sup/xapian_index.rb:24:in `initialize'
> from .../bin/sup:132:in `new'
> from .../bin/sup:132
I've just posted a patch that should fix this.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [sup-talk] sup ignoring SIGTERM?
2009-08-07 16:40 ` Rich Lane
@ 2009-08-08 9:23 ` Adeodato Simó
0 siblings, 0 replies; 14+ messages in thread
From: Adeodato Simó @ 2009-08-08 9:23 UTC (permalink / raw)
+ Rich Lane (Fri, 07 Aug 2009 12:40:18 -0400):
> > [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
> > [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
> > [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
> > [Fri Aug 07 12:31:05 +0200 2009] setting locale...
> > .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily
> > unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
> > from .../lib/sup/xapian_index.rb:24:in `new'
> > from .../lib/sup/xapian_index.rb:24:in `initialize'
> > from .../bin/sup:132:in `new'
> > from .../bin/sup:132
> I've just posted a patch that should fix this.
It works, thank you!
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-08-08 9:23 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-05 14:09 [sup-talk] sup ignoring SIGTERM? Adeodato Simó
2009-08-05 20:03 ` William Morgan
2009-08-05 20:25 ` Nicolas Pouillard
2009-08-05 21:24 ` William Morgan
2009-08-06 17:53 ` William Morgan
2009-08-06 18:09 ` Nicolas Pouillard
2009-08-06 23:56 ` Ben Walton
2009-08-05 20:35 ` Ben Walton
2009-08-05 21:28 ` Edward Z. Yang
2009-08-06 18:37 ` Adeodato Simó
2009-08-07 1:38 ` William Morgan
2009-08-07 10:31 ` Adeodato Simó
2009-08-07 16:40 ` Rich Lane
2009-08-08 9:23 ` Adeodato Simó
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox