UUID is a good old problem when it comes to running SAP NetWeaver on Linux / SuSE. You have a problem when you log in to your SAP system and get an error message. The error message shows the root cause and solution: “The UUID daemon (uuidd) is not active (code 59999). Check SAP note 1391070.”
SAP NetWeaver isn’t meant to run in Docker. When the software was designed, Docker or event containerization wasn’t around (maybe SUN). NetWeaver assumes that it is executed inside a real Linux. And the Docker version of OpenSuSE isn’t 100% a real Linux. A lot of services you get “automatically” when installing OpenSuSE are not available. One of those is that the init.d system is not starting services. Because of this, there is no UUID daemon running.
Make sure that the UUIDD service is running. For a normal Linux distribution, I blogged about this at a previous blog of mine. In case you are using Docker with OpenSuSE, make sure that uuidd is installed and executed during the image creation:
RUN zypper --non-interactive install --replacefiles uuidd
RUN mkdir /run/uuidd && chown uuidd /var/run/uuidd && /usr/sbin/uuidd
With the UUIDD running, the logon to SAP NetWEeaver ABAP is working. No restart of NetWeaver is needed.
Newly installed NetWeaver ABAP 7.5 system on top of SUSE Enterprise Linux 12. Installation via sapinst was executed without errors. NetWeaver system is up and running, first logon into SAP system via SAPGui. Some programs are compiled when logging in, and all ends in a runtime error message.
Error message contains a hint to SAP note 1391070. The SAP Note states that the UUID service on the Linux server is broken and needs to be fixed. A shell script (check-libuuid.sh) that you need to run to get a better error analysis is included in the note. Copy the script to your Linux computer and make it executable:
chmod u+x check-libuuid.sh
The output of the script will tell you what you did wrong and how to fix it.
In the output the steps to solve the problem are given.
Check status of deamon: systemctl status uuidd.socket
Final check of uuidd using script from SAP Note
It seems normal to be able to simply use a Linux distribution to run a SAP system that has the name “for SAP” in its name, but that`s obviously a newbie assumption. The UUID daemon delivered with SLES for SAP SP12 does not create unique id. Not sure how this wasn`t discovered – or more precisely, how this was discovered – but it is as it is. No need to panic, a solution is available. Moreover, this means that you cannot simply go out there and install an SAP system and expect it to work, you have to read the documentation (didn`t find the uuidd error there) and even more important, the SAP notes.
Erroneous libuuid and uuidd
SEL12 comes with a bug in uuidd. The generated numbers are not unique (yes, testing is not everyone strength). To find out if this bug and therefore, target of an imminent upgrade affects your uuidd, use the shell script.
The output states clearly that you need to update your libuuid and uuidd.
Solution: update libuuid and uuidd
The solution is simple. Do as advised by the given SAP note. If you are not a customer of SUSE for their enterprise distribution, you can register for a 60 day trial which gives you access to the update server at no cost. I tried to compile a newer version, without success. It seems the script checks the rpm version and not the actual version of uuidd in use.
Register at SUSE (for trial)
To be able to update the UUIDD package, you need to be registered at SUSE. I was using Yast2 and wasn`t able to update the packages; I got an error when registering. No luck at all. Using the command line tool, however, I was able to register my server.
Checking the dashboard at SUSE customer center shows the system is registered.
Now Yast2 let me connect to the update server and I could update the program.
The check tool is OK with the newly installed version of uuidd.
Reinstall the system?
The original error message stated that an installation error occurred. The root cause is now solved, however, installation error sounds pretty much like: system screwed up beyond all repair. Do you now have to reinstall the whole SAP NetWeaver ABAP system? Not a hard task, but time consuming. I do believe that the SAP team responsible for the installer knows what they are doing and in case the UUIDD bug would have prevented a successful installation, the installer would have told me so. Therefore, I did not reinstall the system (hey, only for demo anyway) and started NetWeaver. And logged on. And finally got no error message, but this:
To be sure, I ran SICK (transaction SM28):
Will keep you posted in case the system is FUBAR. For now it looks good. And is fast.