Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Andrei POPESCU]

On Lu, 22 nov 21, 11:39:46, Greg Wooledge wrote:
> 
> That's as far as I got.  If the OP wants to try writing a systemd --user
> unit file for their unison thingy, and see if that starts and stops in
> a way that they find acceptable, that would be a cool experiment.
 
It's a good way to run background user services.

One less obvious pitfall is that user services/targets/etc. can't 
reference system services, so something like


Wants=network-online.target 


will have no effect. I'm using this hack instead:


ExecStartPre=/usr/bin/sh -c 'until systemctl --quiet is-active 
network-online.target ; do sleep 1 ; done'


(a system service pulling network-online.target is also necessary, 
because as per above, the user service can't do that, see 
systemd.special(7) for details)


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Andrei POPESCU]

On Ma, 23 nov 21, 09:28:39, David Wright wrote:
> On Tue 23 Nov 2021 at 07:51:32 (-0500), Greg Wooledge wrote:
> > On Tue, Nov 23, 2021 at 12:05:37PM +, Jonathan Dowland wrote:
> > > On Mon, Nov 22, 2021 at 11:39:46AM -0500, Greg Wooledge wrote:
> > > > I don't know the exact time that I closed the login shell on tty2.  It
> > > > *could* have been at exactly 11:19:00 but that seems like a suspiciously
> > > > round number (and a suspiciously long time after I started the service).
> > > 
> > > You don't, but your system(d) does: the system instance, not the user
> > > instance.
> > > 
> > > From my "journalctl --follow" output, after a "su -" and then
> > > immediately after closing the resulting shell:
> > > 
> > >   Nov 23 12:03:27 coil su[1330250]: pam_unix(su-l:session): session 
> > > closed for user root
> > 
> > Nov 22 11:18:27 unicorn systemd[1604310]: Started Sleep command for testing.
> > Nov 22 11:18:50 unicorn login[1604301]: pam_unix(login:session): session 
> > closed>
> > Nov 22 11:18:50 unicorn systemd[1]: getty@tty2.service: Succeeded.
> > Nov 22 11:18:50 unicorn systemd[1]: session-7634.scope: Succeeded.
> > Nov 22 11:18:50 unicorn systemd[1]: getty@tty2.service: Scheduled restart 
> > job, >
> > Nov 22 11:18:50 unicorn systemd-logind[611]: Session 7634 logged out. 
> > Waiting f>
> > Nov 22 11:18:50 unicorn systemd[1]: Stopped Getty on tty2.
> > Nov 22 11:18:50 unicorn systemd[1]: Started Getty on tty2.
> > Nov 22 11:18:50 unicorn systemd-logind[611]: Removed session 7634.
> > Nov 22 11:18:50 unicorn pulseaudio[1604331]: Error opening PCM device 
> > front:1: >
> > Nov 22 11:18:50 unicorn systemd[1604310]: pulseaudio.service: Succeeded.
> > Nov 22 11:19:00 unicorn systemd[1]: Stopping User Manager for UID 1004...
> > 
> > This basically confirms my guesswork: the "User Manager" isn't stopped
> > immediately when the last login session is closed.  There's some delay.
> > Maybe it's the next time the clock reads *:00 or maybe it's 10 seconds.
> 
> It looks like you can set it here:
> 
> $ grep 1min /etc/systemd/system.conf 
> #DefaultTimerAccuracySec=1min
> $ man systemd-system.conf | grep -A7 DefaultTimerAccuracySec 
>DefaultTimerAccuracySec=
>Sets the default accuracy of timer units. This controls the global 
> default
>for the AccuracySec= setting of timer units, see systemd.timer(5) 
> for
>details.  AccuracySec= set in individual units override the global 
> default
>for the specific unit. Defaults to 1min. Note that the accuracy of 
> timer
>units is also affected by the configured timer slack for PID 1, see
>TimerSlackNSec= above.

By default systemd is using a random time within the specified accuracy 
in order to avoid to many timers running at once.

It's completely unrelated to stopping processes (as far as the 
systemd-as-pid-1 is concerned, the User Manager is just another process 
to be stopped) when the user logs out (the default unless 'linger'ring 
is enabled for the particular user).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[David Wright]

