Description of problem: "yum upgrade" left a mess for initscripts. The message "Job failed, see logs for details." does not give the filesystem pathname, nor the logical name of _which_ log. So I had to guess where to look. Syslog (/var/log/messages in my case) has many many complaints relating to init. /var/log/yum.log has nothing notable. Anywhere else? Version-Release number of selected component (if applicable): initscripts-9.17-2.fc14.i686 libini_config-0.6.0-21.fc14.i686 How reproducible: haven't tried Steps to Reproduce: 1. yum upgrade 2. 3. Actual results: "Job failed, see logs for details." on gnome-terminal. syslog (/var/log/messages) has: ----- kernel: init[1]: Reloading. init[1]: [/lib/systemd/system/shutdown.target:12] Unknown lvalue 'RefuseManualStart' in section 'Unit'. Ignoring. init[1]: [/lib/systemd/system/systemd-update-utmp-shutdown.service:15] Failed to parse service type: oneshot init[1]: Failed to load configuration for systemd-update-utmp-shutdown.service: Bad message init[1]: [/lib/systemd/system/systemd-update-utmp-runlevel.service:16] Failed to parse service type: oneshot init[1]: Failed to load configuration for systemd-update-utmp-runlevel.service: Bad message kernel: init[1]: [/lib/systemd/system/shutdown.target:12] Unknown lvalue 'RefuseManualStart' in section 'Unit'. Ignoring. kernel: init[1]: [/lib/systemd/system/systemd-update-utmp-shutdown.service:15] Failed to parse service type: oneshot kernel: init[1]: Failed to load configuration for systemd-update-utmp-shutdown.service: Bad message kernel: init[1]: [/lib/systemd/system/systemd-update-utmp-runlevel.service:16] Failed to parse service type: oneshot kernel: init[1]: Failed to load configuration for systemd-update-utmp-runlevel.service: Bad message init[1]: [/lib/systemd/system/plymouth-quit.service:14] Failed to parse service type: oneshot init[1]: Failed to load configuration for plymouth-quit.service: Bad message kernel: init[1]: [/lib/systemd/system/plymouth-quit.service:14] Failed to parse service type: oneshot kernel: init[1]: Failed to load configuration for plymouth-quit.service: Bad message ----- and many more related lines. Expected results: No failure. Upon failure, then "see logs" must give the logical name of _which_ log, and the physical name (rooted filesystem pathname) if known. Additional info:
check /var/log/boot.log for boot log messages. Add all messages related you find as attachment in this bug. It seems a systemd problem. Thanks for your report. -- Fedora Bugzappers Team Member
/var/log/boot.log isn't helpful. First, it omits the boot date and time! How do I know which boot? Second, some boots are missing, even from all former logs: ----- $ ls -l boot* -rw-r--r--. 1 root root 3973 Aug 27 05:42 boot.log # TZ=PST8PDT -rw-r--r--. 1 root root 1564 Aug 1 05:18 boot.log-20100801 -rw-r--r--. 1 root root 2921 Aug 10 11:17 boot.log-20100810 -rw-r--r--. 2 root root 1504 Aug 16 06:44 boot.log-20100816 -rw-r--r--. 1 root root 1199 Aug 22 10:09 boot.log-20100822 $ ----- Note that there is nothing for yesterday Aug.26 (I reboot at least once per day, often more.)
Does 'systemctl daemon-reexec' fix this for you? (What version of systemd do you have installed?)
# systemctl daemon-reexec # No complaints, no output # rpm -q systemd systemd-8-2.fc14.x86_64 # Now I'll re-boot. At boot I have been seeing much more debug text (before graphical X11). However things have been "working" about as well as usual, so I'm unsure about what a "fix" would look like.
Now I'm back after reboot. Things looked the same at this boot as at the one immediately before that: about 3 or 4 times as many lines of text on VGA console as last week; Fedora 14 pre-Alpha then [branched, not rawhide], Alpha now.
OK. Given that things are more or less functioning, assigning to systemd re: the initial complaint about the 'Job failed...' message.
The log output you posted looks as if you were using an old systemd-units package with a new systemd binary. This should normally not happen. Could you make sure you have correctly installed systemd and systemd-units 8-3 packages? Can you reproduce things with that and attach the init logs from /var/log/messages and dmesg again? Thanks,
The "presenting symptom" of this bug is a Usability error. The error message "see logs for details" is not helpful because it does not specify _which_ log(s), nor give a hint as to the common location of those logs. Instead, the message should give the logical name of the log(s), something like, "Consult syslog for details; the default location for syslog is the file /var/log/messages." Is there any other log to check besides syslog? The error message can be improved independent of the Functionality (what actually happened to my box.) The current package configuration of my box is: systemd-8-3.fc14.x86_64 systemd-units-8-3.fc14.x86_64 This box began as Fedora 13 through the rawhide, alpha, and beta of F-13. Then as soon as F-13 was released, I converted the box to F-14 rawhide by changing the repos and doing "yum update". The box has been F-14 rawhide, F-14 branched, now F-14 alpha. In order to get the logs that I filed with this bug, I did nothing other than "yum update", possibly with --skip-broken and --exclude of some packages because yum complained about those packages. Thus the question of "correctly installed" is between yum and systemd*; I did nothing [that I know] to disturb that part of the situation. Nevertheless, the pedigree of evolution from F-13 rawhide to today's F-14 alpha might suggest that the box could have had some strange package configurations at some times. After I filed this bug, then I tried many different things to get something usable. There have been at least three "successful" runs of "yum update" after I filed this bug. Today the box boots "normally" except that I see two or three times as many lines on VGA console during boot as I used to see about a week or ten days ago. The extra lines look like debug info from many different packages. Thus, I cannot reproduce the Functionality problem of seeing all those init[1] messages in syslog. The Functionality part of this bug probably should be closed as "Works for me". But please fix the Usability part about a better error message before closing. Thank you.
What is behind syslog very much depends on configuration. Often it is /var/log/messages, but not always. And even the default configuration for syslog we ship might cause messages from systemd to be distributed among multiple log targets. Then, on other distributions most logging from systemd might actually end up in /var/log/daemon.log. Thus I am a little bit reluctant to refer to an explicit log file, since it really depends on the system where things go. Then, there's the other little problem that you can actually redirect the systemd logs to the kernel log buffer (kmsg) by a config file change or a kernel parameter. That means referring to "syslog" is also a bit misleading, since quite often it might actually never be there, but in the kernel log buffer. And I am against writting out different error messages depending on log configuration. I have now changed terminology in systemd git to "system logs" instead of just "logs". I hope this term is a generic enough to cover both kmsg and syslog, but still explicit enough to make clear that this is not a systemd-specific log file, but something directly related to the system itself. I hope this settles this bug.
systemd-9-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-3.fc14, initscripts-9.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.18-1.fc14
initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.