Last dbus upgrade issues

[Tomasz Kłoczko]

After last dbus upgrade gdm found that is not able to start.
NM basen network configuration as well is broker because it needs dbus as
well which is not starting.
So many dependencies on dubs looks really terrible/strange/dangerous IMO.

So far found that /ust/lib/tmpfiles.d/dbus.conf does not point to /run/dbus.

Can someomeon tell what needs to be done to bring system to usable state?

Level of the verbosity messages written to system logs about what and by
what failed is close to nothing.

BTW when gdm fails console is completely blocked. Only thing which is
possible to do is reboot, go to single mode and after disable gdm service
and reboot is possible to continue troubleshoot system issues.

kloczek

[Zbigniew Jędrzejewski-Szmek]

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

Zbyszek

Post by Tomasz Kłoczko
NM basen network configuration as well is broker because it needs dbus as
well which is not starting.
So many dependencies on dubs looks really terrible/strange/dangerous IMO.
So far found that /ust/lib/tmpfiles.d/dbus.conf does not point to /run/dbus.
Can someomeon tell what needs to be done to bring system to usable state?
Level of the verbosity messages written to system logs about what and by
what failed is close to nothing.
BTW when gdm fails console is completely blocked. Only thing which is
possible to do is reboot, go to single mode and after disable gdm service
and reboot is possible to continue troubleshoot system issues.
kloczek

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/deve

[Tomasz Kłoczko]

Post by Zbigniew Jędrzejewski-Szmek

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

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.

kloczek

[Tomasz Kłoczko]

On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <***@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.
At the same time because in spec file is missing uninstall dbus-daemon
by missing "Obsoletes: dbus-daemon" below

%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.
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.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/a

[David Herrmann]

Hi

On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko

Post by Tomasz Kłoczko
[..]

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.

Post by Tomasz Kłoczko
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.

Post by Tomasz Kłoczko
%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?

Post by Tomasz Kłoczko
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".

Thanks
David
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproj

[Peter Robinson]

Post by David Herrmann
Hi
On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko

Post by Tomasz Kłoczko
[..]

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.

Post by Tomasz Kłoczko
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.

Post by Tomasz Kłoczko
%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?

Post by Tomasz Kłoczko
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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arch

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 07:04, David Herrmann <***@gmail.com> wrote:
[..]

Post by David Herrmann

Post by Tomasz Kłoczko
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".

1) Nothing from any implemented scriptlets printed out such
message/warning that system needs to be rebooted ASAP..

2) Even if some scriplets would be printing something like this dnf
will redirect stdout messages to /dev/null. rpm does not do this and
IMO good question is why dnf is doing this, So generally your 'there
is sadly no way to mark updates as "needs reboot"' is not real barrier
but barrier in dnf. Other thing is that many existing scriptlets which
may emit some workings or even errors are usually redirected by
packagers to /dev/null. For example now it is some number of packages
systemd files are still pointing to /var/run instead to /run. No one
is going to fix those issues because almost no one knows that it is
already reported by some systemd commands. IMO general policy about
scriptlets should be not redirect stdout/stderr to /dev/null because
it hides potential issues in scriplts, configuration files or other
resources.

3) If all dbus connections are not stateless which if it is true would
not allow restart dbus service on running system IMO it is big flaw in
dbus design. In case any dbus security issues this will cause that
Linux will be more like old time Windows (when application level fix
required OS reboot) than modern U*nix. Hopefully this is not truth and
dbus restart is possible.

4) Nevertheless my system ended up with *not enabled* dbus-broker.
If it was caused by upgrade over rpm it clear sign that dnf is not
fully compliant with upgrade semantics implemented in rpm. This will
cause more issues in the future (why dnf is not doing upgrade by use
rpm libs calls? why someone started duplicating this code? It must be
some reason but splitting the code is not a solution)

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedora

[Bruno Wolff III]

On Mon, Nov 26, 2018 at 12:57:34 +0100,

Post by Tomasz Kłoczko
4) Nevertheless my system ended up with *not enabled* dbus-broker.
If it was caused by upgrade over rpm it clear sign that dnf is not
fully compliant with upgrade semantics implemented in rpm. This will
cause more issues in the future (why dnf is not doing upgrade by use
rpm libs calls? why someone started duplicating this code? It must be
some reason but splitting the code is not a solution)

