On Wed, 2016-08-17 at 17:12 +0100, Joshua G Lock wrote: On Wed, 2016-08-17 at 16:09 +0000, Randle, William C wrote: On Wed, 2016-08-17 at 16:59 +0100, Joshua G Lock wrote:
On Tue, 2016-08-16 at 17:09 -0700, Bill Randle wrote: Use a common script to check for a running vnc server, and if not running cleanup dangling lock files and restart the server. [YOCTO #8210] Signed-off-by: Bill Randle <william.c.ran...@intel.com<mailto:william.c.ran...@intel.com>> --- bin/checkvnc | 10 ++++++++++ .../site-packages/autobuilder/buildsteps/RunESDKSanityTests.py | 3 +-- .../site-packages/autobuilder/buildsteps/RunOeSelftest.py | 3 +-- .../site-packages/autobuilder/buildsteps/RunSDKSanityTests.py | 3 +-- .../site-packages/autobuilder/buildsteps/RunSanityTests.py | 3 +-- 5 files changed, 14 insertions(+), 8 deletions(-) create mode 100755 bin/checkvnc diff --git a/bin/checkvnc b/bin/checkvnc new file mode 100755 index 0000000..574ba48 --- /dev/null +++ b/bin/checkvnc @@ -0,0 +1,10 @@ +#!/bin/sh +# +# check if vnc server is running, and if not, cleanup and restart +# +pid=$(pidof Xvnc) +if [[ $? != 0 ]]; then + echo "Xvnc not running, attempting restart" + vncserver -kill :1 + vncserver The vncserver is currently started with `vncserver :1`, whereas this script just calls `vncserver` — is that intentional/desirable? Would it be a little cleaner/more robust if we didn't assume only one Xvnc instance was running and instead write the pid of the process we start to a file and use that file to check the status? Regards, Joshua The vncserver program is a shell script and uses :1 as the default display. The pid of Xvnc is written to a file already. The problem is, if Xvmc crashes, the pid file (and lock file) are left around, so just looking at the pid file existance, you can't tell if it's actually running or not. Can we read the pid from the pidfile and do the tidy up if the process isn't running? My main concern here is that we assume only a single instance of Xvnc is running, I'm not sure if that is a safe assumption to make? I'll take a look at it. You can hold off merging this one for now. -Bill Thanks, Joshua
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
