Re: How to cause a process started in .xsessionrc to terminate with x-session termination?
On Sun 21 Nov 2021 at 14:16:26 (-0500), Greg Wooledge wrote:
> On Sun, Nov 21, 2021 at 07:18:23PM +0100, Arkadiusz Dabrowski wrote:
> > Have you considered using my suggestion? Put these two lines in .xsession:
> > >
> > > . /etc/X11/Xsession
> > > pkill unison
> > >
> > > Keep your .xsessionrc which starts the unison program. (Or you could
> > > move it here, later, but for now I'm simply trying to do the bare
> > > minimum needed to achieve a working setup.)
> > >
> > > That is even worse. I see that ~/.xsession is invoked from
> > etc/X11/Xsession (indirectly by calling
> > /etc/X11/Xsession.d/50x11-common_determine-startup)
> > and after .xsessionrc (called prior from
> > /etc/X11/Xsession.d/40x11-common_xsessionrc) so I ended-up with hundreds of
> > unison instances instead of new X session.
> >
> > But it is not so bad: I learned about X11 starting process so will be able
> > to analyze it and invent something. So thanks a lot :)
>
> Damn. I was hoping I could come up with a nice, simple way for a novice
> user to introduce a .xsession file and reap the benefits thereof, without
> having to undergo all of the complexity of writing a full-blown .xsession
> file.
Perhaps it's expected that a novice would run the GUI version of
unison, when all this would be unnecessary. (CLIs being the exception
rather than the rule.)
> Apparently this is not possible. Debian does not provide a single entry
> point which a .xsession file can call upon to do all of the things that
> the default system session does when .xsession is absent. That logic is
> buried inside one of the dotted-in files (not scripts) in
> /etc/X11/Xsession.d/.
Not very deeply, AFAICT. /etc/X11/Xsession.d/50x11-common_determine-startup
will set STARTUP to .[xX]session if either exists, but otherwise run
one of x-session-manager, x-window-manager and x-terminal-emulator, in
that order. If you've installed a DE, I'm guessing that it sets up
x-session-manager. I have fvwm installed, so my x-window-manager has
been set up, and likewise, xterm has set x-terminal-emulator to lxterm.
So a copy/paste/tweak of
if [ -x /usr/bin/x-session-manager ]; then
x-session-manager
elif [ -x /usr/bin/x-window-manager ]; then
x-window-manager
elif [ -x /usr/bin/x-terminal-emulator ]; then
x-terminal-emulator
fi
should get you there (or just pick the one you want).
> So, if you want to be able to kill a process while logging out of
> your X session, apparently you need to create a whole .xsession file.
> Congratulations: you're graduating out of novice mode whether you like
> it or not.
>
> The first thing you'll have to do is figure out how to actually start
> your MATE session. There'll be some magic starting point that you can
> call. I have no idea what it is. Debian is probably just using a
> symlink from /usr/bin/x-session-manager or something, so if you can't
> find it on Google or from your own knowledge of MATE, maybe you could
> start with that.
Seems logical.
> Since you want the process-killing to be done after you terminate your
> interactive session, you need to *not* use "exec" when you execute the
> MATE session. That way, the shell will still be there to carry on with
> the commands after MATE, one of which will kill the unison process.
>
> In the interests of simplicity, I'd also advise getting rid of the
> .xsessionrc file. You might as well put everything in one file, instead
> of two files. It'll be a lot easier to track things down in the future
> when you need to make a change, if they're all in one file.
>
> Putting the unison invocation and the unison kill both in the same file
> also means you can kill it *properly*, by keeping its PID, instead of
> using pkill.
>
> So then, it would look something like this:
>
> your unison thing &
> unisonPID=$!
> other things you want to run
> magic MATE start command
> kill "$unisonPID"
I expect that DEs have DontZap set, so that they get a chance to clean
up after themselves. (That's just a guess. I have no idea how X
servers, DEs and DMs interact with each other.)
I think that my expectation in my earlier post might have been
unrealistic. If you don't map any sort of window, then I'm not sure
that falling out of .xsession would kill a background job. And
zapping the X server likely wouldn't get to the kill command above.
So it would seem common sense to use the GUI that unison provides,
even if the window was minimised or iconified (whatever is possible
while the program is still left running).
> Expect to need to tweak it a few times. And good luck.
Cheers,
David.
Reply to: