You are not logged in.
Hi.
Since the last update I get this error several times at shutdown:
shutdown[1]: Failed to wait for process: Protocol error
It seems to be related to systemd version 237.0, as I downgraded systemd to version 236.81 and it doesn't show the error.
I also tried systemd 237.0 with linux kernel 4.14.13 (the previous one) and it shows the error as well, so it must be related to systemd somehow.
Is this happening to somebody else? Is it a bug with systemd or could there be something wrong with my system?
Thank you so much!
Last edited by unnilquadium (2018-06-17 09:08:53)
Offline
I also see the message upon shutdown process.
Offline
FYI, It happened to me. We should report it to Arch bug tracker or systemd github.
What you know about computing other people will learn. Don't feel as if the key to successful
computing is only in your hands. What's in your hands, I think and hope, is intelligence:
the ability to see the machine as more than when you were first led up to it, that you can make it more.
—Alan J. Perlis (April 1, 1922 – February 7, 1990)
Offline
same error for me, someone should create a bug report
https://reho.st/self/b473b21a19ca201225 … 0e2250.png
edit : bug report created :
https://github.com/systemd/systemd/issues/8155
Mod edit: Switched img tags to url. Please see the CoC regarding acceptable image sizes. -- WorMzy
Last edited by WorMzy (2018-02-10 19:24:46)
Offline
adding a shutdown to the hooks helped me to get rid of these error messages
/etc/mkinitcpio.conf
HOOKS=(base udev autodetect modconf block filesystems resume keyboard fsck usr shutdown)
mkinitcpio -p linux
Last edited by dront78 (2018-02-10 19:12:00)
Offline
I also have the same problem with latest systemd package (237.31).
Arch wiki says that we shouldn't use shutdown hook because this is deprecated method.
Last edited by majsterek95 (2018-02-12 09:52:29)
Offline
Since a bug report is already open, for now I just keep using systemd 236.81.
Offline
> Arch wiki says that we shouldn't use shutdown hook because this is deprecated method.
yeah
https://lists.archlinux.org/pipermail/a … 25742.html
This probably means that systemd shutdown is broken
Offline
If you mask mkinitcpio-generate-shutdown-ramfs.service does the error message stop? If it does stop you should make upstream aware that it is triggered by this custom arch service.
Offline
If you mask mkinitcpio-generate-shutdown-ramfs.service does the error message stop? If it does stop you should make upstream aware that it is triggered by this custom arch service.
Yes, this works ! Thanks a lot
Can i leave this service masked ?
Last edited by majsterek95 (2018-02-12 20:54:15)
Offline
I do not use it but not because of this issue. If the cause of this issue can be found then that should let you make a more informed choice.
Edit:
I referenced two arch devs on the bug report so they can help explain the mkinitcpio interactions to upstream.
Last edited by loqs (2018-02-12 21:31:10)
Offline
Is this unique to Arch?
Reason I ask, is because I see it on AMD systems
and Intel systems, as well as VBox virtual machines
all running Arch. Doesn't actually mess anything
up that I can see, but it does seem odd.
Offline
If the cause really is mkinitcpio-generate-shutdown-ramfs.service then as that service is arch specific yes it would be unique to arch or at least systems that have mkinitcpio built and installed the same way as arch.
Offline
The thing is that, up until systemd version 237, the message was not generated.
If this was introduced with systemd 237, shouldn't it be solved by correcting what is triggering that in systemd instead of somewhere else?
Offline
Where this gets convoluted, is that Arch is pretty
much the leading edge of Linux releases, and this appears
to be the most current systemd. Can we really treat this
as "merely" an Arch glitch or do we wait for the rest of
the linux community to raise issues?
Last edited by W54J04S07T (2018-02-16 21:49:42)
Offline
You could bisect between systemd 236 and 237 to see which commit in systemd starts to produce the issue.
It is unclear if any distribution not using mkinitcpio-generate-shutdown-ramfs.service such as gentoo, fedora, debian, suse will encounter this issue.
Something triggered by the use of that service triggers the production of that message under systemd 237 but what precisely I do not know.
If its arch using systemd-shutdown in an unintended way thats an arch bug. If systemd-shutdown is not working as expected that is a systemd bug.
Without the systemd and arch devs communicating on this I don't know how much more can be achieved unless you want to do the bisection.
Or somehow trace the exact order of events on shutdown.
Offline
I've observed a different error message upon poweroff with systemd v238 update today. Something to the effect of "sd-remount: failed to remount '/oldroot/sys/fs/cgroup/devices.... /pid.... /memory.... /etc, read-only: Device or resource busy" with about 20 similar errors following it. I'm guessing it's related to the original shutdown[1]: Failed to wait for process: Protocol error found in v237. Anyone else seeing it?
Offline
I've observed a different error message upon poweroff with systemd v238 update today. Something to the effect of "sd-remount: failed to remount '/oldroot/sys/fs/cgroup/devices.... /pid.... /memory.... /etc, read-only: Device or resource busy" with about 20 similar errors following it. I'm guessing it's related to the original shutdown[1]: Failed to wait for process: Protocol error found in v237. Anyone else seeing it?
I have this problem, too.
Offline
I've observed a different error message upon poweroff with systemd v238 update today. Something to the effect of "sd-remount: failed to remount '/oldroot/sys/fs/cgroup/devices.... /pid.... /memory.... /etc, read-only: Device or resource busy" with about 20 similar errors following it. I'm guessing it's related to the original shutdown[1]: Failed to wait for process: Protocol error found in v237. Anyone else seeing it?
I see it too
Offline
Yep, I see it too.
Offline
Enough already. This has been reported upstream. There is no need to further bury the relevant content of this thread when over half the posts already just say "me too".
Last edited by Trilby (2018-03-13 11:33:38)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Is there a vehicle to ask the package maintainer for systemd
to do a pull and try a version "-4" compile for testing to see if the recent
patches have cleaned up the problem?
This particular thread has over 6000 views, so I suspect
there is "some" interest.
Offline
Is there a vehicle to ask the package maintainer for systemd
to do a pull and try a version "-4" compile for testing to see if the recent
patches have cleaned up the problem?
You could build such a package yourself
git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/systemd"
cd packages/trunk/
makepkg -Codd
cd src/systemd/
git log
commit d24e70fe8b6bebd9abe4c1578d22cb5536044cc2 (HEAD -> master, origin/master, origin/HEAD)
Author: futpib <futpib@gmail.com>
Date: Fri Mar 16 17:25:14 2018 +0300
hwdb: fix comment suggested `udevadm trigger` command (#8465)
cd ../.. #then edit PKGBUILD change _commit to _commit='d24e70fe8b6bebd9abe4c1578d22cb5536044cc2'
makepkg -rsi
Even if the messages are removed is there any evidence the issue was more than cosmetic i.e. evidence that something was not unmounted cleanly such as being flagged as such by mount on next boot?
Last edited by loqs (2018-03-16 19:05:45)
Offline
Even if the messages are removed is there any evidence the issue was more than cosmetic i.e. evidence that something was not unmounted cleanly such as being flagged as such by mount on next boot?
I haven't seen anything too serious.
But, there is a report upstream in the bug report
of system hanging requiring reset/shutdown button.
As they say...YMMV.
Oh, and also, the S/W is on github not the Arch git.
Last edited by W54J04S07T (2018-03-16 19:48:12)
Offline
Oh, and also, the S/W is on github not the Arch git.
The PKGBUILD for the arch package systemd is not in the arch git?
Edit:
The instructions I provided pulled the PKGBUILD from the arch git then makepkg pulls the upstream sources from github then use git log to find the newest commit ID
update the PKGBUILD with that commit ID then use makepkg to build the package.
Edit2:
But, there is a report upstream in the bug report
of system hanging requiring reset/shutdown button.
Can you link that post please searching for reboot, hang or reset I could not find it in the the upstream report.
Last edited by loqs (2018-03-16 20:05:58)
Offline