Windows: wait for processes started as user #348
Conversation
When running background maintenance from the service, we want to wait for the process to finish to guarantee we do not have multiple maintenance activities running at the same time. However, we have a custom runner to launch the `scalar run` processes. This runner does not properly wait for the process to end, so we quickly launch all of the maintenance activities at once. This can be particularly bad after opening a laptop after a long sleep. By adding a wait, we will actually ensure that only one maintenance activity runs at a time. Resolves the root cause of microsoft#328 Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Thankfully, the Mac verb runner waits for the process to complete.
The only thing I can think about is to somehow have the runner launch a process that waits for X seconds before returning, then timing how long the method takes. This seems like a problematic way to test. |
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
7c585f9 to
0e53265
Compare
|
you could launch a process that waits in a loop while a lockfile on disk exists and then exit. have the tester create the lockfile and then do a waitforsingleobject with a timeout loop and delete the lockfile at some point. have the test confirm the the child exits after but not before that. or just let the child do a long sleep and have the tester send a SIGHUP or SIGTERM. |
When running background maintenance from the service, we want to wait
for the process to finish to guarantee we do not have multiple
maintenance activities running at the same time. However, we have a
custom runner to launch the
scalar runprocesses. This runner doesnot properly wait for the process to end, so we quickly launch all of
the maintenance activities at once. This can be particularly bad after
opening a laptop after a long sleep.
It is reasonable that we were not waiting before, because this is the
same way that we launch the Scalar.Service.UI executable, and we
cannot wait for that to close.
By adding a wait (only in the case of maintenance verbs), we will
actually ensure that only one maintenance activity runs at a time.
Resolves the root cause of #328.
For evidence that this changes how this works, here is how the old service would run several config steps at startup:
and here is the new service:
Notice that before, these steps all launched in about 1.0
seconds, but actually waiting for the processes to complete
takes 26 seconds.