4.0rc1 awesome restart causing systray app issues

[3hhh]

The systray apps added in 4.0rc1 do not check at startup whether they are already started.

Thus e.g. a lightdm restart will cause the apps to be started again.

[3hhh]

/etx/xdg/autostart/qui-devices.desktop
/etx/xdg/autostart/qui-domains.desktop

[3hhh]

/etx/xdg/autostart/qui-devices.desktop
/etx/xdg/autostart/qui-domains.desktop

[marmarek]

The problem is not (lack of) check at startup, but rather not exiting when you kill your session. I can't check it right now, but I'm almost sure that they do exit when you terminate X server... Anyway, this isn't the only thing that may be broken by restart of X server in dom0. Other examples: - qvm-start-gui have the same problem - audio from VM do not recover after it - probably more... So, while there is some code to recover VM GUI after such event (so your applications running in VM survive X restart), I'd still treat X server restart as something that should be avoided if possible.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

The problem is not (lack of) check at startup, but rather not exiting when you kill your session. I can't check it right now, but I'm almost sure that they do exit when you terminate X server... Anyway, this isn't the only thing that may be broken by restart of X server in dom0. Other examples: - qvm-start-gui have the same problem - audio from VM do not recover after it - probably more... So, while there is some code to recover VM GUI after such event (so your applications running in VM survive X restart), I'd still treat X server restart as something that should be avoided if possible.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[3hhh]

I renamed it accordingly.

Just also noticed that dispVM instances are not deleted on systemctl restart lightdm.

[3hhh]

I renamed it accordingly.

Just also noticed that dispVM instances are not deleted on systemctl restart lightdm.

[3hhh]

I agree that it's not common user behavior and should thus only be low prio though.

[3hhh]

I agree that it's not common user behavior and should thus only be low prio though.

[kalkin]

@3hhh

Thus e.g. a lightdm restart will cause the apps to be started again.

How do you know they're started? Did you see them in ps(1)?

Just also noticed that dispVM instances are not deleted on systemctl restart lightdm.

It's because they're X client instances are not killed and can be recovered by starting qvm-start --gui

[kalkin]

@3hhh

Thus e.g. a lightdm restart will cause the apps to be started again.

How do you know they're started? Did you see them in ps(1)?

Just also noticed that dispVM instances are not deleted on systemctl restart lightdm.

It's because they're X client instances are not killed and can be recovered by starting qvm-start --gui

[3hhh]

@3hhh

Thus e.g. a lightdm restart will cause the apps to be started again.

How do you know they're started? Did you see them in ps(1)?

Yes, exactly. ps aux | grep python3 or so. Unfortunately I currently cannot test it again as they're not started anymore at all for some reason.

Just also noticed that dispVM instances are not deleted on systemctl restart lightdm.

It's because they're X client instances are not killed and can be recovered by starting qvm-start --gui

Hm ok, that's expected. It would be nice if they'd be cleaned up during Qubes shutdown though as they tend to survive a laptop reboot if I recall correctly.
Unfortunately the last testing repo pull also broke my dispoable VMs so I cannot test that atm neither, sorry...

I'll provide an update once my system is more stable again...

[3hhh]

@3hhh

Thus e.g. a lightdm restart will cause the apps to be started again.

How do you know they're started? Did you see them in ps(1)?

Yes, exactly. ps aux | grep python3 or so. Unfortunately I currently cannot test it again as they're not started anymore at all for some reason.

Just also noticed that dispVM instances are not deleted on systemctl restart lightdm.

It's because they're X client instances are not killed and can be recovered by starting qvm-start --gui

Hm ok, that's expected. It would be nice if they'd be cleaned up during Qubes shutdown though as they tend to survive a laptop reboot if I recall correctly.
Unfortunately the last testing repo pull also broke my dispoable VMs so I cannot test that atm neither, sorry...

I'll provide an update once my system is more stable again...

[kalkin]

It would be nice if they'd be cleaned up during Qubes shutdown though as they tend to survive a laptop reboot if I recall correctly

They can't survive a reboot. They only survive a X-server restart.

[kalkin]

It would be nice if they'd be cleaned up during Qubes shutdown though as they tend to survive a laptop reboot if I recall correctly

They can't survive a reboot. They only survive a X-server restart.

[3hhh]

They can't survive a reboot. They only survive a X-server restart.

I'm a tester, not a believer...

Anyway the dispVM issue does not seem to be related to X server restarts - thus I created #3037 for that one.

@Original issue:
It appears to be awesome-specific only.

More precisely it seems to be caused by repeated executions of
dex-autostart -a -e XFCE
(https://github.com/QubesOS/qubes-desktop-linux-awesome/blob/master/awesome-3.5.5-dex-autostart.patch)
during awesome restarts.

Btw my dispVMs started working again after the apps were started again.

[3hhh]

They can't survive a reboot. They only survive a X-server restart.

I'm a tester, not a believer...

Anyway the dispVM issue does not seem to be related to X server restarts - thus I created #3037 for that one.

@Original issue:
It appears to be awesome-specific only.

More precisely it seems to be caused by repeated executions of
dex-autostart -a -e XFCE
(https://github.com/QubesOS/qubes-desktop-linux-awesome/blob/master/awesome-3.5.5-dex-autostart.patch)
during awesome restarts.

Btw my dispVMs started working again after the apps were started again.

[kalkin]

@3hhh > More precisely it seems to be caused by repeated executions of

Ohh you mean that error. :) I know about it and this is on my agenda, but it's low priority, because it's not part of the main Qubes project.

I'm a tester, not a believer...

I think I misunderstood you. I thought you mean the X clients of the dispvm survive reboot. Thanks for opening a new issue.

[kalkin]

@3hhh > More precisely it seems to be caused by repeated executions of

Ohh you mean that error. :) I know about it and this is on my agenda, but it's low priority, because it's not part of the main Qubes project.

