With Raspbian 9(jessie) on a RaspberryPi 3b

I wrote a little service file for systemd to run a bash script at startup. It should run xset commands at startup to prevent my screen from going blank.

I can run the script from the terminal, but the script doesn't succeed when systemd runs it. The command "systemctl status xset" returns the error message xset: unable to open display ""

I suspect that while my bash script is running as root, it is coming into conflict with the setting for DISPLAY in Xauthority as suggested from a RaspberryPi forum post here.


X uses its own authority mechanism where it stores a magic cookie in a file .Xauthority in the user's home directory which is the key, any user wanting to connect to the display needs this key. If the user pi owns the display then by default not even root can connect without the key (although root can easily get it, which is roughly what gksudo does).

The following should work as long as root is running it (note you don't need to export the shell variables, just set them directly before calling a program and they will be set for that instance only). It works by temporarily reading pi's .Xauthority for that instance rather than trying (and failing) to use root's.

subprocess.call('XAUTHORITY=~pi/.Xauthority DISPLAY=:0 xset dpms force on', shell=True)[/PHP]


I looked at my Xauthority file and man xauth,but don't know what to do, or if I am in the right place.

The X session is associated with the user that opened it.

Typically for background processes such as those started by init, cron or systemd, there is no actual user session opened so no DISPLAY or .Xauthority.

You can the X virtual frame buffer (Xvfb) to run X in background without associated devices.

I've done this on init based systems but haven't had to do it on systemd yet and haven't worked with Raspberry at all.

This page talks about how to do it on CentOS7 (which would be same as RHEL7) which is systemd. It may give you ideas on what to do for your Raspbian.

i think you're overthinking this.
2 things:

1. you do not want to run this as root, but as the user that logs in
2. you need to run this when the graphical session already started, and not just before that

my guess is that the startup and gui login mechanism uses other files; on my system it would be ~/.xinitrc or ~/.xsessionrc and ~/.config/openbox/autostart.
that's where you want to add these 3 commands.
no systemd service required.

A solution found...

I did gave up on systemd. Instead I put the three xset commands in .profile, a hidden file in /home/pi and they run at startup.

This is for running "feh" to show a picture series in a continuous loop on a large TV in an art gallery in Copenhagen. Even with pretty pictures it's still harder to sell Art than to sell cosmetics using digital signage.

Thanks to both MensaWater and ondoho for their help.

1 members found this post helpful.

i'm surprised it works, because .profile is sourced before the graphical session begins, and all applications you mention depend on a graphical session.
it would be interesting to see how exactly you implemented this, and where exactly this file is located.

Just stuck it in...

Raspbian Jessie has a .profile file as a hidden file in /home/pi. I added the three commands at the bottom. It happened that I found my notes from a previous feh project and repeated the exercise. I fell over the solution once upon a time on the Internet: it works.

Why it works has eluded my further Internet searchs for any explanation. If anyone has one I'm interested.

I thought .profile was sourced at login, which would be after X had started. Isn't that a user specific file?

But I'm new to using the desktop, so I might have that wrong.

The systemd route might work, assuming it all runs AFTER x has started. But you're missing environment variables like DISPLAY. Adding 'export DISPLAY=":0"' would probably solve the systemd issue.

The .bash_profile runs when you start bash / login. I tend to have scripts that I run manually when I startup. It makes transferring things to new installs easier. You can also one line your xset thing.

$ xset -dpms s noblank s noexpose

Is normally in my .bash_history

If you run it from a console ( CNTRL+ALT+F3 ) you wont have DISPLAY set, so this way would also work.

$ export DISPLAY=":0"; xset -dpms s noblank s noexpose

on my system it's login (to the shell) first, then start X.
not sure if the other way round is possible.

Aha. So you're booting to runlevel 3. I'm booting to runlevel 5, so the GUI runs and presents a login screen. I wouldn't expect .profile (or .bash_profile) to be referenced until I log in.

Again, I'm only recently working with the Linux desktop. Most of my history is at the console or via ssh to the command line. I'm having fun, tho

For most distros installing a display manager is enough. Otherwise various ways to change that behavior.

For systemd:

$ systemctl set-default multi-user.target
(for CLI)

$ systemctl set-default graphical.target
(for GUI)

Where the various .target's can be found in /etc/systemd/system/. And reboot OFC. Assuming that you have a GUI environment to use OFC. I still boot CLI and startx to get the GUI, but I'm not a normal person.

For the older sysv, change /etc/inittab and set the run-level. 5 for GUI, 3 for CLI. But some distros do it special, like debian runs (or ran) things as level 2, including the GUI part. The simple answer being to uninstall the display manager. Or set /etc/X11/default-display-manager to "false" and other options depending on how creative you want to be and which distro.

Regularly for foundation procedures, for example, those begun by init, cron or systemd, there is no real client session opened so no DISPLAY or .Xauthority.

You can the X virtual edge cradle (Xvfb) to run X in foundation without related gadgets.

I've done this on init based frameworks yet haven't needed to do it on systemd yet and haven't worked with Raspberry by any means.

^ well my systemd distro boots to multi-user.target and then i start X from .bash_profile.
no need for a display/login-manager, and still i get a GUI.