Shutdown[1]: Failed to wait for process: Protocol error

Same results for me as @xabbu, 238.0-4 doesn’t crash but does still fail to deactivate all LUKS partitions during systemd shutdown process.

1 Like

For me with one partition it seems to work - / comes back up as clean

My encrypted partions come up as well. I didn’t noticed any real problem at the mount process.

Can you check the journal messages form you last boot? For example

journalctl -e -b-1 

if you have a persistent journal. You can also use -2 and so on for older boots.

Thats the end of my last shutdown (got with your specified comand):

Mär 14 21:16:50 hk-01 systemd[1]: Stopped Load/Save Screen Backlight Brightness of leds:tpacp>
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Load/Save Random Seed.
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Update UTMP about System Boot/Shutdown.
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Load/Save Screen Backlight Brightness of backlight:>
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Create Volatile Files and Directories.
Mär 14 21:16:50 hk-01 systemd[1]: Stopped target Local File Systems.
Mär 14 21:16:50 hk-01 systemd[1]: Unmounting Temporary Directory (/tmp)...
Mär 14 21:16:50 hk-01 systemd[1]: Unmounting /run/user/1000...
Mär 14 21:16:50 hk-01 systemd[1]: Unmounting /boot/efi...
Mär 14 21:16:50 hk-01 systemd[1]: Removed slice system-systemd\x2dbacklight.slice.
Mär 14 21:16:50 hk-01 systemd[1]: Unmounted /run/user/1000.
Mär 14 21:16:50 hk-01 systemd[1]: Unmounted /boot/efi.
Mär 14 21:16:50 hk-01 systemd[1]: Stopped target Local File Systems (Pre).
Mär 14 21:16:50 hk-01 systemd[1]: Stopping Monitoring of LVM2 mirrors, snapshots etc. using d>
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Create Static Device Nodes in /dev.
Mär 14 21:16:50 hk-01 systemd[1]: Unmounted Temporary Directory (/tmp).
Mär 14 21:16:50 hk-01 systemd[1]: Stopped target Swap.
Mär 14 21:16:50 hk-01 systemd[1]: Deactivating swap /swapfile...
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dm>
Mär 14 21:16:50 hk-01 systemd[1]: Stopping LVM2 metadata daemon...
Mär 14 21:16:50 hk-01 systemd[1]: Stopped LVM2 metadata daemon.
Mär 14 21:16:50 hk-01 systemd[1]: Deactivated swap /swapfile.
Mär 14 21:16:50 hk-01 systemd[1]: Reached target Unmount All Filesystems.
Mär 14 21:16:50 hk-01 systemd[1]: Stopped Remount Root and Kernel File Systems.
Mär 14 21:16:50 hk-01 systemd[1]: Reached target Shutdown.
Mär 14 21:16:50 hk-01 systemd[1]: Reached target Final Step.
Mär 14 21:16:50 hk-01 systemd[1]: Starting Reboot...
Mär 14 21:16:50 hk-01 systemd[1]: Shutting down.
Mär 14 21:16:50 hk-01 systemd[1]: Hardware watchdog 'iTCO_wdt', version 0
Mär 14 21:16:50 hk-01 systemd[1]: Set hardware watchdog to 10min.
Mär 14 21:16:50 hk-01 kernel: watchdog: watchdog0: watchdog did not stop!
Mär 14 21:16:50 hk-01 kernel: systemd-shutdow: 33 output lines suppressed due to ratelimiting
Mär 14 21:16:50 hk-01 systemd-shutdown[1]: Syncing filesystems and block devices.
Mär 14 21:16:50 hk-01 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Mär 14 21:16:50 hk-01 systemd-journald[320]: Journal stopped
~

That looks good. You can also use your up arrow key to scroll to older entries, but I don’t expect that you find anything.

So it only affects mounts in /etc/crypttab. At least for me, I have 3 luks encrypted partitions. 2 of them are mounted with an entry in crypttab. And I see only 2 error messages in my journal.

1 Like

@xabbu, @sueridgepipe, @Th3Z0ne: please add your information also to the new pull so it may get properly fixed.

@xabbu: to find your issue, I might need your help after all.

  • please boot with printk.devkmsg=on loglevel=7 to get a full log
  • try package systemd v238.0-2, to see if there is no regression with it
  • try package systemd v238.0-3 and add lines 67 - 73 one by one to find the culprint. You may use the patch from systemd v238.0-4 as needed.

However, you should make sure if your issue was introduced with v238.0 or with one of the additional patches added by me.

Actually it seems the problem is way older or has nothing to do with systemd.
I looked this time a little bit more careful thru older journalctl boots. My oldest one is from February 8 with systemd 236. It also has the cryptsetup error lines.

The oldest systemd which I could install with downgrade was 235.38-4. It has the same errors after two shutdowns. Older binary versions of systemd need cryptsetup 1.7.5.

Maybe the real problem is actually the upgrade form cryptsetup 1.7.5 to cryptsetup 2.0?

I built cryptsetup 1.7.5-2 and then built systemd 380.0-4 against cryptsetup 1. No error messages after 4 shutdowns and a reboot.

Btw, systemd doesn’t like the new libgpg-error 1.28, had to downgrade to 1.27 to successfully build systemd.

1 Like

Very good find, looking through my pacman logs and journal logs I can confirm your finding.

Date of cryptsetup upgrade.

[2017-12-14] [ALPM] upgraded cryptsetup (1.7.5-2 -> 2.0.0-1)

Next day my first cryptsetup deactivation failure messages during shutdown occurred, one message per encrypted device in crypttab.

Dec 15 manjaro systemd-cryptsetup[1082]: Failed to deactivate: Device or resource busy
Dec 15 manjaro systemd-cryptsetup[1084]: Failed to deactivate: Device or resource busy
Dec 15 manjaro systemd-cryptsetup[1083]: Failed to deactivate: Device or resource busy

That’s some good Sherlocking.

So systemd-shutdown processing of encrypted devices doesn’t look like it caters for changes introduced in cryptsetup 2.0.

Maybe report it upstream then and check if some is already reported in the arch bugtracker or/and systemd upstream

@xabbu, @Th3Z0ne, @sueridgepipe: please open a new issue for the cryptsetup thing …

keszybz commented 21 minutes ago

Hmm, I see this error in my shutdown log too. Please open a new issue so we can gather all the info.

I created a new issue

3 Likes

@xabbu: can you update the issue so upstream can work on a fix?

Well I’ve just started getting this shutting down errors on Arch testing the last few days I don’t have encryption, running systemd 238.0.1 kernel 4.15.10-1 if that’s any help

@sueridgepipe can you try this workaround on your system too?

add to your mounts in fstab the option x-systemd.requires=systemd-cryptsetup@XX.service

Replace the XX with the name you used in your crypttab for this LUKS device.

You can also look at the github issue report for a better example.

Please test if we didn’t add any regressions with systemd v238.51-1

No Problems with 238.51-1.1 on my systems.

Can also confirm - 238.51-1.1 - is fine with me.

Thx for confirming that we didn’t add any new regressions to Systemd.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by