5 ms·

I think the problem is that we don't know how to troubleshoot problems with our desktops (especially things related to permissions as in consolekit/policykit/db

I think the problem is that we don't know how to troubleshoot problems with our desktops (especially things related to permissions as in consolekit/policykit/dbus etc): * before the switch to systemd everything "just worked" on Debian and you didn't have to deal with this * during the switch to systemd there were situations when switching was worse than staying with sysvinit (e.g. system wouldn't boot anymore due to entries in fstab). * then the situation started to improve in systemd at the detriment of those who stayed with sysvinit (no suspend button in KDE when not on systemd; policykit not working; virt-viewer shows a permission error on MATE, but not on KDE, etc.) Whether you switched to systemd or not you noticed that something broke. That was always a possibility with unstable of course, but usually fixing it was quite simple. In this situation it was worse because you first had to find where the problem lies, which means understanding all the complex interactions of a desktop's components. Searching for documentation isn't very easy either, because sometimes there is no documentation except the source code and configuration files themselves. Fxing things isn't easy as downgrading or fixing a configuration file either: usually you have to patch the applications, or wait for others to do it. All this is made worse that systemd tries to do too many things at once: PID1/service supervision, initscripts, dbus stuff for logind, policykit/pam, syslog etc. Some people have strong opinions on PID1 and initscripts (myself included) and don't like all these forcibly changed at once. I wouldn't be opposed to service supervision (I like runit), or a better initscript format, but I'd like to have a choice of changing that without breaking unrelated things (like policykit on the desktop). OTOH I don't really care how consolekit/policykit/dbus is implemented as long as it works, and as long as I'm not forced to change something unrelated, like how I boot my system. Also if these were all independent applications that didn't require the rest of systemd troubleshooting would be easier by switching out components one at a time. Things like systemd-shim/cgmanager attempt to do that, but that is more like a band-aid than a properly designed, modular application.

digi_owl 12y ago
I think you are hitting on something with this. And part of the problem is perhaps that so much happens across dbus. I recall trying to set up dbus on a minimal install, and finding that often when something borked, it borked in odd ways. This in that a signal could seemingly get stuck inside dbus, as one party thought it had sent the relevant message, the other party never responded in kind, and the only real way to get everything unstuck was to kill dbus and all relevant parties (pretty much a reboot of anything above the kernel these days). With something as seemingly simple as mounting a thumbdrive, the process goes something like filemanager > udisk > pol(icy)kit > consolekit/logind. All that to "verify" that the person sitting at the keyboard has the rights to do "mount /dev/sdb1". And every > in that chain involves dbus. So if dbus borks, everything borks. And dbus is pretty much a black box.

digi_owl 12y ago

I think you are hitting on something with this. And part of the problem is perhaps that so much happens across dbus. I recall trying to set up dbus on a minimal install, and finding that often when something borked, it borked in odd ways. This in that a signal could seemingly get stuck inside dbus, as one party thought it had sent the relevant message, the other party never responded in kind, and the only real way to get everything unstuck was to kill dbus and all relevant parties (pretty much a reboot of anything above the kernel these days). With something as seemingly simple as mounting a thumbdrive, the process goes something like filemanager > udisk > pol(icy)kit > consolekit/logind. All that to "verify" that the person sitting at the keyboard has the rights to do "mount /dev/sdb1". And every > in that chain involves dbus. So if dbus borks, everything borks. And dbus is pretty much a black box.