| 2020-07-10 14:52:22 |
Brian Turek |
bug |
|
|
added bug |
| 2020-07-22 14:21:55 |
Chris MacNaughton |
openvswitch (Ubuntu): status |
New |
In Progress |
|
| 2020-07-22 14:21:57 |
Chris MacNaughton |
openvswitch (Ubuntu): assignee |
|
Chris MacNaughton (chris.macnaughton) |
|
| 2020-07-22 14:37:05 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~chris.macnaughton/ubuntu/+source/openvswitch/+git/openvswitch/+merge/387852 |
|
| 2020-07-29 11:53:09 |
Sebastian Marsching |
bug |
|
|
added subscriber Sebastian Marsching |
| 2020-09-09 13:19:18 |
Launchpad Janitor |
openvswitch (Ubuntu): status |
In Progress |
Fix Released |
|
| 2020-09-10 06:13:50 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~chris.macnaughton/ubuntu/+source/openvswitch/+git/openvswitch/+merge/390529 |
|
| 2020-09-10 06:15:52 |
Chris MacNaughton |
summary |
ovsdb-server.service needs a depedency on local-fs.target |
[SRU] ovsdb-server.service needs a depedency on local-fs.target |
|
| 2020-09-10 06:20:48 |
Chris MacNaughton |
description |
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 |
[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.
[Discussion] |
|
| 2020-09-10 06:54:14 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~chris.macnaughton/ubuntu/+source/openvswitch/+git/openvswitch/+merge/390530 |
|
| 2020-09-10 07:25:16 |
James Page |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-09-10 07:25:16 |
James Page |
bug task added |
|
openvswitch (Ubuntu Groovy) |
|
| 2020-09-10 07:25:16 |
James Page |
nominated for series |
|
Ubuntu Focal |
|
| 2020-09-10 07:25:16 |
James Page |
bug task added |
|
openvswitch (Ubuntu Focal) |
|
| 2020-09-10 09:29:39 |
James Page |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-09-30 16:50:05 |
Robie Basak |
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.
[Discussion] |
[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] |
|
| 2020-09-30 16:57:30 |
Robie Basak |
openvswitch (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2020-09-30 16:57:33 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2020-09-30 16:57:35 |
Robie Basak |
tags |
|
verification-needed verification-needed-focal |
|
| 2020-10-03 14:26:21 |
Brian Turek |
tags |
verification-needed verification-needed-focal |
verification-done-focal verification-needed |
|
| 2020-10-12 08:57:46 |
James Page |
tags |
verification-done-focal verification-needed |
verification-done verification-done-focal |
|
| 2020-10-21 05:58:40 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-10-21 06:10:15 |
Launchpad Janitor |
openvswitch (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
