gmodena / nix-flatpak

Install flatpaks declaratively
Apache License 2.0
302 stars 10 forks source link

Add 5-second delay before attempting Flatpak updates #67

Closed cig0 closed 5 months ago

cig0 commented 5 months ago

Hello everyone,

I've submitted this pull request to resolve https://github.com/gmodena/nix-flatpak/issues/45, where flatpak-managed-install.service attempts Flatpak updates before NetworkManager can fully establish a network connection, leading to the service failing.

I've introduced a brief 5-second delay upon initial login after a reboot to address this. This minor adjustment ensures NetworkManager has adequate time to provide an IP address to our wireless network interface, preventing update failures due to premature connection attempts.

I welcome your insights and feedback on this approach to improve the reliability of the service update process.

If you have any questions, a troubleshooting discussion on the linked issue is available.

Thank!

cig0 commented 5 months ago

Hmm now that I think about it, if you like this approach I believe we should bump the wait a bit.

If I recall correctly, the folks at https://universal-blue.org wait a few minutes after the user has logged in before triggering the system updates, similarly using a systemd timer—my 2 cents.

gmodena commented 5 months ago

Hey @cig0 thanks for this!

"I would prefer not to adopt this workaround yet; at least till I have a better understanding of the failing scenario (still trying to repro).

One drawback I see, is that this change would introduce a 5s busy wait on every boot. This would introduce delay on systems that don't have the same networkd / nix-flatpak failure you reported.

Might we end up adopting this workaround, I would like the timeout to be user configurable via a services.flatpak option. Also, just FYI, the home-manager unit would need to be adjusted too.

cig0 commented 5 months ago

Hey @cig0 thanks for this!

"I would prefer not to adopt this workaround yet; at least till I have a better understanding of the failing scenario (still trying to repro).

One drawback I see, is that this change would introduce a 5s busy wait on every boot. This would introduce delay on systems that don't have the same networkd / nix-flatpak failure you reported.

Might we end up adopting this workaround, I would like the timeout to be user configurable via a services.flatpak option. Also, just FYI, the home-manager unit would need to be adjusted too.