Am 12.07.20 um 14:37 schrieb unman: > On Fri, Jul 10, 2020 at 01:04:40PM +0200, Phil Kn??fer wrote: >> Hi, >> >> when accessing an SMB share in a Qubes AppVM after the system has been >> suspended for some time, I experience a serious lag (up to about a >> minute or so for each share that is mounted from the same SMB server). >> This seems to be due to the fact that the server has already timed out >> the SMB session, while the client (the AppVM) is still trying to resume >> it and therefore runs in TCP timeouts. >> >> For bare-metal Linux systems, a possible solution is to unmount all SMB >> shares before the system goes into suspend (e.g., via a script in >> /usr/lib/systemd/system-sleep or via pm-utils). >> >> I tried this approach in Qubes but it seems that the AppVMs do not know >> about a suspend event. Is there a way to trigger scripts on suspend in >> Qubes AppVMs or do I need to coordinate the SMB unmount from dom0 (it >> should be possible to trigger a script there that interacts with VMs via >> qvm-run or similar)? >> >> >> Regards, >> Phil >> >> > I think that the dom0 route is the way to go - it's what I use myself. > If you did find a way in the qube of detecting such events, I'd be > interested.
I just had the time to look into this. Analyzing journalctl in an AppVM I saw the line: Jul 22 18:45:04 work qrexec-agent[6750]: executed root:QUBESRPC qubes.SuspendPreAll dom0 pid 6753 A quick web search yielded this Github issue: https://github.com/QubesOS/qubes-issues/issues/1663 TL;DR: I haven't tested it yet but it seems placing the PRE- and POST-suspend files in /etc/qubes/suspend-pre.d/ and /etc/qubes/suspend-post.d/ should do the trick. Regards, Phil -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1ede7803-20d4-f93b-a3fa-0f441ca61c7c%40digitrace.de.