On Tue 23 Nov 2021 at 07:51:32 (-0500), Greg Wooledge wrote:
> On Tue, Nov 23, 2021 at 12:05:37PM +, Jonathan Dowland wrote:
> > On Mon, Nov 22, 2021 at 11:39:46AM -0500, Greg Wooledge wrote:
> > > I don't know the exact time that I closed the login shell on tty2.  It
> > > *could* have been at exactly 11:19:00 but that seems like a suspiciously
> > > round number (and a suspiciously long time after I started the service).
> > 
> > You don't, but your system(d) does: the system instance, not the user
> > instance.
> > 
> > From my "journalctl --follow" output, after a "su -" and then
> > immediately after closing the resulting shell:
> > 
> > Nov 23 12:03:27 coil su[1330250]: pam_unix(su-l:session): session 
> > closed for user root
> 
> Nov 22 11:18:27 unicorn systemd[1604310]: Started Sleep command for testing.
> Nov 22 11:18:50 unicorn login[1604301]: pam_unix(login:session): session 
> closed>
> Nov 22 11:18:50 unicorn systemd[1]: getty@tty2.service: Succeeded.
> Nov 22 11:18:50 unicorn systemd[1]: session-7634.scope: Succeeded.
> Nov 22 11:18:50 unicorn systemd[1]: getty@tty2.service: Scheduled restart 
> job, >
> Nov 22 11:18:50 unicorn systemd-logind[611]: Session 7634 logged out. Waiting 
> f>
> Nov 22 11:18:50 unicorn systemd[1]: Stopped Getty on tty2.
> Nov 22 11:18:50 unicorn systemd[1]: Started Getty on tty2.
> Nov 22 11:18:50 unicorn systemd-logind[611]: Removed session 7634.
> Nov 22 11:18:50 unicorn pulseaudio[1604331]: Error opening PCM device 
> front:1: >
> Nov 22 11:18:50 unicorn systemd[1604310]: pulseaudio.service: Succeeded.
> Nov 22 11:19:00 unicorn systemd[1]: Stopping User Manager for UID 1004...
> 
> This basically confirms my guesswork: the "User Manager" isn't stopped
> immediately when the last login session is closed.  There's some delay.
> Maybe it's the next time the clock reads *:00 or maybe it's 10 seconds.

It looks like you can set it here:

$ grep 1min /etc/systemd/system.conf 
#DefaultTimerAccuracySec=1min
$ man systemd-system.conf | grep -A7 DefaultTimerAccuracySec 
   DefaultTimerAccuracySec=
   Sets the default accuracy of timer units. This controls the global 
default
   for the AccuracySec= setting of timer units, see systemd.timer(5) for
   details.  AccuracySec= set in individual units override the global 
default
   for the specific unit. Defaults to 1min. Note that the accuracy of 
timer
   units is also affected by the configured timer slack for PID 1, see
   TimerSlackNSec= above.

$ 

> Nov 22 11:19:00 unicorn systemd[1]: Stopping User Manager for UID 1004...
> Nov 22 11:19:00 unicorn systemd[1604310]: Stopped target Main User Target.
> Nov 22 11:19:00 unicorn systemd[1604310]: Stopping D-Bus User Message Bus...
> Nov 22 11:19:00 unicorn systemd[1604310]: Stopping Multimedia Service...
> Nov 22 11:19:00 unicorn systemd[1604310]: Stopping Sleep command for 
> testing...
> Nov 22 11:19:00 unicorn systemd[1604310]: dbus.service: Succeeded.
> Nov 22 11:19:00 unicorn systemd[1604310]: Stopped D-Bus User Message Bus.
> Nov 22 11:19:00 unicorn systemd[1604310]: sleeper.service: Succeeded.
> Nov 22 11:19:00 unicorn systemd[1604310]: Stopped Sleep command for testing.
> [...]
> 
> It seems to do what's desired.  That's the important takeaway.

Cheers,
David.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[David Wright]

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.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Tue, Nov 23, 2021 at 12:05:37PM +, Jonathan Dowland wrote:
> On Mon, Nov 22, 2021 at 11:39:46AM -0500, Greg Wooledge wrote:
> > I don't know the exact time that I closed the login shell on tty2.  It
> > *could* have been at exactly 11:19:00 but that seems like a suspiciously
> > round number (and a suspiciously long time after I started the service).
> 
> You don't, but your system(d) does: the system instance, not the user
> instance.
> 
> From my "journalctl --follow" output, after a "su -" and then
> immediately after closing the resulting shell:
> 
>   Nov 23 12:03:27 coil su[1330250]: pam_unix(su-l:session): session 
> closed for user root

Nov 22 11:18:27 unicorn systemd[1604310]: Started Sleep command for testing.
Nov 22 11:18:50 unicorn login[1604301]: pam_unix(login:session): session closed>
Nov 22 11:18:50 unicorn systemd[1]: getty@tty2.service: Succeeded.
Nov 22 11:18:50 unicorn systemd[1]: session-7634.scope: Succeeded.
Nov 22 11:18:50 unicorn systemd[1]: getty@tty2.service: Scheduled restart job, >
Nov 22 11:18:50 unicorn systemd-logind[611]: Session 7634 logged out. Waiting f>
Nov 22 11:18:50 unicorn systemd[1]: Stopped Getty on tty2.
Nov 22 11:18:50 unicorn systemd[1]: Started Getty on tty2.
Nov 22 11:18:50 unicorn systemd-logind[611]: Removed session 7634.
Nov 22 11:18:50 unicorn pulseaudio[1604331]: Error opening PCM device front:1: >
Nov 22 11:18:50 unicorn systemd[1604310]: pulseaudio.service: Succeeded.
Nov 22 11:19:00 unicorn systemd[1]: Stopping User Manager for UID 1004...

This basically confirms my guesswork: the "User Manager" isn't stopped
immediately when the last login session is closed.  There's some delay.
Maybe it's the next time the clock reads *:00 or maybe it's 10 seconds.

Nov 22 11:19:00 unicorn systemd[1]: Stopping User Manager for UID 1004...
Nov 22 11:19:00 unicorn systemd[1604310]: Stopped target Main User Target.
Nov 22 11:19:00 unicorn systemd[1604310]: Stopping D-Bus User Message Bus...
Nov 22 11:19:00 unicorn systemd[1604310]: Stopping Multimedia Service...
Nov 22 11:19:00 unicorn systemd[1604310]: Stopping Sleep command for testing...
Nov 22 11:19:00 unicorn systemd[1604310]: dbus.service: Succeeded.
Nov 22 11:19:00 unicorn systemd[1604310]: Stopped D-Bus User Message Bus.
Nov 22 11:19:00 unicorn systemd[1604310]: sleeper.service: Succeeded.
Nov 22 11:19:00 unicorn systemd[1604310]: Stopped Sleep command for testing.
[...]

It seems to do what's desired.  That's the important takeaway.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Jonathan Dowland]

On Mon, Nov 22, 2021 at 11:39:46AM -0500, Greg Wooledge wrote:

I don't know the exact time that I closed the login shell on tty2.  It
*could* have been at exactly 11:19:00 but that seems like a suspiciously
round number (and a suspiciously long time after I started the service).


You don't, but your system(d) does: the system instance, not the user
instance.

From my "journalctl --follow" output, after a "su -" and then
immediately after closing the resulting shell:

Nov 23 12:03:27 coil su[1330250]: pam_unix(su-l:session): session 
closed for user root


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

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.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[David Wright]

On Mon 22 Nov 2021 at 10:58:28 (-0500), Greg Wooledge wrote:
> On Mon, Nov 22, 2021 at 03:25:02PM +, Musbur wrote:
> > Am 20.11.2021 22:19 schrieb Greg Wooledge:
> > > On Sat, Nov 20, 2021 at 09:46:24PM +0100, Arkadiusz Dabrowski wrote:
> > > > Started with "exec" according to Debian documentation:
> > > > https://wiki.debian.org/Xsession
> > > 
> > > You're cargo-culting stuff with zero understanding.  That's not going
> > > to help.
> > > 
> > > If you don't know how shell scripts work, if you don't know what the
> > > "exec" command does... then this is going to be quite difficult for you.
> > 
> > I know the difference between using exec and not using exec, but I've never
> > understood why Debian explicitly suggests using exec to start the wm in
> > .xsession. Maybe to release resources held by the shell instance?
> 
> Basically, yeah.  There's no reason to keep the shell around waiting
> on the window manager, if the shell isn't going to do anything after
> the WM terminates.  So, for 95% of cases, that's what you want.
> 
> The OP in this thread is an exception.  They want the shell to hang
> around so it can kill a process after the WM terminates.  A .xsession
> file without "exec" on the WM seems to be the most obvious way to do it.
> 
> (Unless someone can figure out how to make systemd do this.)

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 have no idea whether it would benefit to start unison from an
Xsession.d/ file and stop it in Xreset.d/, nor how the two might
communicate information. An Xreset.d/ that's populated with examples
might suggest some ideas. However, I would have thought that the sequence
  start something in Xsession.d/
  run x-session-manager from 99x11-common_start
  stop something in Xreset.d/
was closer to the spirit of Debian's /etc/X11/ than
  start something in .xsession
  run x-session-manager from .xsession
  stop something in .xsession
but maybe I'm wrong. DMs and DEs just aren't my thing.
Anyway, you're less likely to accidentally create a loop. Sorry.

Cheers,
David.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[David Wright]

On Mon 22 Nov 2021 at 07:31:04 (-0500), Greg Wooledge wrote:
> On Sun, Nov 21, 2021 at 11:39:53PM -0600, David Wright wrote:
> > On Sun 21 Nov 2021 at 14:16:26 (-0500), Greg Wooledge wrote:
> > > So then, it would look something like this:
> > > 
> > > your unison thing &
> > > unisonPID=$!
> > > other things you want to run
> > > magic MATE start command
> > > kill "$unisonPID"
> > 

¶A
> > 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.)
> > 

¶B
> > 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.
> 
> I'm not sure what you're saying here.  Are you expecting that the OP is
> going to "zap" the X server (by which I believe you mean pressing
> a magic key combination like Ctrl-Alt-Backspace, with an appropriate
> option set in the xorg.conf file to cause that to terminate the X server)
> rather than exiting from MATE in the normal manner?

When I wrote the post that ¶B refers to, the only evidence that the OP
was using a DE was mention of x-session-manager, which I've never seen
or used. Hence I overlooked it. So that post was written from the
viewpoint of startx, and I'm sure many users of startx terminate their
X server with C-A-B rather that exiting the WM. In my case, it's one
keystroke versus two well-aimed mouse clicks (and the latter assumes
that part of the root window is actually exposed), so you can guess
which way I choose.

> I'm expecting that the OP is exiting/logging out of MATE in whatever
> the normal way is.  Further I'm expecting that this normal logout
> action causes the "magic MATE start command" to terminate, returning
> control to the .xsession script.

As I wrote there, ¶A is a presumption that I have little chance of
confirming myself in the foreseeable future. (If it's untrue, I'd
expect someone would contradict and/or correct it pretty quickly.)

> We're not "falling out of .xsession" either.  It's just a shell script,
> so it works the way any other shell script works.  When the MATE session
> ends, the .xsession shell script moves on to the next command, which
> is kill.

So, back to ¶B; if you're not in the habit of putting exit 0 or return 0
at the end of every script, function, program, etc, that you write,
then most scripts you run can probably terminate by "falling out of
the end". (A counterexample would be FORTRAN X3.9-1966.)

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.

> > 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).
> 
> I know nothing about unison itself.

Nor I, beyond these lines from the Packages file (buster):

  Package: unison
  Description: file-synchronization tool for Unix and Windows

  Package: unison-gtk
  Description: file-synchronization tool for Unix and Windows with GTK+ 
interface
  Tag: admin::backup, admin::file-distribution, implemented-in::ocaml,
   interface::graphical, interface::x11, role::program, scope::utility,
   uitoolkit::gtk, uitoolkit::ncurses, use::synchronizing,
   x11::application

> That might work, but I can't confirm
> or deny it.  In either case, it doesn't appear to be what the OP wants.

No, but I don't let that constrain my thoughts on a topic. IANAI.
(I am not an intern.)

Cheers,
David.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Mon, Nov 22, 2021 at 10:58:28AM -0500, Greg Wooledge wrote:
> (Unless someone can figure out how to make systemd do this.)

Google found  which
is the first time I've ever seen an attempt at an end user's guide
for systemd --user services.

So, I decided to play with this a little bit.

I've got a user account named "tester" which is normally not logged in,
and which had no running processes at the time I began testing.

I used "su - tester" to open a shell as this user.  This did *not* bring
up a systemd --user service manager.  Apparently "su -" does not count
as a login session for that purpose.

Based on the Arch wiki page, I created a .config/systemd/user directory,
and then created this file inside it:


tester@unicorn:~/.config/systemd/user$ cat sleeper.service 
[Unit]
Description=Sleep command for testing

[Service]
ExecStart=/bin/sleep 12345

[Install]
WantedBy=default.target


Of course, I couldn't enable it (at least not via the normal systemctl
route) because there was no --user manager running as "tester" yet.

Next, I pressed Ctrl-Alt-F2 to get to a console terminal, and logged in
as tester.  This brought up the systemd --user manager process.  After
that I was able to enable and start the sleeper.service unit.

I logged out of the tty2 shell, and pressed Ctrl-Alt-F1 to get back to
my X session running as greg.  Then I checked the processes running as
user tester:


unicorn:~$ ps -fu tester
UID  PIDPPID  C STIME TTY  TIME CMD
tester   1604310   1  0 11:18 ?00:00:00 /lib/systemd/systemd --user
tester   1604311 1604310  0 11:18 ?00:00:00 (sd-pam)
tester   1604330 1604310  0 11:18 ?00:00:00 /usr/bin/pipewire
tester   1604335 1604310  0 11:18 ?00:00:00 /usr/bin/dbus-daemon --sessi
tester   1604336 1604330  0 11:18 ?00:00:00 /usr/bin/pipewire-media-sess
tester   1604363 1604310  0 11:18 ?00:00:00 /bin/sleep 12345


