On Mon, Nov 26, 2018 at 5:57 AM David Herrmann <dh.herrmann(a)gmail.com> wrote:
Hi
On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com> wrote:
>
> On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com>
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.