Traceback (most recent call last): File "/usr/bin/systemd-analyze", line 99, in <module> data = acquire_time_data() File "/usr/bin/systemd-analyze", line 7, in acquire_time_data manager = dbus.Interface(bus.get_object('org.freedesktop.systemd1', '/org/freedesktop/systemd1'), 'org.freedesktop.systemd1.Manager') File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 244, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 246, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 183, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 281, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
Steps to Reproduce: 1. Clean install 2. apply all updates and reboot 3. Click up a terminal 4. su - root 5. systemd-analyze blame
Severity: normal => critical
Source RPM: (none) => systemd-37-13.mga2.src.rpm
Hi, thanks for reporting this bug. Assigned to the package maintainer. (no need to add 2_alpha1, in fact the alpha is cauldron ;) )
Blocks: (none) => 2120Summary: 2_alpha1: systemd-analyze blame => systemd-analyze blameKeywords: (none) => Triaged
If may remark this humbly: systemd-analyze is not needed for systemd, so I'm not sure 2120 should depend on current bug?
CC: (none) => dvgevers
(In reply to comment #3) > (no need to add 2_alpha1, in fact the alpha is cauldron ;) ) Heheh, I know, I use it to show which release and phase the problem showed up. When we get to release 3 and still see a 2_alpha1 tag we will know it is not a cauldron 3 problem. ;) I felt a little sad when I saw them being removed. It also helps to see something like this critical bug still open in an Official release but showing as a cauldron bug. :( That assumes all open cauldron bugs will not be converted from cauldron to 2 upon release day. (In reply to comment #2) > If I may remark this humbly: systemd-analyze is not needed for systemd, I am not sure what you mean. If I have indicated the wrong src rpm. I apologize. If you mean not required for Official release. I suggest that may be a mistake. Reason I opened the bug was because my clean install alpha1 install with all updates plus a raft of other packages now cause my boot to take 4+ minutes before I can get a prompt in runlevel 3. Bug https://bugs.mageia.org/show_bug.cgi?id=3581 is not helping the troubleshooting process. I am also getting a nasty problem from udevd about /run/dev is not writable. :( Only recourse at this time is yet another clean install, check boot, apply solution found in https://bugs.mageia.org/show_bug.cgi?id=3580, check boot, then add my additional packages again. To see if /run/dev problem still exists.
What I eman is systemd-analyze is not an rpm-required package for systemd to run (or be installed): I do not have the package on Cauldron. So any other good arguments notwithstanding, IMHO this particular bug can't be a required fix for #2120.
Hey you have not see that I have forget to assign the bug ! :) >What I eman is systemd-analyze is not an rpm-required package for systemd to >run (or be installed) If devs want's to remove the blocker, do with that
Assignee: bugsquad => dmorganec
(In reply to comment #6) > Hey you have not see that I have forget to assign the bug ! :) > > >What I eman is systemd-analyze is not an rpm-required package for systemd to > >run (or be installed) > > If devs want's to remove the blocker, do with that Hmmm, wondering where the confusion is. As I misunderstand it, Severity=Critical means the application (systemd-analyze) will not run. As far as blocking the transition to Official, the Priority=Release_blocker determines that it holds up system release.
(In reply to comment #7) > Hmmm, wondering where the confusion is. As I misunderstand it, > Severity=Critical means the application (systemd-analyze) will not run. > > As far as blocking the transition to Official, the Priority=Release_blocker > determines that it holds up system release. I was spoken about that's one: https://bugs.mageia.org/show_bug.cgi?id=3577#blocked_edit_action ;) If I read our guide (https://wiki.mageia.org/en/Triage_guide#Severity) , here it's more a normal/major bug (but indeed, personnly I don't look carefully this one :/ ) It's also written in the "official" bugzilla doc https://bugs.mageia.org/page.cgi?id=fields.html#importance (another doc to enhance... https://wiki.mageia.org/en/Bugzilla :) ) (Yes off topic, but if some people read bugs@ and don't know what to do :D)
Severity: critical => major
According to the Triage Guide, I have to agree with Dick Gevers that I am at fault. Just finished another clean install, added fglrx package and system takes 10 minutes 58 seconds to get to login prompt. :( According to the guide I should mark it down to Trivial. :-( I do appreciate you and Gevers time spent showing me what is right.
Severity: major => normal
:) don't grovel: no need. And fglrx probably lacked dkms status, so it would be 1st boot only that you suffer such delay - but now I'm off topic. Good luck.
Aaargh :( In comment #10 I removed myself from cc, but Bugzilla changed severity without my doing.
Severity: critical => normal
(In reply to comment #10) > I removed myself from cc, but Bugzilla changed severity without my doing. Nope, I changed it to Normal per the guideline. (In reply to comment #10) > :) don't grovel: no need. Not groveling, :) just owning up to, it was my fault. :-D > And fglrx probably lacked dkms status, so it would be > 1st boot only that you suffer such delay - but now I'm off topic. Good luck. No you are on topic. I made 4 test boots to rule out my three custom kernel arguments were not causing the problem. Times were 10:49, 11:00, 11:00, 10:58 Oddly enough Severity=Critical may have been correct but is not systemd's fault. I will be closing my systemd bugs 3581, 3577 and not create one about "/run/dev is not writable.". Reason, I found a solution to the problems. I saw the same thing in Mandriva Cooker for 2011 release. Constant weird problems seemed to be only found by me. My WAG was they were caused by rpm 5.x. Now I believe the problem is also in this rpm version. :( Solution: clean install, apply updates, install fglrx. Without fglrx I cannot have sound. Boot times for the solution are 2:14 after clean install, 1:41 after updates, 3:42 after fglx systemd-analyze blame now works, boot.log has console messages, /run/dev was writable until I installed fglrx.
Status: NEW => RESOLVEDResolution: (none) => FIXED