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 qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to