On 02/04/2018 03:20 PM, David Hobach wrote: > Honestly I don't really understand why systemd was used at all for that > functionality. > > Anyway I did test your suggestion and unfortunately it didn't reliably > work for me: > 1/3 times it worked and that seemed to be the random chance of it > working that you also mentioned in your first bullet point. In fact I > followed your steps for 2m, tested it again after daemon-reload & it the > connection went through, then attempted 2 times after a reboot (the > service edit was still there) for which it worked once.
When I was testing it I used OnActiveSec=20 and OnUnitActiveSec=20 for speed up debugging. I had "journal -f -u qubes-relaod-firewall@VM-name.timer/service". I experimented that behavior, with OnActiveSec alone the service was triggered once. With OnUnitActiveSec it worked as expected and it seems reliable. Did you get a failure test after adding OnUnitActiveSec? Did you ping same host before expiration or tried different one? > My 3.2 test machine was pretty outdated though, i.e. maybe it also > depends on the systemd version running. > > Feel free to update the ticket though. In particular the observation > that there is a certain chance for it to work as expected is rather > interesting. > > Whether or not an ongoing connection such as a continuing ping should be > broken after timeout is a different topic btw - I guess there's some > RELATED, ESTABLISHED iptables rule that keeps it up. > > I also just noticed that the feature seems to exist in the 4.0 GUI. > Maybe I'll test that as well... It would be nice to found a fix for this but it should only break non-explicitly allowed connections? It seems pretty complex. > In total however using sth like > qvm-firewall [allow all] && sleep [time] ; qvm-firewall [remove allow all] > currently seems to be more reliable. > Totally agree, using systemd for this seems pretty overcomplex. Maybe using sleep could lead some problems with suspend/resume. Another option would be "while true if expiration then update&return else sleep X" Overall it's simply to fix in some of the possible ways. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0d713d27-d620-0fa0-ccab-b0c9ad4993dd%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Description: OpenPGP digital signature