Is this a critical security issue?
Describe the Bug
On one of my nodes the OpenVox agent seems to regularly get stuck and not recover.
Interestingly a process list shows multiple processes still applying configuration:
root 45250 0.0 0.2 1007348 2512 ? Sl Jun10 0:00 puppet agent: applying configuration
root 437708 0.0 3.6 747732 35848 ? Ssl Jun10 0:08 /opt/puppetlabs/puppet/bin/ruby /opt/puppetlabs/puppet/bin/puppet agent --no-daemonize
root 749623 0.0 0.2 1018756 2508 ? Sl Jun05 0:00 puppet agent: applying configuration
root 1714481 0.0 4.7 999628 47496 ? Sl 14:35 0:00 puppet agent: applying configuration
root 1751452 0.0 0.2 1012556 2504 ? Sl Jun01 0:00 puppet agent: applying configuration
root 3375497 0.0 0.2 1013568 2636 ? Sl Jun03 0:00 puppet agent: applying configuration
root 3958388 0.0 0.2 1018784 2512 ? Sl May30 0:00 puppet agent: applying configuration
If I run the agent on the CLI it connects and applies with no problem.
Expected Behavior
I would expect a connection or even apply run to time out after a while and the agent to just carry on eventually.
Steps to Reproduce
Just let the agent run, at least on this VM. I haven't been able to reproduce this elsewhere, but it has happened every few days for a week or so on this system.
Environment
Version: 9.0.0.alpha2-1+debian13
Platform: Debian 13 (trixie)
Additional Context
In case this makes any difference, this is a Linode, using IPv6 to reach the OpenVox server. I have other Linodes and VMs from other providers accessing the same OpenVox server over IPv6 which don't encounter this problem.
Relevant log output
Jun 12 13:35:29 annalee puppet-agent[1682646]: Requesting catalog from puppet.example.com:443 (2001:db8::4)
Jun 12 13:35:32 annalee puppet-agent[1682646]: Catalog compiled by puppetserver.puppet.svc.cluster.local
Jun 12 13:35:34 annalee puppet-agent[1682646]: Applied catalog in 1.16 seconds
Jun 12 14:05:30 annalee puppet-agent[1698573]: Requesting catalog from puppet.example.com:443 (2001:db8::4)
Jun 12 14:05:35 annalee puppet-agent[1698573]: Catalog compiled by puppetserver.puppet.svc.cluster.local
Jun 12 14:05:37 annalee puppet-agent[1698573]: Applied catalog in 1.15 seconds
Jun 12 14:37:25 annalee puppet-agent[1714481]: Connection to https://puppet.example.com/puppet/v3 failed, trying next route: Request to https://puppet.example.com/puppet/v3 timed out connect operation after 120.056 seconds
Jun 12 14:37:25 annalee puppet-agent[1714481]: Wrapped exception:
Jun 12 14:37:25 annalee puppet-agent[1714481]: Failed to open TCP connection to puppet.example.com:443 (user specified timeout for puppet.example.com port 443)
Jun 12 14:37:25 annalee puppet-agent[1714481]: No more routes to fileserver
Jun 12 15:35:25 annalee puppet-agent[1714481]: Could not retrieve local facts: execution expired
Jun 12 15:35:25 annalee puppet-agent[1714481]: Failed to apply catalog: Could not retrieve local facts: execution expired
Jun 12 15:37:25 annalee puppet-agent[1714481]: Connection to https://puppet.example.com/puppet/v3 failed, trying next route: Request to https://puppet.example.com/puppet/v3 timed out connect operation after 120.084 seconds
Jun 12 15:37:25 annalee puppet-agent[1714481]: Wrapped exception:
Jun 12 15:37:25 annalee puppet-agent[1714481]: Failed to open TCP connection to puppet.example.com:443 (user specified timeout for puppet.example.com port 443)
Jun 12 15:37:25 annalee puppet-agent[1714481]: Could not send report: No more routes to report
Is this a critical security issue?
Describe the Bug
On one of my nodes the OpenVox agent seems to regularly get stuck and not recover.
Interestingly a process list shows multiple processes still applying configuration:
If I run the agent on the CLI it connects and applies with no problem.
Expected Behavior
I would expect a connection or even apply run to time out after a while and the agent to just carry on eventually.
Steps to Reproduce
Just let the agent run, at least on this VM. I haven't been able to reproduce this elsewhere, but it has happened every few days for a week or so on this system.
Environment
Version: 9.0.0.alpha2-1+debian13
Platform: Debian 13 (trixie)
Additional Context
In case this makes any difference, this is a Linode, using IPv6 to reach the OpenVox server. I have other Linodes and VMs from other providers accessing the same OpenVox server over IPv6 which don't encounter this problem.
Relevant log output