I'm a tester, not a believer...

I think I misunderstood you. I thought you mean the X clients of the dispvm survive reboot. Thanks for opening a new issue.

[kalkin]

@3hhh If you have some time, have a look at the Awesome exit Signal. It has a parameter for restart. So you can only execute dex-autostart on startup.

[kalkin]

@3hhh If you have some time, have a look at the Awesome exit Signal. It has a parameter for restart. So you can only execute dex-autostart on startup.

[kalkin]

@3hhh Looking more in to the exit Signals it seems not to help much. While you find out if awesome is currently restarted on exit, but after restart it will reparse the rc.lua and you are back where you started ☹

[kalkin]

@3hhh Looking more in to the exit Signals it seems not to help much. While you find out if awesome is currently restarted on exit, but after restart it will reparse the rc.lua and you are back where you started ☹

[cyrinux]

Hi, there is the same systray problem with i3. And gui not recevered after a X crash due to low memory for example and relogin.

[cyrinux]

Hi, there is the same systray problem with i3. And gui not recevered after a X crash due to low memory for example and relogin.

[3hhh]

This fixes it and was tested to work at least with 4.0rc1 even after system crashes (power removed):

--returns true, if the awesome autostart should run (didn't run before already)
local function autostartRequired()
	local lockFilePath = "/tmp/awesome-autostart"
	local lockFile = io.open(lockFilePath,"r")
		if lockFile == nil then

			--create the file
			lockFile = io.open(lockFilePath,"w")
			io.close(lockFile)

			return true
		else
			io.close(lockFile)
			return false
		end
end

--run autostart programs on first boot (awesome restarts won't trigger this)
if autostartRequired() then
	-- Use dex to run the xdg autostart files
	-- for the moment run the ones for XFCE
	awful.util.spawn_with_shell("dex-autostart -a -e XFCE")

	--custom autostart
	-- [...]
end

[3hhh]

This fixes it and was tested to work at least with 4.0rc1 even after system crashes (power removed):

--returns true, if the awesome autostart should run (didn't run before already)
local function autostartRequired()
	local lockFilePath = "/tmp/awesome-autostart"
	local lockFile = io.open(lockFilePath,"r")
		if lockFile == nil then

			--create the file
			lockFile = io.open(lockFilePath,"w")
			io.close(lockFile)

			return true
		else
			io.close(lockFile)
			return false
		end
end

--run autostart programs on first boot (awesome restarts won't trigger this)
if autostartRequired() then
	-- Use dex to run the xdg autostart files
	-- for the moment run the ones for XFCE
	awful.util.spawn_with_shell("dex-autostart -a -e XFCE")

	--custom autostart
	-- [...]
end

[3hhh]

The above just didn't work with an X server restart. :-(

Maybe some pgrep solution is more reliable...

[3hhh]

The above just didn't work with an X server restart. :-(

Maybe some pgrep solution is more reliable...

[3hhh]

The following appears to work:

-- Use dex to run the xdg autostart files
-- for the moment run the ones for XFCE
-- NOTE: awful.util.spawn_with_shell() does some really unpredictable stuff wrt quoting --> you are better off with calling spawn() with your favorite shell and controlling the quoting yourself; still it may not work in awesome, even if it works in your shell
awful.util.spawn('bash -c "pgrep -f -a mqui.tray | grep -v $$ || dex-autostart -a -e XFCE"')

Even minor changes may break it again though due to the unreliable nature of both spawn() and spawn_with_shell() (the latter appears to be even worse).

[3hhh]

The following appears to work:

-- Use dex to run the xdg autostart files
-- for the moment run the ones for XFCE
-- NOTE: awful.util.spawn_with_shell() does some really unpredictable stuff wrt quoting --> you are better off with calling spawn() with your favorite shell and controlling the quoting yourself; still it may not work in awesome, even if it works in your shell
awful.util.spawn('bash -c "pgrep -f -a mqui.tray | grep -v $$ || dex-autostart -a -e XFCE"')

Even minor changes may break it again though due to the unreliable nature of both spawn() and spawn_with_shell() (the latter appears to be even worse).

[kalkin]

@3hhh Thanks. I will integrate this in my Awesome 4.1 patches QubesOS/qubes-desktop-linux-awesome#10

[kalkin]

@3hhh Thanks. I will integrate this in my Awesome 4.1 patches QubesOS/qubes-desktop-linux-awesome#10

[3hhh]

For ref: Currently I'm using the method depicted in #3626 to do the autostart.

[3hhh]

For ref: Currently I'm using the method depicted in #3626 to do the autostart.