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

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

How to prevent rtkit from giving firefox higher priority?

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

Contents

  How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-15 19:50 +0100
    Re: How to prevent rtkit from giving firefox higher priority? <tomas@tuxteam.de> - 2024-01-15 20:30 +0100
      Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-15 21:40 +0100
        Re: How to prevent rtkit from giving firefox higher priority? Tom Furie <tom@furie.org.uk> - 2024-01-15 22:10 +0100
          Re: How to prevent rtkit from giving firefox higher priority? Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-16 11:30 +0100
          Re: How to prevent rtkit from giving firefox higher priority? Michel Verdier <mv524@free.fr> - 2024-01-16 13:10 +0100
        Re: How to prevent rtkit from giving firefox higher priority? <tomas@tuxteam.de> - 2024-01-16 07:00 +0100
          Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 11:30 +0100
            Re: How to prevent rtkit from giving firefox higher priority? Greg Wooledge <greg@wooledge.org> - 2024-01-16 13:10 +0100
              Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 13:50 +0100
                Re: How to prevent rtkit from giving firefox higher priority? Greg Wooledge <greg@wooledge.org> - 2024-01-16 14:10 +0100
                  Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 14:20 +0100
                    Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 14:40 +0100
                    Re: How to prevent rtkit from giving firefox higher priority? Greg Wooledge <greg@wooledge.org> - 2024-01-16 14:50 +0100
                      Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-17 11:30 +0100
                        Re: How to prevent rtkit from giving firefox higher priority? Tixy <tixy@yxit.co.uk> - 2024-01-17 13:30 +0100
                          Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-17 14:50 +0100
                            Re: How to prevent rtkit from giving firefox higher priority? <tomas@tuxteam.de> - 2024-01-17 15:20 +0100
                        Re: How to prevent rtkit from giving firefox higher priority? Greg Wooledge <greg@wooledge.org> - 2024-01-17 13:30 +0100
                          Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-17 15:10 +0100
                            Re: How to prevent rtkit from giving firefox higher priority? The Wanderer <wanderer@fastmail.fm> - 2024-01-17 15:20 +0100
                            Re: How to prevent rtkit from giving firefox higher priority? David Wright <deblis@lionunicorn.co.uk> - 2024-01-18 06:10 +0100
    Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-15 21:00 +0100
      Re: How to prevent rtkit from giving firefox higher priority? <tomas@tuxteam.de> - 2024-01-15 21:10 +0100
        Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 10:50 +0100
          Re: How to prevent rtkit from giving firefox higher priority? Arno Lehmann <al@its-lehmann.de> - 2024-01-16 11:30 +0100
            Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 12:00 +0100
              Re: How to prevent rtkit from giving firefox higher priority? Tom Furie <tom@furie.org.uk> - 2024-01-16 12:50 +0100
              Re: How to prevent rtkit from giving firefox higher priority? debian-user@howorth.org.uk - 2024-01-16 13:20 +0100
                Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 14:00 +0100
      Re: How to prevent rtkit from giving firefox higher priority? John Hasler <john@sugarbit.com> - 2024-01-15 22:30 +0100
        Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-16 10:50 +0100
          Re: How to prevent rtkit from giving firefox higher priority? John Hasler <john@sugarbit.com> - 2024-01-16 17:20 +0100
            Re: How to prevent rtkit from giving firefox higher priority? hw <hw@adminart.net> - 2024-01-17 14:20 +0100

Page 1 of 2  [1] 2  Next page →

#265994 — How to prevent rtkit from giving firefox higher priority?

Hi,

I'm seeing in the journal (and in htop) that rtkit-daemon gives (has
given) a ton of firefox processes increased priority.

Of course, having tons of web browser processes running at increased
priority is like one of the last things I would want.

How do I prevent this from happening?


And why is there no control whatsoever about which processes can get
higher priority?  This is not an acceptable way to do such things.

Is there a better way then disabling/removing rtkit-daemon?  And how
could I remove/disable it?

[toc] | [next] | [standalone]

#265997

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

On Mon, Jan 15, 2024 at 07:38:27PM +0100, hw wrote:
> Hi,
> 
> I'm seeing in the journal (and in htop) that rtkit-daemon gives (has
> given) a ton of firefox processes increased priority.
> 
> Of course, having tons of web browser processes running at increased
> priority is like one of the last things I would want.

It's the ad industry. It won't settle for less than real time access
to your eyeballs ;-P

Sarcasm [1] aside, the idea was possibly to enhance your videoconf
experience.

As far as I understand, rtkit gets told by apps over DBus [2]
"hey, I'm important. Gimme some real-time prio".

No idea where its config is, but there is an admin front end
to it called rtkitctl.

That said, it is Poetteringware, so it should come with a decent
man page.

> How do I prevent this from happening?

Tell us when you find out. I always enjoy stories from the deep
end of the pool :-)

> And why is there no control whatsoever about which processes can get
> higher priority?  This is not an acceptable way to do such things.

There should, yes.

> Is there a better way then disabling/removing rtkit-daemon?  And how
> could I remove/disable it?

Which package does it come with?

Cheers

[1] It always feels queasy when sarcasm and reality are so
   close together.

[2] Phew. No DBus around here. Another bullet dodged :-D

-- 
tomás

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

#266006

On Mon, 2024-01-15 at 20:21 +0100, tomas@tuxteam.de wrote:
> On Mon, Jan 15, 2024 at 07:38:27PM +0100, hw wrote:
> > Hi,
> > 
> > I'm seeing in the journal (and in htop) that rtkit-daemon gives (has
> > given) a ton of firefox processes increased priority.
> > 
> > Of course, having tons of web browser processes running at increased
> > priority is like one of the last things I would want.
> 
> It's the ad industry. It won't settle for less than real time access
> to your eyeballs ;-P
> 
> Sarcasm [1] aside, the idea was possibly to enhance your videoconf
> experience.
> 
> As far as I understand, rtkit gets told by apps over DBus [2]
> "hey, I'm important. Gimme some real-time prio".
> 
> No idea where its config is, but there is an admin front end
> to it called rtkitctl.

It doesn't have any configuration other through command line
arguments.

> That said, it is Poetteringware, so it should come with a decent
> man page.

It doesn't have a man page.

> > How do I prevent this from happening?
> 
> Tell us when you find out. I always enjoy stories from the deep
> end of the pool :-)
> 
> > And why is there no control whatsoever about which processes can get
> > higher priority?  This is not an acceptable way to do such things.
> 
> There should, yes.
> 
> > Is there a better way then disabling/removing rtkit-daemon?  And how
> > could I remove/disable it?
> 
> Which package does it come with?

