Nvidia DGX Spark automatically suspends when running headless (despite power config changes)

Hi everyone,

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.

Thanks in advance!

Please run: sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

And check if it solves your problem

Thanks for the suggestion! I will run that command and check if it solves the problem.

Just as a side note: I have another unit here locally that is connected via Ethernet cable, and it does not have this auto-sleep issue.

I tried applying the mask command and rebooted the system, but unfortunately, it didn’t work. The issue persists.

Is there anything else I should check? Or could this be related to a specific BIOS/Firmware setting on the DGX Spark?

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.

@ThinkNight is the entire system going into sleep mode or only the Wi-Fi adapter and can’t remotely login?

If it’s the Wi-Fi interface and the NetworkManager settings don’t work try the iw command and disable power_save mode on the device:

iw dev wlP9s9 get power_save to display the current mode

iw dev wlP9s9 set power_save off to disable it

On my device the wireless is labeled wlP9s9 I suppose it’s the same on other Sparks also.

I don’t use the Wi-Fi, but running the Sparks headless didn’t noticed any going into sleep mode automatically.

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."

Has anyone found a solution to that problem?

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 ;(

The only way to recover is to force a powerdown…

I got in touch with someone in the dev team, so they are aware of the issue. Now we just need to wait for a fix.

The spark is not suitable for (Christmas) holidays. Sadly, my Wi-Fi didn’t survive its 24-hour holiday either …

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.

Can you try a wire?

Is it a static IP or DHCP?

Can you set a heartbeat (ping -c 1 the gateway via crontab every minute?)

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.

Try this. I think this has resolved the problem for me:

sudo nmcli connection modify “YOUR_WIFI_SSID_GOES_HERE 1” connection.permissions “”

I had Claude analyze my logs on the machine. It says:
15:50:20 — The GDM greeter session (Session 2, running as user gdm) logged out due to idle

  1. 15:50:20 — Since the WiFi connection belongs to gdm, NetworkManager removed it (reason: connection-removed)
  2. 15:50:21 — WiFi deauthenticated, carrier lost, IP address withdrawn
  3. 15:54 — DNS resolution started failing (Temporary failure in name resolution)
  4. Machine stayed running (cron still firing every 5 min) but was completely offline — no network
  5. Display was blank/locked with no active session → keyboard couldn’t wake anything useful

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.