On 05 May 2023 14:11, to...@tuxteam.de wrote:
On Fri, May 05, 2023 at 01:58:55PM +0200, zithro wrote:
On 05 May 2023 06:32, to...@tuxteam.de wrote:
dbus is a candidate. Let me explain: I have a funny setup -- no systemd,
no dbus (still, Debian buster, and X).
I'm on bullseye, I know how to switch back to old init, but have no clue
about Dbus (kinda a Linux-GUI-with-systemd noob).
Which DE/DM you using ? I'm on MATE but also would like to get rid of many
"gvfs-*" stuff. systemctl masking is not enough and filling logs with
errors.
No DE, just a window manager (fvwm2).
Isn't that fluxbox ? That's the GUI I used on Slackware.
Simple, lean, efficient !
Ah, quick search showed me that no, from the derivatives tree image of
fvwm2 on wikipedia. may be wrong.
But I'm a bit fed up with GUIs right now. Well, systemd rather !
Anyways, back to console fun.
At some point in time, the browser (firefox) brought in dbus via some
dependencies. Annoyed, I killed dbus -- and poof, all browser instances
were gone.
Another thing I might try. But no clue what's the relation between dbus and
firefox. Also, I'm running FF in firejail.
Most applications use it to store their app preferences (just as a
transport to the store backend, typically some gsettings-thingy).
But they may use it to start other applications, etc.
No idea what firefox is messing with it (but it seems to run without
currently, nevertheless).
If I inhibit dbus from starting, the browsers run fine without it. My
hunch is that they keep an open socket conection to the dbus and die
on SIGPIPE or some such.
Again, curious how to get rid of dbus, if it's not really useful.
That depends on your needs. There are some things which will refuse
working right away because dbus is deeply built into how they work
(Bluez, for one: they use dbus like someone else would use a shared
lib). So if you use bluetooth devices, you'll have to make do with
dbus, I fear.
Good to know, another thing to look for ...
But no need for bluetooth on this machine, it's a domU \o/
So yes, if all those apps are sharing "the" session dbus, possibly
started by whoever came first *and* the logout takes the session
dbus down, this might be an explanation.
Again, dunno, after domU boot I usually first login via SSH, and on rare
occasions I login via GUI/VNC, and then ... boom.
One thing you could try is to see whether, after starting one
of those programs which get taken down, the user session dbus
is running (and wasn't before). See what happens when you log
out (does it disappear?).
Then try killing it "by hand" and see whether the same happens.
I have now full logs of before/after GUI logon/logoff, I posted them in
the other post.
Will try to make sense of it with this lead ... after a needed break ^^
I don't know whether there's a way to tell the DE to leave the
user session dbus alone when it was already running at start.
Don't even know what you mean, so to do it ... ^^
Those DEs behave as if the computer were theirs, not yours ;-)
Aaaand I *hate* that too !
Now don't ask me why I try to avoid that ;-)
If only I knew beforehand ^^
:-)
Not funny ... for me ^^ (joking)
Cheers
Thanks again
