Bug 1285996

> This is a blocker for systemd in containers when the state of the system
> needs to be captured in a data volume.

This is unsupported setup, you can't have that directory on different partition.

In your case, please use bind-mounts.

(In reply to Lukáš Nykrýn from comment #1)
> > This is a blocker for systemd in containers when the state of the system
> > needs to be captured in a data volume.
> 
> This is unsupported setup, you can't have that directory on different
> partition.

Could you please point me to the documentation that forbids it being on different partition?
 
> In your case, please use bind-mounts.

That will however still make it a different partition, won't it?

The problem with using bind-mounts is that the user would need to keep the bind mount location for /etc/systemd/system and the one with the other configuration bits and data in sync, opening possibility for mismatches and unnecessary failures.

Also, the message

   Too many levels of symbolic links

seems incorrect since one level cannot reasonably be expected "too many".

Hence, reopening.

> The problem with using bind-mounts is that the user would need to keep the
> bind mount location for /etc/systemd/system and the one with the other
> configuration bits and data in sync, opening possibility for mismatches and
> unnecessary failures.

I don't follow. If we are talking about containers, and you have the data elsewhere you can tell your container tool to bindmount it during start for all locations, which would be more cleaner solution.

But I don't understand your use-case at all. Why it needs to be elsewhere, do you have some read-only setup? Or are you sharing the configuration between multiple containers?

Anyway I will look once more in the issue with disable and try to find some fix, but I really think that you are doing something wrong. As a workaround you can just symlink the whole /etc/systemd

(In reply to Lukáš Nykrýn from comment #5)
> 
> I don't follow. If we are talking about containers, and you have the data
> elsewhere you can tell your container tool to bindmount it during start for
> all locations, which would be more cleaner solution.

Not if we have 55 of such locations: https://github.com/adelton/docker-freeipa/blob/master/volume-data-list

That's why we create one bindmounted directory and have all data and config locations pointing with symlinks to that directory.

> But I don't understand your use-case at all.

It's described in more detail for example at https://www.adelton.com/docs/docker/complex-application-in-container

> Why it needs to be elsewhere,
> do you have some read-only setup?

Read-only setup is on the horizon.

> Or are you sharing the configuration
> between multiple containers?

No.

> Anyway I will look once more in the issue with disable and try to find some
> fix, but I really think that you are doing something wrong. As a workaround
> you can just symlink the whole /etc/systemd

That seems too wide for our purposes.

Thank you for looking into it.

I think that just the fact that enable passes and disable does not means that there is some issue in the systemd code.

https://github.com/systemd/systemd/pull/4063

(In reply to Jan Pazdziora from comment #6)
> (In reply to Lukáš Nykrýn from comment #5)
> > 
> > I don't follow. If we are talking about containers, and you have the data
> > elsewhere you can tell your container tool to bindmount it during start for
> > all locations, which would be more cleaner solution.
> 
> Not if we have 55 of such locations:
> https://github.com/adelton/docker-freeipa/blob/master/volume-data-list
> 
> That's why we create one bindmounted directory and have all data and config
> locations pointing with symlinks to that directory.

Looks similar to our fedora(rhel)-readonly. (although it is doing bind mounts) 
https://git.fedorahosted.org/cgit/initscripts.git/tree/rwtab
https://git.fedorahosted.org/cgit/initscripts.git/tree/systemd/fedora-readonly

Maybe we should think about splitting that from initscripts and make that as a general tool for both use-case.

> It's described in more detail for example at
> https://www.adelton.com/docs/docker/complex-application-in-container

Hm, I see. That would be a material to discussion on mailing list or in a pub :-). Lets not spam bugzilla with that.
 
> I think that just the fact that enable passes and disable does not means
> that there is some issue in the systemd code.
I agree with that part

qa acking

fix merged to upstream staging branch ->
https://github.com/lnykryn/systemd-rhel/commit/55b81218e75888640d9127f176a28a6d9ba03d5d
https://github.com/lnykryn/systemd-rhel/commit/30c5299e91db30f07b64c6c47ac7417bd4e6988c
-> post

Verified with systemd-219-29.el7.

Old package:
:: [  BEGIN   ] :: Running 'mv /etc/systemd/system '/tmp/tmp.w6SDW4BUVJ/''
:: [   PASS   ] :: Command 'mv /etc/systemd/system '/tmp/tmp.w6SDW4BUVJ/'' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'ln -s '/tmp/tmp.w6SDW4BUVJ/system' /etc/systemd/system'
:: [   PASS   ] :: Command 'ln -s '/tmp/tmp.w6SDW4BUVJ/system' /etc/systemd/system' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'systemctl disable cups'
Failed to execute operation: Too many levels of symbolic links
:: [   FAIL   ] :: Command 'systemctl disable cups' (Expected 0, got 1)
:: [  BEGIN   ] :: Running 'systemctl enable cups'
:: [   PASS   ] :: Command 'systemctl enable cups' (Expected 0, got 0)

New package:
:: [  BEGIN   ] :: Running 'mv /etc/systemd/system '/tmp/tmp.jH5TSkY5Dg/''
:: [   PASS   ] :: Command 'mv /etc/systemd/system '/tmp/tmp.jH5TSkY5Dg/'' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'ln -s '/tmp/tmp.jH5TSkY5Dg/system' /etc/systemd/system'
:: [   PASS   ] :: Command 'ln -s '/tmp/tmp.jH5TSkY5Dg/system' /etc/systemd/system' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'systemctl disable cups'
Removed symlink /etc/systemd/system/multi-user.target.wants/cups.path.
Removed symlink /etc/systemd/system/multi-user.target.wants/cups.service.
Removed symlink /etc/systemd/system/printer.target.wants/cups.service.
Removed symlink /etc/systemd/system/sockets.target.wants/cups.socket.
:: [   PASS   ] :: Command 'systemctl disable cups' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'systemctl enable cups'
Created symlink from /etc/systemd/system/multi-user.target.wants/cups.service to /usr/lib/systemd/system/cups.service.
Created symlink from /etc/systemd/system/printer.target.wants/cups.service to /usr/lib/systemd/system/cups.service.
Created symlink from /etc/systemd/system/sockets.target.wants/cups.socket to /usr/lib/systemd/system/cups.socket.
Created symlink from /etc/systemd/system/multi-user.target.wants/cups.path to /usr/lib/systemd/system/cups.path.
:: [   PASS   ] :: Command 'systemctl enable cups' (Expected 0, got 0)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2216.html