FS#52009 - [systemd] systemd-nspawn fails to --bind directories

Attached to Project: Arch Linux
Opened by Dimos Dimoulis (dimosd) - Thursday, 01 December 2016, 03:19 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 11 December 2016, 01:13 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

I use systemd-nspawn with --bind=/tmp/.X11-unix as described in the wiki. After the upgrade to systemd 232 in host/container, the directory is not mounted and I get a "Failed unmounting /tmp/.X11-unix." on container shutdown.
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 11 December 2016, 01:13 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd-232-5
Comment by Dimos Dimoulis (dimosd) - Thursday, 01 December 2016, 06:49 GMT
Reverting to systemd 231-4 on the host solved this
Comment by Hartmut Malzahn (hwm) - Thursday, 01 December 2016, 14:47 GMT
I have the same problem, my workaround is to use "--bind=/tmp/.X11-unix:/.X11-unix" and then "ln -s /.X11-unix /tmp/" inside the container, which is really crappy but works for the moment.
Comment by Dave Reisner (falconindy) - Thursday, 01 December 2016, 15:38 GMT
Can you run systemd-nspawn from v232 with SYSTEMD_LOG_LEVEL=debug (as environment) and the original --bind=/tmp/.X11-unix flag?
Comment by Hartmut Malzahn (hwm) - Thursday, 01 December 2016, 16:33 GMT
Update: I can reproduce the error with two commands:

btrfs subvolume snapshot / /.nspawn
systemd-nspawn -D /.nspawn --bind=/tmp/.X11-unix bash

In 231 this shows /tmp/.X11-unix in the container, in 232 /tmp is empty.

I've attached the 232 output with LOG_LEVEL=debug, and it appears that the empty /tmp is mounted after the bind mount happens, which is the wrong order.
   nspawn_debug.txt (5.7 KiB)
Comment by Dave Reisner (falconindy) - Thursday, 01 December 2016, 16:40 GMT
Please report this upstream and include your log.
Comment by Hartmut Malzahn (hwm) - Friday, 02 December 2016, 07:04 GMT
Here's the link to the upstream issue:

https://github.com/systemd/systemd/issues/4789
Comment by Christian Rebischke (Shibumi) - Wednesday, 07 December 2016, 18:36 GMT
Hello,
is it possible to apply a patch for this issue? https://github.com/systemd/systemd/pull/4824
Would be awesome to have this bug fixed without waiting 6 months for the next release.
Comment by Dave Reisner (falconindy) - Wednesday, 07 December 2016, 18:47 GMT
This isn't a trivial cherry-pick because the code in that file has changed substantially. When I have time to write the equivalent patch for v232, it'll appear in [testing].

FWIW, it was exactly 100 days between 231 and 232. That's actually the longest systemd has ever gone between releases, and generally averages about a month and a half (44 days) between tags. I've asked upstream to provide a v233 before the holidays, but it doesn't sound like it'll happen.
Comment by Christian Rebischke (Shibumi) - Wednesday, 07 December 2016, 19:29 GMT
Thanks Dave for your fast answer. Too bad. I think I will just downgrade and wait for an upstream. Thanks for your time!
Comment by Dave Reisner (falconindy) - Wednesday, 07 December 2016, 19:49 GMT
Should be fixed in systemd-232-5.
Comment by Dimos Dimoulis (dimosd) - Sunday, 11 December 2016, 01:10 GMT
It works here.

Loading...