I spent a few seconds reading this, and wondering what on earth a "pipewire"
is.  I checked to see if I was running one as "greg":


unicorn:~$ ps -ef | grep pipewire
greg 849 829  0 Oct09 ?00:00:00 /usr/bin/pipewire
greg 861 849  0 Oct09 ?00:00:14 
/usr/bin/pipewire-media-session
greg 1604399   66960  0 11:19 pts/31   00:00:00 grep pipewire


The pipewire running as "tester" was... gone?  I checked again:


unicorn:~$ ps -fu tester
UID  PIDPPID  C STIME TTY  TIME CMD


So, it seems that the sleeper.service which was started under the
management of the systemd --user process *did* get killed.  Not
immediately, but within a minute or so.

I opened another "su - tester" session, and ran this to check for more
details:


tester@unicorn:~/.config/systemd/user$ journalctl --user -u sleeper
-- Journal begins at Mon 2021-11-22 11:18:09 EST, ends at Mon 2021-11-22 11:19:>
Nov 22 11:18:27 unicorn systemd[1604310]: Started Sleep command for testing.
Nov 22 11:19:00 unicorn systemd[1604310]: Stopping Sleep command for testing...
Nov 22 11:19:00 unicorn systemd[1604310]: sleeper.service: Succeeded.
Nov 22 11:19:00 unicorn systemd[1604310]: Stopped Sleep command for testing.


I don't know the exact time that I closed the login shell on tty2.  It
*could* have been at exactly 11:19:00 but that seems like a suspiciously
round number (and a suspiciously long time after I started the service).
Also:


unicorn:~$ last
tester   tty2  Mon Nov 22 11:18 - 11:18  (00:00)
[...]


Maybe there's something that triggers every minute and cleans up
logged-out user units?  I don't know.

That's as far as I got.  If the OP wants to try writing a systemd --user
unit file for their unison thingy, and see if that starts and stops in
a way that they find acceptable, that would be a cool experiment.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Mon, Nov 22, 2021 at 03:25:02PM +, Musbur wrote:
> Am 20.11.2021 22:19 schrieb Greg Wooledge:
> > On Sat, Nov 20, 2021 at 09:46:24PM +0100, Arkadiusz Dabrowski wrote:
> > > Started with "exec" according to Debian documentation:
> > > https://wiki.debian.org/Xsession
> > 
> > You're cargo-culting stuff with zero understanding.  That's not going
> > to help.
> > 
> > If you don't know how shell scripts work, if you don't know what the
> > "exec" command does... then this is going to be quite difficult for you.
> 
> I know the difference between using exec and not using exec, but I've never
> understood why Debian explicitly suggests using exec to start the wm in
> .xsession. Maybe to release resources held by the shell instance?

Basically, yeah.  There's no reason to keep the shell around waiting
on the window manager, if the shell isn't going to do anything after
the WM terminates.  So, for 95% of cases, that's what you want.

The OP in this thread is an exception.  They want the shell to hang
around so it can kill a process after the WM terminates.  A .xsession
file without "exec" on the WM seems to be the most obvious way to do it.

(Unless someone can figure out how to make systemd do this.)

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Musbur]

Am 20.11.2021 22:19 schrieb Greg Wooledge:

On Sat, Nov 20, 2021 at 09:46:24PM +0100, Arkadiusz Dabrowski wrote:

Started with "exec" according to Debian documentation:
https://wiki.debian.org/Xsession


You're cargo-culting stuff with zero understanding.  That's not going
to help.

If you don't know how shell scripts work, if you don't know what the
"exec" command does... then this is going to be quite difficult for 
you.


I know the difference between using exec and not using exec, but I've 
never understood why Debian explicitly suggests using exec to start the 
wm in .xsession. Maybe to release resources held by the shell instance?

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Sun, Nov 21, 2021 at 11:39:53PM -0600, David Wright wrote:
> On Sun 21 Nov 2021 at 14:16:26 (-0500), Greg Wooledge wrote:
> > 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.

I'm not sure what you're saying here.  Are you expecting that the OP is
going to "zap" the X server (by which I believe you mean pressing
a magic key combination like Ctrl-Alt-Backspace, with an appropriate
option set in the xorg.conf file to cause that to terminate the X server)
rather than exiting from MATE in the normal manner?

I'm expecting that the OP is exiting/logging out of MATE in whatever
the normal way is.  Further I'm expecting that this normal logout
action causes the "magic MATE start command" to terminate, returning
control to the .xsession script.

