On 15/04/2024 14:39, Jon Kohler wrote:
On Apr 11, 2024, at 9:43 AM, Chris Riches wrote:
On 11/04/2024 14:24, Ilya Maximets wrote:
On 4/11/24 10:59, Chris Riches wrote:
From what we know so far, the DB was full of stale connection-tracking
information such as the following:
[...]
Once
On 12/04/2024 10:20, Dumitru Ceara wrote:
On 4/11/24 19:10, Chris Riches wrote:
On 11/04/2024 17:10, Dumitru Ceara wrote:
On 4/11/24 15:43, Chris Riches wrote:
On 11/04/2024 14:24, Ilya Maximets wrote:
On 4/11/24 10:59, Chris Riches wrote:
Hi Chris, Ilya,
From what we know so far
On 11/04/2024 17:10, Dumitru Ceara wrote:
On 4/11/24 15:43, Chris Riches wrote:
On 11/04/2024 14:24, Ilya Maximets wrote:
On 4/11/24 10:59, Chris Riches wrote:
Hi Chris, Ilya,
From what we know so far, the DB was full of stale connection-tracking
information such as the following
On 11/04/2024 14:24, Ilya Maximets wrote:
On 4/11/24 10:59, Chris Riches wrote:
From what we know so far, the DB was full of stale connection-tracking
information such as the following:
[...]
Once the host was recovered by putting in the timeout increase,
ovsdb-server successfully started
On 10/04/2024 23:31, Ilya Maximets wrote:
On 4/10/24 17:48, Chris Riches wrote:
If the database is particularly large (multi-GB), ovsdb-server can take
Hi, Chris. May I ask how did you end up with multi-GB database?
I would understand if it was an OVN Southbound DB, for example,
but why
.
This change brings ovsdb-server's timeout in line with ovs-vswitchd,
which got the same treatment in commit c1c69e8a45 ("rhel/systemd: Set
ovs-vswitchd timeout to 5 minutes").
Signed-off-by: Chris Riches
---
rhel/usr_lib_systemd_system_ovsdb-server.service | 1 +
1 file changed, 1
