You are not logged in.
I upgraded the system earlier and there were a lot of updated packages on account of an update to lots of the KDE stuff. When I tried to reboot the machine, the shutdown hung at the point where it tries to unmount the swap partition (which is an LVM volume in an encrypted LUKS container). It kept saying there as a "stop job" on that volume (referenced in multiple different ways e.g. as mapped, by UUID etc.). It also complained that it could not unmount /var. In the end I shut it off with the power button. There's nothing in the logs because I assume the journal had been stopped at that point. fsck did some clean up on at least the root volume on reboot.
Is there anything I missed which I should have taken care of? That is, have I missed a needed update change somehow? Or is this just random blather? Almost everything updated was KDE (and one of bohoomil's fontconfig packages) so it seems weird if that affected the system handling of swap.
EDIT: I should have made clear that normally the system reboots fine and I've not made any configuration changes. So I'm wondering if I've missed a needed change rather than missed something needed for my setup when I originally configured it. (E.g. I've got the shutdown hook etc. in the initramfs - the usual stuff which is needed for a clean shutdown with lvm-on-luks.)
Last edited by cfr (2013-09-11 01:01:28)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Yep, I have the same issue but it happens very rarely, sometimes if I have teamviewerd running the shutdown takes longer but it doesn't fail to shut down, (but of course an application of user-space couldn't prevent the system from shutting down)...
To think about the issue, are very few processes who cold prevent the system from hanging, and umount is one of those..
1 ) I would debug more the "why" umount fails on unmounting the partitions analysing carefully the logs
2) would check also the stauts of the hardisk and the HDD for I/O errors - just in case - .
3) Before reboot, lsof everything and try understanding which process could prevent the partition from unmounting , or you can try killing them 1 by 1 until you see which one of them is "unkillable" which could work out on discovering the core cause.
The other thing I may try is shutting down with init 0 - if changes anything - however would go for option 1,2 ,3 to understand what's the problem.
Offline
That seems like a rather different issue. My shutdown time also varies depending on what is running at the time. That seems only to be expected.
1) As I explained, the logs are no help - the journal has been closed before the hang.
2) smart monitors the disks and there's nothing unusual - all the tests pass etc. - and nothing odd in the logs.
3) Thanks. If I ever have the problem regularly, I'll try to remember this. As it is, it happened once and I obviously didn't expect it so didn't investigate beforehand.
As for init, init is just a symbolic link to systemd now
.
Thanks for all the suggestions.
Last edited by cfr (2013-09-11 21:20:18)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
same issue with transmission
Offline
The same issue as what?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
for bel3atar it's probably a variant of the bug report FS#37007
https://bugs.archlinux.org/task/37007?p … &sort=desc
with systemd 207 there is sometimes a weird delay on shutdown/reboot, systemd seems to have difficulties to shutdown properly some processes or services, the conditions that trigger this bug are not clear, making it difficult to debug,
downgrading to systemd 203 ( or 204 ) can resolve this problem ( the patch in the bug report FS#37007 doesn't solve the problem on my PC )
Last edited by Potomac (2013-09-26 06:19:01)
Offline