I ended up with this (dbus broken because dbus-daemon wasn't enabled) as well.
I eventually figured out to enable dbs-daemon, but I first tried downgrading
dbus which was a pain, because the machine doesn't support ethernet and I'm
not sure how to manaully wireless when NetworkManager can't be used.

Now I know to re-enable it on my other machines before rebooting.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/dev

[Nicolas Mailhot]

Hi,

Since I hit it too…

I agree it's a problem when subsystem maintainers assume reboot is cheap
and controlled and they do not need to make in-place update work (those
people need a few months baby-sitting headless systems where any mistake
means unracking and rewiring in uncomfortable physical positions just to
access hdmi or usb ports).

But… it’s even more a problem, that the people who assumed they could
design a system around reboots, didn’t provide a reliable way for
packages to declare the actions required to make the next boot work,
somewhere where they are sure to be executed before the next boot
attempt. Because the systems that rebooted on a state without network,
with broken gdm, and no console login, did provide the OS with the
required reboot window in the first place.

We had the same thing with grub fast boot recently. I don't care if boot
is pretty or fast, if problem remediation, is not built in the boot
process in the first place.

Regards,

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fe

[Tom Gundersen]

Hi Tomasz,

On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <

Post by Zbigniew Jędrzejewski-Szmek

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented switch
to dubs-broker.

Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).

Ps. If this change has been propagated to F29 (hopefully not) more things
will be screwed.

It has not (and will not be).

Cheers,

Tom

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 15:19, Tom Gundersen <***@jklm.no> wrote:
[..]

Post by Tom Gundersen

Post by Zbigniew Jędrzejewski-Szmek
What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented switch to dubs-broker.

Thanks for the report, and sorry for the inconvenience.

np .. when tree is chopped chops are flying around :)

Post by Tom Gundersen
There was indeed a bug in the dbus-broker spec file, which we now fixed with version 16-7 (should land in rawhide any minute).

IMO it would be good to learn something out of that small fault
because few thing went really odd way.

1) if dbus service crashes/is not availaible temporary IMO it wold be
good to prepare whole desktop apps code to not crash but handle dbus
disconnection and maybe display centered message that it is not
possible to connect to dbus. Crashing everything looks really *bad*.

2) dbus and glibc NSS subsystem dependency. Still needs to reviewed. I
think that it is anchored in systemd and such dependency must be kind
of wrong design issue.

3) any other dependency on running dbus service should be IMO closely
investigated and if something is just crashing it should be
changed/redesigned to handle this to at least log that to system logs
(nothing like this after all was possible to find in systemd journal
or rsyslogd logs).

4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!

5) review all scriptlets and delete redirections to /dev/null. If
during upgrade some programs are to much chatty it should be changed
to in the application started in sctriplets. IMO should be considered
replace redirection to /dev/null by logging to system logs. That would
be helpful on post mortem diagnose of any existing scriptlets issues.
However second thought .. to not depend on systemd (because dnf/rpm
are changing state of the systemd) probably it would be good to log or
tee scriptlets output to log file in /var/log.

kloczek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Bruno Wolff III]

On Mon, Nov 26, 2018 at 15:57:25 +0100,

Post by Tomasz Kłoczko
4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!

I was able to login to a shell, so this one might be configuration specific.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproject

[Nicolas Mailhot]

Post by Bruno Wolff III
On Mon, Nov 26, 2018 at 15:57:25 +0100,

Post by Tomasz Kłoczko
4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!

I was able to login to a shell, so this one might be configuration specific.

I had it too, forcing boot in rescue mode is not the same thing as
switching to a console (it requires access to the bootloader menu)

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedorapro

[Tomasz Torcz]

Post by Tomasz Kłoczko
[..]

Post by Tom Gundersen

Post by Zbigniew Jędrzejewski-Szmek
What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented switch to dubs-broker.

Thanks for the report, and sorry for the inconvenience.

np .. when tree is chopped chops are flying around :)

Post by Tom Gundersen
There was indeed a bug in the dbus-broker spec file, which we now fixed with version 16-7 (should land in rawhide any minute).

IMO it would be good to learn something out of that small fault
because few thing went really odd way.
1) if dbus service crashes/is not availaible temporary IMO it wold be
good to prepare whole desktop apps code to not crash but handle dbus
disconnection and maybe display centered message that it is not
possible to connect to dbus. Crashing everything looks really *bad*.
3) any other dependency on running dbus service should be IMO closely
investigated and if something is just crashing it should be
changed/redesigned to handle this to at least log that to system logs
(nothing like this after all was possible to find in systemd journal
or rsyslogd logs).

Feel free to provide patches. There was 15 years to fix it.

Alternatively, dbus-broker may store fds in systemd and serialize state
over restarts.

--
Tomasz Torcz "Funeral in the morning, IDE hacking
xmpp: ***@chrome.pl in the afternoon and evening." - Alan Cox
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 17:44, Tomasz Torcz <***@pipebreaker.pl> wrote:
[..]

