If the failure is what we think it is, then this would have always been an issue, though I've only actually seen this happen during SR2019.
The symptom is that when running srcomp-kiosk restart on one of the Pis, the browser does indeed stop, however it doesn't come back up again.
It seems likely that this is caused by the stop command being handled as a non-blocking command which kills the underlying processes. If they don't actually exit fairly quickly, then when it moves on to the start the underlying process is still running and will either fail to start (as there's another copy of itself running) or will pass its arguments onwards and then exit quickly (like firefox opening a new tab rather than launching a new independent process).
From what I recall, the srcomp-kiosk status command does correctly report that it is not running after this failure mode is encountered.
If the failure is what we think it is, then this would have always been an issue, though I've only actually seen this happen during SR2019. The symptom is that when running
srcomp-kiosk restarton one of the Pis, the browser does indeed stop, however it doesn't come back up again.It seems likely that this is caused by the
stopcommand being handled as a non-blocking command whichkills the underlying processes. If they don't actually exit fairly quickly, then when it moves on to thestartthe underlying process is still running and will either fail to start (as there's another copy of itself running) or will pass its arguments onwards and then exit quickly (like firefox opening a new tab rather than launching a new independent process).From what I recall, the
srcomp-kiosk statuscommand does correctly report that it is not running after this failure mode is encountered.