FS#61330 - [devtools] arch-nspawn fails with "Parent died too early" since updating

Attached to Project: Arch Linux
Opened by Mike Javorski (javmorin) - Wednesday, 09 January 2019, 23:51 GMT
Last edited by Kristian (klausenbusk) - Saturday, 03 June 2023, 18:02 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Since upgrading to latest packages on 1/9/19 all attempts to run arch-nspawn (directly and via makechrootpkg) result in "Parent died too early" failure.

Also present are a number of "Failed to attach" messages, though they have been present for some time and didn't prevent arch-nspawn from running before


Additional info:
* linux 4.20.0-arch1-1
* devutils 20180531-4


Steps to reproduce:
* Update to latest (non-testing) packages with pacman -Syu
* Attempt to run arch-nspawn to update a chroot
- or -
Run makechrootpkg for any package
This task depends upon

Closed by  Kristian (klausenbusk)
Saturday, 03 June 2023, 18:02 GMT
Reason for closing:  Upstream
Additional comments about closing:  Please report upstream if still relevant: https://gitlab.archlinux.org/archlinux/d evtools.
Comment by Eli Schwartz (eschwartz) - Thursday, 10 January 2019, 00:11 GMT
You're obviously wrong and it is not so blatantly obvious a problem... since it works for me. Also why do you even think this is the fault of devtools? The error is happening inside of systemd-nspawn, not arch-nspawn.

I will give you one chance to actually post an error message.
Comment by Mike Javorski (javmorin) - Thursday, 10 January 2019, 00:27 GMT
I don't understand the implications wrt systemd enough to pass judgment on whether this is "safe" or not, but I tried the suggestion in  FS#58892  of commenting out the '--keep-unit' portion of the systemd-nspawn call inside arch-nspawn and was able to get things to run. So it would seem whatever tickled that bug for things before, is getting more aggressive in causing failure.

I checked, and during my upgrade systemd went from 239.370-1 -> 240.0-3 if that helps with diagnosis/resolution.

Also the extend of the failure output is:
Failed to attach 13629 to compat systemd cgroup /user.slice/user-1000.slice/session-5.scope/payload: No such file or directory
Failed to attach 13603 to compat systemd cgroup /user.slice/user-1000.slice/session-5.scope/supervisor: No such file or directory
Failed to chown() cgroup /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-5.scope/payload: No such file or directory
Parent died too early

I can find nothing in dmesg indicating a kernel issue, nor is there anything in the journal/logs, and I am not sure where else to look. If there is some guidance you could provide on where to get useful log output for this, I would be happy to provide it.
Comment by Mike Javorski (javmorin) - Thursday, 10 January 2019, 00:32 GMT
@eschwartz to your point made while I was trying to provide more detail; it seems to be related to how systemd-nspawn is called (given the above) that would seem to indicate that arch-nspawn is at least partly at fault, no?

I do not understand why it would be failing for me, but working for you. I don't have any special configuration on my machine wrt systemd (I just have the default Arch install). I am not running any "testing" packages, and the AUR packages I build locally have nothing to do with core system functionality.

I don't know enough about systemd internals to understand why it's failing, but if you would like me to run something in order to give you more details for diagnosis I would be happy to do so.


Comment by Eli Schwartz (eschwartz) - Thursday, 10 January 2019, 00:41 GMT
Okay, that's useful information. It also indicates that this is the same bug, though.

I don't think anything is more aggressive about causing it though -- it just seems to be something that some people mysteriously get occasionally.
Comment by Mike Javorski (javmorin) - Thursday, 10 January 2019, 00:59 GMT
My point on it's aggressiveness is based on the fact that the only delta on this machine was that I just ran a pacman -Syu and rebooted. I have been running this script to update my local packages for 2+ years, and this is the first time in my memory that it refused to run (and I run it at least once a day). Retrying multiple times didn't fix it, so it didn't seem to be a transient issue.

I _have_ been getting the "Failed to attach" messages for many months at this point but they had never stopped the builds from running (which is different than what was indicated in  FS#58892 ). Perhaps systemd 240 changed the nspawn behavior to fail if that occurs now, whereas prior to the upgrade it just logged out the "failures" and kept on trucking. (That doesn't explain  FS#58892  though).

I will try later this evening to see if a few reboots "clears" the error and update this bug accordingly.
Comment by Mike Javorski (javmorin) - Thursday, 10 January 2019, 06:39 GMT
I tried rebooting several (4+) times and system-nspawn/arch-nspawn still fails to execute with the same error if the "keep-unit" flag is in place. For the hell of it, I downgraded systemd* to 239.370-1 and I am still getting the "Parent died to early" messages, so there must be some stored "state" somewhere that is now screwed up on my machine.

Loading...