Post by Tomasz Torcz
Feel free to provide patches. There was 15 years to fix it.
Alternatively, dbus-broker may store fds in systemd and serialize state
over restarts.

So you want to say that in reality it is dbus communication protocol
issue? (protocol is not stateless like for example NFS).
Good to know. .. thx.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraprojec

[Owen Taylor]

Post by Tomasz Kłoczko
1) if dbus service crashes/is not availaible temporary IMO it wold be
good to prepare whole desktop apps code to not crash but handle dbus
disconnection and maybe display centered message that it is not
possible to connect to dbus. Crashing everything looks really *bad*.

The design of D-Bus is that it is the central point of lifecycle
management for your desktop - when the session bus goes away,
everything on it should go away. Trying to make things survive bus
restart compromises that, and makes it more likely you'll get stray
processes after exit. Now with systemd user sessions, cgroups, etc, we
have other mechanisms for session cleanup, but removing the older
concept of exit-with-the-bus would require major rethinking.

Plus, when the connection to the bus is lost, all assumptions that the
app has about the state of the system are invalid. (Normally, with
D-Bus you reliably get messages, or you reliably get notification when
your communication partner goes away.) So the app state needs to be
reinitialized from scratch. There's significant code complexity there
which will be exercised in only very rare circumstance.

In general, I don't think being able to replace the bus implementation
on a running system is *that* interesting - sometimes the user will
have to reboot, and if that's too disruptive, we need to work on
making it less disruptive.