We're not "falling out of .xsession" either.  It's just a shell script,
so it works the way any other shell script works.  When the MATE session
ends, the .xsession shell script moves on to the next command, which
is kill.

> 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).

I know nothing about unison itself.  That might work, but I can't confirm
or deny it.  In either case, it doesn't appear to be what the OP wants.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[David Wright]

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.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Arkadiusz Dabrowski]

niedz., 21 lis 2021 o 20:16 Greg Wooledge  napisał(a):
>
> 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.
>
> 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/.
>
> 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.
>
> 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"
>
> Expect to need to tweak it a few times.  And good luck.

I see, that the real final executor is in the very-last file in the whole
sequence:
/etc/X11/Xsession.d/99x11-common_start:

exec $STARTUP

and STARTUP is set, according to file existence, to one of the
x-session-manager
x-window-manager
x-terminal-emulator
but preferably to: ~/.xsession if it exists

So it seems I need to run one of these three standard executables in my
.xsession and surround it with my process execution and termination by PID.

Thanks again!

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

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.

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/.

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.

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"

Expect to need to tweak it a few times.  And good luck.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Arkadiusz Dabrowski]

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 :)


> > Started with "exec" according to Debian documentation:
> > https://wiki.debian.org/Xsession
>
> You're cargo-culting stuff with zero understanding.  That's not going
> to help.
>
> If you don't know how shell scripts work, if you don't know what the
> "exec" command does... then this is going to be quite difficult for you.
>

Too far-reaching assumption. Only the second part about the "exec" was
right :) Now I know about the exec too.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Sat, Nov 20, 2021 at 09:46:24PM +0100, Arkadiusz Dabrowski wrote:
> Unfortunately, the solution with .xsession file doesn't work.
> I resorted to something very simplistic:
> 
> 
> exec /usr/bin/marco
> 
> 
> Note: I use mate desktop with marco wm.

I doubt very much that this is the correct command for starting MATE.
Unfortunately, I am not a MATE user, so I don't know what the correct
command *is*.  But this doesn't look like it'll be the one.

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.)

> Started with "exec" according to Debian documentation:
> https://wiki.debian.org/Xsession

You're cargo-culting stuff with zero understanding.  That's not going
to help.

If you don't know how shell scripts work, if you don't know what the
"exec" command does... then this is going to be quite difficult for you.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Arkadiusz Dabrowski]

Unfortunately, the solution with .xsession file doesn't work.
I resorted to something very simplistic:


exec /usr/bin/marco


Note: I use mate desktop with marco wm.
Started with "exec" according to Debian documentation:
https://wiki.debian.org/Xsession
They also use some other stuff, I'm not sure if I need any of these lines:

xsetroot -solid grayxmodmap -e "keysym Super_L = Multi_key"xset s off;
xset dpms 0 1800 0exec fvwm


...and my session doesn't start at all - login popup disappears and nothing
else happens on the screen.
I see that marco is started and ssh-agent is the only process under it.
I have no idea why my .xsession file name appears in the command line where
ssh-agent is started but it looks suspicious. Another x-session is started?

root   17474  0.0  0.1 165776  9604 ?Sl   21:23   0:00  \_
lightdm --session-child 12 21
arek   17484  0.0  0.3 274164 27188 ?Ssl  21:23   0:00  \_
/usr/bin/marco
arek   17572  0.0  0.0   5964   468 ?Ss   21:23   0:00
 \_ /usr/bin/ssh-agent env TMPDIR=/tmp/0_arek /usr/bin/im-launch /bin/bash
/home/arek/.xsession


What could happen here?

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Brian]

On Thu 18 Nov 2021 at 15:46:48 -0500, Greg Wooledge wrote:

> On Thu, Nov 18, 2021 at 02:34:52PM -0600, David Wright wrote:
> > On Wed 17 Nov 2021 at 22:39:21 (+0100), Arkadiusz Dabrowski wrote:
> > 
> > > I have a problem with unison sync termination when it is started from
> > > .xsessionrc.
> > > It works flawlessly but when I log out it is orphaned and not terminated.
> > > I start it like this:
> > > nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> > > Once started the parent is x-session-manager and they the same process
> > > group.
> > 
> > I think this is because you're starting it in the wrong file.
> > Everything in .xsessionrc should complete immediately. Use it
> > to set parameters and things like that.
> 
> I think of .xsessionrc a little differently.  It's the "novice mode" file,
> which you can use regardless of which x-session-manager or x-window-manager
> ultimately gets used, and without needing to take control of your whole
> session yourself.
> 
> That makes it great for quickie "I just want to start xclock too" type
> things, where maintaining a whole .xsession file would be overkill.
> 
> In the OP's case, though, they want something that "novice mode" can't
> handle, so there's a decent reason to move to "advanced mode".

