reassign -1 elogind thanks The story so far:
The submitter identified that: /usr/share/dbus-1/system-services/org.freedesktop.login1.service contains: Exec=/bin/true I noted that systemd says in its file: Exec=/bin/false I have a feeling that dbus auto-starts `true` in this case expecting it to provide the interfaces, which it obviously doesn't, but I haven't tested that theory. Maybe you have or have another idea? For more details see my previous message [0] that in hindsight I should have used for the reassign… oh well. Summary end. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1129339#46 Am Tue, Mar 03, 2026 at 03:43:40PM +0100, schrieb [email protected]: > Maybe there is an explanation: users routinely launch dist-upgrades just > seconds before pulling the plug of their systems, when dpkg is in the > middle of a critical library upgrade; of course we need to protect them > with (1) and (2); moreover people so stupid are obviously not going to > benefit from the docs anyway, therefore also (3). Or, unattended-upgrade starts in the background. Or you have a laptop and more or less by reflex close the lid as someone comes by (which could very well cause not only suspend but hiberation) or or or. It's not "stupid" to declare your requirements and let automated process take care of it for you even if you could easily do it all by hand if you wanted. If it were, why are we here? We could all use Slackware and deal with dependencies by hand – or are you too stupid to do that?! Of course not. > What I fail to understand is the reluctance to adopt the simplest > solution, i.e. fix (3). It is an APT issue: don't try to divert it to > other packages, don't propose changes to other packages' configurations, > just let people know how to bypass a possibly useless and time-consuming > step. Because that isn't the simplest solution. You have to identify what your problem is, find the relevant documentation, understand it, create a config file to disable this explicitly and maintain it for ever. Multiplied by every user that ever runs into this that isn't just throwing their hands in the air and gives up in frustration. Multiplied by every other tool that also interacts with login1 and hence runs into a related problem that you can workaround in some (other)way (hopefully). The simplest solution is to find the cause of the problem (= why is dbus waiting needlessly for a timeout here?) and resolve it, so that nobody else runs into this (and related) problems ever again as it simple doesn't exist anymore. Yes, that involves work finding the cause, possibly coordination with other people and implementing and testing possible solutions, but it has no "by every user running into this" multiplier attached. Nor the "by every other tool" multiplier. I was assuming you wanted to help in that process, but maybe I was wrong and you don't, which is fine, of course. Also, Julian didn't say he won't document the option. But I don't consider that a good solution for this issue. You are welcome. Best regards David Kalnischkies
signature.asc
Description: PGP signature
