The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:49 UTC (Thu) by jonnor (guest, #76768)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by timtas
Parent article: The Grumpy Editor's guide to surviving the systemd debate

The goal is to make things that works better than today/yesterday. Because Linux core system has been developed as a hodgepodge of independent solutions to often partially overlapping problems, by multiple disparate groups of people with little collaboration (especially between distros), many things are* not working as well as it could.
The organization of the systemd project, as a cross-distro, cross-company and cross-component collaboration is probably a bit of a reaction to that.
Maybe this is not the right approach, time will show. But there is no evidence that I have seen that supports that being intrusive is a goal.

* well, were; systemd project has fixed a lot already

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 11:39 UTC (Fri) by johannbg (guest, #65743) [Link]

" The goal is to make things that works better than today/yesterday."

Right and too give an practical example we started to deploy RHEL/CEL 7 instances for clients and most if not all of them use IBM's TSM as their prefered backup solution.

Now RHEL 7 is supported by the 7.1.1 client without Journal Based Backup and SLES 12 does not seem to be supported et all [1].

Installing the package quickly revealed that the latest tsm client does not ship native systemd unit files so IBM is not getting with the program and generally what's happening on the 21 century ( like their lack of proper 64bit support in plethora of their applications shows ).

Looking at the initscript one can see the legacy sysv crap is 115 lines long

cat /etc/init.d/dsmcad | wc -l
115

Full of distribution spesific bits like...

if [ -f /etc/redhat-release ]
then
. /etc/init.d/functions <-- needless deviation between distro's
...
elif [ -f /etc/SuSE-release ]
then
. /etc/rc.status <--- needless deviation between distro's
...

And supports only RHEL and SLES...

else
echo "This distribution is not supported"
exit 2
fi
....

5 mins later after migrating the legacy sysv initscript you can see the unit file reduced the legacy sysv initscript by 102 lines! and comes with an automatic restart on failure which would have required additional bash script or some other daemon monitoring tool.

cat /etc/systemd/system/dsmcad.service | wc -l
13

An unit file that is self explanatory and usable by --> all <-- systemd based distribution

### dsmcad.service ###

[Unit]
Description=IBM Tivoli Storage Manager Client
Documentation=http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1....
After=network.target

[Service]
Type=forking
GuessMainPID=no
ExecStart=/usr/bin/dsmcad
Restart=on-failure

[Install]
WantedBy=multi-user.target

Just save the above in /etc/systemd/system/dsmcad.service and run systemctl daemon-reload and you are good to go on *any* systemd based distribution until IBM start's shipping it's own.

Unfortunately IBM only ships rpm packages for it's TSM client and only supports RHEL/SLES leaving every other distribution with "Best Effort support" and Debian ( and any non rpm based distribution ) out in the cold package wize [2].

* Note for Debian-based distributions (Debian and Ubuntu): The TSM Linux x86_64 client is made available in RPM package format. Third party tools can be used to convert the package to Debian format for installation. IBM Support will not accept calls related to package conversion or installation of converted packages.

If "Revisiting How We Put Together Linux Systems" comes widely accepted ( or something similar ) that might change as well and companies like IBM could provide a single installation package and thus provide the same level of support for all systemd based distributions regardless what they are called.

1. http://www-01.ibm.com/support/docview.wss?&uid=swg210...
2. http://www-01.ibm.com/support/docview.wss?uid=swg21417165...