An interesting view. I think of ~/.xsession as being the correct,
traditional and well-tested file for a user to customise an X session
begun with startx or xdm. It never fails to work for novice users.

I think of ~/.xsessionrc in terms of the what is in the changelog for
xorg:

  * Add support for $HOME/.xsessionrc. Closes: #411639
This file, if present, will get sourced during the start of your
X session. This allows you to set session-wide environment variables
easily for things like locale information. Patch adapted from one by
Yves-Alexis Perez. Thanks also to Holger Levsen and Osamu Aoki for
advice.

-- 
Brian.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Arkadiusz Dabrowski]

Thank You all guys for help!
If systemd feature is not an option I'll try a .xession solution. Looks
promising.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Thu, Nov 18, 2021 at 09:21:34PM +, Jonathan Dowland wrote:
> On Thu, Nov 18, 2021 at 03:46:48PM -0500, Greg Wooledge wrote:
> > (I still wonder whether systemd offers anything relevant here.  And if
> > not, what the hell *is* the point of systemctl --user?  I've never used
> > it, nor found any reason to use it.  Yet.)
> 
> systemd certainly does offer something here. It's related to what
> processes are considered to belong to a "session", it came in with
> version 230, and there was quite a stink about it from people who
> wanted this not to happen, at the time:
> 
> 
> It seems that the Debian Xsession setup does start a systemd --user
> service. I've never tried to use it for this purpose.

I've seen that bug before.  That's a change which got reverted, or at
least, the default behavior was returned to the previous norm.

Debian's /etc/systemd/logind.conf has

#KillUserProcesses=no

which indicates that the default is for this "kill everything the user
left running" setting to be disabled, as it was before the controversial
change.

I think this is a dead end for this particular question, because it's
an all-or-nothing setting.  Either *all* background processes that the
user creates get nuked when the user logs out, or *none* of them do.  There
doesn't appear to be a way to "mark" particular processes for reaping
while leaving the rest alone.

Maybe some other part of systemd offers more flexibility, but if so, I
don't know what part it would be.  I'm still waiting to see an actual
user-friendly *document* that describes how to use systemd.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Jonathan Dowland]

I'd echo Greg in that the simplest answer might lie with using systemd's
facility for this, but,

On Thu, Nov 18, 2021 at 02:34:52PM -0600, David Wright wrote:

# ~/.xsession contents

…

# now start your clients and programs, all backgrounded with &


^^
This would be the point at which OP would invoke unison,
…


# at the end of the file is one foreground program:

# wait for the window manager in the background to die
wait $Wmpid

# end-of-file


^^
when the WM dies, code here could be used to kill the unison process
(or send it a signal or anything else needed)


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Jonathan Dowland]

On Thu, Nov 18, 2021 at 03:46:48PM -0500, Greg Wooledge wrote:

(I still wonder whether systemd offers anything relevant here.  And if
not, what the hell *is* the point of systemctl --user?  I've never used
it, nor found any reason to use it.  Yet.)


systemd certainly does offer something here. It's related to what
processes are considered to belong to a "session", it came in with
version 230, and there was quite a stink about it from people who
wanted this not to happen, at the time:


It seems that the Debian Xsession setup does start a systemd --user
service. I've never tried to use it for this purpose.


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Mark Neyhart]

On 11/17/21 12:39 PM, Arkadiusz Dabrowski wrote:
> Hi all
> I have a problem with unison sync termination when it is started from
> .xsessionrc.
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> Once started the parent is x-session-manager and they the same process
> group.
> What can I do to terminate the process with x-session?
>


/etc/X11/Xreset.d is a directory which holds scripts to be executed
upon termination of a display manager.  It may work to put a kill
script in there.  The /etc/X11/Xreset.d/README file has more details.
I use it to terminate non-X tasks which are started by my window manager.

Mark

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Thu, Nov 18, 2021 at 02:34:52PM -0600, David Wright wrote:
> On Wed 17 Nov 2021 at 22:39:21 (+0100), Arkadiusz Dabrowski wrote:
> 
> > I have a problem with unison sync termination when it is started from
> > .xsessionrc.
> > It works flawlessly but when I log out it is orphaned and not terminated.
> > I start it like this:
> > nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> > Once started the parent is x-session-manager and they the same process
> > group.
> 
> I think this is because you're starting it in the wrong file.
> Everything in .xsessionrc should complete immediately. Use it
> to set parameters and things like that.

I think of .xsessionrc a little differently.  It's the "novice mode" file,
which you can use regardless of which x-session-manager or x-window-manager
ultimately gets used, and without needing to take control of your whole
session yourself.

That makes it great for quickie "I just want to start xclock too" type
things, where maintaining a whole .xsession file would be overkill.

In the OP's case, though, they want something that "novice mode" can't
handle, so there's a decent reason to move to "advanced mode".

(I still wonder whether systemd offers anything relevant here.  And if
not, what the hell *is* the point of systemctl --user?  I've never used
it, nor found any reason to use it.  Yet.)

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[David Wright]

On Wed 17 Nov 2021 at 22:39:21 (+0100), Arkadiusz Dabrowski wrote:

> I have a problem with unison sync termination when it is started from
> .xsessionrc.
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> Once started the parent is x-session-manager and they the same process
> group.

I think this is because you're starting it in the wrong file.
Everything in .xsessionrc should complete immediately. Use it
to set parameters and things like that.

> What can I do to terminate the process with x-session?

Start all your X clients and programs in .xsession. They should all be
backgrounded with &, as shown in   man xinit. There's an example at
about line 78 (buster version) on that page.

You'll see there that they start the Window Manager last. This has
disadvantages, in that you can't tell programs like xterm where to
map their windows if the WM hasn't yet started. This is solved by
exec'ing the WM early in .xsession, and waiting on its PID at the
end. If and when you close the WM, wait terminates and you fall out
of the end of .xsession, and X terminates.

That way, all these background processes get destroyed, and the same
is true if you are in the habit of using Ctrl-Alt-Backspace to kill
X rather than neatly closing the WM.

Briefly:

# ~/.xsession contents

# very early stuff
# [ … ]

if [ -x /usr/bin/fvwm ]; then
exec /usr/bin/fvwm & Wmpid=$!
else
printf '%s\n' "Error - no window manager found"
fi

# now start your clients and programs, all backgrounded with &
# [ … ]

# at the end of the file is one foreground program:

# wait for the window manager in the background to die
wait $Wmpid

# end-of-file

Cheers,
David.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Wed, Nov 17, 2021 at 08:21:00PM -0500, songbird wrote:
> Arkadiusz Dabrowski wrote:
> ...
> > It works flawlessly but when I log out it is orphaned and not terminated.
> > I start it like this:
> > nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> > Once started the parent is x-session-manager and they the same process
> > group.
> > What can I do to terminate the process with x-session?
> 
>   does it work if you don't put it in the background?

That would prevent the rest of the X session from running, until the
unison process terminates.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[songbird]

Arkadiusz Dabrowski wrote:
...
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> Once started the parent is x-session-manager and they the same process
> group.
> What can I do to terminate the process with x-session?

  does it work if you don't put it in the background?


  songbird

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Brian]

On Wed 17 Nov 2021 at 22:39:21 +0100, Arkadiusz Dabrowski wrote:

> Hi all
> I have a problem with unison sync termination when it is started from
> .xsessionrc.

.xsessionrc is for stting environment variables for an X session. This
your intentio?

-- 
Brian.

Re: How to cause a process started in .xsessionrc to terminate with x-session termination?

[Greg Wooledge]

On Wed, Nov 17, 2021 at 10:39:21PM +0100, Arkadiusz Dabrowski wrote:
> I have a problem with unison sync termination when it is started from
> .xsessionrc.
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &

It sounds like you don't have a .xsession (or .xinitrc) file, and are
simply using the default Debian Xsession.

It also sounds like unison is not an X application.  Usually the programs
that you start from .xsessionrc are X client apps, which will terminate
when the X server goes away at logout.  Since unison is presumably not an
X client app, it survives this.

You could try using an .xsession file.  This gives you more control over
the session.  You could even read the default Debian Xsession from your
.xsession file, to keep things simple.  For example, something like this
may meet your needs (untested):

. /etc/X11/Xsession
pkill unison

It's not the most elegant solution, but you could start with this,
see whether it works at all, and then improve it from here if it does.

There may be other solutions.  For instance, maybe you can find something
in systemd or dbus that starts a managed service as a child of your login
session, and kills it upon logout.  I don't actually know whether systemd
or dbus can do this, but if it can, it might be a better solution.

How to cause a process started in .xsessionrc to terminate with x-session termination?

[Arkadiusz Dabrowski]

Hi all
I have a problem with unison sync termination when it is started from
.xsessionrc.
It works flawlessly but when I log out it is orphaned and not terminated.
I start it like this:
nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
Once started the parent is x-session-manager and they the same process
group.
What can I do to terminate the process with x-session?