sys-net occasionally dies on resume from suspend #4658
Comments
andrewdavidwong
added
T: bug
|
Posted bounty ($100): https://www.bountysource.com/issues/67959138-sys-net-dies-on-resume-from-suspend |
|
@andrewdavidwong @brycepg I feel this must be hardware specific, since I dont see it on any of the machines that I still have access to running 3.2.1. |
|
Laptop model: Lenovo Thinkpad T530 EDIT: Strangely I cannot repro right now with a quick suspend. Will try out with longer suspend times. |
|
I should have clarified that this only happens occasionally, so it would be difficult to reproduce without suspending/resuming many times. I'll update the issue to reflect this. Lenovo Thinkpad T450s: |
andrewdavidwong
changed the title
|
same issue, thinkpad x220, qubes 4.0 Maybe a script that shut down and restart all net-vm could be a temporary fix ? ( its pretty long and painful to do it manually ) |
|
This happened to me recently after re-doing some templates and VMs. What I discovered was that my wifi module suspend settings were gone.... I forgot to re-add them. I agree with unman this is a hardware-specific issue. OTOH it would be nice if Qubes had some way of automatically populating this module information. Here is what I use in /rw/config/suspend-module-blacklist for an Intel "Ultimate-N" card: |
|
In my case,
The result in my case is the following output in sys-net: In the case of I hope that this is relevant for this issue. If not please indicate how I can proceed. For the record, essentially the machine (DELL XPS 13 9360) is running R4.0. |
|
I'm experiencing this issue with a Librem 13 laptop and my easiest solution is to kill the |
|
Myself and several peers all have librem15 and librem13 devices and sys-net dies often on resume exactly as @quantumpacket describes. This is a serious PITA we would love help with. |
|
As per the discussion on qubes-users ("[qubes-users] sys-net keeps dying") here is the dmesg from a netvm (formerly fedora-29, upgraded to fedora-30) as it begins to exhibit the described behaviour: |
|
Creating a new sys-net does not appear to have fixed the issue, crashes still occur. |
|
I also face this issue sometimes but also with sys-usb. I also have a T450. I will post the the ouput of The next time it occurs. |
|
@andrewdavidwong Could you claim the bounty I made please? Apparently BountySource will take the bounty after 2 years which is 2 months away, and I want it to go to a Qubes member. I've pretty much never had this issue after getting a new (used) T530 which supports HVM so I could install Qubes 4.0 |
Thanks for letting us know, @brycepg. I think the bounty should be turned into a donation to the Qubes OS Project, if possible. @mfc, @MiCh, do you know how to do that? |
I also have not experienced this bug in a very long time, even on the same hardware as when I filed this report. It looks like the last report was from @w1k1n9cc on May 24. @w1k1n9cc, are you still experiencing this? |
|
My Qubes-PC is not very active at the moment. I will try it until tuesday. Maybe I have some sparse time at the weekend. |
andrewdavidwong
added
R: duplicate
|
@andrewdavidwong I think the reason everyone came here is that this issue was still open, and the other was closed. Now they are both closed. But the issue is clearly not fixed. |
DemiMarie
added
needs diagnosis
|
@DemiMarie, you're the one who asked whether this is a duplicate of #4042. Do you no longer have reason to think it is? If so, what are those reasons? And please don't say "because the other one is closed." That would be a reason to reopen the other issue, not this one! |
|
Whoops! |
DemiMarie
added
R: duplicate
DemiMarie
removed
the
R: duplicate
|
@andrewdavidwong #4042 affects sys-usb whie this one affects sys-net. |
I tried disabling this service via |
Disabling systemd-udevd will break a lot of stuff. |
|
On 5/11/22 20:07, Demi Marie Obenour wrote:
>> Try disabling the `/usr/lib/systemd/system/systemd-udevd.service` watchdog in your `sys-net` template and please report back if it helps.
>
> I tried disabling this service via `systemd stop systemd-udevd && systemd disable systemd-udevd` and it didn't fix the issue. Disabling the service via Qubes VM settings (adding an entry for `systemd-udevd` and unchecking the box) also did not help.
Disabling systemd-udevd will break a lot of stuff.
Exactly.
I was talking about the watchdog back then, not the entire service. I.e. remove or comment out the `WatchdogSec` line in that file. I was suspecting that a udevd restart caused by the watchdog (which is triggered by clock issues caused by the resume from suspend) would cause havoc.
|
|
On Wed, May 11, 2022 at 11:28:33AM -0700, 3hhh wrote:
I was talking about the watchdog back then, not the entire service. I.e. remove or comment out the `WatchdogSec` line in that file. I was suspecting that a udevd restart caused by the watchdog (which is triggered by clock issues caused by the resume from suspend) would cause havoc.
There is no WatchdogSec line. Here is my systemd-udevd.service file:
```
[Unit]
Description=Rule-based Manager for Device Events and Files
Documentation=man:systemd-udevd.service(8) man:udev(7)
DefaultDependencies=no
After=systemd-sysusers.service systemd-hwdb-update.service
Before=sysinit.target
ConditionPathIsReadWrite=/sys
[Service]
DeviceAllow=block-* rwm
DeviceAllow=char-* rwm
Type=notify
# Note that udev will reset the value internally for its workers
OOMScoreAdjust=-1000
Sockets=systemd-udevd-control.socket systemd-udevd-kernel.socket
Restart=always
RestartSec=0
ExecStart=/usr/lib/systemd/systemd-udevd
ExecReload=udevadm control --reload --timeout 0
KillMode=mixed
TasksMax=infinity
PrivateMounts=yes
ProtectClock=yes
ProtectHostname=yes
MemoryDenyWriteExecute=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
RestrictRealtime=yes
RestrictSUIDSGID=yes
***@***.*** @module @raw-io
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
LockPersonality=yes
IPAddressDeny=any
```
|
|
Well, then it's not that on your system.
(Debian has the watchdog btw, Fedora apparently not.)
|
|
Still experiencing this problem. In my case, it ONLY affects WiFi, Ethernet connections continue normally. See also #5508 |
|
I haven't had this happen to be for a while. And I haven't had it happen to me at all since upgading to 4.1 (Lenovo T530). My sys-net is on |
Fedora 35 is EOL, FYI |
andrewdavidwong
added
the
eol-4.1
|
This issue is being closed because:
If anyone believes that this issue should be reopened, please leave a comment saying so. |
Qubes OS version:
R3.2Affected component(s):
sys-netSteps to reproduce the behavior:
Expected behavior:
sys-netstays on and continues to provide network access normally.Actual behavior:
Occasionally:
sys-netlooks like it's trying to connect for a second, then the entiresys-netjust dies (shows powered off in Qubes Manager).sys-firewalland AppVMs usingsys-firewallfor network access are still running normally, but of course they don't have network access.sys-netdoes not restore network access to these other AppVMs.sys-net. (Maybe restarting justsys-netandsys-firewallwould be enough, but in practice it's easier for me just to shut them all down and restart them all.)General notes:
This has been going on for at least a few months. When reading #4657, I saw that it mentioned this problem with
sys-netin passing. I thought we already had an issue on this (see below) but couldn't find one, so I'm filing this now.Related issues:
I could have sworn we already had an issue about this, but after searching, I can't find one. These all look different:
#2964 was about losing network access when
sys-netstays on#3008/#3030 was about failing to connect to a network after resume when
sys-netstays on#3151 was about NetworkManager not running in
sys-netafter resume whensys-netstays on#3738 was about the entire computer not resuming correctly from suspend.
Ah, maybe I was thinking of #4042, which is a similar report about
sys-usb.The text was updated successfully, but these errors were encountered: