qubes-updates-proxy: Start request repeated too quickly #9110
Comments
kaie
added
P: default
|
Can you check earlier logs why it failed initially? You can get it with |
andrewdavidwong
added
needs diagnosis
|
I guess you meant "-b -u" (not "b -u") |
|
I think the lines 14-17 it complains about are: MinSpareServers 2 |
|
I think the above log isn't helpful to understand the reason for the restart. Apr 12 16:26:24 sys-net systemd[1]: tinyproxy.service - Tinyproxy lightweight HTTP Proxy was skipped because of an unmet condition check (ConditionPathExists=/var/run/qubes-service/tinyproxy). Should that maybe check for tinyproxy.pid ? |
|
Hmm, not sure my theory is right. The existing script looks for something in /var/run/qubes-service/ The pid file I had suggested to check for is in |
|
tinyproxy.service is a different thing than qubes-updates-proxy.service. Do you see any other log entries? Maybe NetworkManager is quickly changing settings (updates proxy is reloaded on each IP change) |
|
Your theory that it has to do with IP addresses and network manager was correct. My laptop was connected to the network with an ethernet cable, and in addition it was in reach of a wifi network that was configured for automaatic connection. At startup, network manager reports that it connected to both. With ethernet disconnected, the updates-proxy stay up, no error. The problem happens for me if network manager is able to connect using two different methods at the same time. |
|
I can confirm @kaie's findings: When my laptop is connected to LAN and Wifi at the same time then the updates proxy is down. |
|
I have too many vlans connected via ethernet. I can confirm that is the reason "start-limit-hit" on qubes-updates-proxy.service . I modified sys-net (where my qubes-updates-proxy.service is running) /lib/systemd/system/qubes-updates-proxy.service file. Added StartLimitBurst=0 under [Service]. It solved for me. Ref: https://www.suse.com/support/kb/doc/?id=000019750 |
NetworkManager will call the hook when anything about the connection changes. In some cases (like multiple connections) this can be quite often and restarting tinyproxy each time will eventually trigger restart rate limit and keep the service down. But even if not hitting this limit, restart interrupts any download in progress. Add a check if DNS addresses actually changed since the las hook call, and restart the service only when necessary. As a side effect, this will also avoid restarting the service on DHCP lease renew. Fixes QubesOS/qubes-issues#9110
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The package |
andrewdavidwong
added
diagnosed
NetworkManager will call the hook when anything about the connection changes. In some cases (like multiple connections) this can be quite often and restarting tinyproxy each time will eventually trigger restart rate limit and keep the service down. But even if not hitting this limit, restart interrupts any download in progress. Add a check if DNS addresses actually changed since the las hook call, and restart the service only when necessary. As a side effect, this will also avoid restarting the service on DHCP lease renew. Fixes QubesOS/qubes-issues#9110 (cherry picked from commit 01aa298)
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
How to file a helpful issue
Qubes OS release
4.2
Brief summary
qubes-updates-proxy fails to start in sys-net.
systemctl status qubes-updates-proxy
reports:
Steps to reproduce
Shut down all VMs.
Start up sys-net, either directly or indirectly.
Try to update a qube, which fails.
Open a terminal in sys-net and check systemctl, the above service has failed to start.
I can manually work around the issue, after sys-net has started, by running this command:
systemctl start qubes-updates-proxy
Additional notes
I originally mentioned my update problems in issue #9025 and claimed it had to with the template that sys-net was based on.
That was an incorrect statement, I had incorrectly concluded that, I got misled during my various attempts to resolve that issue on my system.
The new issue I'm reporting happens regardless of the template used for sys-net, I tried both debian-12-xfce and fedora-39-xfce.
The text was updated successfully, but these errors were encountered: