Vivid switched to systemd, so this isn't a problem there any more. I
added an open utopic task, as that's still affected.
** Also affects: systemd (Ubuntu Utopic)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Utopic)
Status: New => Triaged
** Changed in: syste
I also experienced a blocked system every time i shutdown or reboot my
Dell Latitude 6530 with ubuntu 14.10 (64bit), after upgrading from
14.04). If i remove the "quiet splash" kernel option from the grub menu,
the last message seen is "wait-for-state stop/waiting".
After installing "systemd-sysv"
This can also be reproduced in QEMU by issuing "system_powerdown" twice
in quick succession in the monitor.
** Changed in: systemd (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
Yes, per IRC, this is more or less the expected behavior of both systemd
(logind) and upstart (poweroff). It's only the emergent behavior
combined with a buggy kernel/hardware button behavior that's surprising.
As noted on IRC, there are three possible solutions:
1) get the kernel fixed to not p
As you mentioned in IRC, this is probably just documented behavior. From
reboot(8):
When called with --force or when in runlevel 0 or 6, this tool invokes
the reboot(2) system call itself (with REBOOTCOMMAND argument passed)
and directly reboots the system. Otherwise this
You're right, it is calling /sbin/poweroff, I made a wrapper to see what
was going on there as you suggested. While using the wrapper (to prevent
an actual poweroff), I noticed:
- 'udevadm monitor -e' logs no events
- No arguments are supplied to /sbin/poweroff
- '/sbin/poweroff' gets called multi
Ok. I don't have a theory as to what would be short-circuiting the tail
end of /etc/rc0.d for this case. As far as I can see, logind just calls
'poweroff', which should do the right thing - and certainly, sendsigs
should always be followed by umountnfs.sh, networking, umountfs,
umountroot, and {h
On Mon, Jul 28, 2014 at 3:46 PM, Steve Langasek
wrote:
> Dann, what upstart services fail to be shut down? The last messages
> shown in your log are from /etc/init.d/sendsigs and /etc/init.d/reboot,
> which on an upstart system are only ever called via /etc/init/rc.conf,
> systemd notwithstanding.
Dann, what upstart services fail to be shut down? The last messages
shown in your log are from /etc/init.d/sendsigs and /etc/init.d/reboot,
which on an upstart system are only ever called via /etc/init/rc.conf,
systemd notwithstanding.
** Changed in: systemd (Ubuntu)
Status: New => Incomple
