On Mon, Nov 26, 2018 at 5:57 AM David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > > Hi > > On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko > <kloczko.tomasz@xxxxxxxxx> wrote: > > > > On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote: > > [..] > > > I’m talking about F30 recent change in which has been implemented switch to dubs-broker. > > > Ps. If this change has been propagated to F29 (hopefully not) more things will be screwed. > > > > Seems I found what caused the issue. > > I've been doing upgrade (only) dbus packages using rpm and for some > > reason after all old dbus-daemon has been killed and deactivated and > > at the same time dbus-broker has not been started. > > Instant effect was very strange. For example I was unable to unpack > > any archives with files owned by group/user not present in my system > > because NSS seems now depends on dbus as well. After next few minutes > > Gnome GUI crashed, > > > > if [ $1 -eq 1 ] ; then > > systemctl --no-reload disable dbus-daemon.service > > systemctl --no-reload --global disable dbus-daemon.service > > systemctl --no-reload enable dbus-broker.service > > systemctl --no-reload --global enable dbus-broker.service > > fi > > > > This dbus-broker %post scriplet seems is only swapping started > > services but does not stops dbus-daemon and starts dbus-broker if > > dbus-daemon is already runimg. > > You cannot stop dbus-daemon on a running system. This would tear down > everything. The package upgrade needs a reboot. > > > At the same time because in spec file is missing uninstall dbus-daemon > > by missing "Obsoletes: dbus-daemon" below > > Uninstalling dbus-daemon would break a running system, because it > would stop the system bus. Furthermore, other packages still depend on > tools provided by the old dbus-package. Can you elaborate why it is > harmful to keep dbus-daemon around? We made sure you can manually > remove it, unless other packages explicitly depend on the dbus-daemon > binary for private buses. > > > %triggerpostun -- dbus-daemon > > systemctl --no-reload preset dbus-broker.service > > systemctl --no-reload --global preset dbus-broker.service > > > > has not been activated as well. IMO implementing whole transition with > > leaving both old and new packages installed seems is wrong. > > > > Solution: login after all in single mode and execute "systemctl enable > > dbus-broker" than reboot. > > This surprises me. You are saying a simple reboot did not solve your > issues? The `enable` line is executed during upgrade, but you are > saying on your system dbus-broker was not enabled after the upgrade? > > > Other problem is that dnf and rpm are executing batch of packages > > scriplets not the same order with other operations. Breaking rpm > > semantics by dnf is kind of asking for troubles. > > Thanks a lot for the report. We tested this upgrade with several > different setups (both dbus-daemon and broker installed/not installed > before the upgrade, etc.), and we didn't see this behavior. We are > aware that this update needs a reboot to fully work, but we made sure > it somewhat works even if you don't reboot. For rawhide, there is > sadly no way to mark updates as "needs reboot". I have two arm systems running rawhide and they've both had problems where I've ended up without dbus running so no network etc. I needed to explicitly login locally and enable/disable services and reboot to get things working again. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
