Description of problem: shutdown does not work when given a time in the future. It claims to accept the command but logs in /var/log/messages that the command was not accepted $ sudo /sbin/shutdown -h +2 'go halt' Shutdown scheduled for Mon, 20 Feb 2012 16:40:15 -0800, use 'shutdown -c' to cancel. Yet in /var/log/messages one sees: Feb 20 16:38:15 myhostname systemd-shutdownd[20934]: Received message without credentials. Ignoring. Version-Release number of selected component (if applicable): $ rpm -q -a | grep systemd | sort systemd-37-13.fc16.i686 systemd-sysv-37-13.fc16.i686 systemd-units-37-13.fc16.i686 (is current) $ sudo 'yum' 'update' '-y' Loaded plugins: langpacks, presto, refresh-packagekit Setting up Update Process No Packages marked for Update How reproducible: yes showed this thrice Steps to Reproduce: 1. sudo /sbin/shutdown -h +2 'go halt' 2. 3. Actual results: no halting Expected results: halting Additional info: The noun "now" works just fine! $ sudo /sbin/shutdown -h now 'go halt'
(In reply to comment #0) > $ rpm -q -a | grep systemd | sort > systemd-37-13.fc16.i686 > systemd-sysv-37-13.fc16.i686 > systemd-units-37-13.fc16.i686 Did you boot with these versions already installed, or have you just recently updated the packages?
Created attachment 564709 [details] sudo grep -Eie '(imklog|restart|yum|shutdown)' /var/log/messages The procedure was: - install F16 - yum update -y - exhibit problem - yum update -y (actuality shown in the original report, no updates possible) - file bug There are some relevant lines from /var/log/messages that show the history. It's an attachment because it's gratuitously long. The machine was built 2012-02-20 15:30 or so. The relevant lines are: Feb 20 15:36:33 suffragor yum[2065]: Updated: systemd-37-13.fc16.i686 Feb 20 15:36:34 suffragor yum[2065]: Updated: systemd-units-37-13.fc16.i686 Feb 20 15:36:35 suffragor yum[2065]: Updated: systemd-sysv-37-13.fc16.i686 ... Feb 20 16:34:13 suffragor systemd-shutdownd[20597]: Received message without credentials. Ignoring. Feb 20 16:36:01 suffragor systemd-shutdownd[20891]: Received message without credentials. Ignoring. Feb 20 16:38:15 suffragor systemd-shutdownd[20934]: Received message without credentials. Ignoring. The machine is at runlevel3, I'm on the remotely box via ssh -Y -A suffragor gnome-terminal
Is it still broken after reboot? I see kernel-PAE-3.2.6-3.fc16.i686 was installed in the yum transaction, but I do not see what the currently running kernel version was at the time. Could you find it out from the logs?
heh ... works now. 3.1.0-7.fc16.i686.PAE was running at the time of the report 3.2.6-3.fc16.i686.PAE was installed with the massive yum update 3.2.6-3.fc16.i686.PAE is running now shutdown worked as expected now. From before $ sudo grep -Eie '(Linux.*version|restart|shutdown)' /var/log/messages | tail -30 Feb 20 15:04:55 suffragor kernel: [ 0.000000] Linux version 3.1.0-7.fc16.i686.PAE (mockbuild.fedoraproject.org) (gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) ) #1 SMP Tue Nov 1 20:53:45 UTC 2011 Feb 20 15:13:06 suffragor ntpd[1497]: 0.0.0.0 c016 06 restart Feb 20 15:13:17 suffragor root: t.start-rsyslog fixes up and restarts rsyslog at 2012-02-20 15:13:17-08:00 Feb 20 15:40:35 suffragor ntpd[5340]: 0.0.0.0 c016 06 restart Feb 20 16:34:13 suffragor systemd-shutdownd[20597]: Received message without credentials. Ignoring. Feb 20 16:36:01 suffragor systemd-shutdownd[20891]: Received message without credentials. Ignoring. Feb 20 16:38:15 suffragor systemd-shutdownd[20934]: Received message without credentials. Ignoring. Feb 20 17:06:12 suffragor kernel: [ 0.000000] Linux version 3.2.6-3.fc16.i686.PAE (mockbuild.fedoraproject.org) (gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) ) #1 SMP Mon Feb 13 20:44:23 UTC 2012 Feb 20 17:13:38 suffragor ntpd[1200]: 0.0.0.0 c016 06 restart From just now with 3.2.6-3.fc16.i686.PAE running. $ sudo shutdown -r +2 'see of shutdown works' Shutdown scheduled for Tue, 21 Feb 2012 20:07:13 -0800, use 'shutdown -c' to cancel. wbaker:wbaker@suffragor [wbaker] [l1 u0002 ssh] [F16 Verne] ~ $ Broadcast message from root@suffragor (Tue, 21 Feb 2012 20:05:13 -0800): see of shutdown works The system is going down for reboot at Tue, 21 Feb 2012 20:07:13 -0800! paf! gone. /var/log/messages says ... Feb 21 20:05:13 suffragor systemd-shutdownd[16540]: Creating /run/nologin, blocking further logins... Feb 21 20:07:13 suffragor ip6tables.init[16697]: ip6tables: Flushing firewall rules: [ OK ] Feb 21 20:07:13 suffragor ip6tables.init[16697]: ip6tables: Setting chains to policy ACCEPT: filter [ OK ] Feb 21 20:07:13 suffragor iptables.init[16698]: iptables: Flushing firewall rules: [ OK ] Feb 21 20:07:13 suffragor iptables.init[16698]: iptables: Setting chains to policy ACCEPT: filter [ OK ] Feb 21 20:07:13 suffragor ntpd[1200]: ntpd exiting on signal 15 Feb 21 20:07:13 suffragor kernel: Kernel logging (proc) stopped. Feb 21 20:07:13 suffragor rsyslogd: [origin software="rsyslogd" swVersion="5.8.7" x-pid="979" x-info="http://www.rsy slog.com"] exiting on signal 15. Feb 21 20:08:45 suffragor kernel: imklog 5.8.7, log source = /proc/kmsg started. Feb 21 20:08:45 suffragor rsyslogd: [origin software="rsyslogd" swVersion="5.8.7" x-pid="986" x-info="http://www.rsy slog.com"] start Feb 21 20:08:45 suffragor dbus[983]: [system] Activating systemd to hand-off: service name='org.freedesktop.NetworkM anager' unit='dbus-org.freedesktop.NetworkManager.service' Feb 21 20:08:45 suffragor avahi-daemon[973]: Successfully called chroot(). Feb 21 20:08:45 suffragor avahi-daemon[973]: Successfully dropped remaining capabilities. Feb 21 20:08:45 suffragor avahi-daemon[973]: Loading service file /services/ssh.service. Feb 21 20:08:45 suffragor dbus-daemon[983]: dbus[983]: [system] Activating systemd to hand-off: service name='org.fr eedesktop.NetworkManager' unit='dbus-org.freedesktop.NetworkManager.service' Feb 21 20:08:45 suffragor avahi-daemon[973]: Loading service file /services/udisks.service. Feb 21 20:08:45 suffragor avahi-daemon[973]: Network interface enumeration completed. Feb 21 20:08:45 suffragor systemd-logind[969]: New seat seat0. Feb 21 20:08:45 suffragor avahi-daemon[973]: Registering HINFO record with values 'I686'/'LINUX'. Feb 21 20:08:45 suffragor kernel: [ 0.000000] Initializing cgroup subsys cpuset Feb 21 20:08:45 suffragor avahi-daemon[973]: Server startup complete. Host name is suffragor.local. Local service co okie is 1768976140. Feb 21 20:08:45 suffragor avahi-daemon[973]: Service "suffragor" (/services/udisks.service) successfully established . Feb 21 20:08:45 suffragor dbus[983]: [system] Successfully activated service 'org.freedesktop.systemd1' Feb 21 20:08:45 suffragor kernel: [ 0.000000] Initializing cgroup subsys cpu Feb 21 20:08:45 suffragor kernel: [ 0.000000] Linux version 3.2.6-3.fc16.i686.PAE (mockbuild.fedorapr oject.org) (gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) ) #1 SMP Mon Feb 13 20:44:23 UTC 2012 Feb 21 20:08:45 suffragor kernel: [ 0.000000] BIOS-provided physical RAM map: problem solved.
It's an unfortunate transitional problem caused by SO_PASSCRED not being set when systemd is updated to systemd-37-11.fc16 from a previous F16 build. It would be set if systemd-shutdown.socket were restarted in the process. I may add that to the scriptlets.
*** Bug 796471 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > It's an unfortunate transitional problem caused by SO_PASSCRED not being set > when systemd is updated to systemd-37-11.fc16 from a previous F16 build. It > would be set if systemd-shutdown.socket were restarted in the process. I may > add that to the scriptlets. Is there something we can do on a machine in that state to fix it?
This should work: systemctl stop systemd-shutdown.service systemctl restart systemd-shutdown.socket
systemctl showed that systemd-shutdown.service was not running anyway, so only the second line was needed. Thank you very much.
(In reply to comment #5) > It's an unfortunate transitional problem caused by SO_PASSCRED not being set > when systemd is updated to systemd-37-11.fc16 from a previous F16 build. It > would be set if systemd-shutdown.socket were restarted in the process. I may > add that to the scriptlets. I had the problem on kernel 2.6.42.3-2.fc15.x86_64, does that mean the scriptlet change needs to be back ported?
Michal, we probably could call socket_apply_socket_options() (and friends) when taking possession of deserilized sockets in socket.c. THis would fix this specific problem?
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Proposed as a Blocker for f24-beta by Fedora user mkrizek using the blocker tracking app because: Test
I don't see this in F-36.