Re: Diagnositc output on background processes

Some thoughts.

You should know that signal handlers are not fully safe to do much in especially printing.

You probably want to set a flag in your handler and return. Then check the flag in your main code and write out relevant info and clear the flag.

As for reconnecting output with your terminal, I think you should look along the lines of an output file then in your session tail -f the file or look into syslog which can recieve messages from programs and then send them to users (you) when they are logged in. Messages collected while you are not logged in are tossed though unless you also have syslog send those messages to some file, which brings us back to the first method.

Comment on Re: Diagnositc output on background processes

Replies are listed 'Best First'.
(tye)Re: Diagnositc output on background processes by tye (Sage) on Aug 25, 2001 at 10:26 UTC
Note that signals in Perl aren't safe even if you just set a flag. This is being fixed but I'm not sure when it will be released. So I'd avoid the signal handler altogether when using Perl. You could just have a separate file that you periodically `seek(STATUS,0,0); truncate(STATUS,0); print STATUS, status();` [download] and be sure to include a time stamp in that output (and be sure to turn on autoflush). Another fun idea is to listen on a socket and occasionally do a non-blocking accept. If the accept succeeds, then you can output status information via the socket so anyone can "telnet" to that port to see how things are going. Our long-running servers have telnet interfaces where you can not only get detailed status information but also change configuration information, reset statistics, etc. Though doing something like that is a bit tricky in Perl since threading support is still experimental. - tye (but my friends call me "Tye")	[reply] [d/l]

Replies are listed 'Best First'.

(tye)Re: Diagnositc output on background processes
by tye (Sage) on Aug 25, 2001 at 10:26 UTC

Note that signals in Perl aren't safe even if you just set a flag. This is being fixed but I'm not sure when it will be released. So I'd avoid the signal handler altogether when using Perl.

You could just have a separate file that you periodically

    seek(STATUS,0,0);
    truncate(STATUS,0);
    print STATUS, status();
[download]

Another fun idea is to listen on a socket and occasionally do a non-blocking accept. If the accept succeeds, then you can output status information via the socket so anyone can "telnet" to that port to see how things are going. Our long-running servers have telnet interfaces where you can not only get detailed status information but also change configuration information, reset statistics, etc. Though doing something like that is a bit tricky in Perl since threading support is still experimental.

tye

[reply]
[d/l]