Announcement

Collapse
No announcement yet.

Fedora 24 Users: Don't Run "DNF Update" From The Desktop

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by danieru View Post

    Lies, I would have had experienced at least once or heard about it, if it was true with any package manager.
    The general category of bug can affect any traditional package manager (as opposed to new-gen stuff like ostree, flatpak, snappy etc, which are usually designed differently). This specific bug has distro-specific elements, it's likely it wouldn't affect all distros.

    Comment


    • #32


      I confirm my system, an AMD/AMD hybrid graphics powered laptop, is affected by executing 'systemctl restart systemd-udev-trigger.service' as root on desktop. The desktop session crashed and the login screen comes afterwards.
      systemd :-) no surprise there.

      Comment


      • #33
        Originally posted by mbohun 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


        • #34
          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...
          You could say "Hitting your laptop with a hammer could crash the hard-drive and systemd", and the anti-systemd trolls would exclaim "Aha, so systemd is crashing again!" without bothering to understand the real cause.

          Comment


          • #35
            Originally posted by NotMine999 View Post
            Why 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.
            well, on one hand fedora is a bleeding edge distribution with plenty of novel tech in each release. But i can agree that introducing dnf was a mistake and should have been put off for a few releases, seeing as embarrassing mistakes pop up quite often related to it.

            Comment


            • #36
              > sudo systemctl restart systemd-udev-trigger.service

              Didn't crash Weston (on an AMD Llano APU), but it did spin up all my disks!

              Comment


              • #37
                Originally posted by yturmisil
                AdamW,
                You know it's possible to provide a correction without sounding like a gigantic jackass, right?

                Comment


                • #38
                  Originally posted by bofh80
                  Official systemd response "Nah" . . . "I don't see anything to change in systemd here. Sorry."


                  Wonder which package ends up with the change / fix.
                  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


                  • #39
                    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...
                    or


                    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.
                    4. only to admit couple of hours later that yes indeed the problem is with systemd

                    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.
                    5. a new version of systemd is being released:


                    Comment


                    • #40
                      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

                      Working...
                      X