Bug 1785586
| Summary: | Start openvswitch service failed with error message ovs|00002|daemon_unix|EMER|/var/run/openvswitch/ovsdb-server.pid.tmp: create failed (Permission denied) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Hekai Wang <hewang> |
| Component: | openvswitch2.11 | Assignee: | Timothy Redaelli <tredaelli> |
| Status: | CLOSED ERRATA | QA Contact: | Hekai Wang <hewang> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | FDP 20.A | CC: | aconole, aloughla, atomasov, atragler, ctrautma, hewang, jhsiao, jmacku, kfida, kzhang, lnst-team, mburman, network-qe, qding, ralongi, tredaelli |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openvswitch2.11-2.11.0-43.el7fdn | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-10 09:35:30 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: | |||
|
Description
Hekai Wang
2019-12-20 11:07:19 UTC
Hello, we can see exactly the same behavior using the same distribution. Versions and logs: [root@slevac1 ~]# rpm -qa | grep switch openvswitch-2.9.0-3.el8+7.x86_64 [root@slevac1 ~]# rpm -qa | grep systemd python3-systemd-234-8.el8.x86_64 systemd-libs-239-21.el8.x86_64 systemd-239-21.el8.x86_64 systemd-pam-239-21.el8.x86_64 systemd-udev-239-21.el8.x86_64 systemd-container-239-21.el8.x86_64 rpm-plugin-systemd-inhibit-4.14.2-35.el8.x86_64 [root@slevac1 ~]# uname -a Linux slevac1.slevarna.tpb.lab.eng.brq.redhat.com 4.18.0-167.el8.x86_64 #1 SMP Sun Dec 15 01:24:23 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@slevac1 ~]# [root@slevac1 ~]# service openvswitch start Redirecting to /bin/systemctl start openvswitch.service A dependency job for openvswitch.service failed. See 'journalctl -xe' for details. [root@slevac1 ~]# journalctl -xe -- Unit ovsdb-server.service has begun starting up. Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com runuser[7495]: pam_unix(runuser:session): session opened for user openvswitch by (uid=0) Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com runuser[7495]: pam_unix(runuser:session): session closed for user openvswitch Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com runuser[7498]: pam_unix(runuser:session): session opened for user openvswitch by (uid=0) Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com runuser[7498]: pam_unix(runuser:session): session closed for user openvswitch Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com ovsdb-server[7501]: ovs|00002|daemon_unix|EMER|/var/run/openvswitch/ovsdb-server.pid.tmp: create failed (Permission denied) Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com ovs-ctl[7462]: Starting ovsdb-server ovsdb-server: /var/run/openvswitch/ovsdb-server.pid.tmp: create failed (Permission denied) Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com ovs-ctl[7462]: [FAILED] Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com systemd[1]: ovsdb-server.service: Control process exited, code=exited status=1 Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com systemd[1]: ovsdb-server.service: Failed with result 'exit-code'. Dec 22 13:52:10 slevac1.slevarna.tpb.lab.eng.brq.redhat.com systemd[1]: Failed to start Open vSwitch Database Unit. -- Subject: Unit ovsdb-server.service has failed -- Defined-By: systemd This all says el8, but we didn't release OvS 2.9 for el8 - did I miss something? I see two different OvS versions reported. I never saw this under OvS 2.11 - can we confirm you are using that version? (In reply to HeKai Wang from comment #0) > Description of problem: > > can not start openvswtich service on rhel8.2 beta verison > with the error message below > ovs|00002|daemon_unix|EMER|/var/run/openvswitch/ovsdb-server.pid.tmp: create > failed (Permission denied) > > It also does not work even after disable selinux and reboot system . > > Version-Release number of selected component (if applicable): > [root@dell-per740-43 run]# rpm -qa | grep openv > openvswitch2.11-2.11.0-35.el8fdp.x86_64 > openvswitch-selinux-extra-policy-1.0-19.el8fdp.noarch > [root@dell-per740-43 run]# uname -a > Linux dell-per740-43.rhts.eng.pek2.redhat.com 4.18.0-167.el8.x86_64 #1 SMP > Sun Dec 15 01:24:23 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > [root@dell-per740-43 run]# > > > RHEL-8.2.0-20191219.0 > > How reproducible: > Always > > Steps to Reproduce: > 1. > 2. > 3. > > Actual results: > can not start service > > Expected results: > Start openvswitch service fine . > > Additional info: Hi Hekai, I have reproduced the same issue. But, for 20.A testing we're not supposed to run under RHEL-8.2. We need to run under released 8.1.0. Thanks! Jean (In reply to Aaron Conole from comment #3) > I see two different OvS versions reported. I never saw this under OvS 2.11 > - can we confirm you are using that version? Hekai was using openvswitch2.11-2.11.0-35.el8fdp.x86_64 based on his description. And, my reproduction was also based on the same package under RHEL-8.2 20191219.0 Snapshot I guess it needs 7a65e5a9252ac06df62707a571931f501747ecfc to be backported. Thanks. *** Bug 1792952 has been marked as a duplicate of this bug. *** We need the fix on OVS 2.11 for RHEL 7.7/7.8 and RHEL 8.1/8.2 Is this already fixed on FDP 20.A or coming with 20.B? Does OVS 2.13 have the fix already Hi, the commit is already included in 2.12+. The bug is on VERIFIED status, it means it's not released yet and it'll be released on FDP 20.B. The builds are always aligned between RHEL7 and RHEL8, but, in this case, the problem is only present on RHEL8 since it's a behavior change in newer systemd versions 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://access.redhat.com/errata/RHBA-2020:0743 |