Bug: LockException on VM shutdown

[jamoore]

Accessing config.xml lead to a lockexception. See screenshot

[cmacleod-x]

Not familiar with the lock exception but I'm assuming this is due to ordering upon shutdown. Have a recommendation on how to fix it?

[cmacleod-x]

Which VM version is this as well?

[cmacleod-x]

Unable to reproduce on 4.3.4 nor on a recent snapshot. Tested both an external shutdown by virtualbox as well as a shutdown from inside the OS.

[jmoore]

Note: just started up the RC2 build and omero web wasn't running. On trying /etc/init.d/omero-web status I got this:

root@omerovm:/etc/init.d# /etc/init.d/omero-web status
Status omero-web:OMERO.web status... Traceback (most recent call last):
  File "/home/omero/OMERO.server/bin/omero", line 123, in <module>
    rv = omero.cli.argv()
  File "/home/omero/OMERO.server/lib/python/omero/cli.py", line 1184, in argv
    cli.invoke(args[1:])
  File "/home/omero/OMERO.server/lib/python/omero/cli.py", line 734, in invoke
    stop = self.onecmd(line, previous_args)
  File "/home/omero/OMERO.server/lib/python/omero/cli.py", line 803, in onecmd
    self.execute(line, previous_args)
  File "/home/omero/OMERO.server/lib/python/omero/cli.py", line 883, in execute
    args.func(args)
  File "/home/omero/OMERO.server/lib/python/omero/plugins/web.py", line 365, in status
    import omeroweb.settings as settings
  File "/home/omero/OMERO.server/lib/python/omeroweb/settings.py", line 156, in <module>
    raise exctype, value
portalocker.LockException: (1, 'Resource temporarily unavailable')

[bpindelski]

Reopening. Another type of lock exception happening now... Would be maybe good to add some timeout logic in the shutdown script? Added lock-exception.png

[cmacleod-x]

What memory settings are configured on the VM, also what version of virtualbox?

[bpindelski]

It's the VM from build #399. 1024 MB of RAM. VirtualBox? 4.1.18 on OS X 10.6.8.

[jmoore]

Nothing we can do about it in 4.4.0

[cmacleod-x]

fixed in ​https://github.com/stick/openmicroscopy/commit/53846469e0109926e2456da54e22276949fdb6e2
Looks like it was a race condition between an existing session and when postgres was shutdown. I've fixed the deps in the initscripts to do things in a more correct order. Debian's boot process runs all scripts of the same level concurrently so the race condition was exasperated.