Re: How to cause a process started in .xsessionrc to terminate with x-session termination?
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.
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.
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 (tertiary-something?)
because it only applies to DM sessions, not startx.
Reply to: