[Bug 1910209] Re: "systemctl stop openvswitch-switch" will remove /var/run/openvswitch

Christian Ehrhardt  1910209 at bugs.launchpad.net
Mon Jan 11 15:23:42 UTC 2021


MPs for B/F/G SRUs:
https://code.launchpad.net/~paelzer/ubuntu/+source/openvswitch/+git/openvswitch/+merge/396076
https://code.launchpad.net/~paelzer/ubuntu/+source/openvswitch/+git/openvswitch/+merge/396075
https://code.launchpad.net/~paelzer/ubuntu/+source/openvswitch/+git/openvswitch/+merge/396074

Also I updated the bug description. It should be ready for SRU upload by
James if he agrees.

** Description changed:

+ [Impact]
+ 
+  * The current systemd profile (only active in Debian/Ubuntu) in that form
+    has a runtime directory. But in the default that means the runtime
+    dir is removed on service stop or restart.
+ 
+  * In the past dpdhvhostuser connections used to use paths under that run dir
+    which was no problem as they were dead on restart anyway. But more modern
+    dpdkvhostuserclient connections might (out of habit) use the same path
+    and the dir removal kills that and effectively prevents to keep guest
+    networking alive.
+ 
+  * The fix ensures the directory is kept around via the proper systemd
+    statement
+ 
+ [Test Case]
+ 
+  * start the service and touch any new file in there e.g.
+    $ touch /var/run/openvswitch/foo
+    After a restart this should still be there
+    $ systemctl restart openvswitch-switch
+    $ ls -laF /var/run/openvswitch/foo
+ 
+ [Where problems could occur]
+ 
+  * In our discussions we didn't find a reason that requires to clean that
+    directory. But if there are any setup scenarios we have forgotten that need
+    it then on restart they will have to deal with that "old content".
+    Therefore on service restart is the place to watch out for regressions.
+ 
+ [Other Info]
+ 
+  * n/a
+ 
+ 
+ ---
+ 
  TL;DR:
  - stoping/restarting OVS clears /var/run/openvswitch
  - out of the "vhostuser" connection times a common socket path used
-   was at /var/run/openvswitch
+   was at /var/run/openvswitch
  - if that path used with "vhostuserclient" that removes the sockets
-   on OVS stop/restart
+   on OVS stop/restart
  - Since qemu in server mode only creates this sockets once (as by
-   the client/server design makes sense) that breaks the guests until
-   restarted which is what the tech of vhostuserclient wanted to avoid.
- + Workaround: do use a different path like e.g. 
-   "/var/run/vhostuserclient/vhost-user-client-1"
+   the client/server design makes sense) that breaks the guests until
+   restarted which is what the tech of vhostuserclient wanted to avoid.
+ + Workaround: do use a different path like e.g.
+   "/var/run/vhostuserclient/vhost-user-client-1"
  + Solution: let us think if we could keep the path around on stop/restart
  
  --- vv original report vv ---
  
  My system is Ubuntu 18.04, I installed ovs DPDK by apt-get and used ovs-
  vswitchd DPDK version, but when I stop openvswitch-switch (sudo
  systemctl stop openvswitch-switch), /var/run/openvswitch is removed, so
  the exisitng VMs can't be accessed any more. I don't know why it is
  removed and who removed it.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to openvswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1910209

Title:
  "systemctl stop openvswitch-switch" will remove /var/run/openvswitch

Status in Ubuntu Server Guide:
  Fix Released
Status in dpdk package in Ubuntu:
  Invalid
Status in openvswitch package in Ubuntu:
  Fix Released
Status in openvswitch source package in Bionic:
  Confirmed
Status in openvswitch source package in Focal:
  Confirmed
Status in openvswitch source package in Groovy:
  Confirmed

Bug description:
  [Impact]

   * The current systemd profile (only active in Debian/Ubuntu) in that form
     has a runtime directory. But in the default that means the runtime
     dir is removed on service stop or restart.

   * In the past dpdhvhostuser connections used to use paths under that run dir
     which was no problem as they were dead on restart anyway. But more modern
     dpdkvhostuserclient connections might (out of habit) use the same path
     and the dir removal kills that and effectively prevents to keep guest
     networking alive.

   * The fix ensures the directory is kept around via the proper systemd
     statement

  [Test Case]

   * start the service and touch any new file in there e.g.
     $ touch /var/run/openvswitch/foo
     After a restart this should still be there
     $ systemctl restart openvswitch-switch
     $ ls -laF /var/run/openvswitch/foo

  [Where problems could occur]

   * In our discussions we didn't find a reason that requires to clean that
     directory. But if there are any setup scenarios we have forgotten that need
     it then on restart they will have to deal with that "old content".
     Therefore on service restart is the place to watch out for regressions.

  [Other Info]

   * n/a

  
  ---

  TL;DR:
  - stoping/restarting OVS clears /var/run/openvswitch
  - out of the "vhostuser" connection times a common socket path used
    was at /var/run/openvswitch
  - if that path used with "vhostuserclient" that removes the sockets
    on OVS stop/restart
  - Since qemu in server mode only creates this sockets once (as by
    the client/server design makes sense) that breaks the guests until
    restarted which is what the tech of vhostuserclient wanted to avoid.
  + Workaround: do use a different path like e.g.
    "/var/run/vhostuserclient/vhost-user-client-1"
  + Solution: let us think if we could keep the path around on stop/restart

  --- vv original report vv ---

  My system is Ubuntu 18.04, I installed ovs DPDK by apt-get and used
  ovs-vswitchd DPDK version, but when I stop openvswitch-switch (sudo
  systemctl stop openvswitch-switch), /var/run/openvswitch is removed,
  so the exisitng VMs can't be accessed any more. I don't know why it is
  removed and who removed it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/serverguide/+bug/1910209/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list