On Mon 22 Nov 2021 at 16:14:37 (-0500), Greg Wooledge wrote: > On Mon, Nov 22, 2021 at 02:45:28PM -0600, David Wright wrote: > > I implied in my first post that a background job started in .xsession > > would be killed when the X server terminated, be that by reaching the > > end of the .xsession script (if you prefer that expression), or by > > killing the X server (which abandons the rest of the .xsession script). > > But I think this applies only if it maps a window, hence the need to > > kill it, as shown in your example above, and absent from my post. > > The .xsession file is executed as a shell script, either under sh or bash > or some other shell, depending on the permissions on the file, the user's > login account's shell, the shebang (if any) inside the .xsession file, > and possibly other factors. Let's assume sh or bash, because I don't > want to make blanket statements about other shells. I don't know how > they all work. > > If you run a non-X background job from a shell script (including .xsession), > and the script terminates, the background job will keep running. That is, > unless you've specifically taken steps to arrange for something to kill > that background job. It will not happen automatically.
You're right, and that's the correction I was making above. > In the event of an X client run as a background job, that X client will > be forcefully killed when the X server shuts down. > > So, at least some parts of the paragraph quoted above are correct. > X client programs will always be killed (by termination of the X server). > > You've also claimed that "zapping" the X server, as opposed to exiting > the window manager in the normal manner, causes the .xsession script to > be killed prematurely. I have my doubts about this, but I am not going > to test it. First and foremost, because it's a *real* pain in the ass > to log out and back in and get everything set back up the way I like. > Second, because Debian hasn't configured X with a "zap" option by default > in a very long time, and I don't feel like changing my X configuration > to put a deprecated "zap" option back into it. > > I don't immediately see any reason why "zapping" the X server would kill > the .xsession shell script. As far as I know, it should continue > running just like any other shell script. The only reasons it would > exit are: > > (1) You've reached the end of the script. > (2) You've called "exit". > (3) You've used "exec" to replace the shell with some other program, such > as a window manager. > (4) You've used "set -e" or an equivalent option, and one of your commands > exited with a nonzero status in a context where set -e will trigger > and kill the shell. > > I suspect you've run across one of the above cases, without realizing it. Well, that would be a welcome correction—and one less thing to worry about. > On Mon, Nov 22, 2021 at 02:45:43PM -0600, David Wright wrote: > > I haven't looked for differences that might have arisen since systemd > > entered upon the scene (and I've yet to work my way through your > > addition to this subthread), but in looking through /etc/X11/ to see > > what x-session-manager might be, I see that Xsession.d has a twin, > > Xreset.d, called from Xreset. This says it's for "when a user log[s] > > out from a display manager", which might be what the OP is doing > > "when I log out [and] it [unison] is orphaned and not terminated". > > I don't consider that a valid solution to the problem, because there is no > equivalent at the user level. Anything that goes into /etc/X11/Xreset.d/ > is executed *as root* when *any* user's display manager X session > terminates. > > That's just unacceptable. Primarily because it applies to all users, not > just the one user who wants it. Secondarily because it runs as root > instead of the user whose session is ending. Third (tertiar[il]y-something?) > because it only applies to DM sessions, not startx. I can't argue with your teriary reason. The other two shouldn't matter because (1) the script can check for which user it is, in $USER, and (2) then runuser as that user. Cheers, David.
