Originally posted by danieru
View Post
Announcement
Collapse
No announcement yet.
Fedora 24 Users: Don't Run "DNF Update" From The Desktop
Collapse
X
-
-
Originally posted by mbohun View Post
- Likes 1
Comment
-
Originally posted by AdamW View Post
There's nothing terribly systemd-ish about the issue; the service just runs a couple of udevadm commands, which existed long before udev was moved into systemd. You can equally well reproduce the issue by running `udevadm trigger --type=devices --action=add` , it's just longer to type and harder to remember...
Comment
-
Originally posted by NotMine999 View PostWhy does this Fedora "behavior" for DNF strike me as "poor quality control" and something that should be caught during pre-release product testing?
I would have instructed the programmers to either: give me a "fix"; deny DNF from working via the desktop ("a workaround"); or, delayed the release of the product rather than introduce a flaw (call it a "feature" if you wish) that might damage the reputation of the product.
Comment
-
Anything you see from Zbyszek in that bug report is just as 'official' as anything you see from Lennart, since Zbyszek is a core systemd maintainer as well. They are discussing the situation there.
Comment
-
a little recap:
1. a problem is reported
2. all available evidence points (once again obviously) to a bug/problem in systemd
3. however the pro-systemd hecklers/zealots (in general they are illiterate) unable to tell the diff between tech start the usual lies and mindless denial:
Originally posted by AdamW View Post
There's nothing terribly systemd-ish about the issue; the service just runs a couple of udevadm commands, which existed long before udev was moved into systemd. You can equally well reproduce the issue by running `udevadm trigger --type=devices --action=add` , it's just longer to type and harder to remember...
Lennart Poettering 2016-10-04 18:15:46 EDT
Nah, "udevadm trigger" is an operation that should always be safe. Software (be it apps or drivers) that cannot deal with such a replug is broken, and needs to be fixed.
We have been retriggering udevadm either fully or only specific subsystems since about always. If X11 is broken now with that it needs to be fixed really.
I don't see anything to change in systemd here. Sorry.
Zbigniew Jędrzejewski-Szmek 2016-10-04 18:33 EDT
journalctl -f logs from udevadm trigger --type=devices --action=add The issue is not caused by udevadm trigger --type=devices --action=add directly, but through systemd-logind. If systemd-logind is SIGSTOPed, nothing happens. If systemd-logind is running normally there is a bunch of remove/add events logged by Xorg (see) attachment. systemd-logind doesn't log anything, even at debug level unfortunately. I think it should at least log when it adds/removes devices. I also don't think it should remove the devices from clients, even temporarily. I would expect this to cause glitches at least.
- Likes 1
Comment
-
Originally posted by AdamW View Post
Anything you see from Zbyszek in that bug report is just as 'official' as anything you see from Lennart, since Zbyszek is a core systemd maintainer as well. They are discussing the situation there.
Comment
Comment