[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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.


Reply to: