Just thought I'd post that I cannot find a good workaround. I did find a *bad* workaround, which is to let the power management daemon just kill off soffice.
The reason this is better than the current bug is that the current bug has the potential to completely hang the system if you fail to kill soffice quickly. It's horrible, but I haven't found anything else that works. (One poster in the original launchpad bug suggested using compiz -replace in a pm.d script, but that did not work for me.)
Bad workaround
--------------
Create a file:
sudo touch /etc/pm.d/sleep.d/20_kill_soffice
sudo chmod +x /etc/pm.d/sleep.d/20_kill_soffice
Just thought I'd post that I cannot find a good workaround. I did find a *bad* workaround, which is to let the power management daemon just kill off soffice.
The reason this is better than the current bug is that the current bug has the potential to completely hang the system if you fail to kill soffice quickly. It's horrible, but I haven't found anything else that works. (One poster in the original launchpad bug suggested using compiz -replace in a pm.d script, but that did not work for me.)
Bad workaround d/sleep. d/20_kill_ soffice d/sleep. d/20_kill_ soffice
--------------
Create a file:
sudo touch /etc/pm.
sudo chmod +x /etc/pm.
Add these contents:
#!/bin/bash
PATH=/sbin: /usr/sbin: /bin:/usr/ bin
SELF=kill-soffice
COMMAND=
# pm-action(8) - <action> <suspend method> /bugs.launchpad .net/ubuntu/ +source/ nvidia- graphics- drivers- 180/+bug/ 185600
#
# On suspend|hibernate, kill soffice due to compiz-related hang:
# https:/
case "${1}" in
resume| thaw)
hibernate)
;;
# hope soffice's recovery function works.
pkill -f soffice.bin
;;
esac