Contents
What happens when you change a setting in XScreenSaver?
If you change a setting in the .xscreensaver file while xscreensaver is already running, it will notice this, and reload the file. (The file will be reloaded the next time the screen saver needs to take some action, such as blanking or unblanking the screen, or picking a new graphics mode.)
What happens if you run XScreenSaver as root?
If run as root, xscreensaver changes its effective user and group ids to something safe (like “nobody”) before connecting to the X server or launching user-specified programs. An unfortunate side effect of this (important) security precaution is that it may conflict with cookie-based authentication.
Why does systemd not wait for the unit to finish?
Unless there are ordering dependencies in place, these services can/will be started in parallel. However, multi-user.target (and thus also graphical.target) are not finished until the rc.service finishes. That is why graphical.target is listed as “dead” for 1000 seconds.
What’s the difference between.xscreensaver and.xdefaults?
The syntax of the .xscreensaver file is similar to that of the .Xdefaults file; for example, to set the timeout parameter in the .xscreensaver file, you would write the following: whereas, in the .Xdefaults file, you would write
How to run XScreenSaver from a GDM session?
You can run xscreensaver from your gdm (1) session, so that the screensaver will run even when nobody is logged in on the console. To do this, run gdmconfig (1) and on the Background page, type the command “xscreensaver -nosplash” into the Background Program field.
How to set XScreenSaver to autostart in startup?
In the event you make a typo creating the autostart entry in Startup Applications, you have to fix it in two places. So even if you fix the typo later in Startup Applications, it does not update the filename (as of 20.04.1 LTS) and you will continue to be puzzled why the daemon doesn’t start on login.