[Solved] so what is run-user-1000 ??

[graemev2]

I ask because using systemd-analyse plot shows:

Code: Select all

run-user-1000.mount

Seems to take a very long while. Boot is not excessively long but I ask because the user with UID=1000 is called "owner"
and I ONLY use that user at install time. I've never AFAIK logged on as that user.

Is there something special about this user?

BTW. I think the reason my boot is as slow as it it (OKish) is because I have 2 Ethernet ports , both defined in /etc/network/interfaces ... but only one has a cable plugged in (most of the time).

[CwF]

It is likely you!

That is the time the system setup mounts some tmpfs for the user.

Check id

Code: Select all

~$  id
uid=1001(user) gid=1001(user) groups=1001(user), n(group),etc

[graemev2]

No, not me (as I said in the question it was only used to install the system)

Code: Select all

graeme@real:~$ id
uid=1501(graeme) gid=100(everyone) groups=100(everyone),7(lp),20(dialout),24(cdrom),27(sudo),46(plugdev),1100(users),1101(family)

[CwF]

No idea. User 1501 eh?

Ask your computer

Code: Select all

$ id 1000

[graemev2]

As I said at the start; uid 1000 is a user called "owner" ... who I used to install systems and then never use again.

(Mainly because I need to control my uid/gid quite carefully for NFSv3.

My question was and still is :

What on earth is is this systemd service (and why is it using so much resource)

run-user-1000.mount

To avoid a repeat of the previous responses ... the USER 1000 (owner) is NOT logged on has never logged on.

[None1975]

Usually, the user id for users created on Linux systems now starts from 1000. On Fedora/CentOS systems it used to be from 500. It is specified in /etc/login.defs file. So, a user with uid 1000 is the first normal user (non-root user) created on the system. Or if your system starts giving uid from 500, then another non-root (non administrator) user with uid 1000.

[Aki]

Hello,

I ask because using systemd-analyse plot shows:

Code: Select all

run-user-1000.mount

[..] I need to control my uid/gid quite carefully for NFSv3.
My question was and still is :
What on earth is is this systemd service (and why is it using so much resource) run-user-1000.mount ?
To avoid a repeat of the previous responses ... the USER 1000 (owner) is NOT logged on has never logged on.

I suspect that part of the answer is in this quote from your previous message:

[..] I need to control my uid/gid quite carefully for NFSv3.

It could be useful to take a look at full output of systemd-analyze command.

Just as a guess, the "run-user-1000.mount" unit might be generated by the "systemd-fstab-generator" service during boot when systemd tried to mount a (remote ?) file system with privileges of user with uid=1000.

It could be useful to collect some information with the following commands (root password is required):

Code: Select all

script log.txt
su -l
systemd-analyze critical-chain
loginctl -a
systemd-cgls -a
journalctl -b -g 1000
cat /etc/fstab
exit
exit

The file "log.txt" will contains the output of previous messages. You can report it in one the following ways:

• paste them into the Debian Pastezone service (https://paste.debian.net) and report the URL/link of the paste in a follow-up message

• attaching the logs to a follow-up forum message as a compressed zip or gz file

• paste logs into the body of a follow-up message between code tags (if they fit the size of a forum message)

[graemev2]

OK, I'll attach as a gzip here (smaller)

Not sure how this relates to my question? I can see from many posts that most (all?) people see run-user-1000 ... I'm only asking "what is it"?

[Aki]

Hello,

I can see from many posts that most (all?) people see run-user-1000 ... I'm only asking "what is it"?

From your logs it seems that a user manager istance for user uid=1000 is created:

Code: Select all

│ └─user-1000.slice (#4294968789)
│   → user.invocation_id: ae50f32cd8d34a048e0cd2167892e041
│   → trusted.invocation_id: ae50f32cd8d34a048e0cd2167892e041
│   └─user@1000.service … (#4294969194)
│     → user.delegate: 1
│     → trusted.delegate: 1
│     → user.invocation_id: 32dcd24e6ecf44748c3042b2d9e54bf8
│     → trusted.invocation_id: 32dcd24e6ecf44748c3042b2d9e54bf8
│     ├─init.scope (#4294969239)
│     │ ├─1488 /lib/systemd/systemd --user
│     │ └─1492 (sd-pam)
│     └─app.slice (#4294969284)
│       └─dbus.socket (#4294969308)
[..]

and:

Code: Select all

Dec 15 11:30:00 ts412 systemd[1]: Created slice user-1000.slice - User Slice of UID 1000.
Dec 15 11:30:02 ts412 systemd[1]: Starting user-runtime-dir@1000.service - User Runtime Directory /run/user/1000...
Dec 15 11:30:03 ts412 systemd[1]: Finished user-runtime-dir@1000.service - User Runtime Directory /run/user/1000.
Dec 15 11:30:14 ts412 systemd-journald[226]: Failed to read journal file /var/log/journal/b0c93537f14b45a4b019dc8f7210c41c/user-10>
Dec 15 11:31:35 ts412 systemd[1]: Starting user@1000.service - User Manager for UID 1000...
Dec 15 11:31:35 ts412 (systemd)[1488]: pam_unix(systemd-user:session): session opened for user owner(uid=1000) by (uid=0)
Dec 15 11:31:52 ts412 systemd[1]: Started user@1000.service - User Manager for UID 1000.

When the user-slice for user uid=1000 starts, the "run-user-1000.mount" service mounts the temporary directory for it; for example, in my Debian Bookworm:

Code: Select all

$ systemctl show run-user-1000.mount | head -n 2
Where=/run/user/1000
What=tmpfs

You can inspect in your computer the run-user-1000.mount with the command:

Code: Select all

$ systemctl show run-user-1000.mount

Your computer mounts a network (NFS ?) share from your QNAP nas:

Code: Select all

$ systemd-analyze critical-chain
graphical.target @3min 13.605s
└─multi-user.target @3min 13.598s
  └─smbd.service @3min 3.859s +7.586s
    └─nmbd.service @2min 42.015s +21.815s
      └─network-online.target @2min 41.846s
        └─network.target @2min 41.838s
          └─networking.service @55.235s +1min 46.593s
            └─apparmor.service @45.625s +6.045s
              └─local-fs.target @45.522s
 ===>>          └─QNAP-mounts-md0.mount @3min 11.258s
                  └─dev-md0.device @19.426s

I guess that the user uid=1000 is used to mount the QNAP network share, therefore a systemd slice is created for such a mount operation and the temporary directory for user uid=1000 is created.

[graemev2]

Nope, no NFS mounts. This "bookworm" is running on the QNAP (ts412 is a QNAP model).
The QNAP-mounts-md0.mount is most likely a RAID array (/dev/md0) created with mdadm(8) .


Now I spent quite a while trying to delay the creation of md0 ...so I'm all too aware that it gets created on initrd (So slowing boot for no good reason ...I never want to mount it as say /root , it's only even needed much later ...maybe days later)

Code: Select all

root@ts412:~# systemctl show QNAP-mounts-md0.mount | head -2
Where=/QNAP/mounts/md0
What=/dev/md0

FYI /QNAP/mounts/md0 is a mount point for /dev/md0 ...there will be NFSv3 & SAMBA exports from subdirectories of here.

Code: Select all

root@ts412:~# ps -fuowner
UID        PID  PPID  C STIME TTY          TIME CMD
owner     1488     1  0 Dec15 ?        00:00:08 /lib/systemd/systemd --user
owner     1492  1488  0 Dec15 ?        00:00:00 (sd-pam)
root@ts412:~# pstree 1488
systemd───(sd-pam)

I don't feel I've got much closer to what run-user-1000 "is" .

1: Something to do with UID=1000 AKA "owner"
2: something to do with systemd

But to repeat myself again "the user owner(uid=1000) has NEVER logged on and used this machine" ... I've considered deleting the user as possible security hole ... an account no longer used, common hacking route.

Now there are processes owned by me (uid=1501) and processes owned by root , and some special cases like processes owned by "lp" or "mail" , all are reasonable . But the user "owner(uid=1000)" is not a special "nologin" , it's a regular user who has never logged in.

Why does he have any processes at running? ...my guess being because of "run-user-1000" ...but that's my starting point , what is it , why is uid=1000 special?

[CwF]

why is uid=1000 special?

It's not, and your install is not default, it is user/foreign package modified.
I ask earlier for output from 'id 1000'. This would show if the user has standard user groups from the original install. Also, does ~/owner exist, does it contain a default skel, or maybe a creation date. It is not normal to have a system controlled uid of 1000, it is not normal to have a first user uid of 1501.

Code: Select all

$  journalctl -b0 -g 1000

...and maybe some history,

Code: Select all

$ cat /var/log/installer/lsb-release

[graemev2]

Code: Select all

root@ts412:~# id 1000
uid=1000(owner) gid=1000(owner) groups=1000(owner),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(lpadmin),117(scanner)
root@ts412:~#  journalctl -b0 -g 1000
Dec 15 11:29:04 ts412 kernel: clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
Dec 15 11:29:04 ts412 kernel: kirkwood-pinctrl f1010000.pin-controller: registered pinctrl driver
Dec 15 11:29:04 ts412 kernel: mvebu-pcie mbus@f1000000:pcie@82000000: host bridge /mbus@f1000000/pcie@82000000 ranges:
Dec 15 11:29:04 ts412 kernel: mvebu-pcie mbus@f1000000:pcie@82000000:      MEM 0x00f1040000..0x00f1041fff -> 0x0000040000
Dec 15 11:29:04 ts412 kernel: mvebu-pcie mbus@f1000000:pcie@82000000:      MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000
Dec 15 11:29:04 ts412 kernel: mvebu-pcie mbus@f1000000:pcie@82000000:       IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000
Dec 15 11:29:04 ts412 kernel: mvebu-pcie mbus@f1000000:pcie@82000000: PCI host bridge to bus 0000:00
Dec 15 11:29:04 ts412 kernel: pci_bus 0000:00: root bus resource [io  0x1000-0xeffff]
Dec 15 11:29:04 ts412 kernel: pci 0000:01:00.0: [11ab:7042] type 00 class 0x010000
Dec 15 11:29:04 ts412 kernel: pci 0000:00:01.0: BAR 7: assigned [io  0x10000-0x10fff]
Dec 15 11:29:04 ts412 kernel: pci 0000:01:00.0: BAR 2: assigned [io  0x10000-0x100ff]
Dec 15 11:29:04 ts412 kernel: pci 0000:00:01.0:   bridge window [io  0x10000-0x10fff]
Dec 15 11:29:13 ts412 kernel: mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
Dec 15 11:29:27 ts412 kernel: 0x000000500000-0x000001000000 : "RootFS1"
Dec 15 11:29:27 ts412 kernel: 0x000000000000-0x000001000000 : "all"
Dec 15 11:29:48 ts412 qcontrol[1246]: sender mapped address: 0xb6f71000
Dec 15 11:29:59 ts412 kernel: mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Dec 15 11:30:00 ts412 systemd[1]: Created slice user-1000.slice - User Slice of UID 1000.
Dec 15 11:30:02 ts412 systemd[1]: Starting user-runtime-dir@1000.service - User Runtime Directory /run/user/1000...
Dec 15 11:30:03 ts412 systemd[1]: Finished user-runtime-dir@1000.service - User Runtime Directory /run/user/1000.
Dec 15 11:30:14 ts412 systemd-journald[226]: Failed to read journal file /var/log/journal/b0c93537f14b45a4b019dc8f7210c41c/user-1000.journal for rotation, trying to move it out of the way: Device or resource busy
Dec 15 11:31:35 ts412 systemd[1]: Starting user@1000.service - User Manager for UID 1000...
Dec 15 11:31:35 ts412 (systemd)[1488]: pam_unix(systemd-user:session): session opened for user owner(uid=1000) by (uid=0)
Dec 15 11:31:52 ts412 systemd[1]: Started user@1000.service - User Manager for UID 1000.
root@ts412:~# 

It is not normal to have a first user uid of 1501.

Its not particularly the "first user" it's just "a user" it happens to be my user. It's 1501 because I want a common uid between many different machines ... if I can put the effort in it would be defined in NIS (YP) and so all machines would simply use it.

Code: Select all

root@ts412:~# tail -25 /etc/passwd
rtkit:x:111:113:RealtimeKit,,,:/proc:/bin/false
pulse:x:113:115:PulseAudio daemon,,,:/var/run/pulse:/bin/false
avahi:x:114:118:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
saned:x:115:119::/var/lib/saned:/bin/false
owner:x:1000:1000:owner,,,:/home/owner:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
x2gouser:x:103:105::/var/lib/x2go:/bin/false
x2goprint:x:116:122::/var/spool/x2goprint:/bin/sh
colord:x:117:124:colord colour management daemon,,,:/var/lib/colord:/usr/sbin/nologin
....elided...
oldgraeme:x:501:100:Retired user, in case old files turn up:/home/oldgraeme:/bin/bash
graeme:x:1501:100:New Graeme Vetterlein:/home/graeme:/bin/bash
sebastian:x:1500:500:New Sebastian Vetterlein:/home/sebastian:/bin/bash
sabine:x:1502:502:New Sabine Vetterlein:/home/sabine:/bin/bash
olivia:x:1505:505:New Olivia Vetterlein:/home/olivia:/bin/bash
git:x:200:200:Owns GIT Repos:/home/git:/bin/bash
mailtest:x:1007:8:Just a dummy user to receive localhost mailtests:/home/mailtest:/bin/bash
sonos:x:504:1102:User of SONOS music box:/home/sonos:/bin/bash
....elided.

...

Code: Select all

root@ts412:~# cat /var/log/installer/lsb-release
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u9"
X_INSTALLATION_MEDIUM=network-console
root@ts412:~# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Code: Select all

root@ts412:~# grep owner /etc/passwd
owner:x:1000:1000:owner,,,:/home/owner:/bin/bash
root@ts412:~# ls -ld /home/owner/
drwxr-xr-x 20 owner owner 4096 Dec 14 17:27 /home/owner/
root@ts412:~# stat /home/owner/
  File: /home/owner/
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 8,72	Inode: 9961473     Links: 20
Access: (0755/drwxr-xr-x)  Uid: ( 1000/   owner)   Gid: ( 1000/   owner)
Access: 2023-12-17 16:03:13.432011839 +0000
Modify: 2023-12-14 17:27:36.289330600 +0000
Change: 2023-12-14 17:27:36.289330600 +0000
 Birth: 2023-06-16 22:30:49.643256873 +0100

I admit to being somewhat perplexed by the creation date of /home/owner , esp. as directories within it are all 16/17 Mar 2023.

[CwF]

Dec 15 11:31:35 ts412 systemd[1]: Starting user@1000.service - User Manager for UID 1000...

check for odd extras (gpg-agent.service?);

Code: Select all

$ ls ~/.config/systemd/user

Code: Select all

$ ls /home/owner/.config/systemd/user

Code: Select all

$ ls /etc/systemd/user

So at least we know for sure 'owner' is a normal user, created upon installation like you said. Grep around for the service request for user 1000, created at some time by user 1000, or by a package installed by user 1000.

[graemev2]

Code: Select all

root@ts412:~# ls ~/.config/systemd/user
ls: cannot access '/root/.config/systemd/user': No such file or directory

root@ts412:~# ls ~graeme/.config/systemd/user
ls: cannot access '/home/graeme/.config/systemd/user': No such file or directory

root@ts412:~# ls /home/owner/.config/systemd/user
ls: cannot access '/home/owner/.config/systemd/user': No such file or directory

root@ts412:~# ls /etc/systemd/user
default.target.wants  graphical-session-pre.target.wants  pipewire.service.wants  pk-debconf-helper.socket  pulseaudio.service	pulseaudio.socket  sockets.target.wants

root@ts412:~# ls -l /etc/systemd/user
total 16
drwxr-xr-x 2 root root 4096 Oct 14 21:02 default.target.wants
drwxr-xr-x 2 root root 4096 Oct 14 18:06 graphical-session-pre.target.wants
drwxr-xr-x 2 root root 4096 Oct 14 21:02 pipewire.service.wants
lrwxrwxrwx 1 root root    9 Oct 14 19:01 pk-debconf-helper.socket -> /dev/null
lrwxrwxrwx 1 root root    9 Oct 14 19:01 pulseaudio.service -> /dev/null
lrwxrwxrwx 1 root root    9 Oct 14 19:01 pulseaudio.socket -> /dev/null
drwxr-xr-x 2 root root 4096 Oct 14 21:02 sockets.target.wants

Recursively goes down quite a long way, many (all?) appear as broken links (red in emacs)

Grepping /etc

# find /etc -type f -exec grep --color=auto -nH --null -e owner \{\} + > /tmp/matches

... and discarding "junk" like "ownership" and "the owner" and all
apparmor matches, leaves just these files:

Code: Select all

/etc/aliases
/etc/group
/etc/group-
/etc/group.org
/etc/gshadow
/etc/gshadow-
/etc/lynx/lynx.cfg
/etc/passwd
/etc/passwd-
/etc/passwd.org
/etc/passwd~
/etc/shadow
/etc/shadow-
/etc/shadow.org
/etc/subgid
/etc/subgid-
/etc/subuid
/etc/subuid-

Running grep on an unpacked initrd didn't show anything of interest either.

Code: Select all

# df -h
Filesystem                Size  Used Avail Use% Mounted on
udev                      118M     0  118M   0% /dev
tmpfs                      25M  1.6M   24M   7% /run
/dev/disk/by-label/root5   23G  2.7G   19G  13% /
tmpfs                     124M  4.0K  124M   1% /dev/shm
tmpfs                     5.0M     0  5.0M   0% /run/lock
/dev/sde1                 1.1G   16M  1.0G   2% /boot
/dev/sde7                 1.8G   68K  1.7G   1% /tmp
/dev/sde5                 9.1G  2.0G  6.6G  24% /var
/dev/sde8                 404G  586M  383G   1% /home
tmpfs                      25M  4.0K   25M   1% /run/user/1000
/dev/sda10                373G   28K  354G   1% /QNAP/mounts/rest1
/dev/sdb10                831G   40K  789G   1% /QNAP/mounts/rest2
/dev/sdc10                3.1T   32K  2.9T   1% /QNAP/mounts/rest3
/dev/sdd10                831G   56K  789G   1% /QNAP/mounts/rest4
/dev/md0                  1.5T   40K  1.5T   1% /QNAP/mounts/md0
tmpfs                      25M  8.0K   25M   1% /run/user/0

root@ts412:/etc/systemd# find /boot /var /tmp / -xdev  -uid 1000
/var/mail/owner
root@ts412:/etc/systemd# 

So owner appears to own little outside of his home.

[CwF]

It seems some mod I don't know about was used to create a sub user 1501. User 1000 is running on behalf of 1501. I propose this based on the fact "/run/user/1501" does not exit in your df -h response. 1000 does, and also oddly so does 0.

0 has a session going on somewhere for some unknown reason.
1000 is the active user
1501 is not a normal user, voodoo unknown.

that's all I got.

Oh, curious

Code: Select all

$  apt policy systemd-homed

[graemev2]

You seem to get very focused on uid=1501 being some kind of magic. It's just a normal user created via the usual commands. I run it as a script on all new machines.

Code: Select all

groupmod -g 1100  users

groupadd -g 100   everyone
groupadd -g 1000  owner
groupadd -g 501   graeme
groupadd -g 500   sebastian
groupadd -g 502   sabine
groupadd -g 505   olivia


groupadd -g 200   git
groupadd -g 1101  family
groupadd -g 1100  users




useradd -c "Nominal System Owner (like root)"         -s /bin/bash -m -u 1000 -g 1000 -G 1000 owner

useradd -c "Retired user, in case old files turn up" -s /bin/bash -m -u 501  -g 100    oldgraeme
useradd -c "New Graeme Vetterlein"                   -s /bin/bash -m -u 1501 -g 100  -G family,users,everyone  graeme
useradd -c "New Sebastian Vetterlein"                -s /bin/bash -m -u 1500 -g 500  -G family,users,everyone  sebastian
useradd -c "New Sabine Vetterlein"                   -s /bin/bash -m -u 1502 -g 502  -G family,users,everyone  sabine
useradd -c "New Olivia Vetterlein"                   -s /bin/bash -m -u 1505 -g 505  -G family,users,everyone  olivia

useradd -c "Owns GIT Repos"                          -s /bin/bash -m -u 200  -g 200  git
useradd -c "GLI Geust user"                          -s /bin/bash -m -u 1001 -g 1001 guest
useradd -c "CLI Guest user"                          -s /bin/bash -m -u 601  -g 1002 guestCLI

useradd -c "Just a dummy user to receive localhost mailtests" -s /bin/bash -m -u 1007  -g mail mailtest

useradd -c "User of SONOS music box" -s /bin/bash -m -u 504  sonos



usermod -a -G owner,adm,cdrom,sudo,dip,plugdev,lpadmin,lxd,sambashare  graeme



cp  ./faces/246/png/Graeme-246.png     /home/graeme/.face     && chown graeme: /home/graeme/.face 
cp  ./faces/246/png/Olivia-246.png     /home/olivia/.face     && chown olivia: /home/olivia/.face 
cp  ./faces/246/png/Sabine-246.png     /home/sabine/.face     && chown sabine: /home/sabine/.face 
cp  ./faces/246/png/Sebastian-246.png  /home/sebastian/.face  && chown sebastian: /home/sebastian/.face 

rm /home/graeme/.face.icon    && ln /home/graeme/.face  /home/graeme/.face.icon
rm /home/olivia/.face.icon    && ln /home/olivia/.face  /home/olivia/.face.icon
rm /home/sabine/.face.icon    && ln /home/sabine/.face  /home/sabine/.face.icon
rm /home/sebastian/.face.icon && ln /home/sebastian/.face  /home/sebastian/.face.icon

I don't understand the comment " create a sub user 1501" what is a "sub user"?

Anyhow, I'm no nearer understanding what run-user-1000 is? What is its purpose ? As I said earlier it seems to appear in many people traces (google "run-user-1000.mount" for many hits) ABTW, since it crops up in the many other posts:

Code: Select all

# ls /run/user
0  1000

I'm beginning to suspect it's some "assumption about a GUI" ... something happening to support GUI logins ... on the mistaken assumption that users login via a GUI?

[CwF]

Looks to me like everyone is group 1000
Looks to me like it's an arrangement I'm not familiar with, but is used in a similar way to 'wheel', 'staff', or 'users' methods for common access.

So maybe no mystery after all.

[pbear]

Taking your suggestion, I did an internet search (linux run user 1000). Lots of explanations (example), surely you're read some of them. Bottom line, it's normal.

[graemev2]

Taking your suggestion, I did an internet search (linux run user 1000). Lots of explanations (example), surely you're read some of them. Bottom line, it's normal.

• "Normal" is not a good explanation of what it is
• The link you provide is about .... /run/user/$uid (which indeed I suspect is related, but it's run-user-1000 that I'm focusing on)
• If you read the above posts you'll see a major reason it's of interest is because I don't use uid=1000

[graemev2]

Well that was a voyage of discovery ...

TL;DR look at:

Code: Select all

ls /var/lib/systemd/linger

Then (if you don't want it)

Code: Select all

loginctl disable-linger username

step 1 on the voyage:

Code: Select all

man 5 systemd-system.conf
then
man 1 systemd

Which says:

The user
manager instances are started automatically through the
user@.service(5) service.

Step 2: Which lead me to: https://wiki.archlinux.org/title/systemd/User

Which contains the following:

As per default configuration in /etc/pam.d/system-login, the pam_systemd module automatically launches a systemd --user instance when the user logs in for the first time. This process will survive as long as there is some session for that user, and will be killed as soon as the last session for the user is closed. When #Automatic start-up of systemd user instances is enabled, the instance is started on boot and will not be killed.

So started on boot and will not be killed. sounds about right

Later on is the article:

Automatic start-up of systemd user instances

The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for your own user:

$ loginctl enable-linger

Step3: ...and a bit of digging yields:

https://serverfault.com/questions/84644 ... ger-status

AHH!

And so , on the various systems I have:

Code: Select all

graeme@NUC:/$ ls /var/lib/systemd/linger
graeme

graeme@box1:/$ ls /var/lib/systemd/linger
graeme  owner  x2gotest

graeme@ts412:~$ ls /var/lib/systemd/linger
owner

This is a fairly "tight" machine and holding resource for a user who will NEVER login is an issue:

graeme@ts412:~$ free -h
total used free shared buff/cache available
Mem: 246Mi 68Mi 8.1Mi 336Ki 177Mi 177Mi
Swap: 725Mi 42Mi 683Mi

So my guess is that somewhere during (one of the many) install/upgrades on this
machine somebody decided that uid=1000 was a significant user and warranted
being allocated resource at boot time (maybe to speed up login?) the main goal
of this seems to be control groups and I guess the control/limit of resources.

FYI:

Code: Select all

graeme@ts412:~$ loginctl show-user 1000
UID=1000
GID=1000
Name=owner
Timestamp=Fri 2023-12-15 11:30:00 GMT
TimestampMonotonic=115727934
RuntimePath=/run/user/1000
Service=user@1000.service
Slice=user-1000.slice
State=lingering
Sessions=
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=yes