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:
>>> 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
On 4/23/24 13:10, Ilya Maximets wrote:
> On 4/23/24 12:35, Simon Horman wrote:
>> On Thu, Apr 18, 2024 at 03:35:06PM +0100, Chris Riches wrote:
>>> 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
Chris Riches writes:
> 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
>
On 4/23/24 12:35, Simon Horman wrote:
> On Thu, Apr 18, 2024 at 03:35:06PM +0100, Chris Riches wrote:
>> 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:
On Thu, Apr 18, 2024 at 03:35:06PM +0100, Chris Riches wrote:
> 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
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 the
> 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 the host was
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, the
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, the DB was full of stale
>
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 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:
>>>
>>> [...]
>>>
>>> Once the host was
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 4/11/24 10:59, Chris Riches wrote:
> 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
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 the
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 the local database that only stores
If the database is particularly large (multi-GB), ovsdb-server can take
several minutes to come up. This tends to fall afoul of the default
systemd start timeout, which is typically 90s, putting the service into
an infinite restart loop.
To avoid this, set the timeout to a more generous 5
16 matches
Mail list logo
