On Tue, 2024-01-16 at 08:41 -0500, Greg Wooledge wrote: > On Tue, Jan 16, 2024 at 02:17:05PM +0100, hw wrote: > > On Tue, 2024-01-16 at 08:03 -0500, Greg Wooledge wrote: > > > On Tue, Jan 16, 2024 at 01:43:23PM +0100, hw wrote: > > > > There's only a bunch of links in that directory, apparently all > > > > pointing to files that don't exist. Don't you have that? > > > > > > unicorn:~$ ls -l /run/user/1000/systemd/units > > > total 0 > > > lrwxrwxrwx 1 greg greg 32 Jan 4 10:33 invocation:at-spi-dbus-bus.service > > > -> bfec6466520a4586b8c9205c235ccc92 > > > [...] > > > I guess that's normal, then. It seems they're using the symlink target > > > as the actual *data*, not a link to another file that contains the data. > > > Why? I have no idea. I seem to recall one of the BSDs doing something > > > like this, but I never fully understood the rationale. Something about > > > atomic operations, maybe? > > > > > > > I consider it as alarming rather than normal when I can't access data > > on my own computer. > > You can access it just fine. You just don't *understand* it. (Neither > do I.)
If I could access it, I could display the file. If there is no file, then these directory entries shouldn't exist. > > And I do want to know what this unit file for firefox contains and > > does and how it is being brought about. > > If it's a symlink whose name begins with "invocation:" and whose target > is a 32-hex-digit (128-bit) value, like the one shown above, then > you are seeing everything there is to see. I don't know what the 128-bit > number is used for, but that number *is* the data. Of that, I'm certain. > > I did a bit of Google searching, and I think this is something called > an "InvocationID". > > > > lrwxrwxrwx 1 greg greg 32 Jan 4 10:33 invocation:at-spi-dbus-bus.service > > > -> bfec6466520a4586b8c9205c235ccc92 > > unicorn:~$ systemctl --user show -p InvocationID at-spi-dbus-bus.service > InvocationID=bfec6466520a4586b8c9205c235ccc92 That is not useful: systemctl --user show -p InvocationID at-spi-dbus-bus.service InvocationID=4bd113a0ec4c4f1eab6c51da8a43c1af Invalid unit name "InvocationID=4bd113a0ec4c4f1eab6c51da8a43c1af" escaped as "InvocationID\x3d4bd113a0ec4c4f1eab6c51da8a43c1af" (maybe you should use systemd-escape?). InvocationID=b6e84c2dd18b4d9f84436580113abaca InvocationID= Neither the user, nor root gets anything from this. What is it supposed to show? > <https://sleeplessbeastie.eu/2022/07/01/how-to-display-systemd-journal-for-specific-service-since-it-started/> > describes this as "a unique 128-bit ID identifying each runtime cycle > of the unit". > > There is also a man page systemd-id128(1) ("man systemd-id128") but > it doesn't describe things in a way I can currently understand. It > seems to reference another page sd-id128(3) which I do not have, but > which I can find online at > <https://manpages.debian.org/bookworm/libsystemd-dev/sd-id128.3.en.html> It indicates that these numbers are just UUIDs with the dashes omitted. Apparently they aren't called UUIDs to make things more complicated and/or to hide something. UUIDs are good as unique identifiers and not good for being data themselves. > ... which, OK, that's pretty boring. What I cannot find anywhere is > a basic explanation of *what this ID is used for*. > > Maybe it's just a fancy PID? I dunno, it's all very shrouded in mystery. See, you're starting to understand how this is alarming :) I'll try to find out more but I don't have time for now ...
