Hi,
After investigating (please read the full report including links to desktop-devel-list)
https://bugzilla.redhat.com/show_bug.cgi?id=427316
I realized what an incredibly poor state session service management is in and what kind of hoops upstream authors jump through because neither X11, nor xdg or GNOME has provided them with useful infrastructure. It looks like KDE has _some_ kind of infrastructure for this.
There are basically two problems that we've been ignoring and hacking around for as long as I've used Linux on the desktop
1. There is no good way of starting session services that needs to export environment variables. While one may rightfully argue this is utter crack in most cases, things like seahorse-agent demonstrates that this is sometimes needed. Also, you surely need to do this for the session message bus.
2. I think we've all experienced this one or more times; you log out of your session and log back in. Wow, now things are weird or maybe doesn't even work. The reason for this is that processes from your old session keeps hanging around. In fact, I was bitten by this just before the holidays; I simply couldn't login. Why? An old gconfd process was lingering and that blocked login. The solution? Log in as root on VT1 and do the usual 'killall -9 -u davidz' dance.
The latter problem is, I think, on the level of being a security bug. The former is just hindering process and is making people build on top of our platform (speaking in upstream sense here) do really crackful things like rewriting your .gnupg/gpg.conf file.
I think with a little work we could fix this on the X11 level and potentially get this upstream too. First, in Fedora we actually got a rather decent way of solving 1.; see
https://bugzilla.redhat.com/show_bug.cgi?id=427316#c15
for the solution. Unfortunately, this a) isn't upstream; and b) isn't as perfect as it needs to be. If you follow the flow, basically this happens
/usr/bin/xinit sources /etc/X11/xinit/xinitrc sources /etc/X11/xinit/xinitrc-common sources /etc/X11/xinit/xinitrc.d/*.sh sets up SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION does some weird stuff, then evals three variables above and, essentially, execs gnome-session or startkde
Observations
a. Ideally SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION would just use /etc/X11/xinit/xinitrc.d/. I'm told this is to make sure things are reaped (because of problem 2. above)
b. It's annoying that the session bus is started after the stuff in /etc/X11/xinit/xinitrc.d/ - no session bus for you.
c. No way to run code once the session is over.
Proposal
Assuming problem 2. will be magically solved for us (see below), we could nicely rearrange the flow such that SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION could just use standard constructs in /etc/X11/xinit/xinitrc.d/.
Another observation is that only stuff using environment variables should use /etc/X11/xinit/xinitrc.d/ (some man page should spell this out) - everything else should use the XDG autostart spec (where we have UI, e.g. gnome-session-properties).
Also, since we're talking about environment variables, we surely need to care about the ordering; e.g. we want
00-ck-xinit-session.sh 01-dbus-session-bus.sh 10-ssh-agent.sh 10-seahorse-agent.sh
and so forth. Again, the man page should be clear about this. Also, there should be a README file in /etc/X11/xinit/xinitrc.d/ that points to the man page.
Instead of exec'ing gnome-session, we run it in the background. When we are done we run the same scripts in reverse just with 'stop' instead of 'start' as the first positional parameter.
Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it does this is because of the way that ConsoleKit works. It basically will just kill all the processes where the uid and the environment variable XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few seconds, it moves on to SIGKILL (e.g. -9).
(of course, any process can unset XDG_SESSION_COOKIE and then fork and that way linger on. But no sane process would do that unless it's hostile.)
All of this only includes modifying xorg-x11-xinit. We surely should get this upstream.
The benefits?
- Things like seahorse-agent, ssh-agent and so forth now has proper infrastructure to use. If we make the docs good enough we can point people to these and hopefully people won't do horrendous things like e.g. rewriting .gnupg/gpg.conf.
- We solve the decade-long problem of lingering processes after logout.
I think this is a pretty small project that could be done in a few days, maybe a week. Any takers? Thoughts? Am I on crack?
David
Hi,
David Zeuthen wrote:
- I think we've all experienced this one or more times; you log out of your session and log back in. Wow, now things are weird or maybe doesn't even work. The reason for this is that processes from your old session keeps hanging around. In fact, I was bitten by this just before the holidays; I simply couldn't login. Why? An old gconfd process was lingering and that blocked login. The solution? Log in as root on VT1 and do the usual 'killall -9 -u davidz' dance.
This may be obvious, but the "correct" solution is supposed to be that apps should connect to either the X server or the session message bus and they should exit when the X server or message bus does. (Both Xlib and libdbus exit on disconnect by default for this reason.)
Other solutions are pretty much hacks, I mean, they may be worthwhile and pragmatic hacks, but, nonetheless. Apps should be exiting with the session already or they are buggy.
One alternate approach might be to write a little babysitter/proxy app (just like the way dbus-launch ties the session bus to the X server). The babysitter app would connect to the session bus, then exec its args as a child process, and kill the child process when it lost the connection. Of course, this involves modifying any code that launches a session service so it launches it with the babysitter, so perhaps not ideal.
Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it does this is because of the way that ConsoleKit works. It basically will just kill all the processes where the uid and the environment variable XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few seconds, it moves on to SIGKILL (e.g. -9).
I would think this should only be done after the session bus is gone and apps have had a chance to cleanly exit, and maybe some kind of warning should be logged like "crappy app xyz had to be killed"
There is a race, where a correct app that was on its way to exiting on its own gets killed because it was too slow... but in practice I doubt that would happen too much.
Havoc
On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
This may be obvious, but the "correct" solution is supposed to be that apps should connect to either the X server or the session message bus and they should exit when the X server or message bus does. (Both Xlib and libdbus exit on disconnect by default for this reason.)
Of course...
Other solutions are pretty much hacks, I mean, they may be worthwhile and pragmatic hacks, but, nonetheless. Apps should be exiting with the session already or they are buggy.
... but people write all sorts of weird apps, they have religious reasons for not wanting deps.. that, and as soon as you require people to add code to their app then everything falls apart.
I would think this should only be done after the session bus is gone and apps have had a chance to cleanly exit, and maybe some kind of warning should be logged like "crappy app xyz had to be killed"
Certainly. The proposed ordering would guarantee this (00 < 01). I'm a big fan of logging this to syslog too.
David
David Zeuthen wrote:
Also, since we're talking about environment variables, we surely need to care about the ordering; e.g. we want
00-ck-xinit-session.sh 01-dbus-session-bus.sh 10-ssh-agent.sh 10-seahorse-agent.sh
and so forth.
That still doesn't work though; dbus-daemon won't have access to $SSH_AGENT or $GPG_AGENT_INFO, and so therefore neither will any applications that it launches. (We already have this problem with $SESSION_MANAGER.)
The only real solution is "don't use environment variables for long-term IPC". Eg, libgnomekeyring used to use an environment variable to find gnome-keyring-daemon, which ended up meaning that dbus-launched apps couldn't access gnome-keyring, but now it's been fixed to use dbus instead. But yeah, we're not going to get gpg and ssh to use dbus, I know.
The "new-gnome-session" branch in SVN (which Lucas Rocha is hacking on, but it looks like won't make it in time for 2.22?) has a dbus interface (org.gnome.SessionManager.Setenv) that lets apps that start very early in the startup process hand environment variables back up to the session manager so that apps started after them will see those vars. If dbus-daemon itself also supported something like this, that would help solve the ordering issues somewhat (though still not entirely).
-- Dan
Hi,
Also, since we're talking about environment variables, we surely need to care about the ordering; e.g. we want
00-ck-xinit-session.sh 01-dbus-session-bus.sh 10-ssh-agent.sh 10-seahorse-agent.sh
and so forth.
That still doesn't work though; dbus-daemon won't have access to $SSH_AGENT or $GPG_AGENT_INFO, and so therefore neither will any applications that it launches. (We already have this problem with $SESSION_MANAGER.)
Those scripts get sourced before dbus daemon is launched.
--Ray
Ray Strode wrote:
Hi,
Also, since we're talking about environment variables, we surely need to care about the ordering; e.g. we want
00-ck-xinit-session.sh 01-dbus-session-bus.sh 10-ssh-agent.sh 10-seahorse-agent.sh
and so forth.
That still doesn't work though; dbus-daemon won't have access to $SSH_AGENT or $GPG_AGENT_INFO, and so therefore neither will any applications that it launches. (We already have this problem with $SESSION_MANAGER.)
Those scripts get sourced before dbus daemon is launched.
*currently*. But that's exactly what David is talking about changing. (Note the ordering above.)
-- Dan
Hi,
Assuming problem 2. will be magically solved for us (see below), we could nicely rearrange the flow such that SSH_AGENT, DBUS_LAUNCH, CK_XINIT_SESSION could just use standard constructs in /etc/X11/xinit/xinitrc.d/.
I actually have that written on my whiteboard as a TODO when I get time.
Another observation is that only stuff using environment variables should use /etc/X11/xinit/xinitrc.d/ (some man page should spell this out) - everything else should use the XDG autostart spec (where we have UI, e.g. gnome-session-properties).
Also, since we're talking about environment variables, we surely need to care about the ordering; e.g. we want
00-ck-xinit-session.sh 01-dbus-session-bus.sh 10-ssh-agent.sh 10-seahorse-agent.sh
and so forth. Again, the man page should be clear about this. Also, there should be a README file in /etc/X11/xinit/xinitrc.d/ that points to the man page.
Instead of exec'ing gnome-session, we run it in the background. When we are done we run the same scripts in reverse just with 'stop' instead of 'start' as the first positional parameter.
Starting to seem a lot like initscripts... Anyway, definitely could be improvement here, but I don't think we should promote this directory too much. We really want apps using the session bus instead of their own socket protocol and an environment variable to advertise where it is.
Really this directory is an escape hatch for programs that don't leverage our platform.
I think this is a pretty small project that could be done in a few days, maybe a week.
Much bigger, more important fish to fry right now.
--Ray
Hi,
On Thu, 2008-01-03 at 20:10 -0500, David Zeuthen wrote:
Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it does this is because of the way that ConsoleKit works. It basically will just kill all the processes where the uid and the environment variable XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few seconds, it moves on to SIGKILL (e.g. -9).
(of course, any process can unset XDG_SESSION_COOKIE and then fork and that way linger on. But no sane process would do that unless it's hostile.)
Not in the least, there are programs which are supposed to stay running even when you log out -- screen, vncserver, nohup'ed processes etc. Mind that non-desktop oriented projects might not be that inclined to work around the "desktop strangeness du jour" (background processes being killed when logging out would count as such).
On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
This may be obvious, but the "correct" solution is supposed to be that apps should connect to either the X server or the session message bus and they should exit when the X server or message bus does. (Both Xlib and libdbus exit on disconnect by default for this reason.)
This would solve the problem above more cleanly.
Nils
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
This may be obvious, but the "correct" solution is supposed to be that apps should connect to either the X server or the session message bus and they should exit when the X server or message bus does. (Both Xlib and libdbus exit on disconnect by default for this reason.)
This would solve the problem above more cleanly.
Except that a decade of evidence shows us this is not the case.... but I guess you'd rather want the status quo, with all the security issues and perceived instability, rather than a working and secure system...
(But then again, this is the typical story of the Linux desktop; we can't ever change or fix a thing because people who use the desktop in rather strange (dare I even say perverse?) ways (e.g. expecting processes to keep running) will start complaining as soon as we change something that will break their highly-customized setups and habits. Do not pass start. Do not collect $100. Instead let the naysayers and status quo win.)
David
On Fri, 2008-01-04 at 10:22 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
This may be obvious, but the "correct" solution is supposed to be that apps should connect to either the X server or the session message bus and they should exit when the X server or message bus does. (Both Xlib and libdbus exit on disconnect by default for this reason.)
This would solve the problem above more cleanly.
Except that a decade of evidence shows us this is not the case.... but I guess you'd rather want the status quo, with all the security issues and perceived instability, rather than a working and secure system...
Show me why your proposal (which you admitted can be circumvented easily) is better or more secure than fixing the handful of programs that don't end themselves when the session exits. If we don't talk about hostile processes which actively circumvent, we're talking about dumb processes. These should be fixed rather than declaring stuff which up to now worked correctly as erroneous just to avoid doing the fixing. Where is the difficulty in letting these handful of processes either connect to dbus, X11 or the session manager and bail out if the connection dies? I'm curious.
(But then again, this is the typical story of the Linux desktop; we can't ever change or fix a thing because people who use the desktop in rather strange (dare I even say perverse?) ways (e.g. expecting processes to keep running) will start complaining as soon as we change something that will break their highly-customized setups and habits. Do not pass start. Do not collect $100. Instead let the naysayers and status quo win.)
David, you need to accept that there are people who use computers differently than you think they should. This doesn't make them second class users. Only because an approach is different from what exists already, that doesn't make it better. I like to think that much can be achieved without hurting existing users. If that makes me a naysayer, it makes you a yeasayer which is almost equally bad ;-).
Nils
On Fri, 2008-01-04 at 17:19 +0100, Nils Philippsen wrote:
Show me why your proposal (which you admitted can be circumvented easily) is better or more secure than fixing the handful of programs that don't end themselves when the session exits. If we don't talk about hostile processes which actively circumvent, we're talking about dumb processes. These should be fixed rather than declaring stuff which up to now worked correctly as erroneous just to avoid doing the fixing. Where is the difficulty in letting these handful of processes either connect to dbus, X11 or the session manager and bail out if the connection dies? I'm curious.
Maybe it's just me, but I think it's a lot easier to just fix the few programs such as screen and nohup to opt out of getting reaped.. rather than going through every potential program in the distro (or on the planet) that people may launch in their session. There's an analogy here: Maintaining a whitelist is a lot easier than maintaining a blacklist.
David, you need to accept that there are people who use computers differently than you think they should. This doesn't make them second class users. Only because an approach is different from what exists already, that doesn't make it better. I like to think that much can be achieved without hurting existing users. If that makes me a naysayer, it makes you a yeasayer which is almost equally bad ;-).
Nils, it's very evident you are in the annoying "oh, but it's worked this way forever so we can't change it" camp. You need to accept that some of us are not and your camp is sometimes perceived as hindering progress. The indisputable fact is that X11 session service management is just *broken* as I outlined in my original mail. The fact that some people take advantage of this brokenness via screen, nohup etc. doesn't mean we shouldn't fix the fundamental problem. Doesn't mean either we shouldn't fix the few oddball cases such as screen and nohup to opt out of getting reaped.
David
On Fri, 2008-01-04 at 11:29 -0500, David Zeuthen wrote:
Maybe it's just me, but I think it's a lot easier to just fix the few programs such as screen and nohup to opt out of getting reaped..
Unix has had a pretty standard definition of "session" using SIGHUP. The way programs have historically "opted out" of termination is to ignore that signal.
I don't think we should change that.
Rather, some programs should be fixed to gain a dep on X11, DBus, or be run through the babysitter.
On Fri, 2008-01-04 at 11:37 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 11:29 -0500, David Zeuthen wrote:
Maybe it's just me, but I think it's a lot easier to just fix the few programs such as screen and nohup to opt out of getting reaped..
Unix has had a pretty standard definition of "session" using SIGHUP. The way programs have historically "opted out" of termination is to ignore that signal.
I don't think we should change that.
Fine so we send a SIGHUP instead of SIGTERM, then SIGKILL. Makes this a lot easier.....
Rather, some programs should be fixed to gain a dep on X11, DBus, or be run through the babysitter.
Why do you think it's a good idea to add libX11 or libdbus deps to a program that don't use either? Do you think random upstream projects would ever take such patches?
David
On Fri, 2008-01-04 at 11:40 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 11:37 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 11:29 -0500, David Zeuthen wrote:
Maybe it's just me, but I think it's a lot easier to just fix the few programs such as screen and nohup to opt out of getting reaped..
Unix has had a pretty standard definition of "session" using SIGHUP. The way programs have historically "opted out" of termination is to ignore that signal.
I don't think we should change that.
Fine so we send a SIGHUP instead of SIGTERM, then SIGKILL. Makes this a lot easier.....
Sending SIGHUP to all processes manually is fine; in theory actually the kernel will do this for you when the process session group leader exits. Now, whether something is correctly set as the process group leader in the twisted desktop login stack is an open question. A regression here would mostly be masked by the fact that *almost* everything run from the desktop does connect to X11.
Rather, some programs should be fixed to gain a dep on X11, DBus, or be run through the babysitter.
Why do you think it's a good idea to add libX11 or libdbus deps to a program that don't use either? Do you think random upstream projects would ever take such patches?
The babysitter is another option. But I think (generally speaking) most projects nowadays *should* gain a dbus dep, and if we can explain clearly to them why it it useful, they would accept it.
On Fri, 2008-01-04 at 12:04 -0500, Colin Walters wrote:
Sending SIGHUP to all processes manually is fine; in theory actually the kernel will do this for you when the process session group leader exits. Now, whether something is correctly set as the process group leader in the twisted desktop login stack is an open question. A regression here would mostly be masked by the fact that *almost* everything run from the desktop does connect to X11.
Lots of programs (including GNOME ones) daemonizes e.g. creates their own process group etc. etc. so clearly we can't rely on this.
That's why we need to iterate over the process list and send SIGHUP to processes matching the uid and XDG_SESSION_COOKIE (or other attribute but XDG_SESSION_COOKIE is what we have right now). It's not really rocket science.
Rather, some programs should be fixed to gain a dep on X11, DBus, or be run through the babysitter.
Why do you think it's a good idea to add libX11 or libdbus deps to a program that don't use either? Do you think random upstream projects would ever take such patches?
The babysitter is another option.
You are being vague here; I think you just use that term because Havoc said something vague about a babysitter execing stuff. The way I read this (it's vague so I'm guessing) sounds like it needs source code modification and if it isn't clear I don't think that's an option.
But I think (generally speaking) most projects nowadays *should* gain a dbus dep, and if we can explain clearly to them why it it useful, they would accept it.
I think that is what they call wishful thinking. Seriously.
David
On Fri, 2008-01-04 at 12:12 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 12:04 -0500, Colin Walters wrote:
Sending SIGHUP to all processes manually is fine; in theory actually the kernel will do this for you when the process session group leader exits. Now, whether something is correctly set as the process group leader in the twisted desktop login stack is an open question. A regression here would mostly be masked by the fact that *almost* everything run from the desktop does connect to X11.
Lots of programs (including GNOME ones) daemonizes e.g. creates their own process group etc. etc. so clearly we can't rely on this.
There's no reason for programs to daemonize for the desktop session. If they are, it's a bug. Most likely it's just a case of someone thinking their program is l33t because it's a "daemon".
That's why we need to iterate over the process list and send SIGHUP to processes matching the uid and XDG_SESSION_COOKIE (or other attribute but XDG_SESSION_COOKIE is what we have right now). It's not really rocket science.
It's also working around bugs in other apps; and I don't think the list of buggy apps is very large. GConf and bonobo are the two main offenders.
You are being vague here; I think you just use that term because Havoc said something vague about a babysitter execing stuff. The way I read this (it's vague so I'm guessing) sounds like it needs source code modification and if it isn't clear I don't think that's an option.
It doesn't require modifying apps. The idea is just to have a binary which monitors X11/DBus, and can fork()/exec() a child binary to monitor. If X11 goes away, it kills the child. Thus the only thing that needs to be modified is that the session startup script is changed from:
some-random-daemon --args
to:
dbus-scope-to-session some-random-daemon --args
But I think (generally speaking) most projects nowadays *should* gain a dbus dep, and if we can explain clearly to them why it it useful, they would accept it.
I think that is what they call wishful thinking. Seriously.
Let's be more concrete here - what other apps are buggy?
On Fri, 2008-01-04 at 12:37 -0500, Colin Walters wrote:
It doesn't require modifying apps. The idea is just to have a binary which monitors X11/DBus, and can fork()/exec() a child binary to monitor. If X11 goes away, it kills the child. Thus the only thing that needs to be modified is that the session startup script is changed from:
some-random-daemon --args
to:
dbus-scope-to-session some-random-daemon --args
Falls apart when some-random-daemon daemonizes...
But I think (generally speaking) most projects nowadays *should* gain a dbus dep, and if we can explain clearly to them why it it useful, they would accept it.
I think that is what they call wishful thinking. Seriously.
Let's be more concrete here - what other apps are buggy?
I'm sorry but I don't have a magical list of all the potential programs that people may run. And if I did, I certainly wouldn't put myself through the pain of reviewing each and every program even if I had the source code.
David
On Fri, 2008-01-04 at 12:44 -0500, David Zeuthen wrote:
I'm sorry but I don't have a magical list of all the potential programs that people may run. And if I did, I certainly wouldn't put myself through the pain of reviewing each and every program even if I had the source code.
Remember though - we're only talking about programs running in the desktop session which don't connect to X. That set is radically smaller than the set of "all potential programs".
On Fri, 2008-01-04 at 11:29 -0500, David Zeuthen wrote:
Nils, it's very evident you are in the annoying "oh, but it's worked this way forever so we can't change it" camp. You need to accept that some of us are not and your camp is sometimes perceived as hindering progress.
David, you should have listened in on some of the conversations I had with colleagues in the office, then you would have to admit that putting me in the "change is baaad" crowd is a bit far-fetched.
If I wanted to talk in terms of "camps" or "crowds" (which I don't, because this kind of simplification just causes hostilities), then I'd put myself in the "let's look at this from all angles" or "don't break things without good cause" corners. Granted, this in itself is a sure recipe to annoy more people and it would help if I not just criticized stuff but also e.g. talked about where I experience new things as positive. Apologies for that.
The indisputable fact is that X11 session service management is just *broken* as I outlined in my original mail. The fact that some people take advantage of this brokenness via screen, nohup etc. doesn't mean we shouldn't fix the fundamental problem. Doesn't mean either we shouldn't fix the few oddball cases such as screen and nohup to opt out of getting reaped.
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. It's bad that X session management is broken, but I don't see a compelling reason yet why stuff that has got nothing to do with X should accommodate workarounds for such brokenness.
Or to phrase it in a (hopefully) less annoying way: I think it should be feasible to have programs which should end with the session be "bound" (by whatever means) to the session manager in a way where the session manager kills them off at the end of the session without making this leak to all child processes. Kind of like POSIX process groups, where the session manager takes the role of the process group leader. Hey, if GUI apps wouldn't have the obnoxious habit of disconnecting from their parent processes (e.g. via the fork()/exit() "workaround" you mentioned in another post), we even might get by with walking the process tree from the session manager process downwards.
Talking about the issue at hand, there are already two ways that cause processes to end if the session ends (libX11 and dbus), it should be easy enough to fix the remainder properly.
Nils
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.
-jef
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.
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...
David
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...
/me wipes sweat from brow. :-) Thanks, David.
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.
On Tue, 2008-01-08 at 10:05 +0100, Alexander Larsson wrote:
SIGHUP already have a defined meaning, and is normally sent when the controlling tty disappears.
Right.
In an X session this would be when the terminal app dies. I'm not sure that extending/changing this will work well.
It seems analogous to me to send SIGHUP to the process group when the desktop session ends. ConsoleKit adds a new notion of "session" defined by the XDG_SESSION_COOKIE which includes even processes which disassociate themselves from the initial login process group. That's fine and should make things more robust, though I would still argue that processes launched as part of the "normal" desktop which setsid (or more generally "daemonize") are wrong.
Anyways, I think if David changes ConsoleKit to send SIGHUP instead of SIGTERM/SIGKILL as he said he would, we're all happy. "nohup" etc. continue to work unmodified.
On Fri, 2008-01-04 at 19:50 +0100, Nils Philippsen wrote:
David, you should have listened in on some of the conversations
(JFYI It's pretty patronizing to address people like "XXX, blabla". It's passive aggressive.)
As for the rest of the thread, I give up because, frankly, it's tiring and this part of the open source "process" isn't my cup of tea. Have fun
David
On Fri, 2008-01-04 at 14:23 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 19:50 +0100, Nils Philippsen wrote:
David, you should have listened in on some of the conversations
(JFYI It's pretty patronizing to address people like "XXX, blabla".
It wasn't my intention to patronize you or anybody else just by addressing you with your given name. Sorry for that.
It's passive aggressive.)
It isn't. It'd rather be a lack of social graces ;-).
As for the rest of the thread, I give up because, frankly, it's tiring and this part of the open source "process" isn't my cup of tea. Have fun
Arguing about different standpoints can be tiresome sometimes. Hopefully I haven't tired you too much...
Nils
On Jan 4, 2008 6:22 AM, David Zeuthen davidz@redhat.com wrote:
Do not pass start. Do not collect $100.
Has the value of the US dollar de-valued so much that we only get 100 in funny colored (what I assumed is Canadian) dollars for passing go now?
-jef"Back in my day..we got $200..and we liked it"spaleta
On Fri, 2008-01-04 at 08:32 -0900, Jeff Spaleta wrote:
On Jan 4, 2008 6:22 AM, David Zeuthen davidz@redhat.com wrote:
Do not pass start. Do not collect $100.
Has the value of the US dollar de-valued so much that we only get 100 in funny colored (what I assumed is Canadian) dollars for passing go now?
Well, and evidently it's been renamed to 'start' instead of 'go'.
crazy. :)
-sv
On Fri, 2008-01-04 at 08:32 -0900, Jeff Spaleta wrote:
On Jan 4, 2008 6:22 AM, David Zeuthen davidz@redhat.com wrote:
Do not pass start. Do not collect $100.
Has the value of the US dollar de-valued so much that we only get 100 in funny colored (what I assumed is Canadian) dollars for passing go now?
-jef"Back in my day..we got $200..and we liked it"spaleta
Sorry, I'm not from around here. And last time I played Monopoly, I guess some 15-20 years ago, the USD was actually twice as much to the DKK than it is today.
David
On Jan 4, 2008 8:39 AM, David Zeuthen davidz@redhat.com wrote:
Sorry, I'm not from around here. And last time I played Monopoly, I guess some 15-20 years ago, the USD was actually twice as much to the DKK than it is today.
Which makes the use of the phrase all that more interesting.. in a very off-topic sort of way. Does US consumer culture have a ...monopoly... on widely adopted popular culture? It makes me a little sad to think that it might. I was hoping interacting with a global community, even if we are doing it in Englishese, I'd get a chance to vacuum up some useful, badly translated and out-of-context colloquial phrases from other cultures.
-jef"was really hoping the global internet community would develop a pidgin language that looks more like Card's battle school pidgin and less like aol-speak"spaleta
On Fri, 2008-01-04 at 09:01 -0900, Jeff Spaleta wrote:
On Jan 4, 2008 8:39 AM, David Zeuthen davidz@redhat.com wrote:
Sorry, I'm not from around here. And last time I played Monopoly, I guess some 15-20 years ago, the USD was actually twice as much to the DKK than it is today.
Which makes the use of the phrase all that more interesting.. in a very off-topic sort of way. Does US consumer culture have a ...monopoly... on widely adopted popular culture? It makes me a little sad to think that it might. I was hoping interacting with a global community, even if we are doing it in Englishese, I'd get a chance to vacuum up some useful, badly translated and out-of-context colloquial phrases from other cultures.
-jef"was really hoping the global internet community would develop a pidgin language that looks more like Card's battle school pidgin and less like aol-speak"spaleta
you're gathering a jeesh even now, ne? :)
-sv
On Fri, 04 Jan 2008 13:11:21 -0500 seth vidal skvidal@fedoraproject.org wrote:
you're gathering a jeesh even now, ne? :)
Ho, seth.
"Jeff Spaleta" jspaleta@gmail.com writes:
Which makes the use of the phrase all that more interesting.. in a very off-topic sort of way. Does US consumer culture have a ...monopoly... on widely adopted popular culture?
This particular game is so old that when it was introduced in Denmark (I don't know exactly when, but definitely before the 1940's), it was extensively localized. The name was changed to "Matador" and all the property names were taken from Copenhagen street names. The board is circular rather than square, and there is only one type of event card.
Over time the prices in Matador have changed; in my parents' version of the game you collect DKR 200 when you pass go, in the last version I played, you collect DKR 4000. Another difference is that all the pieces are cars - and always Volvos - in the Danish version.
I'm not sure the game would be changed that much if it were introduced to Denmark today.
Soren
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
Not in the least, there are programs which are supposed to stay running even when you log out -- screen, vncserver, nohup'ed processes etc.
No one is talking about changing the semantics of "nohup".
What we're talking about it is that it is actually hard to write apps to exit with the session when that's what is the desired behavior.
On Fri, 2008-01-04 at 11:10 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
Not in the least, there are programs which are supposed to stay running even when you log out -- screen, vncserver, nohup'ed processes etc.
No one is talking about changing the semantics of "nohup".
Perhaps I'm a bit slow, but how would it not do this if it relies on the inheritance of a previously non-existent environment variable that needs to be deleted if a process shall not be killed on session exit?
What we're talking about it is that it is actually hard to write apps to exit with the session when that's what is the desired behavior.
I still don't understand why this would be the case. I assume what Havoc wrote is true, i.e. stuff that uses xlib or dbus is already covered. How is it difficult to let the remaining handful of processes die when the session exits? We could even let these few register themselves with gnome-session (or whatever else is applicable) so it could explicitly kill them on session exit, couldn't we?
Nils
On Fri, 2008-01-04 at 17:23 +0100, Nils Philippsen wrote:
On Fri, 2008-01-04 at 11:10 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
Not in the least, there are programs which are supposed to stay running even when you log out -- screen, vncserver, nohup'ed processes etc.
No one is talking about changing the semantics of "nohup".
Perhaps I'm a bit slow, but how would it not do this if it relies on the inheritance of a previously non-existent environment variable that needs to be deleted if a process shall not be killed on session exit?
Oh I see, I was wrong; yes David was talking about automatically killing all processes. That is wrong, I agree with you.
As Havoc said, having them connect to X11 or DBus, or using a babysitter that does is the right way.
On Fri, 2008-01-04 at 11:35 -0500, Colin Walters wrote:
Oh I see, I was wrong; yes David was talking about automatically killing all processes. That is wrong, I agree with you.
Care to explain why this is wrong?
As Havoc said, having them connect to X11 or DBus, or using a babysitter that does is the right way.
So in order to avoid having a process linger we now need to patch it? Good luck with that....
David
On Fri, 2008-01-04 at 11:37 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 11:35 -0500, Colin Walters wrote:
Oh I see, I was wrong; yes David was talking about automatically killing all processes. That is wrong, I agree with you.
Care to explain why this is wrong?
See my other mail.
As Havoc said, having them connect to X11 or DBus, or using a babysitter that does is the right way.
So in order to avoid having a process linger we now need to patch it? Good luck with that....
Don't need luck in the original case you were talking about, just an editor and commit access to the upstream =)
Here's a patch for GConf:
On Fri, 2008-01-04 at 12:01 -0500, Colin Walters wrote:
Don't need luck in the original case you were talking about, just an editor and commit access to the upstream =)
Here's a patch for GConf:
Might work for GConf; not going to work for the rest of the software on the planet. See, if even upstream GNOME can't get this right.. then how do you imagine the rest of the free-software eco-system getting it right? Not to mention all the apps people run for which you will never see the source...
David
On Fri, 2008-01-04 at 12:01 -0500, Colin Walters wrote:
Here's a patch for GConf:
This issue can now be tracked at: http://bugzilla.gnome.org/show_bug.cgi?id=507310
On Fri, 2008-01-04 at 11:35 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 17:23 +0100, Nils Philippsen wrote:
On Fri, 2008-01-04 at 11:10 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
Not in the least, there are programs which are supposed to stay running even when you log out -- screen, vncserver, nohup'ed processes etc.
No one is talking about changing the semantics of "nohup".
Perhaps I'm a bit slow, but how would it not do this if it relies on the inheritance of a previously non-existent environment variable that needs to be deleted if a process shall not be killed on session exit?
Oh I see, I was wrong; yes David was talking about automatically killing all processes. That is wrong, I agree with you.
As Havoc said, having them connect to X11 or DBus, or using a babysitter that does is the right way.
One problem here is that too many apps set exit-on-disconnect false with D-Bus to work around bugs in the stupid app where the app gets kicked off the bus for doing something bad.
dan
On Fri, 2008-01-04 at 11:46 -0500, Dan Williams wrote:
One problem here is that too many apps set exit-on-disconnect false with D-Bus to work around bugs in the stupid app where the app gets kicked off the bus for doing something bad.
That is a per-connection property and only apps connecting to the system bus does this. The app would presumably have a libx11 or session bus connection and that would force to exit(). Otherwise we reap it with SIGHUP.
(Btw, even though HUP means "Hang Up Now", many programs abuse this signal to mean "reload config" or "reexec yourself" or whatever the want. But I guess we can fix that small proportion of programs.)
David
On Fri, 2008-01-04 at 17:23 +0100, Nils Philippsen wrote:
On Fri, 2008-01-04 at 11:10 -0500, Colin Walters wrote:
On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
Not in the least, there are programs which are supposed to stay running even when you log out -- screen, vncserver, nohup'ed processes etc.
No one is talking about changing the semantics of "nohup".
Perhaps I'm a bit slow, but how would it not do this if it relies on the inheritance of a previously non-existent environment variable that needs to be deleted if a process shall not be killed on session exit?
The way someone would opt out would be to do this
unsetenv("XDG_SESSION_COOKIE"); if (fork() <= 0) exit (1);
very early in the program.
David
On Thu, 03.01.08 20:10, David Zeuthen (davidz@redhat.com) wrote:
Hi,
After investigating (please read the full report including links to desktop-devel-list)
https://bugzilla.redhat.com/show_bug.cgi?id=427316
I realized what an incredibly poor state session service management is in and what kind of hoops upstream authors jump through because neither X11, nor xdg or GNOME has provided them with useful infrastructure. It looks like KDE has _some_ kind of infrastructure for this.
There are basically two problems that we've been ignoring and hacking around for as long as I've used Linux on the desktop
[...]
I still believe the proper way to fix this is have some kind of babysitter daemon that shares most of its code with the init system. The problems for system startup and service management and for session startup and service management are mostly the same. Both sides would benefit if system and session startup/management would be handled by the same powerful system.
Lennart
On Fri, 2008-01-04 at 18:26 +0100, Lennart Poettering wrote:
I still believe the proper way to fix this is have some kind of babysitter daemon that shares most of its code with the init system. The problems for system startup and service management and for session startup and service management are mostly the same. Both sides would benefit if system and session startup/management would be handled by the same powerful system.
Indeed, but until that pie-in-the-blue-sky thing is available I think it's worthwhile to make this tiny enhancement (it would have been quicker to JFDI than entertaining a whole thread about it).
David
On Fri, 2008-01-04 at 12:34 -0500, David Zeuthen wrote:
On Fri, 2008-01-04 at 18:26 +0100, Lennart Poettering wrote:
I still believe the proper way to fix this is have some kind of babysitter daemon that shares most of its code with the init system. The problems for system startup and service management and for session startup and service management are mostly the same. Both sides would benefit if system and session startup/management would be handled by the same powerful system.
Indeed, but until that pie-in-the-blue-sky thing is available I think it's worthwhile to make this tiny enhancement (it would have been quicker to JFDI than entertaining a whole thread about it).
What is an enhancement in your scope would break things in other people's scopes -- we would have had this discussion either way. By discussing things first you at least escaped accusations of being part of a "cabal" doing things "in the secret" and "shoving it down other people's throats" ;-P.
Nils
desktop@lists.fedoraproject.org
-
Alexander Larsson -
Colin Walters -
Dan Williams -
Dan Winship -
David Zeuthen -
Havoc Pennington -
Jef Spaleta -
Jesse Keating -
Lennart Poettering -
Nils Philippsen -
Paul W. Frields -
Ray Strode -
Seth Vidal -
Soren Pedersen