Closed marmarek closed 6 years ago
Maybe it's a different issue - in my case it finishes but takes a long time because /tmp is busy and cannot be unmounted, which in turn prevents luks from being closed, which then prevents the underlying device from being stopped, which triggers a handful of timeouts. Eventually systemd shutdowns/reboots the machine though. The issue is reproducible, I get that problem each time I shutdown. Note: Qubes' install was done with auto partitioning - no fancy custom stuff here.
log's excerpt attached: journal-shutdown.txt
I encounter this occasionally on R2 too.
FWIW, tried to debug this as per https://wiki.freedesktop.org/www/Software/systemd/Debugging/#index2h1 ; for some reason /var/lib/xenstored can't be unmounted, the umount process dies with return status 32. See [173.256405] and [173.265964] lines onward in the attached systemd debug output.
I'm suffering from this problem also. There are times when I've returned to the room hours later to find the laptop stuck on "waiting for 2 jobs" i.e. mounted volumes.
The power management stack ought to have a low-level timeout feature that turns off the power no matter what, once the shutdown process has been started from the UI.
I think I've isolated this problem - In my case I have a proxy VM I use for VPN, and shutdown fails only when the proxy VM is running at the same time as other VMs that rely on it for networking. Seems like there should be some 'reverse shutdown order' so that dependent VMs are shut down first, and then the proxy VM.
Trying to shut down the proxy VM by hand fails saying 'there are other VMs connected to this VM' so maybe that's what's happening.
Could anyone try to replicate this? I can shut down the system reliably if I manually shut down the VMs in the correct reverse order first.
Hi, I can confirm you, I have the same problem and same temporary solution. Regards,
Le jeu. 12 mai 2016 10:33, Lorenzo G. notifications@github.com a écrit :
I think I've isolated this problem - In my case I have a proxy VM I use for VPN, and shutdown fails only when the proxy VM is running at the same time as other VMs that rely on it for networking. Seems like there should be some 'reverse shutdown order' so that dependent VMs are shut down first, and then the proxy VM.
Trying to shut down the proxy VM by hand fails saying 'there are other VMs connected to this VM' so maybe that's what's happening.
Could anyone try to replicate this? I can shut down the system reliably if I manually shut down the VMs in the correct reverse order first.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/QubesOS/qubes-issues/issues/1581#issuecomment-218693602
Shutting down all VMs indeed solves the problem. But I don't have a proxyVM, the problem in my case is because sys-net's kernel crashes during shutdown (probably issue #1978.). Either I need to kill it, or wait for a timeout.
I have had this problem also. Haven't tried any workarounds yet.
A small update - running qvm-shutdown --all works intermittently - if I turn off the VPN first it works more reliably but it still hangs occasionally when trying to shutdown the 'VPN' VM, regarless of the VPN state.
@lorenzog adding --force to qvm-shutdown is supposed to shut them all down regardless of network dependency... But even that doesn't work. I get the same hang and logged issue #1826 for it. BTW, I also use a VPN VM extensively.
On 2016-11-16 13:27, Loren Rogers wrote:
On 11/16/2016 02:33 PM, Grzesiek Chodzicki wrote:
W dniu środa, 16 listopada 2016 20:04:14 UTC+1 użytkownik Loren Rogers napisał:
Hi all,
I've successfully installed Qubes on my Thinkpad X201 tablet, but it has issues shutting down. When I explicitly tell it to reboot or shutdown, it goes through the entire shutdown sequence, but hangs on an empty black screen. Occasionally, I see an unchanging white underscore (_) character displayed in the top left when it hangs.
I tried leaving it in this state for about an hour, and no change--I've always had to force-reset. I assume this is not normal?
Also, I find that the system randomly begins the shutdown sequence on its own. (And hangs on the black screen at the end.)
Thanks, Loren The same issue occurs on my system only if I shut the system down while a VM with a PCI device without FLR support is running
Also, I just confirmed that it shuts down cleanly with all VMs off and no USB devices plugged in.
I may backtrack my comment a little--I've since had one instance where it wouldn't shut down even with nothing plugged in. The sys-net VM is connected to a VPN, but I don't believe that this has been correlated with the shutdown issue.
Perhaps on a related note, I believe my machine may be having overheating issues, a known problem with non-Windows distros on the Lenovo X201t. It randomly shuts down completely without warning.
I believe the VPN shutdown delay is a consistent problem, but that its separate from the problem of the system not reaching power-off/reset. If I stop the openvpn process in VPN VM before I shutdown, the delay will still occur (whether I'm doing a regular shutdown, or a qvm-shutdown --all).
OTOH, if I have no VMs running a system shutdown can still hang.
With R3.2, the VPN shutdown delay always occurs but the failure to shutdown occurs only around 2% of the time (irregularly).
FWIW, I've been using simple shutdown and reboot scripts to work around this issue (I think since I first started using Qubes). Here's an example:
#!/bin/bash
qvm-shutdown --wait --all \
--exclude=sys-net \
--exclude=sys-firewall \
--exclude=sys-usb \
--exclude=sys-whonix \
qvm-shutdown --wait --all
sleep 3
shutdown now
Works every time. The idea is to exclude all service VMs from the first pass of qvm-shutdown
so that it doesn't jam up (#1826), so if you use VPN VMs, exclude those too.
User requests to substitute scripts like the one above (https://github.com/QubesOS/qubes-issues/issues/1581#issuecomment-266266876) as the default reboot and shutdown scripts here.
Any chance of this happening for 4.0, @marmarek?
(Also see: #1826)
@andrewdavidwong Your script works great for me - very handy! Just confirming that this works on my machine. It would be great if we could have this as the default shutdown operation.
Actually - I've been using a simplified version of this, which has been fine for me:
#!/bin/bash
qvm-shutdown --all --wait
shutdown now
I've not noticed it jamming up, but it may just be my particular installation setup.
Looks like the reason why --wait --all
works, and just --wait
(without --all
) doesn't, is because --wait
keeps retrying to shutdown the VMs every x seconds (where x=1 or 2?). Otherwise, if I have VM work
which depends on sys-firewall
which in turn depends on sys-net
, with qvm-shutdown --all
it will only shutdown the work
one, so I have to rerun the command two more times for the other two dependent VMs to ensure all are shutdown - meanwhile qvm-shutdown --all --wait
does all this on its own and it only takes it 11 seconds. After this, the dom0 shutdown happens under 10 seconds, instead of minutes like before.
In other words, --wait
implies a --retry
(not an actual option) which was highly unexpected. But hey, it does the job.
Can this --wait
be added to the existing qvm-shutdown
call that, I assume, happens when dom0 is being shutdown (when the purpose is to shutdown the computer), this would avoid all the epic delay(of at least 1 minute) that would otherwise happen due to not all VMs being shutdown by a, presumably, qvm-shutdown --all
(without a --wait
) that happens in the background. You get the picture.
Thanks.
EDIT: (I meant all this for R4.0)
Maybe the --wait
was already added recently, I just tested this and it did shutdown fast(ish) even with sys-net
and sys-firewall
VMs started. I haven't tested it since a few weeks ago. The only things that still appeared (compared to when no VMs were started before shutdown) are the luks spamming line from https://github.com/QubesOS/qubes-issues/issues/2593
EDIT2 I stand corrected, the delay is still there and it's at least 90 seconds more IFF I also have work
VM started (so work
<- sys-firewall
<- sys-net
are started, then shutdown from dom0 xfce's menu will take at least 90 seconds to complete)
There is already --wait
option: https://github.com/QubesOS/qubes-core-admin/blob/master/linux/systemd/qubes-core.service#L13
There is already
--wait
option: https://github.com/QubesOS/qubes-core-admin/blob/master/linux/systemd/qubes-core.service#L13
This will fail and leave some VMs running (hence the a shutdown hang) if qubesd sends an empty response at any point because it threw an exception. DispVM destruction seems to be a common trigger - here's a random log:
qubesd[1318]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.Kill' dest=b'disp8244' arg=b'' len(untrusted_payload)=0
qubesd[1318]: Traceback (most recent call last):
qubesd[1318]: File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 260, in respond
qubesd[1318]: self.send_event)
qubesd[1318]: File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 127, in __init__
qubesd[1318]: self.dest = self.app.domains[dest.decode('ascii')]
qubesd[1318]: File "/usr/lib/python3.5/site-packages/qubes/app.py", line 465, in __getitem__
qubesd[1318]: raise KeyError(key)
qubesd[1318]: KeyError: 'disp8244'
qubesd[1318]: socket.send() raised exception.
But there are many similar situations, where some qvm-
tool or qui widget invokes an admin method on a VM that was just destroyed, and qubesd throws an exception instead of sending an error response.
There is already --wait option: https://github.com/QubesOS/qubes-core-admin/blob/master/linux/systemd/qubes-core.service#L13
I can confirm that is true on my system also(I checked, just in case).
Perhaps @rustybird above is on to something.
I don't know why qvm-shutdown -q --all --wait
isn't able to do its job from qubes-core.service
, (is a socket already closed?) but it seems as if that's the case. Or, maybe it's something else?
@marmarek I'm hoping that the following partial contents from journalctl -b -1
and dmesg
, where it takes at least 2 minutes to reboot(Start->Logout->Restart, from xfce), help you get an idea about what's going on:
With systemd.log_target=kmsg
in /proc/cmdline (via /boot/efi/EFI/qubes/xen.cfg
) I notice that on the first console (Alt+F1) it says that systemd is waiting for 8 jobs to finish and I believe that none finish and the above journalctl -b -1
shows that they timed out and they were killed.
Sep 02 19:04:09 dom0 systemd[1]: session-2.scope: Stopping timed out. Killing. Sep 02 19:04:09 dom0 systemd[1]: session-2.scope: Killing process 3570 (qubes-guid) with signal SIGKILL.
That's interesting, what happens if you manually kill all qubes-guid processes, then initiate shutdown/reboot?
For comparison(with the above), please allow me to post the partial logs from when the reboot does not stall(for 2min) but rather, finishes in what seems to be like 6 seconds (I already ran a qvm-shutdown --all --wait
which took 13 sec before the Start->Logout->Restart):
That's interesting, what happens if you manually kill all qubes-guid processes, then initiate shutdown/reboot?
The delay seems to be greatly reduced (down to 18 seconds - looking at journal's time between System is rebooting.
and Journal stopped
). EDIT looks like this 18seconds boot was a fluke because it sometimes is fast(er) and sometimes is slower (like 50 seconds).
I used ps auxw|grep -i qubes-guid
to see how many there were (3), then pkill qubes-guid
, then checked that all 3 were gone via ps auxw|grep -i qubes-guid
.
Ok, see if https://github.com/QubesOS/qubes-core-admin/pull/227 helps.
I wonder why device-mapper still complains, now when all domains are properly terminated, DM cleanup should also work. Maybe some other process keep it busy? Can you list processes at that time? And domains with xl list
(maybe some is left there anyway?).
Can you list processes at that time? And domains with xl list (maybe some is left there anyway?).
I did it like this:
[Unit]
Description=Qubes Dom0 startup setup
After=qubes-db-dom0.service libvirtd.service xenconsoled.service qubesd.service qubes-qmemman.service
# Cover legacy init.d script
[Service]
Type=oneshot
StandardOutput=syslog
RemainAfterExit=yes
# Needed to avoid rebooting before all VMs have shut down.
TimeoutStopSec=180
ExecStart=/usr/lib/qubes/startup-misc.sh
ExecStop=-/usr/bin/pkill qubes-guid
ExecStop=/usr/bin/qvm-shutdown --verbose --all --wait
# QubesDB daemons stop after 60s timeout in worst case; speed it up, since no
# VMs are running now
ExecStop=-/usr/bin/pkill qubesdb-daemon
ExecStopPost=-/usr/bin/ps axuw
ExecStopPost=-/usr/bin/xl list
[Install]
WantedBy=multi-user.target
Also=qubes-meminfo-writer-dom0.service qubes-qmemman.service
Alias=qubes_core.service
I didn't know how else to do it (and not risk bricking my system).
I can't figure out why the outputs from ps
, xl
and others are intermingled - I doubt they are all executed at the same time (I mean, I hope they aren't). I firstly tried with just ExecStop
instead of ExecStopPost
, but got the same intermingled output.
Note that in the logs from this post(and any future ones) I decreased the systemd default timeouts from 90 to 30 seconds:
DefaultTimeoutStartSec=30s
DefaultTimeoutStopSec=30s
in /etc/systemd/system.conf
So the following reboot took at least 47 seconds to finish: Not sure why it did NOT take only 18 seconds like the last time.
EDIT:
I'm not sure how relevant this is but, xl list
reports some (null)
VMs(apparently sys-net
and sys-firewall
leftovers!) after qvm-shutdown --all --wait
finishes, for a few more seconds, like:
$ ./preshutdown
Name ID Mem VCPUs State Time(s)
Domain-0 0 4077 6 r----- 333.8
sys-net 1 384 2 -b---- 9.4
sys-net-dm 2 144 1 -b---- 72.7
sys-firewall 3 3648 2 -b---- 32.4
gitsites-baseon-w-s-f-fdr28 4 3983 2 -b---- 126.8
gmail-basedon-w-s-f-fdr28 5 3671 2 -b---- 30.0
stackexchangelogins-w-s-f-fdr28 6 3655 2 -b---- 14.9
2018-09-03 01:20:02,820 [MainProcess selector_events.__init__:65] asyncio: Using selector: EpollSelector
real 0m14.026s
user 0m0.066s
sys 0m0.021s
exitcode: '0'
Name ID Mem VCPUs State Time(s)
Domain-0 0 4095 6 r----- 348.5
(null) 1 0 1 --ps-d 10.2
(null) 3 0 0 --ps-d 33.4
[ctor@dom0 ~]$ xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4095 6 r----- 349.4
(null) 1 0 1 --ps-d 10.2
[ctor@dom0 ~]$ xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4095 6 r----- 349.7
(null) 1 0 1 --ps-d 10.2
[ctor@dom0 ~]$ xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4095 6 r----- 349.8
[ctor@dom0 ~]$ xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 4095 6 r----- 350.3
[ctor@dom0 ~]$
where preshutdown
is:
#!/bin/bash
xl list
time qvm-shutdown --verbose --all --wait; echo "exitcode: '$?'"
xl list
Something seems wrong with the (reported?)order of execution here:
[ 2264.120719] systemd-logind[1887]: System is rebooting.
...
[ 2264.128178] systemd[1]: Stopping Session 2 of user ctor.
...
[ 2294.230402] systemd[1]: dev-disk-by\x2did-lvm\x2dpv\x2duuid\x2dpxC3ch\x2d0MF0\x2dOzJs\x2dJogd\x2d9rOz\x2dJkSt\x2dCf8G7m.device: Job dev-disk-by\x2did-lvm\x2dpv\x2duuid\x2dpxC3ch\x2d0MF0\x2dOzJs\x2dJogd\x2d9rOz\x2dJkSt\x2dCf8G7m.device/stop timed out.
...
[ 2294.233143] systemd[1]: Timed out stopping /sys/devices/virtual/block/dm-0.
...
[ 2294.245285] systemd[1]: session-2.scope: Stopping timed out. Killing.
...
[ 2294.249906] systemd[1]: Stopped Session 2 of user ctor.
...
[ 2294.286218] systemd[1]: Stopping Qubes Dom0 startup setup...
...
[ 2306.406772] echo[12427]: will sleep for 5 sec
[ 2311.415800] echo[12456]: done sleeping for 5 sec
...
[ 2311.444059] ps[12463]: root 8 0.0 0.0 0 0 ? I 00:49 0:00 [rcu_sched]
[ 2311.445569] systemd[1]: Stopped Qubes Dom0 startup setup.
[ 2311.448041] ps[12463]: root 9 0.0 0.0 0 0 ? I 00:49 0:00 [rcu_bh]
...
all that while using the following qubes-core.service
(note: I did do the required sudo systemctl daemon-reload
after modifying the file with the echo
s):
[Unit]
Description=Qubes Dom0 startup setup
After=qubes-db-dom0.service libvirtd.service xenconsoled.service qubesd.service qubes-qmemman.service
# Cover legacy init.d script
[Service]
Type=oneshot
StandardOutput=syslog
RemainAfterExit=yes
# Needed to avoid rebooting before all VMs have shut down.
TimeoutStopSec=180
ExecStart=/usr/lib/qubes/startup-misc.sh
ExecStop=-/usr/bin/pkill qubes-guid
ExecStop=/usr/bin/qvm-shutdown --verbose --all --wait
# QubesDB daemons stop after 60s timeout in worst case; speed it up, since no
# VMs are running now
ExecStop=/usr/bin/echo "will sleep for 5 sec"
ExecStop=/usr/bin/sleep 5
ExecStop=/usr/bin/echo "done sleeping for 5 sec"
ExecStop=-/usr/bin/pkill qubesdb-daemon
ExecStopPost=-/usr/bin/ps axuw
ExecStopPost=-/usr/bin/xl list
[Install]
WantedBy=multi-user.target
Also=qubes-meminfo-writer-dom0.service qubes-qmemman.service
Alias=qubes_core.service
So is it trying to stop the DM stuff before even running the Stop for qubes-core.service
or is there some glitch with the order in which the messages are being reported due to all those ForwardTo* that I've changed in journald.conf
? I'll answer this with No
here because a previous log here which is pure journalctl -b -1
generated, shows the same wicked order:
...
Sep 02 19:04:09 dom0 systemd[1]: Timed out stopping /sys/devices/virtual/block/dm-0.
...
Sep 02 19:04:09 dom0 systemd[1]: Stopping Qubes Dom0 startup setup...
...
Sep 02 19:04:20 dom0 systemd[1]: Stopped Qubes Dom0 startup setup.
...
EDIT: I must be missing something or are all these services seemingly shut down in alphabetical order (if not even, some, also concurrently):
nevermind i was wrong about this.
EDIT: I'm continuing to try figuring this out here: https://gist.github.com/constantoverride/78a3dfced04234cbe0f91f91a1bc99db Meanwhile this is what I use(run) as a workaround(before doing the Restart from menu):
#!/bin/bash
xl list
time qvm-shutdown --verbose --all --wait; ec="$?"
echo "exitcode: '$ec'"
time while xl list|grep -q -F '(null)'; do xl list;sleep 1; done
exit $ec
I wonder why device-mapper still complains, now when all domains are properly terminated, DM cleanup should also work.
Maybe it's a systemd bug? Or I simply do not know how to ensure that qubes-core.service
stops AFTER those DM devices are attempting to stop.
For example, I've had 3 consecutive reboots and without changing anything, the 3rd one decided to fail with the timeout because systemd decided to reverse the stop order:
First reboot, all good, achieving expected stop order:
[ 67.643774] systemd[1]: dev-block-253:0.device: Installed new job dev-block-253:0.device/stop as 777
[ 67.643982] systemd[1]: qubes-core.service: Installed new job qubes-core.service/stop as 860
[ 68.032308] systemd[1]: qubes-core.service: About to execute: /usr/bin/pkill qubes-guid
[ 68.033396] systemd[1]: Stopping Qubes Dom0 startup setup...
[ 76.932065] systemd[1]: Stopped Qubes Dom0 startup setup.
[ 76.985423] systemd[1]: dev-block-253:0.device: Redirecting stop request from dev-block-253:0.device to sys-devices-virtual-block-dm\x2d0.device.
[ 82.205556] systemd[1]: dev-block-253:0.device: Failed to send unit remove signal for dev-block-253:0.device: Transport endpoint is not connected
Second reboot, all good, achieving expected stop order:
[ 147.675870] systemd[1]: dev-block-253:0.device: Installed new job dev-block-253:0.device/stop as 875
[ 147.675940] systemd[1]: qubes-core.service: Installed new job qubes-core.service/stop as 943
[ 148.079458] systemd[1]: qubes-core.service: About to execute: /usr/bin/pkill qubes-guid
[ 148.081959] systemd[1]: Stopping Qubes Dom0 startup setup...
[ 162.058060] systemd[1]: Stopped Qubes Dom0 startup setup.
[ 162.107938] systemd[1]: dev-block-253:0.device: Redirecting stop request from dev-block-253:0.device to sys-devices-virtual-block-dm\x2d0.device.
Third reboot, bad, the stop order is reversed(no idea why, I didn't change anything, I only rebooted):
[ 443.660340] systemd[1]: qubes-core.service: Installed new job qubes-core.service/stop as 797
[ 443.660426] systemd[1]: dev-block-253:0.device: Installed new job dev-block-253:0.device/stop as 867
[ 533.755109] systemd[1]: dev-block-253:0.device: Job dev-block-253:0.device/stop timed out.
[ 534.047847] systemd[1]: qubes-core.service: About to execute: /usr/bin/pkill qubes-guid
[ 534.048939] systemd[1]: Stopping Qubes Dom0 startup setup...
[ 542.648718] systemd[1]: Stopped Qubes Dom0 startup setup.
[ 547.940019] systemd[1]: dev-block-253:0.device: Failed to send unit remove signal for dev-block-253:0.device: Transport endpoint is not connected
Full details here: https://gist.github.com/constantoverride/61207ebf622263d25fb1e5b1f11d0148/9443ef0babe29b32622dd0f17a2435a9e0f1df92#gistcomment-2696607
Since dom0 is stuck at Fedora 25 (latest being Fedora 28?), is there some way that I can update dom0's systemd ? it was at systemd 231
while I tested all these, but 240
is latest. Otherwise, assume that I stopped trying to fix this, as I am out of ideas or something...
I've found a workaround, details here: https://unix.stackexchange.com/a/468356/306023
In short, pkill -9 qubes-guid
is needed when graphical.target
is stopped, else qubes-core.service
's ExecStop
only gets to run after the 90 second timeout incurred by whatever wants to stop *.device
s like /dev/dm-0
(which seems to happen concurrently with that pkill
, and yet prior to qubes-core.service
's ExecStop
).
According to this by a systemd dev., I posit that if we would know which service starts up those devices (like /dev/dm-0) then, I guess, we could put that pkill -9 qubes-guid
on its ExecPreStop or something, or even better, put there also the whole shutdown-all-running-VMs. But I'm not sure.
Great find! Anyway, for the correct solution we need to find why those qubes-guid processes hang and fix this. Could you collect backtrace of such process? For example:
gdb --batch -ex bt -p $(pidof qubes-guid|head -1)
we need to find why those qubes-guid processes hang and fix this. Could you collect backtrace of such process?
I forgot to mention anywhere(else) that there is only one PID of qubes-guid that hangs (and requires that pkill -9
instead of just pkill
SIGTERM) at reboot/shutdown and that is:
[ 779.184064] ps[5699]: ctor 3585 0.0 0.1 160856 5884 ? RLs 02:26 0:00 /usr/bin/qubes-guid -N sys-net -c 0xcc0000 -i /usr/share/icons/hicolor/128x128/devices/appvm-red.png -l 1 -q -d 1 -n
Its backtrace is:
Thread 1 (Thread 0x7565905228c0 (LWP 3585)):
#0 0x00007565900aeb70 in _XReply () from /lib64/libX11.so.6
#1 0x00007565900aa6cd in XSync () from /lib64/libX11.so.6
#2 0x00005a1feed97cf2 in release_mapped_mfns.part.3.constprop ()
#3 0x00005a1feed97d87 in release_all_mapped_mfns ()
#4 0x000075658e45c3d0 in __run_exit_handlers () from /lib64/libc.so.6
#5 0x000075658e45c42a in exit () from /lib64/libc.so.6
#6 0x00005a1feed9507b in dummy_signal_handler ()
#7 <signal handler called>
#8 0x00005a1feed95060 in sighup_signal_handler ()
#9 <signal handler called>
#10 0x000075658e51df3d in poll () from /lib64/libc.so.6
#11 0x000075658e205d10 in _xcb_conn_wait () from /lib64/libxcb.so.1
#12 0x000075658e2077cf in wait_for_reply () from /lib64/libxcb.so.1
#13 0x000075658e207941 in xcb_wait_for_reply64 () from /lib64/libxcb.so.1
#14 0x00007565900aebc8 in _XReply () from /lib64/libX11.so.6
#15 0x000075659009424d in XGetImage () from /lib64/libX11.so.6
#16 0x00005a1feed98d7a in tint_tray_and_update ()
#17 0x00005a1feed97932 in do_shm_update.constprop ()
#18 0x00005a1feed927db in main ()
I forgot to mention (other than in an edit) that I'm only testing these under Qubes 4.0 (instead of 3.1 as the OP mentions this issue is for). I was hoping that maybe it's the same issue for both versions(but mainly I only read the title Systemd shutdown hang
, and later figured out the issue is for 3.1 only). Let me know if I should switch to the proper issue for 4.0 instead.
qubes-guid is mostly the same on both versions, so it's fine here too. Looking at the backtrace, there was very similar bug in the past: #1406. That one was about X error handler, this one is about signal handler. I'll prepare very similar fix for this case.
See pull request linked above. I've also built the package with it and uploaded to qubes-dom0-unstable repository, it's qubes-gui-dom0-4.0.8-1.29.fc25
.
That works! I've tried several reboots even without redsparrow.service
!
qubes-guid
is no longer lingering and
Hey marmarek if this is you https://unix.stackexchange.com/users/209970/marmarek and you care about it, place an answer on this question (it's about this very issue) because I'd love to give you the 150 rep bounty (possible only if you place an answer in 3 days before it expires). Only if you care, I imagine you're busy, but hey that's the least I could do:)
It seems you have posted a bad link for the question…
Automated announcement from builder-github
The package qubes-gui-dom0-4.0.9-1.fc25
has been pushed to the r4.0
testing repository for dom0.
To test this update, please install it with the following command:
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
Automated announcement from builder-github
The package qubes-gui-dom0-4.0.9-1.fc25
has been pushed to the r4.0
stable repository for dom0.
To install this update, please use the standard update command:
sudo qubes-dom0-update
Or update dom0 via Qubes Manager.
@DemiMarie, please confirm that you had the latest packages (see above) when experiencing the problem you reported in #4368.
Wow. Nice work in tracking this down @constantoverride! Well done, and impressive find. Thank you :)
Sometimes Qubes R3.1 shutdown never finishes.