Bug 1130939

Summary: Don't create /var/run in new chroot's, as it's a magic dir. now
Product: Red Hat Enterprise Linux 7 Reporter: Erwan Velu <erwan.velu>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED ERRATA QA Contact: Karel Srot <ksrot>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.0CC: emilien.macchi, james.antill, lnykryn, systemd-maint-list, vmukhame
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: yum-3.4.3-119.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 09:04:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Initial Chroot creation none

Description Erwan Velu 2014-08-18 09:05:26 UTC
Description of problem:

On a RHEL7 chroot we are facing the following situation: 

systemd-run from systemd 208 expect the dbus socket to be in /run/dbus/system_bus_socket (or being overrided by DBUS_SYSTEM_BUS_ADDRESS) like shown in http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd-bus/sd-bus.c?id=v208#n968

but

dbus creates the socket in /var/run/dbus/system_bus_socket as specified by the ListenStream parameter in /lib/systemd/system/dbus.socket 

So we have 3 options to workaround:
- symlinking both files
- overriding DBUS_SYSTEM_BUS_ADDRESS
- fixing /var/run/dbus/system_bus_socket to /run instead of /var/run

Clearly the latest option sounds like the good one or maybe the installer is setting up DBUS_SYSTEM_BUS_ADDRESS somewhere which is crap for those who do generate RHEL chroots.

The bug is in between systemd & dbus, assigned it to systemd but maybe we'll have to move it to dbus regarding your opinion on the bug.

Version-Release number of selected component (if applicable):

dbus-1.6.12-8.el7.x86_64
systemd-208-11.el7.x86_64

How reproducible:


Steps to Reproduce:
1. install a RHEL7 in a chroot with yum
2. try to make a systemd-run
3.

Actual results:
A message telling that systemd can contact dbus :
"Failed to create bus connection: No such file or directory"

Expected results:
Running the expected command ;)

Additional info:

Comment 2 Lukáš Nykrýn 2014-08-18 14:11:03 UTC
So problem is elsewhere. /var/run should be symlink to /run and all new services should use /run.

Our old version systemd in rhel7 uses old path, so for example systemctl is working without problem. But there is couple of new parts, which use the new library which looks in /run. Fix for this in systemd should be quite easy, but I would like to fix the culprit, so it works for all packages.

My first suspision is filesystem package, which should create this symlink in pretrans.

D: filesystem-3.2-18.el7.x86_64: SHA1 digest v hlavičce: OK (170efc540bf1be952e5fbda6302ad1e133047ab8)
%pretrans(filesystem-3.2-18.el7.x86_64): running <lua> scriptlet.

Comment 3 Erwan Velu 2014-08-18 14:49:04 UTC
Thanks for the quick answer. I didn't knew about this part.

The stuff around the var/lock is properly in place but indeed the run and var/run isn't. It's maybe on my side, I'm checking that and keep you posted.

Thanks for the hint.

Comment 4 Erwan Velu 2014-08-18 15:02:23 UTC
Created attachment 927945 [details]
Initial Chroot creation

Comment 5 Erwan Velu 2014-08-18 15:03:52 UTC
I've been double checking. 

- Before the creation of the chroot, the /var/run & /var/lock doesn't exist
- After the chroot creation, /var/lock is a symlink but /var/run is a directory

Please find attached the trace of the package installation process and the command used. 

Can you confirm this behaviour ?

Comment 6 Erwan Velu 2014-08-18 15:05:37 UTC
Note that doing a " yum --installroot /var/lib/debootstrap/install/RH7.0-1.6.0/base install -y filesystem" is enough to trigger the bug.

Comment 7 Erwan Velu 2014-08-18 15:24:46 UTC
Installing the filesystem rpm by itself with a very crappy way shows that it does the job of creating the /var/run properly. So another package is killing that stuff after... I have to go for today, I'll inspect the other packages on that selection tomorrow.

Comment 8 Ondrej Vasik 2014-08-18 19:59:02 UTC
It might be anything - pretrans scriptlet in filesystem works just fine for most of the usecases, however I haven't tried --installroot option before. It might be yum issue, it might be some other package doing something wrong - or some corner case causing the pretrans failure. Definitely needs more debugging to find a culprit.

Comment 9 Erwan Velu 2014-08-19 07:07:19 UTC
Sounds like I got the culprit. I did pause yum at the earlier stages even before downloading or installing anything.

I saw that : /var/lib/debootstrap/install/RH7.0-1.6.0/base/var/run/yum.pid

Looking at yum source-code we have :
YUM_PID_FILE = '/var/run/yum.pid' as shown here : http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=yum/constants.py;h=5c728d4b86cbd4f6363b47582c578080e3bfb553;hb=HEAD#l21

Then we do have a doLock() function that setup PID file at the earlier stage of yum.
http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=yum/__init__.py;h=bf13f40d4f09b63c2c28a99de758cfa18bb0fc17;hb=HEAD#l2148

So we have here an issue that prevent creating a clean chroot by using yum install-root

I do see several options to solve this issue :
- Changing YUM_PID_FILE to /run
- Adding a quirk in the pretrans to move everything from /var/run to /run, delete /var/run and create the symlink

Other options ?

Comment 10 Erwan Velu 2014-08-19 07:09:58 UTC
Note that I did forced manually my YUM_PID_FILE to /run and that made the /var/run to be created properly.

Comment 12 James Antill 2014-08-19 18:52:49 UTC
This is fixed upstream by:

commit ffb40e6a1b9c3f4b5b08151a04a5922fc5a9b521
Author: James Antill <james>
Date:   Wed Jan 29 16:04:18 2014 -0500

    Don't create lockdir directories, as they are magic now. BZ 975864

Comment 15 Erwan Velu 2014-09-04 16:41:27 UTC
Good news, thanks !

Comment 18 errata-xmlrpc 2015-03-05 09:04:10 UTC
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-2015-0398.html