-
Notifications
You must be signed in to change notification settings - Fork 296
Description
I've noticed this a few times now, and have now tried a few experiments to confirm it.
It might not count as a bug, and could just need explaining more clearly in the documentation?
My expectation was that --idle would work by wall clock time; is it supposed to be based on active CPU time?
However I don't think it is working from CPU time either; what I think might be happening is that the suspend/resume action counts as activity?
Experiment 1:
Mounted an encrypted folder at 16:59:00. ps shows it as: /usr/bin/gocryptfs -fg -notifypid=24350 -idle=2m /home/example/xxxenc /home/example/xxx
I opened a file under "xxx", then closed that application at 16:59:30.
I then suspended the machine from approx 16:59:40 until 17:01:40.
Resuming I still see it (with ps) at 17:02.
By 17:04 it has disappeared (i.e. been automatically unmounted).
Experiment 2:
I've repeated the test with --idle=4m and paying more attention to exact timing.
Mounted at 17:09:00, quick bit of activity closed at 17:09:20, machine suspended from 17:09:30.
Resumed at 17:11:13.
So the 4 minutes of idle by the wall clock would be up at 17:13:20.
If it works by 4 minutes of CPU time from last activity that would be 17:15:03 or so.
It stayed mounted until 17:15:26. I.e. just over 4 minutes from the resume time.
That might be a bit close to be convincing, but it matches my more casual observations.
Repeating the experiment but waiting to suspend until almost all the wait has been done should make it clearer?
Request:
Does anyone have a ready-made (systemctl service) script to unmount all gocryptfs mounted directories on suspend?
That would effectively solve the security issue for my use cases, at least.