Ubuntu – NVIDIA persistence daemon continuously starting and stopping in syslog

17.10driversnvidiaperformancesystemd

I am on Ubuntu 17.10 and have both an intel and Nvidia GTX 1060 card (the latter usually selected), with driver version 387.22.

I have noticed the following entries in my /var/log/syslog:

  • Nov 22 18:46:36 [machine name omitted] systemd[1]: Starting NVIDIA Persistence Daemon...
  • [some unrelated entries]
  • Nov 22 18:46:36 [...] systemd[1]: Started NVIDIA Persistence Daemon.
  • [some unrelated entries]
  • Nov 22 18:46:36 [...] systemd[1]: Stopping NVIDIA Persistence Daemon...
  • Nov 22 18:46:36 [...] nvidia-persistenced: PID file unlocked.
  • Nov 22 18:46:36 [...] nvidia-persistenced: PID file closed.
  • Nov 22 18:46:36 [...] nvidia-persistenced: The daemon no longer has permission to remove its runtime data directory /var/run/nvidia-persistenced
  • Nov 22 18:46:36 [...] nvidia-persistenced: Shutdown (1115)
  • Nov 22 18:46:36 [...] gdm3: GdmDisplay: display lasted 1.202396 seconds
  • Nov 22 18:46:36 [...] systemd[1]: Stopped NVIDIA Persistence Daemon.

The weird part is that those entries (and a few related I might be omitting here) are occurring continuously, multiple times and sometimes within the same timestamp.

That sounds suspicious to me – why is the daemon continuously started and stopped this way and wouldn't that severely impact on performance?

I'm asking because I am still clueless as per why my machine performs so poorly (especially with regards to gaming) in 17.10, compared to 17.04 – see related question.

Obviously the desktop and dependencies are prime suspects here, not so much the driver version (as I recall seeing the exact same with a previous version).

Questions

  • Is the above reflecting a normal behavior, and if not, how to investigate/fix it?
  • Could that relate to performance issues when running demanding applications, such as games?

Edit

Interestingly, if I log on with the old Unity desktop, these log entries do not seem to occur.
Performance also seems a lot snappier from a pure desktop perspective (although it might be my imagination), but the gaming performance is quite the same.

Best Answer

Although this is an old problem, I've still encountered it myself on Kubuntu 18.04 and nvidia driver 390. Namely, the nvidia-persistence daemon spams the screen during boot (sometimes, not always). Thus, my solution circumvents the standard nvidia daemon startup on system boot by using a separate systemd service.

Like stated before, it seems to be a misconfiguration of starting the nvidia-persistence daemon. More precisely, the udev rules seem to be the problem for me. Thus, I modified /lib/udev/rules.d/71-nvidia.rules and commented out the actions under power-off and power-on. Like mentioned in other answers, you may also comment out the lines for loading and unloading.

Now the daemon does not start on power-on. Consequently, we have to schedule the start of the daemon manually. We can achieve that by copying /lib/systemd/system/nvidia-persistenced.service, e.g. 

sudo cp /lib/systemd/system/nvidia-persistenced.service /lib/systemd/system/nvidia-persistenced-manual.service

Now modify /lib/systemd/system/nvidia-persistenced-manual.service to look something like this: 

[Unit]
Description=NVIDIA Persistence Daemon
Wants=syslog.target
Requires=local-fs.target

[Service]
Type=forking
User=root
Group=root
ExecStart=/usr/bin/nvidia-persistenced
ExecStopPost=/bin/rm -rf /var/run/nvidia-persistenced

[Install]
WantedBy=multi-user.target

To enable the service, execute

sudo systemctl enable nvidia-persistenced-manual.service

and if the old service is still enabled, run

sudo systemctl disable nvidia-persistenced.service

This way, the daemon will start on system startup. Feel free to modify the line ExecStart=/usr/bin/nvidia-persistenced to e.g. include --verbose or --user [...].

Keep in mind, that in my default way, the daemon is running with root permissions. If you do not want this, make sure to run the daemon with the --user argument.

Altogether, this is not a perfect solution, but it was able to fix the bug on my system.

Related Question