Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #242225 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-17 22:40 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-17 23:10 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Brian <ad44@cityscape.co.uk> - 2021-11-18 00:50 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-18 14:10 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? songbird <songbird@anthive.com> - 2021-11-18 14:10 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-18 21:40 +0100
      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-18 21:50 +0100
        Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Jonathan Dowland <jon+debian-user@dow.land> - 2021-11-18 22:30 +0100
          Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-18 23:00 +0100
            Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-18 23:10 +0100
        Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Brian <ad44@cityscape.co.uk> - 2021-11-19 19:40 +0100
          Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-20 21:50 +0100
            Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-20 22:20 +0100
              Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-21 19:20 +0100
                Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-21 20:20 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-21 20:50 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-22 06:50 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 13:40 +0100
                      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-22 21:50 +0100
              Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Musbur <musbur@posteo.org> - 2021-11-22 16:30 +0100
                Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 17:00 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 17:50 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Jonathan Dowland <jon+debian-user@dow.land> - 2021-11-23 13:10 +0100
                      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-23 14:00 +0100
                        Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-23 16:30 +0100
                          Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-10 14:40 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-10 15:10 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-22 21:50 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 22:20 +0100
                      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-23 16:30 +0100
      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Jonathan Dowland <jon+debian-user@dow.land> - 2021-11-18 22:30 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Mark Neyhart <Mark.Neyhart@akleg.gov> - 2021-11-18 22:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#242329

On Mon, Nov 22, 2021 at 03:25:02PM +0000, 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.)

[toc] | [prev] | [next] | [standalone]

#242330

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 <https://wiki.archlinux.org/title/systemd/User> 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          PID    PPID  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          PID    PPID  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.

[toc] | [prev] | [next] | [standalone]

#242337

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
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#242338

On Tue, Nov 23, 2021 at 12:05:37PM +0000, 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.

[toc] | [prev] | [next] | [standalone]

#242343

On Tue 23 Nov 2021 at 07:51:32 (-0500), Greg Wooledge wrote:
> On Tue, Nov 23, 2021 at 12:05:37PM +0000, 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.

[toc] | [prev] | [next] | [standalone]

#242906

[Multipart message — attachments visible in raw view] — view raw

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 +0000, 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

[toc] | [prev] | [next] | [standalone]

#242908

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#242332

On Mon 22 Nov 2021 at 10:58:28 (-0500), Greg Wooledge wrote:
> On Mon, Nov 22, 2021 at 03:25:02PM +0000, 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.

[toc] | [prev] | [next] | [standalone]

#242334

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.

[toc] | [prev] | [next] | [standalone]

#242344

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.

[toc] | [prev] | [next] | [standalone]

#242241

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
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#242239

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web