Thanks for the link, I will give it a shot.
You write: "Some technical notes: this presumes you're running on your actual display, not a virtual display generated by a VNC client." I do not quite understand. If I am running MC headless can I use the script as is? Why is the script affected by the display being used (especially when there is none)?
The unit exports a DISPLAY as an environment variable. The actual, physical, display is typically DISPLAY=:0 (except on the Gnome desktop), and if you use x11vnc, which just mirrors the actual display, DISPLAY=:0 is the correct environment variable to export. Many VNC solutions, instead of sharing the default output, generate a virtual display on DISPLAY=:1, which obviously will not work if you tell MC to display on DISPLAY=:0. Many of the virtual display solutions no longer work correctly with MC by the way, which is why I made the switch to x11vnc from tightvnc in the guide.
Headlessness, per se, has nothing to do with it. For example, I run x11vnc on many headless systems, but x11vnc nonetheless mirrors what would be displayed on the actual hardware output if you plugged it in (which is useful if you ever need to plug it in). TigerVNC or TightVNC typically generate a virtual display entirely disconnected from the physical hardware so if you plugged in a display cable, you wouldn't see the desktops created by those VNC solutions.
In any case, the "fix" is to connect to your pi via VNC, and then open a graphical terminal in the desktop enviroment. Then enter on the command line: echo $DISPLAY That will tell you what you need to put in the service file environment variables.
I'm using the method described in the guide: Shell script that starts on boot (via cron) that runs x11vnc, and then mediacenter . It works just fine as far as I can tell.
What's the motivation for the systemd service? Other than it being slick and cool and fun.
Brian.
It grew out of efforts to script deployment of MC automatically to virtual machines as well as raspberry pi's.
The systemd service will wait until the desktop environment is up so there are no false starts (not usually an issue on the pi, but I've hit issues on faster hardware), and the systemd service can autorestart MC if it crashes without having to run once a minute (systemd monitors processes on an ongoing basis with low overhead). Those are minor, but more meaningful is that the service allows MC time to shut down properly before a reboot or a poweroff, which the cron script does not do. The systemd service also provides more diagnostic information if something goes wrong (again because systemd logs unit failures more robustly than cron does). I could in theory script some of those advantages, but systemd does it automagically and is almost universally present. Not all modern linux systems even ship with cron pre-installed anymore (Arch for example), or ship with cron implementations that are flaky with the @reboot time designation, but systemd is almost universal and works the same everywhere.
Nothing wrong with the cron script if it works, I used for quite a while and obviously recommended it for years. I just found the systemd units more elegant and easier to deploy, so I'll be switching the next version of the quick start guide over to the systemd units (with the cron offered as an alternative).