I am encountering an issue with my Nvidia DGX Spark. The system automatically enters sleep/suspend mode after a period of inactivity whenever I run it headless (without a monitor, keyboard, or mouse connected).
The Problem: If I boot the machine with peripherals attached, it stays awake. However, when I disconnect them for remote access (SSH), the system suspends itself, making it inaccessible until I manually wake it up.
What I have tried so far: I initially thought this might be related to network power management. I attempted to disable Wi-Fi power saving by editing /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf:
Ini, TOML
[connection]
wifi.powersave = 2
I then applied the changes with: sudo systemctl restart NetworkManager
Current Status: Unfortunately, this did not solve the problem. The machine still goes to sleep automatically when no monitor is detected.
My Question: Is there a specific DGX OS or Ubuntu configuration I need to change to completely disable system suspension and ensure the machine stays 100% active in headless mode?
Any advice on systemd settings or logind.conf modifications for this specific hardware would be greatly appreciated.
I don’t think there’s a configuration on BIOS for that kind of behavior. I have 2 sparks here, one is on headless mode and the other is in desktop mode. They never sleep.
Thanks for the reply. To clarify: The server itself is NOT going to sleep (the system is still running), but the Wi-Fi adapter seems to be going dormant or disconnecting. I checked the status with iw dev get power_save, and it currently shows:Power save: off So, even though power save is explicitly disabled, the Wi-Fi connection still drops when running headless
During what idle period does this occur? I have had a WiFi-connected headless Spark running remotely in the Alps for a week. I think my clean idle period was about 18 hours, the rest of the time I worked on it sporadically and two llama server instances were running (for testing) … and I haven’t had any problems yet … but(?!) I also increased the net.ipv4.tcp_keepalive_time.
I have a web platform deployed on this unit and the disconnects usually happen after about 16-20 hours of inactivity, frequently over weekends when I’m not actively logging in. I actually have two units for comparison: one is connected to a monitor and remains stable, while the other (the problematic one) is running headless, and that is the specific unit dropping the Wi-Fi connection."
I tried all the above, unfortunately without success. The network adapter goes into a kind of power saving mode (WiFi) and none of the config changes mentioned seem to resolve the problem.
This started with the latest OS update… It’s impossible to use the Spark as a network resource anymore ;(
Oh, to know if it’s a good idea. I’ve now set up a system service as a precaution, where the little spark pings my WiFi router every hour … but unfortunately I can’t test it, as the little one is normally in use ;)
Do you have a null adapter (fake monitor) hooked up to the HDMI port, and have screen blank set to Never? I haven’t encountered this issue before, and my Spark is on WiFi.
The cron job idea was good, unfortunately it did not solve the issue for me… It’s a bit annoying because this power saving policy was not there when I had acquired the device and now it seems the issue is simply ignored :(
To me, command ‘sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target‘ does help current running session, but not persist over reboot.
If nothing works a HDMI dummy plug could be used to trick the Spark there’s a display present and keep power-saving triggers from napping devices, i.e. Wi-Fi port. Those devices are very affordable and help with RDP also on headless systems.
For what it’s worth, this is not a universal problem.
My unit is completely headless - only the power brick is connected - and has always been since first boot. User account set up over wifi, connected to wifi exclusively for its entire lifespan. It’s been rock solid; I have never experienced sleep or unexpected connectivity loss.
If there are any settings or logs you’d like to compare notes on let me know.