Re: How to cause a process started in .xsessionrc to terminate with x-session termination?
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.
Reply to: