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 2 of 2 — ← Prev page 1 [2]

#266115

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

On 2024-01-17 at 09:02, hw wrote:

> On Wed, 2024-01-17 at 07:26 -0500, Greg Wooledge wrote:
>
>> On Wed, Jan 17, 2024 at 11:19:50AM +0100, hw wrote:

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

Not just "supposed to be" - I'm essentially certain that it *was* that.

What I think happened is that you saw the command, and its output on the
next line, and mistakenly thought that this was a single longer command
that had been line-wrapped.

> That shows only
> 
> 
> InvocationID=b6e84c2dd18b4d9f84436580113abaca
> 
> 
> which doesn't tell me anything.

If I'm not mistaken, it shows the same value as is the target of the
symlink, which tells you that the target of the symlink is the
InvocationID value. (I'd guess that the command is getting it from that
same symlink.)

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

As a way of looking up the InvocationID of the "service" in question.

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

My guess is: so that they can get the data directly in a variable by a
call to stat() or similar, rather than having to read and parse (and
validate against possible malicious replacement) the contents of a file.

I wouldn't consider that to be sufficient benefit to justify abusing the
semantics of symbolic links, but it's long since clear that the
freedesktop.org people don't use the same criteria in assessing these
things as I would, so it's no surprise that they might have done it anyway.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#266167

On Wed 17 Jan 2024 at 15:02:05 (+0100), hw wrote:
> 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.

Perhaps a more understandable example would help. If you edit some
file with emacs, and make some change in the buffer, take a look at
the directory the file is in, and you'll see something like:

  $ ls -al foo
  total 28
  drwxr-x---  2  4096 Jan 17 22:56 .
  lrwxrwxrwx  1    27 Jan 17 22:56 .#connectivity -> auser@ahost.26418:1705500887
  drwxrwxrwt 17 20480 Jan 17 22:55 ..
  -rw-------  1   793 Apr 26  2017 connectivity
  $ 

If someone else tries to edit the same file and make an alteration,
emacs will prompt them with a query, and they can back off, or
carry on editing, or "steal" the file (swapping roles, so the original
editor becomes the intruder).

That process is enabled by the lock file, a dangling symlink, which
enables emacs to inform the second person who and where the first
person is, and their process's PID. In this case, the data in the
symlink is easily recognised: user@host.PID:seconds, where seconds
is likely the host's boot time.

> Unknown things never seen before are always alarming.

Nonsense. Small children would be in a constant state of alarm.

Cheers,
David.

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

#266002

On Mon, 2024-01-15 at 19:38 +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.
> 
> 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?
> 

PS:

I have --- at least temporarily --- disabled rtkit-daemon by masking
the service and renaming
/usr/share/dbus-1/system-services/org.freedesktop.RealtimeKit1.service
so dbus doesn't try to start it anymore.

I've restarted firefox and am still seeing processes with higher
priority in htop (labled as /usr/lib64/firefox/firefox).  I've checked
with ps that rtkit-daemon is not running.

How can firefox assume a higher priority, and how do I prevent these
processes from assuming higher priority?

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

#266005

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

On Mon, Jan 15, 2024 at 08:52:45PM +0100, hw wrote:
> On Mon, 2024-01-15 at 19:38 +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.
> > 
> > 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?
> > 
> 
> PS:
> 
> I have --- at least temporarily --- disabled rtkit-daemon by masking
> the service and renaming
> /usr/share/dbus-1/system-services/org.freedesktop.RealtimeKit1.service
> so dbus doesn't try to start it anymore.
> 
> I've restarted firefox and am still seeing processes with higher
> priority in htop (labled as /usr/lib64/firefox/firefox).  I've checked
> with ps that rtkit-daemon is not running.

Interesting. All of them 20 here, i.e. normal. But my setup isn't
normal, mind you :)

Cheers
-- 
t

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

#266048

On Mon, 2024-01-15 at 21:02 +0100, tomas@tuxteam.de wrote:
> > [...]
> > I have --- at least temporarily --- disabled rtkit-daemon by masking
> > the service and renaming
> > /usr/share/dbus-1/system-services/org.freedesktop.RealtimeKit1.service
> > so dbus doesn't try to start it anymore.
> > 
> > I've restarted firefox and am still seeing processes with higher
> > priority in htop (labled as /usr/lib64/firefox/firefox).  I've checked
> > with ps that rtkit-daemon is not running.
> 
> Interesting. All of them 20 here, i.e. normal. But my setup isn't
> normal, mind you :)

Mine isn't either in that I have allowed myself to run things at
higher priority when I tried to get better FPS rates for a game I was
playing.

I wonder if you're seeing the same with firefox when you allow higher
priority, too.  Otherwise I don't see how firefox or any other user
process should be able to do it (without rtkit).

Still it seems unusual that firefox does something it usually can't
do.  Who would go to the lengths of implementing a feature that nobody
uses.

The messages in the journal are actually weird:


rtkit-daemon[132284]: Successfully made thread 145442 of process 145185 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.

rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.


It says 'made owned by'.  Does user 1000 not own the process to begin
with?  Which user owned it before?  Or what is that supposed to mean?

Eventually it will run into a limit:


rtkit-daemon[1121]: Failed to look up client: Device or resource busy
rtkit-daemon[1121]: Warning: Reached maximum concurrent process limit for user '1000', denying request.
J


Will firefox will make its processes higher priority despite the limit
is reached since it does it without rtkit?

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

#266051

I don't know anything about rtkit, but I may be able to parse English :-)

Am 16.01.2024 um 10:42 schrieb hw:
...
> The messages in the journal are actually weird:
> 
> 
> rtkit-daemon[132284]: Successfully made thread 145442 of process 145185 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
> 
> rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
> rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
> rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
> rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
> 
> 
> It says 'made owned by'.  Does user 1000 not own the process to begin
> with?  Which user owned it before?  Or what is that supposed to mean?

What it tries to say is probably "made (thread ... owned by 1000) high 
priority".

Cheers,

Arno

-- 
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

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

#266054

On Tue, 2024-01-16 at 11:27 +0100, Arno Lehmann wrote:
> I don't know anything about rtkit, but I may be able to parse English :-)
> 
> Am 16.01.2024 um 10:42 schrieb hw:
> ...
> > The messages in the journal are actually weird:
> > 
> > 
> > rtkit-daemon[132284]: Successfully made thread 145442 of process 145185 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
> > 
> > rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
> > rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
> > rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
> > rtkit-daemon[132284]: Successfully made thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
> > 
> > 
> > It says 'made owned by'.  Does user 1000 not own the process to begin
> > with?  Which user owned it before?  Or what is that supposed to mean?
> 
> What it tries to say is probably "made (thread ... owned by 1000) high 
> priority".

It says 'made thread ... (at nice level 0) owned by 1000'.  This is
inconclusive at best: The thread is obviously _at_ some nice level or
_at_ some priority and was made owned by 1000.

If it had changed the priority it should say that, but it doesn't.

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

#266056

hw <hw@adminart.net> writes:

>> > 
> It says 'made thread ... (at nice level 0) owned by 1000'.  This is
> inconclusive at best: The thread is obviously _at_ some nice level or
> _at_ some priority and was made owned by 1000.
>
> If it had changed the priority it should say that, but it doesn't.

It does say that. Perhaps insertings commas of hyphens into the log
entry would have made the statement easier to parse.

e.g:

rtkit-daemon[132284]: Successfully made thread 145442 of process 145185
(/usr/lib64/firefox/firefox), owned by '1000', RT at priority 10.

or

rtkit-daemon[132284]: Successfully made thread 145442 of process 145185
(/usr/lib64/firefox/firefox) - owned by '1000' - RT at priority 10.

So, it has changed the priority of a process which is owned by UID 1000.

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

#266059

hw <hw@adminart.net> wrote:
> On Tue, 2024-01-16 at 11:27 +0100, Arno Lehmann wrote:
> > I don't know anything about rtkit, but I may be able to parse
> > English :-)
> > 
> > Am 16.01.2024 um 10:42 schrieb hw:
> > ...  
> > > The messages in the journal are actually weird:
> > > 
> > > 
> > > rtkit-daemon[132284]: Successfully made thread 145442 of process
> > > 145185 (/usr/lib64/firefox/firefox) owned by '1000' RT at
> > > priority 10.
> > > 
> > > rtkit-daemon[132284]: Successfully made thread 2534 of process
> > > 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
> > > rtkit-daemon[132284]: Successfully made thread 2534 of process
> > > 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice
> > > level 0. rtkit-daemon[132284]: Successfully made thread 2534 of
> > > process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at
> > > priority 20. rtkit-daemon[132284]: Successfully made thread 2534
> > > of process 2507 (/usr/bin/gnome-shell) owned by '1000' high
> > > priority at nice level 0.
> > > 
> > > 
> > > It says 'made owned by'.  Does user 1000 not own the process to
> > > begin with?  Which user owned it before?  Or what is that
> > > supposed to mean?  
> > 
> > What it tries to say is probably "made (thread ... owned by 1000)
> > high priority".  
> 
> It says 'made thread ... (at nice level 0) owned by 1000'.  This is
> inconclusive at best: The thread is obviously _at_ some nice level or
> _at_ some priority and was made owned by 1000.

Well no it doesn't. You've changed the order of the words and that
changes the meaning.
 
> If it had changed the priority it should say that, but it doesn't.

There's a rather unwieldy noun phrase
"thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000'"
which identifies a particular thread. Let's call that THREAD.

Then what the log says is:

rtkit-daemon[132284]: Successfully made THREAD RT at priority 20.
rtkit-daemon[132284]: Successfully made THREAD high priority at nice
level 0. 
rtkit-daemon[132284]: Successfully made THREAD RT at priority 20.
rtkit-daemon[132284]: Successfully made THREAD high priority at nice
level 0.

