Bug 1045849 is related ...

It seems opencryptoki needs to be fixed instead. It doesn't make sense to install anything into /var/lock as it is linked to /run/lock and therefore the installed content is erased with the reboot.

Changed component to opencryptoki then.

After some discussion on irc, we concluded *someone* needs the job to ensure that /run/lock (target of filesystem's /var/lock symlink) needs to exist at systemd package install time.    IMHO, I think the best place to implement that is systemd package itself.

Options include:
* systemd run it's own tmpfile-related scriptlets in %post to create/populate /run/lock (and friends).  Ideally accompanied by %ghost of them, so they are owned (currently /run/lock is unowned)
* or just create/own /run/lock is a regular dir
* ... or some better implementation idea

(not sure why rawhide is seeing this problem when apparently related f20 bug #1045849 is marked fixed already)

I've been looking at adding a mechanism for the mock config file to specify extra directories to setup in the chroot and finally added the 'extra_chroot_dirs' config option. I modified the f19, f20 and rawhide configs to have the line:

    config_opts['extra_chroot_dirs'] = ['/run/lock', ]

Mock 1.36 for f19 and up will create /run/lock while initializing the chroot framework.

This is something really between yum and mock, they set up the really basic directory tree, not systemd. Reassigning.

Doesn't answer my query in comment #4 , why does systemd (or *some* package) not own /run/lock ?

Relatedly, filesystem %changelog mentions:

* Wed Jun 20 2013 Ondrej Vasik <ovasik> - 3.2-16
- /var/run and /var/lock can't be in payload for some reason

wonder what "some reason" means.  maybe there is more going on.

CC: ovasik ...

Ondrej, can you help explain why filesystem pkg doesn't own /var/lock ?

(In reply to Rex Dieter from comment #8)
They used to be dirs and cannot be converted to symlinks and stored in the rpm because of RPM inaneness.

Actually, filesystem pkg does already include the 
%pretrans -p <lua>
magic to workaround that (largely).  The prior commit was about trying to own the symlink as a dir, which is apparently bad. (workaround was to use %ghost instead).
 

More irc conversation, and I realized the filesystem comment was about /var/lock (not /run/lock), and that it has never tried to own /run/lock too.  So, lets amend the question to:

Ondrej, any objections/comments about filesystem owning /run/lock dir ?


This case of /var/lock (symlink) and /var/run (target dir) isn't much different that the situation of /var/run (symlink) and /run (target dir)

Well, filesystem already owned /run/lock (#693394) - and I'm fine with owning it again if necessary - this drop was requested by systemd guys (Kay Sievers namely) - http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=5a403cd70564264b9bb7a5e2b3f1a6351c2f4ad8 - to address the "symlinked /var" related yum buildroot issue with dirs ending up in /var instead of symlinks to /run/ . It seems that it would be better to fix the yum buildroot issue instead of removing the /run/lock dir ownership (or to see if the /run/lock ownership removal was really necessary there).

Interesting, bug #693394 is essentially the same as this bug (obviously something has regressed), and comment 14 basically says filesystem should own /run/lock too.  I *think* the dropping of /run/lock ownership was either not intended or not required to fix the prior issue(s).

I'm (still) of a mind to recommend moving forward with filesystem owning /run/lock dir, unless evidence or rationale comes to suggest doing otherwise.

Don't know, adding Kay Sievers to CC - he may recall some reason for it. If not, I'll return /run/lock ownership back to filesystem.

How can you own /run/lock? /run is on tmpfs and should be correctly mounted and setup prior to installation.
Either by the initramfs, mock, anaconda or whatever provides a root/chroot to be installed to.

Someone needs to own /run/lock - no matter who. In filesystem, it would be just %ghost ownership, and mkdir-ed in the pretrans of the setup installation. That way, /run/lock will be there even during the mock installation - and after cleanup, systemd will create it again in the brand new tmpfs after reboot.

Please note new --boot option added to systemd-tmpfiles not so long ago. In tmpfiles.d configuration files it is now possible to mark entries with exclamation mark, meaning that it is possible to execute action according to entry in question *only* during system boot and it might possibly break running system if executed at later time. 

Also note tmpfiles.d/legacy.conf, that /run/lock is not marked with !, thus I propose adding call to systemd-tmpfiles (without --boot of course) to systemd %post. This would assure existence of the directory on both, rootfs as well as in chroot. I am not 100% sure if systemd would be installed earlier in the transaction as component which needs directory, but I think we should at least consider this option. Might solve similar issues for some rather legacy daemons too. Just my 2¢...

Anyway this directory is created by mock (since mock-1.1.36) so original issue reported against mock should be fixed.
Can you please confirm it?

trace-cmd built fine: https://brewweb.devel.redhat.com/buildinfo?buildID=343808

Closing per #19 and #5.

Weird, please close this bugreport if you see something what I don't.

Looking at mock profiles on my machine (f20, mock 1.1.38), I see the hack
  config_opts['extra_chroot_dirs'] = [ '/run/lock', ]

This results in something like this in mock lock:
  ....
  DEBUG: ensuring that dir exists: /var/lib/mock/fedora-20-x86_64/root/sys
  DEBUG: ensuring that dir exists: /var/lib/mock/fedora-20-x86_64/root/run/lock
  ...

But in ..
(In reply to Marcin Juszkiewicz from comment #19)
> trace-cmd built fine:
> https://brewweb.devel.redhat.com/buildinfo?buildID=343808

.. this build, I don't see such output.  I am coming here to this bug because
of the bug 1101325 (well, uucp should be fixed to provide the directory as
a %ghost probably but still, I don't think that the hack currently works.
Build of hylafax facing this issue:

https://koji.fedoraproject.org/koji/taskinfo?taskID=6894360

Yep, looks like fix in mock doesn't work and packages need to workaround that in %post. As I mentioned in comment #17 we can add %tmpfiles_create to systemd %post and that should fix this issue for most packages. FYI I went ahead and did exactly that in systemd for RHEL7 and I think we should do the same in Fedora too. Also we should keep in mind that this is not only about mock but also installing some package set via yum --installroot has the same problem.

[OT, should have its own systemd bug]

(In reply to Michal Sekletar from comment #22)
> Yep, looks like fix in mock doesn't work and packages need to workaround
> that in %post.

If this is really workaround, what is proper fix?

> As I mentioned in comment #17 we can add %tmpfiles_create to systemd %post
> and that should fix this issue for most packages. FYI I went ahead and did
> exactly that in systemd for RHEL7 and I think we should do the same in
> Fedora too.

If the package is not installed together with systemd in one transaction?
Probably %posttrans would be better workaround?

[/OT]

I split the systemd relevant issue into its own bug 1101983.

Re: comment #23
> If this is really workaround, what is proper fix?

See comment #13 and comment #16 (imho)

(In reply to Rex Dieter from comment #25)
> Re: comment #23
> > If this is really workaround, what is proper fix?
> 
> See comment #13 and comment #16 (imho)

Done via #1101983 fix.  Systemd should now create /var/lock in %post.  It is
still _not_ "owned" as it should be IMO (%ghost ownership would be OK), but
anyway, it should work.

Seems like package guidelines should be changed a little.  If (a) packages
_own_ some directory under /var/lock (non-ghost), they must have set correct
permissions on two places (the tmpfilesdir conf file and %dir
%files-statement).  These two permissions should really match.  (b) The
%package can %ghost own that directory and keep the permission just in conf
%file (but it must call tmpfiles_create in %post).

Still does not change the fact that config_opts['extra_chroot_dirs'] is broken,
thats why this is reopened.

Ad #21 - according the log
  http://download.devel.redhat.com/brewroot/packages/trace-cmd/2.2.1/6.sa1.2/data/logs/aarch64/state.log
Brew use mock-1.1.35, while #5 say, that this was fixed in 1.1.36, talk to Brew owners about upgrading mock.

Oh, sorry, comment #21 was partly bad.  The second link was hitting the bug:

from comment #21
> Build of hylafax facing this issue:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=6894360

Also this one (newer build):

https://kojipkgs.fedoraproject.org//packages/hylafax+/5.5.5/1.fc20/data/logs/x86_64/root.log

Koji have separate configs for mock. And those config overwrited default mock config. Therefore this bug still appear in Fedora Koji.
I created:
  https://fedorahosted.org/fedora-infrastructure/ticket/4390