[systemd-devel] systemd-nspawn at .service is unusable

[Peter Lemenkov]

2014-12-05 4:43 GMT+03:00 Lennart Poettering <lennart at poettering.net>:
> On Thu, 04.12.14 20:12, Peter Lemenkov (lemenkov at gmail.com) wrote:
>
>> Hello All!
>>
>> I'm playing with systemd-nspawn at .service and cannot make it work. It
>> seems that similar issues were discussed (and addressed upstream) in
>> Debian bug #770275 ( https://bugs.debian.org/770275 ) however I
>> believe I've hit by something else.
>>
>> What I've done so far:
>>
>> * Ensured that /var/lib/container exists
>> * Created both  /var/log/journal/<machineid> and
>> /var/lib/container/<containername>/var/log/journal/<machineid>
>> * Ensured that Storage=persistent is set in
>> /var/lib/container/<containername>/etc/systemd/journald.conf
>>
>> Every my attempt to run "systemctl status
>> systemd-nspawn@<containername>" ended up like this:
>>
>> https://paste.fedoraproject.org/156640/14177088/
>>
>> Please note that systemd-journald fails so I can't find out what's
>> going on there. I'm stuck right here. Some other services failed as
>> well, and I can't login using "machinectl login" but that's another
>> story I believe.
>>
>> Any advice on how to debug this and make
>> systemd-nspawn@<containername> usable are highly appreciate!
>
> What happens if you run the same nspawn command from the command line?
> Does journald then start up correctly in it?
>
> What happens if you add "debug" to the end of the nspawn cmdline? Do
> you see anything interesting in the additional log output this
> generates?
>
> If it fails then, too. Can you "strace -ff -o ~/nspawnlogs" the whole nspawn process
> (and hence also its child processes), then find the strace log this
> created for journald, and check what the last bits are that it does.

Ok, now I've got something. Here is a a diff between good (1st,
commandline) and bad (2nd, systemd service) sessions:

* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff

More specifically I found these pieces interesting:

* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L253-L258

Notice "open("/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES
(Permission denied)" when started as systemd service:

* https://gist.github.com/lemenkov/ee70c42baedcb9b43189#file-sessions-diff-L699-L700

Notice "unlink("/run/systemd/journal/dev-log")  = -1 EACCES
(Permission denied)" followed by "bind(7, {sa_family=AF_LOCAL,
sun_path="/run/systemd/journal/dev-log"}, 30) = -1 EADDRINUSE (Address
already in use)".

Looks like systemd-nspawn either doesn't mounts (bind mounts) a
necessary devices or doesn't create them properly.

-- 
With best regards, Peter Lemenkov.