[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: musings on session service mgmt



On Mon, 2008-01-07 at 10:16 -0500, David Zeuthen wrote:
> On Sun, 2008-01-06 at 18:50 -0500, Paul W. Frields wrote:
> > On Fri, 2008-01-04 at 10:21 -0900, Jeff Spaleta wrote:
> > > On Jan 4, 2008 9:50 AM, Nils Philippsen <nphilipp redhat com> wrote:
> > > > If I'm not off track, at least screen predates X session management by a
> > > > few years. So if anything, X session management was (for want of a
> > > > better word) designed to not make established ways how to make a process
> > > > a daemon (and screen, nohup etc. do nothing else) break.
> > > 
> > > I personally don't know what I would do if screen was forcibly exited
> > > when I left the desktop environment.  I've been relying on screen to
> > > run data analysis processes which take a long time due primarily to
> > > file i/o and not memory or cpu.  What would be the quickest and least
> > > annoying workaround for that behavior. I guess it would be to open a
> > > gnome-terminal, then ssh into localhost and then start screen from
> > > inside the ssh session.  Then when the desktop session ended and all
> > > related processes were killed, gnome-terminal and the ssh connection
> > > would die, but the screen session would live because it was started
> > > from inside the ssh session and thus outside the scope of desktop
> > > session itself.
> > 
> > I can't *wait* to explain that in the release notes.
> 
> No, Jeff is getting it wrong. According to the thread SIGHUP is proposed
> to be used and screen(1) don't exit when someone sends SIGHUP to it. No
> need to cry wolf...

SIGHUP already have a defined meaning, and is normally sent when the
controlling tty disappears. In an X session this would be when the
terminal app dies. I'm not sure that extending/changing this will work
well.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]