Well, I don't remove it because it can be useful.  I only want to
prevent it from doing stuff I don't want it to do.  That ability goes
more and more down the drain :(

And it turned out that it's apparently not rtkit-daemon but firefox
itself that makes it assume a higher priority.

> Cheers
> 
> [1] It always feels queasy when sarcasm and reality are so
>    close together.
> 
> [2] Phew. No DBus around here. Another bullet dodged :-D

Aren't there going to be lots of problems with things not working when
you don't have dbus?

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

#266008

hw <hw@adminart.net> writes:

> Aren't there going to be lots of problems with things not working when
> you don't have dbus?

Fewer than when things don't work when you *do* have dbus, apparently ;)
There doesn't seem to be an overwhelming need for it once you step away
from the DE's.

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

#266052

Tom Furie <tom@furie.org.uk> writes:

> Fewer than when things don't work when you *do* have dbus, apparently ;)
> There doesn't seem to be an overwhelming need for it once you step away
> from the DE's.

I don't have a DE on my main desktop but still it looks like I have five
dbus-daemons and one dbus-launch running in the system.

On my headless router there's one dbus-daemon, another two headless
machines have one or two of those. I don't know what for but they're
there and they don't seem to cause any issues.

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

#266058

On 2024-01-15, Tom Furie wrote:

> There doesn't seem to be an overwhelming need for it once you step away
> from the DE's.

I don't use DE but bluez clementine gnumeric sound-juicer and a lots more
which need dbus

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

#266039

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

On Mon, Jan 15, 2024 at 09:37:34PM +0100, hw wrote:
> On Mon, 2024-01-15 at 20:21 +0100, tomas@tuxteam.de wrote:
> > On Mon, Jan 15, 2024 at 07:38:27PM +0100, hw wrote:

[rkit...]

> > No idea where its config is, but there is an admin front end
> > to it called rtkitctl.
> 
> It doesn't have any configuration other through command line
> arguments.

Darn :-(

> > That said, it is Poetteringware, so it should come with a decent
> > man page.
> 
> It doesn't have a man page.

Double darn. I do have my issues with Poetteringware (since avahi),
but my experience is that it had pretty good docs. Disappointed.

> Well, I don't remove it because it can be useful.  I only want to
> prevent it from doing stuff I don't want it to do.  That ability goes
> more and more down the drain :(

Reminds one of the Monkey's Paw [1], doesn't it :)

> And it turned out that it's apparently not rtkit-daemon but firefox
> itself that makes it assume a higher priority.

Firefox itself can't (unless it is started with extra capabilities
(CAP_SYS_NICE,I think). Thus the roundabout via DBus and (possibly)
rtkit.

> > [2] Phew. No DBus around here. Another bullet dodged :-D
> 
> Aren't there going to be lots of problems with things not working when
> you don't have dbus?

Heh. But they are the known knowns. The only real limitation
actually is no Bluetooth, because Bluez insists on a brain
dead architecture which replaces plain old lib interface with
DBus calls.

The others... well. No "Desktop Environment": duh, I don't enjoy
those. Pulseaudio and Systemd don't want to play with me -- I don't
want to play with them either, not on my daily driver. The browser
has gone gaga and *wants* Pulseaudio: there's apulse for that
(thanks, Rinat Ibragimov!).

All I learn about those is when trying to help others keep their
system afloat (yes, for someone coming from the Dark Side and
not wanting to tinker, something like Gnome or Mate does make
sense).

Cheers

[1] https://en.wikipedia.org/wiki/The_Monkey's_Paw
-- 
t

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

#266050

On Tue, 2024-01-16 at 06:52 +0100, tomas@tuxteam.de wrote:
> On Mon, Jan 15, 2024 at 09:37:34PM +0100, hw wrote:
> [...]
> > And it turned out that it's apparently not rtkit-daemon but firefox
> > itself that makes it assume a higher priority.
> 
> Firefox itself can't (unless it is started with extra capabilities
> (CAP_SYS_NICE,I think). Thus the roundabout via DBus and (possibly)
> rtkit.

There are two scripts being executed that end up starting the firefox
binary.  None of them seem to be doing anything to make it so that
firefox could assume higher priority.

After that, there is


systemd[2241]: Started cgroupify@app-gnome-firefox-152280.scope.service.
systemd[2241]: Started app-gnome-firefox-152280.scope - Application launched by gnome-shell.


in the journal.  That service is a file that doesn't seem to exist,
and I can't see its contents:


ls -la /run/user/1000/systemd/units/invocation\:app-gnome-firefox-152280.scope 
lrwxrwxrwx. 1 ... ... 32 Jan 16 10:47 /run/user/1000/systemd/units/invocation:app-gnome-firefox-152280.scope -> 47228f6ad8054d29a0d20c5517b76757


A file 47228f6ad8054d29a0d20c5517b76757 is not present where the link
points to.  What's with that?

> > > [2] Phew. No DBus around here. Another bullet dodged :-D
> > 
> > Aren't there going to be lots of problems with things not working when
> > you don't have dbus?
> 
> Heh. But they are the known knowns. The only real limitation
> actually is no Bluetooth, because Bluez insists on a brain
> dead architecture which replaces plain old lib interface with
> DBus calls.
> 
> The others... well. No "Desktop Environment": duh, I don't enjoy
> those. Pulseaudio and Systemd don't want to play with me -- I don't
> want to play with them either, not on my daily driver. The browser
> has gone gaga and *wants* Pulseaudio: there's apulse for that
> (thanks, Rinat Ibragimov!).

Well, xorg is not longer maintained, and there is no version of fvwm
that would work with wayland.  That only leaves either KDE, Gnome or
sway.  I don't get along with tiling window managers though tiling
with fvwm was actually great.  You get the best of worlds with that.

Someone needs to make a fvwm version for wayland so we can have a
decent window manager again, and all the other software needs to be
improved so it doesn't have all these dependencies that don't even let
you do the most basic things like adjusting the font size.

> All I learn about those is when trying to help others keep their
> system afloat (yes, for someone coming from the Dark Side and
> not wanting to tinker, something like Gnome or Mate does make
> sense).

Well, yes, when software doesn't do what it is supposed to do, that
means it's not working right.  Give it a little time and sofware will
only do what /it/ wants and nothing else :(  We'll all be forced to go
braindead then, or have to escape this planet.

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

#266057

On Tue, Jan 16, 2024 at 11:27:43AM +0100, hw wrote:
> systemd[2241]: Started cgroupify@app-gnome-firefox-152280.scope.service.
> systemd[2241]: Started app-gnome-firefox-152280.scope - Application launched by gnome-shell.
> 
> 
> in the journal.  That service is a file that doesn't seem to exist,
> and I can't see its contents:
> 
> 
> ls -la /run/user/1000/systemd/units/invocation\:app-gnome-firefox-152280.scope 
> lrwxrwxrwx. 1 ... ... 32 Jan 16 10:47 /run/user/1000/systemd/units/invocation:app-gnome-firefox-152280.scope -> 47228f6ad8054d29a0d20c5517b76757
> 
> 
> A file 47228f6ad8054d29a0d20c5517b76757 is not present where the link
> points to.  What's with that?

See, this is why we ask people to include their SHELL PROMPT along with
the command they type.  The shell prompt would most likely contain
a "$" character or a "#" character, which would tell us who you were
when you ran this command.

I'm betting you ran this as root, and this is why you can't see the
contents underneath /run/user/1000.

Only user 1000 can see that.

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

#266061

On Tue, 2024-01-16 at 07:05 -0500, Greg Wooledge wrote:
> On Tue, Jan 16, 2024 at 11:27:43AM +0100, hw wrote:
> > systemd[2241]: Started cgroupify@app-gnome-firefox-152280.scope.service.
> > systemd[2241]: Started app-gnome-firefox-152280.scope - Application launched by gnome-shell.
> > 
> > 
> > in the journal.  That service is a file that doesn't seem to exist,
> > and I can't see its contents:
> > 
> > 
> > ls -la /run/user/1000/systemd/units/invocation\:app-gnome-firefox-152280.scope 
> > lrwxrwxrwx. 1 ... ... 32 Jan 16 10:47 /run/user/1000/systemd/units/invocation:app-gnome-firefox-152280.scope -> 47228f6ad8054d29a0d20c5517b76757
> > 
> > 
> > A file 47228f6ad8054d29a0d20c5517b76757 is not present where the link
> > points to.  What's with that?
> 
> See, this is why we ask people to include their SHELL PROMPT along with
> the command they type.  The shell prompt would most likely contain
> a "$" character or a "#" character, which would tell us who you were
> when you ran this command.
> 
> I'm betting you ran this as root, and this is why you can't see the
> contents underneath /run/user/1000.
> 
> Only user 1000 can see that.

Good point.  I tried it both as root and as user 1000, and both can
not display the file and the listing shows that the file the link
points to does not exist as either user.

There's only a bunch of links in that directory, apparently all
pointing to files that don't exist.  Don't you have that?

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

#266064

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
lrwxrwxrwx 1 greg greg 32 Jan  4 10:32 invocation:dbus.service -> 2b212423fe7f48df993bf1a7159a917f
lrwxrwxrwx 1 greg greg 32 Jan  4 10:32 invocation:dbus.socket -> febb123312794a6b90cf4c833af5b2e3
lrwxrwxrwx 1 greg greg 32 Jan 10 15:19 invocation:dconf.service -> 32ff4a266ef64caca6ceb62cebe5baa5
lrwxrwxrwx 1 greg greg 32 Jan  4 10:32 invocation:pipewire.service -> 8a54321c93d04ef9860e128c27399c18
lrwxrwxrwx 1 greg greg 32 Jan  4 10:32 invocation:pulseaudio.service -> b8e04b1f22ac4f01b9e262a7f5fab40c
lrwxrwxrwx 1 greg greg 32 Jan  4 10:33 invocation:xdg-desktop-portal-gtk.service -> d7768c07f7d04410857a3feb8000dc3b
lrwxrwxrwx 1 greg greg 32 Jan  4 10:33 invocation:xdg-desktop-portal.service -> ac5527db968648b99b4361e517616318
lrwxrwxrwx 1 greg greg 32 Jan  4 10:33 invocation:xdg-document-portal.service -> 1422bb0407ed475eb3f1e312bf97e4b8
lrwxrwxrwx 1 greg greg 32 Jan  4 10:33 invocation:xdg-permission-store.service -> 7ff0ce2fc8ef4ca498e4f63be7e49429

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?

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

#266065

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.

And I do want to know what this unit file for firefox contains and
does and how it is being brought about.

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

#266067

On Tue, 2024-01-16 at 14:17 +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.
> 
> And I do want to know what this unit file for firefox contains and
> does and how it is being brought about.
> 

Hm, ok, this seems to go to
'/usr/lib/systemd/user/app-firefox-.scope.d/99-cgroupify.conf'.

What the hell is cgroupify?  It seems to be yet another undocumented
thing coming from the freedesktop crap.

I still don't know what's with these non-existing files, though.

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

#266068

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

> 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

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

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

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

#266108

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

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

#266109

On Wed, 2024-01-17 at 11:19 +0100, hw wrote:
> 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.

Filesystem directories entries hold more than file and directory
objects. As well as symbolic links, there's named FIFOs, named sockets,
and devices.

E.g.

$ mkfifo a-fifo
$ nc -lkU a-socket&
$ ln -T target -s a-link

$ ls -l a-*
prw-r--r-- 1 tixy tixy 0 Jan 17 12:07 a-fifo
lrwxrwxrwx 1 tixy tixy 6 Jan 17 12:08 a-link -> target
srwxr-xr-x 1 tixy tixy 0 Jan 17 12:07 a-socket

-- 
Tixy

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

#266113

On Wed, 2024-01-17 at 12:25 +0000, Tixy wrote:
> On Wed, 2024-01-17 at 11:19 +0100, hw wrote:
> > 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.
> 
> Filesystem directories entries hold more than file and directory
> objects. As well as symbolic links, there's named FIFOs, named sockets,
> and devices.
> 
> E.g.
> 
> $ mkfifo a-fifo
> $ nc -lkU a-socket&
> $ ln -T target -s a-link
> 
> $ ls -l a-*
> prw-r--r-- 1 tixy tixy 0 Jan 17 12:07 a-fifo
> lrwxrwxrwx 1 tixy tixy 6 Jan 17 12:08 a-link -> target
> srwxr-xr-x 1 tixy tixy 0 Jan 17 12:07 a-socket
> 

Ok but all the files in /run/user/1000/systemd/units/ are
lrwxrwxrwx. (except . and ..).

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

#266116

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

On Wed, Jan 17, 2024 at 02:41:37PM +0100, hw wrote:

[...]

> Ok but all the files in /run/user/1000/systemd/units/ are
> lrwxrwxrwx. (except . and ..).

Symlinks are always like this. The "real" permissions are the
target's, which, as you have found out, doesn't exist.

(Permissions don't actually make sense for a symlink, since
the "content" is off-limits for user space anyway, which can
only access it through "ln" and friends).

Cheers
-- 
t

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

#266110

On Wed, Jan 17, 2024 at 11:19:50AM +0100, hw wrote:
> 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

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

I don't know how to make it any clearer.  THE SYMBOLIC LINK TARGET IS
THE CONTENT.  They are storing this "Invocation ID" inside the symbolic
link itself.

This is what they chose to do.  I don't know WHY.  But you can clearly
see what they're doing.

> > 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=

What were you trying to do?  You took my command and mangled it.  You
appended the *output* of my command as an *argument* to your command,
substituting my 128-bit InvocationID with one of your own.  Why?

> Neither the user, nor root gets anything from this.  What is it
> supposed to show?

You got the InvocationID of the at-spi-dbus-bus.service unit.  You
also got an error message because of the mangled argument you passed,
and an extra blank InvocationID= line as output from that same mangled
argument, because it wasn't a running unit's name.

When I ran *my* command, I was simply demonstrating that the "systemctl"
command, when asked for the InvocationID of a unit, gives the same
128-bit number that you can see with ls -l.

That's all.  Nothing more complicated than that.

THE 128-BIT HEX NUMBER IS THE CONTENT.  IT IS THE DATA.  IT IS WHAT YOU
SEEM TO BE LOOKING FOR.  THAT'S ALL THERE IS.  THERE IS NO ADDITIONAL
PAYLOAD TO BE FOUND.

THE SYMBOLIC LINKS ARE *SUPPOSED* TO BE DANGLING.  THEY ARE NOT MEANT
TO BE catTED.

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

If you want to know what the InvocationID IS USED FOR, ask on the
systemd mailing lists, because clearly we don't know.

If you want to know WHY they chose to store the InvocationID inside
the target of a symbolic link, instead of as regular file content,
ask on the systemd mailing lists, because clearly we don't know.

If you want to know why things that you've never seen before are
alarming to you, ask your therapist, because... well, you get the picture,
I hope.

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

#266114

On Wed, 2024-01-17 at 07:26 -0500, Greg Wooledge wrote:
> On Wed, Jan 17, 2024 at 11:19:50AM +0100, hw wrote:
> > 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
> 
> > > 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.
> 
> I don't know how to make it any clearer.  THE SYMBOLIC LINK TARGET IS
> THE CONTENT.  They are storing this "Invocation ID" inside the symbolic
> link itself.
>
> This is what they chose to do.  I don't know WHY.  But you can clearly
> see what they're doing.

I can only see links to files that don't exist.

> > > 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=
> 
> What were you trying to do?  You took my command and mangled it.  You
> appended the *output* of my command as an *argument* to your command,
> substituting my 128-bit InvocationID with one of your own.  Why?

I copied your command and replaced the UUID with one that shows up in
/run/user/1000/systemd/units/ as a link target since it seems unlikely
that the same UUIDs you have are being used here..  At least that was
my intention.

Maybe your command was supposed to be 'systemctl --user show -p
InvocationID at-spi-dbus-bus.service'?  That shows only


InvocationID=b6e84c2dd18b4d9f84436580113abaca


which doesn't tell me anything.

> > Neither the user, nor root gets anything from this.  What is it
> > supposed to show?
> 
> You got the InvocationID of the at-spi-dbus-bus.service unit.  You
> also got an error message because of the mangled argument you passed,
> and an extra blank InvocationID= line as output from that same mangled
> argument, because it wasn't a running unit's name.
> 
> When I ran *my* command, I was simply demonstrating that the "systemctl"
> command, when asked for the InvocationID of a unit, gives the same
> 128-bit number that you can see with ls -l.
> 
> That's all.  Nothing more complicated than that.

How would that be useful?

> THE 128-BIT HEX NUMBER IS THE CONTENT.  IT IS THE DATA.  IT IS WHAT YOU
> SEEM TO BE LOOKING FOR.  THAT'S ALL THERE IS.  THERE IS NO ADDITIONAL
> PAYLOAD TO BE FOUND.
> 
> THE SYMBOLIC LINKS ARE *SUPPOSED* TO BE DANGLING.  THEY ARE NOT MEANT
> TO BE catTED.

If that is so, what is the purpose of useless directory entries?

> > > 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 :)
> 
> If you want to know what the InvocationID IS USED FOR, ask on the
> systemd mailing lists, because clearly we don't know.

That may be a good idea.

> If you want to know WHY they chose to store the InvocationID inside
> the target of a symbolic link, instead of as regular file content,
> ask on the systemd mailing lists, because clearly we don't know.
> 
> If you want to know why things that you've never seen before are
> alarming to you, ask your therapist, because... well, you get the picture,
> I hope.
> 

Unknown things never seen before are always alarming.  There may not
be any therapist able to help you if they aren't alarming to you.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web