Owen
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/***@lists.fedoraproj

[Tomasz Kłoczko]

Post by Owen Taylor

Post by Tomasz Kłoczko
1) if dbus service crashes/is not availaible temporary IMO it wold be
good to prepare whole desktop apps code to not crash but handle dbus
disconnection and maybe display centered message that it is not
possible to connect to dbus. Crashing everything looks really *bad*.

The design of D-Bus is that it is the central point of lifecycle
management for your desktop - when the session bus goes away,
everything on it should go away. Trying to make things survive bus
restart compromises that, and makes it more likely you'll get stray
processes after exit. Now with systemd user sessions, cgroups, etc, we
have other mechanisms for session cleanup, but removing the older
concept of exit-with-the-bus would require major rethinking.

Cleaning the session is perfect example of what can be done with using
Solaris contracts which is kind of grouping attribute for some group
of processes which needs to be treated as the group. When session
needs to be closed all processes which are part of the contract needs
to be killed by contract id (which works like task id or pid).
Lack of contacts is IMO another cause current systemd complexity
(Solaris SMF for example kills all service processes by not looking
for all PIDs but simple by killing all processes with the same ctid).
Is it any other propose of the dbus communication? (my question is
more about original initial design than what is now)
I'm asking because I do not fully understand of the cause why dbus has
been designed and to solve current design issue original cause of
erecting/designing such communication needs to be well understood.

Post by Owen Taylor
Plus, when the connection to the bus is lost, all assumptions that the
app has about the state of the system are invalid. (Normally, with
D-Bus you reliably get messages, or you reliably get notification when
your communication partner goes away.) So the app state needs to be
reinitialized from scratch. There's significant code complexity there
which will be exercised in only very rare circumstance.

Looks like again contracts could solve such scenarios with sending
normal signal to PID 1 (like HUP) with masking to be received by all
processes with the same ctid. No new communication or protocols ..
just minute modifications of well known signal handlers.
https://docs.oracle.com/cd/E18752_01/html/816-5174/contract-4.html#REFMAN4contract-4
This idea already is used on live systems from more than decade.

kloczek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/arc

[Dominik 'Rathann' Mierzejewski]

On Monday, 26 November 2018 at 23:49, Tomasz Kłoczko wrote:
[...]

Post by Tomasz Kłoczko
Cleaning the session is perfect example of what can be done with using
Solaris contracts which is kind of grouping attribute for some group
of processes which needs to be treated as the group. When session

The Linux implementation is called control groups (cgroups) and systemd
makes heavy use of it.

Regards,
Dominik
--
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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

[Adam Williamson]

Post by Tom Gundersen
Hi Tomasz,

On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <

Post by Zbigniew Jędrzejewski-Szmek

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented switch
to dubs-broker.

Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).

Per https://bugzilla.redhat.com/show_bug.cgi?id=1653059#c25 I believe
this is still wrong, and - intentionally or otherwise - significantly
out of the scope of the Change.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/li

[Jan Pokorný]

Hello ,

Post by Tom Gundersen

On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

[...]

Post by Tom Gundersen
Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).

Thanks for sparing others if not early adopters (nicely demonstrated
like even mere-text-mode-friendly available tooling is dependent on
this single central point these days, NetworkManager/nmtui, even
dhclient complained about DBus, luckily it worked regardless).

Anyway, I've hit another new incompatibility, preventing me to, e.g.,
run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
Workaround is to switch back to dbus-daemon.service.

[Jan Pokorný]

Post by Jan Pokorný

Post by Tom Gundersen

On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

[...]

Post by Tom Gundersen
Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).

Thanks for sparing others if not early adopters (nicely demonstrated
like even mere-text-mode-friendly available tooling is dependent on
this single central point these days, NetworkManager/nmtui, even
dhclient complained about DBus, luckily it worked regardless).
Anyway, I've hit another new incompatibility, preventing me to, e.g.,
run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
Workaround is to switch back to dbus-daemon.service.

This must have been something intermittent, perhaps a fallout from me
trying to deal with a "difficulties to do anything once rebooted after
installing -6 build" as detailed by others in this thread, bug closed.

[Igor Gnatenko]

So I've tried to do following update:
Install dbus-broker-16-7.fc30.x86_64 @rawhide
Upgrade dbus-1:1.12.10-9.fc30.x86_64 @rawhide
Upgraded dbus-1:1.12.10-8.fc30.x86_64 @@System
Upgrade dbus-common-1:1.12.10-9.fc30.noarch @rawhide
Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
Upgrade dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
Upgrade dbus-libs-1:1.12.10-9.fc30.x86_64 @rawhide
Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64 @@System
Upgrade dbus-tools-1:1.12.10-9.fc30.x86_64 @rawhide
Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64 @@System
Upgrade dbus-x11-1:1.12.10-9.fc30.x86_64 @rawhide
Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64 @@System

I ended up with disabled both dbus-daemon and dbus-broker.

Post by Tom Gundersen
Hi Tomasz,

Post by Zbigniew Jędrzejewski-Szmek

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented switch to dubs-broker.

Thanks for the report, and sorry for the inconvenience. There was indeed a bug in the dbus-broker spec file, which we now fixed with version 16-7 (should land in rawhide any minute).

Ps. If this change has been propagated to F29 (hopefully not) more things will be screwed.

It has not (and will not be).
Cheers,
Tom
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/archive

[Tom Gundersen]

Hi Igor,

The upgrade path should hopefully be fixed with dbus-broker-16-8.

Cheers,

Tom

On Wed, Nov 28, 2018 at 10:33 AM Igor Gnatenko <

Post by Igor Gnatenko
I ended up with disabled both dbus-daemon and dbus-broker.

Post by Tom Gundersen
Hi Tomasz,
On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <

On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <

Post by Zbigniew Jędrzejewski-Szmek

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented

switch to dubs-broker.

Post by Tom Gundersen
Thanks for the report, and sorry for the inconvenience. There was indeed

a bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).

Post by Tom Gundersen

Ps. If this change has been propagated to F29 (hopefully not) more

things will be screwed.

Post by Tom Gundersen
It has not (and will not be).
Cheers,
Tom
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Igor Gnatenko]

I don't have time to revert back and try updating again, but the fix looks good!

Thanks!

Post by Tom Gundersen
Hi Igor,
The upgrade path should hopefully be fixed with dbus-broker-16-8.
Cheers,
Tom

Post by Igor Gnatenko
I ended up with disabled both dbus-daemon and dbus-broker.

Post by Tom Gundersen
Hi Tomasz,

Post by Zbigniew Jędrzejewski-Szmek

Post by Tomasz Kłoczko
After last dbus upgrade gdm found that is not able to start.

What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

I’m talking about F30 recent change in which has been implemented switch to dubs-broker.

Thanks for the report, and sorry for the inconvenience. There was indeed a bug in the dbus-broker spec file, which we now fixed with version 16-7 (should land in rawhide any minute).

Ps. If this change has been propagated to F29 (hopefully not) more things will be screwed.

It has not (and will not be).
Cheers,
Tom
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
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/li

[Tomasz Kłoczko]

On Wed, 28 Nov 2018 at 13:44, Igor Gnatenko

Post by Igor Gnatenko
I don't have time to revert back and try updating again, but the fix looks good!

Whoever will be doing dbus upgrade just please do this using commands like below

# dnf upgrade -y --downloadonly dbus\*

than:

# rpm -Uvvvh /var/cache/dnf/rawhide-*/packages/dbus* 2>&1 | tee
~/dbus-upgrade.out

If anything will go wrong just please share ~/dbus-upgrade.out file.
I think that instead download and upgrade using rpm necessary
diagnostics could be done by add more -v to dnf like "dnf upgrade
-yvvv dbus\*"

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorapro