[Bug 1887177] Re: [SRU] ovsdb-server.service needs a depedency on local-fs.target
Brian Turek
1887177 at bugs.launchpad.net
Sat Oct 3 14:25:44 UTC 2020
I checked proposed and the amd64 versions finally built. I installed
v2.13.1-0ubuntu0.20.04.1, removed my temporary fix, rebooted, and am
pleased to report that ovsdb-server is now waiting for ZFS to mount.
Manual inspection using "systemctl list-dependencies ovsdb-
server.service --after" shows dependencies on the relevant ZFS mounts as
well.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
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/1887177
Title:
[SRU] ovsdb-server.service needs a depedency on local-fs.target
Status in openvswitch package in Ubuntu:
Fix Released
Status in openvswitch source package in Focal:
Fix Committed
Status in openvswitch source package in Groovy:
Fix Released
Bug description:
[Impact]
When /var is on a separate filesystem (ZFS), ovsdb-server crashes on start if it is triggered before that filesystem is ready.
I recently just did a from-scratch install of Ubuntu 20.04 server
edition and ran into issues with Open vSwitch and ZFS. I attempted to
use ZFS for all of /var only to find that ovsdb-server pre-empted my
ZFS /var mount which caused it to crash when trying to read its
configuration DB at/var/lib/openvswitch/conf.db After much
troubleshooting, the problem basically boils down to ovsdb-
server.service needing a requirement on local-fs.target
I then found a blog post on Open Cloud Blog
(https://www.opencloudblog.com/?p=240) that contained a fix:
The "After" line /lib/systemd/system/ovsdb-server.service needs the
following changes:
[Unit]
Description=Open vSwitch Database Unit
After=syslog.target network-pre.target dpdk.service local-fs.target
Before=network.target networking.service
PartOf=openvswitch-switch.service
DefaultDependencies=no
[Service]
LimitNOFILE=1048576
Type=forking
Restart=on-failure
EnvironmentFile=-/etc/default/openvswitch
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
--no-ovs-vswitchd --no-monitor --system-id=random \
start $OPTIONS
ExecStop=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd stop
ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd \
--no-monitor restart $OPTIONS
RuntimeDirectory=openvswitch
RuntimeDirectoryMode=0755
[Test Case]
Install ZFS on a machine, configure /var to be mounted on ZFS, install
Open vSwitch, restart the server. The OpenvSwitch process should wait
on the ZFS mount to start.
[Regression Potential]
Low. The only change in this is to defer the ovsdb-server startup
until after the local-fs Systemd target has started. The only risk I
can forsee is if the local-fs target didn't come up.
[racb] Service dependency and thus ordering is being adjusted, so if
there is a regression it might manifest in users with unusual or
different service installations from the norm, or in users with
customised service configurations. There might also be unrelated
latent issues or race conditions revealed as a result of changing the
order of service startups.
[Discussion]
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1887177/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list