How to set up for running gpuOwl under Ubuntu (and other Linux) with OpenCL

[ewmayer]

Originally Posted by masser

Should the original post be updated from

to

This was the first stumbling block as I try to get an AMD device running on Ubuntu.

AMD must've changed the repo structure sometime in past year - have edited OP to update link to your version, thanks.

[kriesel]

Re https://mersenneforum.org/showpost.p...43&postcount=1
reading it repeatedly in preparation for attempting installation of a GPU and gpuowl on an existing CentOS installation that's already running Mlucas, I wonder about the following:
At what point in the sequence should the GPU be physically installed? (I'm guessing before ROCm installation. Is that right?)
Other than apt vs yum, what differences are there between Ubuntu installation process and CentOS 8 Stream for example?
Some of the steps are quite descriptive, while others are a bit mysterious as to purpose for a Linux noob. Could some more description be added of what the intent is for individual command lines as stated? (Especially some of those beginning o)
How does one verify the GPU is functional as far as being seen by openCL?
Seems like at least running ./gpuowl -h would be in order before queuing up work etc.
Which CentOS versions have been found to work with ROCM & RadeonVII, or not work?
https://rocmdocs.amd.com/en/latest/I...ion-Guide.html indicates 7.9 or 8.3; note 8.3 is essentially no longer installable because of
repository issues.

A summary of some gleanings from the thread:
to pick gpuowl branches,
"git switch v6" to switch to the v6 branch, "git switch master" to go back to the currently v7 branch https://mersenneforum.org/showpost.p...03&postcount=9

Distros that have worked:
Ubuntu 19.10, 20.04
Mint 20?
Fedora 33?

Distros that have led to problems:
Mint (maybe just a path problem)
Debian (lacking ROCm support; requires an uninstallable version of python)
CentOS 8.x that are not stream (repository issues preventing required updates)
Ubuntu 20.10 with iGPU & latest ROCm as of 2020-11-13

GPU models successful:
GTX970
Radeon VII

GPU models unsuccessful:
AMD APU on A8-9600
Radeon 540 (OpenCL not recognizing that GPU model)

My first intended target system is an i5-7600T CPU, which includes an Intel HD630, running CentOS 8 stream OS. Intel Linux driver support listed is for Ubuntu, RHEL 8.3 or 8.4, and some Suse versions; no CentOS listed, much less the stream version.
clinfo returns no platforms. The HD630 is not a requirement, but it would have been useful to learn upon.
The must-have is Radeon VII support.

[kriesel]

Given the following on a box build, same motherboard and cpu as the preceding post:
(same hardware as for attachment 4 of https://www.mersenneforum.org/showpo...5&postcount=17)
BIOS set for onboard video display regardless
CentOS 7.9 OS new install on blank HD
Mlucas installed and working
Increased from 32GiB system ram to 64
Shut down the system sprawled across a table, install in a case, restart & confirm it's functional
Physically installed RX 5700 XT GPU for compute (probably mostly gpuowl)
amdgpu 21.40.1 installed per AMD's directions (for eventual A:B:C test, Win:amdgpu:rocm on same GPU & system)
gpuowl working directory created, worktodo.txt, config.txt
gpuowl-v6.11-380 zip file for linux from a forum post extracted there
A test run of gpuowl complains about libOpenCL.so.1 absent & terminates. Won't even run gpuowl.exe -h.
After some fumbling around including numerous web searches and dead ends, yum install opencl-headers
Then it's on to issues with libstdc libgxx etc.
I think I'll need to install git, select the right git branch for gpuowl, git clone, recompile etc.
Also clinfo showed no platforms. No idea for fixes for that.
Did not get opencl to work on CentOS 7.9 before moving on.

System has subsequently been taken to CentOS 8 Stream by partition removal and fresh install, so will need to redo all gpuowl and opencl and gpu driver related.

I've also been stumped by how to defeat nouveaux drivers and install real NVIDIA-provided drivers for NVIDIA GPUs on Ubuntu (attempted repeatedly on Ubuntu and a Core 2 Duo system long ago).

[chris2be8]

Originally Posted by kriesel

I've also been stumped by how to defeat nouveaux drivers and install real NVIDIA-provided drivers for NVIDIA GPUs on Ubuntu (attempted repeatedly on Ubuntu and a Core 2 Duo system long ago).

Two issues I've run into are:
1: Make sure you have updated initrd.img by running update-initramfs (this should happen automatically when you install the Nvidia drivers). The system looks there for the blacklist of drivers not to install. Without doing that you can update the blacklist, reboot and wonder why it made no difference (as I did for some time).

2: The Nvidia drivers don't work with the preempt kernel. I hit this on OpenSUSE and had to reboot with the default kernel to make them work. I don't know if this can affect Ubuntu though, but check what kernel you are using.

Running lspci -v -s 07:00 should tell you what driver is in use (replace 07:00 with the address of your GPU). If it says nouveau is in use you need to change something.

[M344587487]

Could some more description be added of what the intent is for individual command lines as stated? (Especially some of those beginning o)

o Edit /etc/default/grub to add amdgpu.ppfeaturemask=0xffffffff to GRUB_CMDLINE_LINUX_DEFAULT
Exposes file-based clocking/voltage controls for AMD cards as used in the script (things like /sys/class/drm/card0/device/pp_od_clk_voltage are virtual files that don't exist without the kernel being booted with this option enabled). grub is a bootloader and what you're doing here is adding a boot option to grub's config that will load the kernel with this option on every boot.

o sudo update-grub
Generates the actual config file used by grub from the file you just edited. If you bork grub you bork the system, not directly editing the config guards from formatting errors at least.

o wget -qO - https://repo.radeon.com/rocm/rocm.gpg.key | sudo apt-key add -
Add AMD key to your keychain, allowing you to add the repo below as a trusted source

o echo 'deb [arch=amd64] http://repo.radeon.com/rocm/apt/debian/ xenial main' | sudo tee /etc/apt/sources.list.d/rocm.list
Add AMD's deb repo to the list of repositories searched by your machine


o sudo apt update && sudo apt install rocm-dev
Update repo's and install rocm-dev, which will be found in the repo just added


o Add yourself to the video group. There are 2 options for doing this:
On Ubuntu you need to be in the video group to access the GPU. Not sure if/how this translates to other OS's

How does one verify the GPU is functional as far as being seen by openCL?

Start a PRP to be sure, just running the help might seem to work but in practice there could be an issue.

Which CentOS versions have been found to work with ROCM & RadeonVII, or not work?

Personally (many may disagree) every version of CentOS is unsuitable or at least are hard mode, roughly speaking they're intentionally old toolchains which you're trying to use modern features with by using gpuowl. CentOS 8 Stream may be your best bet if you're sticking with CentOS as relative to non-stream it's a much newer toolchain, albeit still years behind. At the very least you'll probably need to install AMD's drivers as the supplied kernel may be too old to have working mainline drivers. You may have trouble compiling because of the old toolchain. You may have trouble running someone else's binary because they probably linked against a newer libc. You may even run into a situation with RadeonVII/RDNA2/newer-nvidia-cards where the firmware for the card isn't present by default.

A test run of gpuowl complains about libOpenCL.so.1 absent & terminates. Won't even run gpuowl.exe -h

OpenCL isn't installed so the help fails as even then it tries to populate a list with GPUs. The guide uses ROCm to install opencl as it contains an implementation (possibly AMD-specific?). If you can't get ROCm to work then you'll need to find other means of getting a working OpenCL runtime for your hardware. I am not familiar with CentOS (other than using the ancient version to compile P95) so this is very basic advice: running "yum search opencl" will search the default repo's for OpenCL and you might get lucky. For example I could do this with apt on Ubuntu to find the package intel-opencl-icd, which is the package on Ubuntu for the OpenCL compute runtime for intel iGPU's. gpuowl doesn't need to be compiled for each OpenCL runtime, you just need a working gpuowl binary for your environment and a suitable OpenCL runtime for the hardware you want to run gpuowl on.

Then it's on to issues with libstdc libgxx etc.

That rings a bell. There was another thread where someone else was torturing themselves trying to get gpuowl running on CentOS. They couldn't compile their own gpuowl because the toolchain was too old to support gpuowl's relatively modern C++ dialect (C++17?), but coming from the other direction they couldn't run a binary I compiled because I was linking against a much newer libc (as an aside this is one reason P95 is compiled on an ancient CentOS). Libc compatibility hell is just the sort of thing that everyone especially noobs should avoid IMO. If a modern-enough g++ isn't in the repo's you'll likely need to compile it yourself, even then it's unclear to me if you'll have trouble linking to an older libc.

[kriesel]

Originally Posted by M344587487

Personally (many may disagree) every version of CentOS is unsuitable or at least are hard mode, roughly speaking they're intentionally old toolchains which you're trying to use modern features with by using gpuowl. CentOS 8 Stream may be your best bet if you're sticking with CentOS as relative to non-stream it's a much newer toolchain, albeit still years behind. At the very least you'll probably need to install AMD's drivers as the supplied kernel may be too old to have working mainline drivers. You may have trouble compiling because of the old toolchain. You may have trouble running someone else's binary because they probably linked against a newer libc. You may even run into a situation with RadeonVII/RDNA2/newer-nvidia-cards where the firmware for the card isn't present by default.

OpenCL isn't installed so the help fails as even then it tries to populate a list with GPUs. The guide uses ROCm to install opencl as it contains an implementation (possibly AMD-specific?). If you can't get ROCm to work then you'll need to find other means of getting a working OpenCL runtime for your hardware. I am not familiar with CentOS (other than using the ancient version to compile P95) so this is very basic advice: running "yum search opencl" will search the default repo's for OpenCL and you might get lucky. For example I could do this with apt on Ubuntu to find the package intel-opencl-icd, which is the package on Ubuntu for the OpenCL compute runtime for intel iGPU's. gpuowl doesn't need to be compiled for each OpenCL runtime, you just need a working gpuowl binary for your environment and a suitable OpenCL runtime for the hardware you want to run gpuowl on.

That rings a bell. There was another thread where someone else was torturing themselves trying to get gpuowl running on CentOS. They couldn't compile their own gpuowl because the toolchain was too old to support gpuowl's relatively modern C++ dialect (C++17?), but coming from the other direction they couldn't run a binary I compiled because I was linking against a much newer libc (as an aside this is one reason P95 is compiled on an ancient CentOS). Libc compatibility hell is just the sort of thing that everyone especially noobs should avoid IMO. If a modern-enough g++ isn't in the repo's you'll likely need to compile it yourself, even then it's unclear to me if you'll have trouble linking to an older libc.

Thanks for the extensive response and the time spent to offer help.

Here's where I'm coming from on this inquiry. Linux is strongly advocated by some GIMPS participants for various reasons. I have decades of heavy Windows experience, & very little Linux over the same period (Slackware, & early RedHat, lately mostly Ubuntu, but in prep for some systems, a little CentOS).
Ubuntu seems a popular distro, and is also available atop WSL. I have both a native Ubuntu on a garden variety system and Windows with Ubuntu atop WSL on the same system for head to head comparisons of the three environments for things like Mlucas and prime95. I depend heavily on Windows remote desktop or VNC for remote management of numerous systems; generally performed from a single laptop.

Gpuowl was developed on Linux & ROCm. Some say gpuowl is much more efficient on AMD gpus with the ROCm driver which is only supported for Linux. That includes Mihai Preda, and as he is the author of gpuowl, I trust his opinion. George Woltman too.

Mlucas no longer compiles in the msys2/mingw environment on Windows, so recent and future versions of Mlucas require some Linux environment. (Since V18, due to use of Linux signals if not more, if my notes are accurate.)

Two drawbacks, close to deal-breakers for some installs here, of Ubuntu, are:
1) VNC remote desktop to Ubuntu 18 or later systems does not allow connecting to existing user sessions, by design, which is my intended use case, so VNC on Ubuntu, though the install was eventually successful, is useless to me;

2) Ubuntu was attempted and abandoned by Ernst Mayer, on his Xeon Phi 7250 (after running into the "purple screen of death). He settled on CentOS 8.2 for that system. CentOS is supported on that hardware; Ubuntu is not. I have a Xeon Phi 7250 and 7210. I have Windows10 on them but they behave strangely in prime95 timings over time, switching abruptly to a much slower iteration timing unpredictably and staying slow until restarted; and otherwise, such as after adding DIMM ram, Windows does not make effective NUMA control available in that scenario, but per Ernst, CentOS does. Also WSL with Ubuntu atop is a VM only capable of accessing at most 64 virtual cpus due to Windows' processor group construct, which may be only 16 real cores, out of 64 or 68 real cores present. Efficiency can be very low, so operation quite slow. Sometimes Windows seems to get in a mode where it is spending much more cpu time on some sort of overhead than the user's computing tasks; perhaps shuffling work between the very many logical cores. Xeon Phis are x4 HT, so 256 or 272 logical cores.

So I tried to match the version Ernst has been running, because it was proven to support that hardware well.
But the 7210 has a GPU installed now, and the 7250 might in the future.

My Xeon Phi 7250 and 7210 are very cantankerous at startup, such that it can take many attempts to get through the BIOS tests and get to attempts at OS startup with one boot succeeding. That process can take an hour or more with frequent tending; minimum BIOS time is ~4 minutes. So rather than attempt learning about Linux distros on it at the start, I used some practice machines.

I ended up at CentOS 8 stream after trying on V7.9, 8.2, 8.3, 8.4 IIRC. I currently have one system running CentOS 8 stream only.
Another old dual-Xeon system is hard-drive-swap switchable between Windows10 and CentOS 8 stream.
These were practice for attempting dual-boot install of CentOS on the Xeon Phi 7250.

Both these practice machines are candidates for GPU installations in Linux. One is now GPU equipped and running Windows. The other I'd like to move a Radeon VII into, and leave it CentOS 8 stream with Mlucas already running there. If I could get some Linux distro identified that was compatible with the hardware, and AMD GPUs, and remote access of already ongoing sessions, it would permit another type of hardware that is Linux-only. Some of my other hardware would also be candidates for Linux if I could get the remote admin worked out.

Today I attempted TigerVNC installation on the box currently running CentOS 8 stream. It appears to install successfully following online directions, but did not create the etc/tigervnc directory or put any configuration files there.
After consulting a few more CentOS oriented install guides, I resorted to manually creating the folder and config files, but it still fails to start successfully.

[root@raven etc]# ls -l . | grep tig
drwxr-xr-x.  2 root root        29 Apr 12 16:08 tigervnc
[root@raven etc]# ls -l tig*
-rw-r--r--. 1 root root 133 Apr 12 16:08 vncserver.users
$ systemctl start vncserver@:1 --now
$ systemctl enable vncserver@:1 --now
$ systemctl status vncserver@:1
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2022-04-12 21:55:00 CDT; 57s ago
  Process: 12253 ExecStart=/usr/bin/vncserver_wrapper <USER> %i (code=exited, status=2)
  Process: 12245 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 12253 (code=exited, status=2)

Apr 12 21:55:00 raven systemd[1]: Starting Remote desktop service (VNC)...
Apr 12 21:55:00 raven systemd[1]: Started Remote desktop service (VNC).
Apr 12 21:55:00 raven vncserver_wrapper[12253]: runuser: user <USER> does not exist
Apr 12 21:55:00 raven systemd[1]: vncserver@:1.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 12 21:55:00 raven vncserver_wrapper[12253]: FATAL: 'runuser -l <USER>' failed!
Apr 12 21:55:00 raven systemd[1]: Unit vncserver@:1.service entered failed state.
Apr 12 21:55:00 raven systemd[1]: vncserver@:1.service failed.

This seems order of magnitude slower than Windows VNC installation, and still not working on the VNC server end. Any Linux TigerVNC server guidance please, anyone qualified?

[chalsall]

Originally Posted by kriesel

Any Linux TigerVNC server guidance please, anyone qualified?

Ken... To put it explicitly on the table, you and I have our differences over the years. On many different subject domains.

But if you actually want to learn how to control your Linux machines, I'm more than willing to help.

Sincerely.

[M344587487]

To run a Radeon VII or other AMD hardware you'll need the AMD OpenCL driver.
Centos8stream is not a supported target, I'm assuming this workaround is necessary but regardless it's sufficient: https://github.com/RadeonOpenCompute...ent-1041392453

dnf install -y https://repo.radeon.com/amdgpu-install/21.50/rhel/8.5/amdgpu-install-21.50.50000-1.el8.noarch.rpm

Fix repo as centos 8 stream is not officially supported:

sed -e's/$amdgpudistro/8.5/g' -i /etc/yum.repos.d/amdgpu*.repo

Install OpenCL runtime:

amdgpu-install --usecase=opencl

At this point you could try the gpuowl binary you downloaded, but you mentioned libc errors earlier which we haven't fixed and it probably won't work (the problem is likely that you're running an older libc than whoever compiled gpuowl). Better to compile your own, luckily the centos8stream default toolchain uses gcc 8 (the earliest version that supports c++17, centos8stream is just new enough to not be a complete PITA) so there shouldn't be any painful workarounds. The following would apply regardless of AMD/intel/nvidia hardware as long as the appropriate OpenCL driver was installed.

Install gcc:

dnf group install "Development Tools"

Install gmp:

dnf install gmp-devel

Clone gpuowl repo:

git clone https://github/com/preda/gpuowl

Switch to v6:

cd gpuowl && git switch v6

Edit a path in the LIBPATH line in the Makefile from -L/opt/rocm/opencl/lib/x86_64 to -L/opt/rocm/opencl/lib , newer ROCm have changed the layout and v6 hasn't added new location to search.
Build:

make

Note a lot of the install commands need to be executed either with sudo from a user with sudo rights or as root, depends how you've set up accounts. Tested in a VM, everything appears to be working to the point of gpuowl -h but I have no GPU attached to confirm.

Originally Posted by kriesel

Any Linux TigerVNC server guidance please, anyone qualified?

It looks like you've copied a script and were meant to replace <USER> with your username, I have no VNC experience but that should at least get you to the next problem. Is VNC strictly necessary or are you just going with what you know? As you're just using CLI programs on the Linux machines ssh seems a better choice. There's not much to a basic ssh workflow really:

• ssh to remote in or run commands
• Run screen or tmux after remoting in so that any programs you start in the session don't depend on you being connected. To get back to the session you would for example remote in again then run 'tmux attach'
• scp to copy files with CLI
• sshfs to mount a client directory on the local system so you can copy/paste/edit work/result files as if they were local. This could be the main way you admin the device once a session has started assuming you're mostly just feeding gpuowl more work

[kriesel]

Originally Posted by kriesel

[root@raven etc]# ls -l . | grep tig
drwxr-xr-x.  2 root root        29 Apr 12 16:08 tigervnc
[root@raven etc]# ls -l tig*
-rw-r--r--. 1 root root 133 Apr 12 16:08 vncserver.users
$ systemctl start vncserver@:1 --now
$ systemctl enable vncserver@:1 --now
$ systemctl status vncserver@:1
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2022-04-12 21:55:00 CDT; 57s ago
  Process: 12253 ExecStart=/usr/bin/vncserver_wrapper <USER> %i (code=exited, status=2)
  Process: 12245 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 12253 (code=exited, status=2)

Apr 12 21:55:00 raven systemd[1]: Starting Remote desktop service (VNC)...
Apr 12 21:55:00 raven systemd[1]: Started Remote desktop service (VNC).
Apr 12 21:55:00 raven vncserver_wrapper[12253]: runuser: user <USER> does not exist
Apr 12 21:55:00 raven systemd[1]: vncserver@:1.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 12 21:55:00 raven vncserver_wrapper[12253]: FATAL: 'runuser -l <USER>' failed!
Apr 12 21:55:00 raven systemd[1]: Unit vncserver@:1.service entered failed state.
Apr 12 21:55:00 raven systemd[1]: vncserver@:1.service failed.

This seems order of magnitude slower than Windows VNC installation, and still not working on the VNC server end. Any Linux TigerVNC server guidance please, anyone qualified?

Following https://www.linuxfordevices.com/tuto...er-on-centos-8, got slightly further; step 7 appears to quietly fail, revealed by step 8's output:

[root@raven kkriesel]# systemctl start vncserver@:1.service
[root@raven kkriesel]# 
[root@raven kkriesel]# systemctl status vncserver@:1.service
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:1.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2022-05-26 20:27:56 CDT; 21s ago
  Process: 25136 ExecStart=/usr/bin/vncserver_wrapper kkriesel %i (code=exited, status=2)
  Process: 25130 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 25136 (code=exited, status=2)

May 26 20:27:56 raven vncserver_wrapper[25136]: rfbauth        - Alias for PasswordFile
May 26 20:27:56 raven vncserver_wrapper[25136]: PasswordFile   - Password file for VNC authentication (default=)
May 26 20:27:56 raven vncserver_wrapper[25136]: SecurityTypes  - Specify which security scheme to use (None, VncAuth, Plain,
May 26 20:27:56 raven vncserver_wrapper[25136]: TLSNone, TLSVnc, TLSPlain, X509None, X509Vnc, X509Plain)
May 26 20:27:56 raven vncserver_wrapper[25136]: (default=TLSVnc,VncAuth)
May 26 20:27:56 raven vncserver_wrapper[25136]: (EE)
May 26 20:27:56 raven vncserver_wrapper[25136]: Fatal server error:
May 26 20:27:56 raven vncserver_wrapper[25136]: (EE) Unrecognized option: -session
May 26 20:27:56 raven vncserver_wrapper[25136]: (EE)
May 26 20:27:56 raven vncserver_wrapper[25136]: FATAL: 'runuser -l kkriesel' failed!

I am loathe to attempt sshd etc both because it is terra incognito likely to go similarly awry in my unfamiliar hands, and because I'm only able to access my file server from the linux system via graphical tools. (Step by step guides for cmd line file server access failed.)


Edit: hit upon getting out of root, then sudo systemctl start vncserver@:1.service
systemctl status vncserver@:1.service
which supposedly gave an active successful start. But STILL! TightVNC viewer can not connect, nor TigerVNC viewer either, although the same client system can ping the intended vnc server system.

[kriesel]

[kkriesel@raven ~]$ sudo systemctl start vncserver@:1.service
[kkriesel@raven ~]$ systemctl status vncserver@:1.service
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:1.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2022-05-26 21:01:37 CDT; 5s ago
  Process: 25928 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 25934 (vncserver_wrapp)
   CGroup: /system.slice/system-vncserver.slice/vncserver@:1.service
           └─25934 /bin/sh /usr/bin/vncserver_wrapper kkriesel :1

May 26 21:01:37 raven systemd[1]: Starting Remote desktop service (VNC)...
May 26 21:01:37 raven systemd[1]: Started Remote desktop service (VNC).
May 26 21:01:40 raven vncserver_wrapper[25934]: WARNING: The first attempt to start Xvnc failed, possibly because the font
May 26 21:01:40 raven vncserver_wrapper[25934]: catalog is not properly configured.  Attempting to determine an appropriate
May 26 21:01:40 raven vncserver_wrapper[25934]: font path for this system and restart Xvnc using that font path ...
[kkriesel@raven ~]$ systemctl status vncserver@:1.service
● vncserver@:1.service - Remote desktop service (VNC)
   Loaded: loaded (/etc/systemd/system/vncserver@:1.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2022-05-26 21:01:43 CDT; 41min ago
  Process: 25934 ExecStart=/usr/bin/vncserver_wrapper kkriesel %i (code=exited, status=2)
  Process: 25928 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 25934 (code=exited, status=2)

May 26 21:01:43 raven vncserver_wrapper[25934]: rfbauth        - Alias for PasswordFile
May 26 21:01:43 raven vncserver_wrapper[25934]: PasswordFile   - Password file for VNC authentication (default=)
May 26 21:01:43 raven vncserver_wrapper[25934]: SecurityTypes  - Specify which security scheme to use (None, VncAuth, Plain,
May 26 21:01:43 raven vncserver_wrapper[25934]: TLSNone, TLSVnc, TLSPlain, X509None, X509Vnc, X509Plain)
May 26 21:01:43 raven vncserver_wrapper[25934]: (default=TLSVnc,VncAuth)
May 26 21:01:43 raven vncserver_wrapper[25934]: (EE)
May 26 21:01:43 raven vncserver_wrapper[25934]: Fatal server error:
May 26 21:01:43 raven vncserver_wrapper[25934]: (EE) Unrecognized option: -session
May 26 21:01:43 raven vncserver_wrapper[25934]: (EE)
May 26 21:01:43 raven vncserver_wrapper[25934]: FATAL: 'runuser -l kkriesel' failed!

If not infinite, it is at least deep recursion of obscure puzzles. I want my 3 hours back.