So the log is telling you something about changes to the priority and
real-time nature of that particular THREAD. I've no idea what they
actually mean.

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

#266063

On Tue, 2024-01-16 at 12:15 +0000, debian-user@howorth.org.uk wrote:
> hw <hw@adminart.net> wrote:
> > On Tue, 2024-01-16 at 11:27 +0100, Arno Lehmann wrote:
> > > I don't know anything about rtkit, but I may be able to parse
> > > English :-)
> > > 
> > > Am 16.01.2024 um 10:42 schrieb hw:
> > > ...  
> > > > The messages in the journal are actually weird:
> > > > 
> > > > 
> > > > rtkit-daemon[132284]: Successfully made thread 145442 of process
> > > > 145185 (/usr/lib64/firefox/firefox) owned by '1000' RT at
> > > > priority 10.
> > > > 
> > > > rtkit-daemon[132284]: Successfully made thread 2534 of process
> > > > 2507 (/usr/bin/gnome-shell) owned by '1000' RT at priority 20.
> > > > rtkit-daemon[132284]: Successfully made thread 2534 of process
> > > > 2507 (/usr/bin/gnome-shell) owned by '1000' high priority at nice
> > > > level 0. rtkit-daemon[132284]: Successfully made thread 2534 of
> > > > process 2507 (/usr/bin/gnome-shell) owned by '1000' RT at
> > > > priority 20. rtkit-daemon[132284]: Successfully made thread 2534
> > > > of process 2507 (/usr/bin/gnome-shell) owned by '1000' high
> > > > priority at nice level 0.
> > > > 
> > > > 
> > > > It says 'made owned by'.  Does user 1000 not own the process to
> > > > begin with?  Which user owned it before?  Or what is that
> > > > supposed to mean?  
> > > 
> > > What it tries to say is probably "made (thread ... owned by 1000)
> > > high priority".  
> > 
> > It says 'made thread ... (at nice level 0) owned by 1000'.  This is
> > inconclusive at best: The thread is obviously _at_ some nice level or
> > _at_ some priority and was made owned by 1000.
> 
> Well no it doesn't. You've changed the order of the words and that
> changes the meaning.
>  
> > If it had changed the priority it should say that, but it doesn't.
> 
> There's a rather unwieldy noun phrase
> "thread 2534 of process 2507 (/usr/bin/gnome-shell) owned by '1000'"
> which identifies a particular thread. Let's call that THREAD.
> 
> Then what the log says is:
> 
> rtkit-daemon[132284]: Successfully made THREAD RT at priority 20.
> rtkit-daemon[132284]: Successfully made THREAD high priority at nice
> level 0. 
> rtkit-daemon[132284]: Successfully made THREAD RT at priority 20.
> rtkit-daemon[132284]: Successfully made THREAD high priority at nice
> level 0.
> 
> So the log is telling you something about changes to the priority and
> real-time nature of that particular THREAD. I've no idea what they
> actually mean.

Yes, it finally occured to me that it's supposed to mean 'made RT'
when I looked at the journal again.  RT probably means real time, and
there seems to be a distinction between real time and nice.  However,
this is not a real time system, so real time is basically meaningless.

Still, how do I prevent rtkit-daemon and firefox from giving it(self)
higher priority?

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

#266012

You may be able to prevent Firefox from getting increased priority by
using polkit.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

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

#266049

On Mon, 2024-01-15 at 15:24 -0600, John Hasler wrote:
> You may be able to prevent Firefox from getting increased priority by
> using polkit.

How would I do that?  All the freedektop stuff always has been a big
mystery, and polkit is part of it, or isn't it?

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

#266078

I  wrote:
> You may be able to prevent Firefox from getting increased priority by
> using polkit.

hw writes:
> How would I do that?  All the freedektop stuff always has been a big
> mystery, and polkit is part of it, or isn't it?

I don't know, but it at least has a man page and I think that this is
the sort of stuff it is supposed to be for.  Worth investigating.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

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

#266112

On Tue, 2024-01-16 at 10:19 -0600, John Hasler wrote:
> I  wrote:
> > You may be able to prevent Firefox from getting increased priority by
> > using polkit.
> 
> hw writes:
> > How would I do that?  All the freedektop stuff always has been a big
> > mystery, and polkit is part of it, or isn't it?
> 
> I don't know, but it at least has a man page and I think that this is
> the sort of stuff it is supposed to be for.  Worth investigating.

Cool, it has a man page :)  I checked the files/directories mentioned
in the page, and nothing seems to indicate that there is anything that
would allow firefox to increase its priority.

It might not need a special allowance because I have allowed the user
to set a nice level of up to -10 in /etc/security/limits.conf.  I
think that doesn't mean that firefox could get real time priority
though --- unless rtkit-daemon is somehow able to set any process that
asks for it to whatever priority the process asks for.

If rtkit-daemon can do that I wonder why the default configuration
is made to open such an enormous security backdoor.

[toc] | [prev] | [standalone]

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

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

csiph-web