# SLED & systemd **URL:** \ **Category:** SLED Configure-Administer\ **Created:** [February 2, 2018, 10:25pm UTC](https://forums.suse.com/t/sled-systemd/31988 "2018-02-02T22:25:37Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![susecmail](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@susecmail](https://forums.suse.com/u/susecmail)\ **Post date:** [February 2, 2018, 10:25pm UTC](https://forums.suse.com/t/sled-systemd/31988/1 "2018-02-02T22:25:37Z")
Is it possible to replace systemd and run SLED with an alternative such as runit? If not, is systemd viable without other component parts (journald, etc.)? I prefer to have my log files in plain text and not binary. Same with DNS resolution. I’m looking to start my IT security business again and previously, I had suggested SLED and SLES, due to the fact that I had been using a form of SUSE since it was a small German company with a Linux called S.u.S.E. and trusted both their product and their service commitment. Kind of related, but not on topic, why was systemd embraced so quickly by SUSE? Was it because SUSE is committed to GNOME? ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [February 2, 2018, 11:47pm UTC](https://forums.suse.com/t/sled-systemd/31988/2 "2018-02-02T23:47:17Z")
On 02/02/2018 01:34 PM, susecmail wrote:[color=blue] > Is it possible to replace systemd and run SLED with an alternative such > as runit? If not, is systemd viable without other component parts[/color] I doubt it, particularly if you want support. Could you make it work? Probably, but you can do a lot of things when you roll your own distribution. [color=blue] > (journald, etc.)? I prefer to have my log files in plain text and not > binary. Same with DNS resolution.[/color] A lot of the logs still end up in plain text files, so I do not know that you lose much. At the end of the day, there are no “text” or “binary” differences on the platter (assuming you still use spinning rust disks); everything is made up of zeroes (0) and ones (1), so I am not sure I agree with you. Still, you’re entitled to your opinions, and if they make you a billionaire, remember us little people. [color=blue] > I’m looking to start my IT security business again and previously, I had > suggested SLED and SLES, due to the fact that I had been using a form of > SUSE since it was a small German company with a Linux called S.u.S.E. > and trusted both their product and their service commitment.[/color] I agree; product quality is pretty awesome, and I’ve had fewer problems in the quality department with SUSE’s stuff than with other vendors. They focus on Enterprise, which helps with that, and they focus on tested things, which obviously helps. There are some great presentations from SUSECon and other places where the testing and automation stuff is presented. It takes a lot of investment to get it where it is. – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often. ---
**Author:** ![susecmail](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@susecmail](https://forums.suse.com/u/susecmail)\ **Post date:** [February 3, 2018, 12:25am UTC](https://forums.suse.com/t/sled-systemd/31988/3 "2018-02-03T00:25:03Z")
Thank you for taking the time to answer. I’m pretty sure I could wrestle a system together with just systemd, although why I would want to do it, or anybody for that matter, is beyond me. Everything on the computer is ones and zeroes; I was programming machine language on AWACS back in the earlly ninties, so I’m familiar with the concept. I’m also familiar with the heartache that systemd gave me the first few years and I found out what I didn’t like about it (pretty much everything). I’m posting this from Void Linux, which I’ve been using for awhile and haven’t had a problem with it, personally. The problem I do have with it is that there is no enterprise-level support. I just don’t like nor trust systemd, at all, so it’s hard to ask people to adopt that if I won’t. Which will leave me with suggesting a Windows-based solution _sigh_. I should probably give SUSE a call or talk to one of their reps to get an official answer; I was hoping somebody had a similar concern/issue/experience here, which has been my first place to stop. Actually, my only place, as most of my questions have been answered either here or on another forum. As a side note: Runit is so easy compared to systemd, especially as implemented. PostgreSQL autostart script under systemd: [CODE][Unit] Description=PostgreSQL database server After=network.target [Service] Type=forking User=postgres Group=postgres # Where to send early-startup messages from the server (before the logging # options of postgresql.conf take effect) # This is normally controlled by the global default set by systemd # StandardOutput=syslog # Disable OOM kill on the postmaster OOMScoreAdjust=-1000 # … but allow it still to be effective for child processes # (note that these settings are ignored by Postgres releases before 9.5) Environment=PG\_OOM\_ADJUST\_FILE=/proc/self/oom\_score\_adj Environment=PG\_OOM\_ADJUST\_VALUE=0 # Maximum number of seconds pg\_ctl will wait for postgres to start. Note that # PGSTARTTIMEOUT should be less than TimeoutSec value. Environment=PGSTARTTIMEOUT=270 Environment=PGDATA=/usr/local/pgsql/data ExecStart=/usr/local/pgsql/bin/pg\_ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT} ExecStop=/usr/local/pgsql/bin/pg\_ctl stop -D ${PGDATA} -s -m fast ExecReload=/usr/local/pgsql/bin/pg\_ctl reload -D ${PGDATA} -s # Give a reasonable amount of time for the server to start up/shut down. # Ideally, the timeout for starting PostgreSQL server should be handled more # nicely by pg\_ctl in ExecStart, so keep its timeout smaller than this value. TimeoutSec=300 [Install] WantedBy=multi-user.target[/CODE] Note: this must be created if a person installs postgresql from scratch rather than through their distro. PostgreSQL autostart under runit: ` #!/bin/sh exec setuidgid postgres /usr/lib/postgresql/bin/postmaster \\ -D /var/lib/postgres/data 2>&1` These are just quick examples I’ve had to research in the past. I am not an expert in creating systemd startup scripts, so I rely on searches. However, in runit, I can create a small script based off man page info, place it in /etc/sv/ and then link it to /var/service/ and it’s done. ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [February 5, 2018, 8:09am UTC](https://forums.suse.com/t/sled-systemd/31988/4 "2018-02-05T08:09:29Z")
On 02/02/2018 03:34 PM, susecmail wrote:[color=blue] > Thank you for taking the time to answer. I’m pretty sure I could wrestle > a system together with just systemd, although why I would want to do it, > or anybody for that matter, is beyond me. Everything on the computer is > ones and zeroes; I was programming machine language on AWACS back in the > earlly ninties, so I’m familiar with the concept. I’m also familiar with > the heartache that systemd gave me the first few years and I found out > what I didn’t like about it (pretty much everything).[/color] At the end of the day most distributions have made their bed with systemd in it, so finding an alternative, with support, in an enterprise distro, will basically mean you are starting a new company and offering support to yourself. If you can rule out the enterprise support portion, you can get things like Slackware running, or you could go the BSD route with FreeBSD or OpenBSD, which considering your background may be something easier than a lot of things. It may be worth noting a lot of things are provided by systemd that are nice to have, though depending on your familiarity with alternatives, your ability with shell scripting, and your desire to not have a monolothic daemon, could also be seen as negatives. Pick your poison. A few quick benefit that init just didn’t have (runit may have them; I have no idea as I need Enterprise support for clients, and that means systemd today): Immediate and automatic restart of services that die. Centralized logging; sure, in theory applications could all write to /var/log, but developers often did their own thing instead. This is particularly nice as it shows STDOUT from the init scripts, which was usually lost leaving you with application logging only, which is useless if the application isn’t starting. Simple analysis of startup delay causes (find that pesky process slowing down bootup performance). Along those lines, faster boot times by nicely parallelizing service initialization. Traditional init starts things serially. No need for scripting to make most things work. I’ve built a couple systemd service unit files, and most of the time I used this template and modified the two lines that mattered (Description and ExecStart) and let systemd do everything else: ```auto [Unit] Description=Neato service here [Service] ExecStart=/path/to/startup/command [Install] WantedBy=multi-user.target ``` Also, customization of these is trivial with systemd drop-in files/directories, which is a huge improvement over relying on application developers to provide extensions to their init scripts, or more likely, rolling your own init scripts. In Enterprise distros you seldom do customization of init scripts or systemd services, but when it is necessary it is great to have this option (I’ve used it a couple times) to do so without worrying about vendor-path-X overwriting your changes and re-breaking things, which is what happens when the vendor provides the init script, as is the case with all software in an enterprise distro [color=blue] > I’m posting this from Void Linux, which I’ve been using for awhile and > haven’t had a problem with it, personally. The problem I do have with it > is that there is no enterprise-level support. I just don’t like nor > trust systemd, at all, so it’s hard to ask people to adopt that if I > won’t. Which will leave me with suggesting a Windows-based solution[/color] If you trust windows more than Linux, that’s the best solution. Your writing and background makes me wonder how that could be possible, since at least systemd is open source and at this point is running most current Linux installs, but I trust windows about as much as you reportedly trust systemd and separated myself from it the better part of twenty (20) years ago as a result. [color=blue] > _sigh_. I should probably give SUSE a call or talk to one of their reps > to get an official answer; I was hoping somebody had a similar > concern/issue/experience here, which has been my first place to stop. > Actually, my only place, as most of my questions have been answered > either here or on another forum.[/color] The forums are great, another benefit of SUSE stuff. You may find the openSUSE side of things useful; while there is not enterprise support like SLES, the Open Build Service (OBS) MAY have somebody contributing ‘init’ (or similar) to replace systemd. I doubt it, as it would be a monumental task to maintain, but it’s possible. [color=blue] > PostgreSQL autostart script under systemd: > > ## Code: > > ``` > [Unit] > > ``` > > Description=PostgreSQL database server > After=network.target > > [Service] > Type=forking > > User=postgres > Group=postgres > > # Where to send early-startup messages from the server (before the logging > > # options of postgresql.conf take effect) > > # This is normally controlled by the global default set by systemd > > # StandardOutput=syslog > > # Disable OOM kill on the postmaster > > OOMScoreAdjust=-1000 > > # … but allow it still to be effective for child processes > > # (note that these settings are ignored by Postgres releases before 9.5) > > Environment=PG\_OOM\_ADJUST\_FILE=/proc/self/oom\_score\_adj > Environment=PG\_OOM\_ADJUST\_VALUE=0 > > # Maximum number of seconds pg\_ctl will wait for postgres to start. Note that > > # PGSTARTTIMEOUT should be less than TimeoutSec value. > > Environment=PGSTARTTIMEOUT=270 > > Environment=PGDATA=/usr/local/pgsql/data > > ExecStart=/usr/local/pgsql/bin/pg\_ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT} > ExecStop=/usr/local/pgsql/bin/pg\_ctl stop -D ${PGDATA} -s -m fast > ExecReload=/usr/local/pgsql/bin/pg\_ctl reload -D ${PGDATA} -s > > # Give a reasonable amount of time for the server to start up/shut down. > > # Ideally, the timeout for starting PostgreSQL server should be handled more > > # nicely by pg\_ctl in ExecStart, so keep its timeout smaller than this value. > > TimeoutSec=300 > > [Install] > WantedBy=multi-user.target > --------------------[/color] This is the one from SLES 12 with PostgreSQL 9.6: ```auto [Unit] Description=PostgreSQL database server After=syslog.target After=network.target [Service] Type=forking User=postgres EnvironmentFile=-/etc/sysconfig/postgresql ExecStart=/usr/lib/postgresql-init start ExecStop=/usr/lib/postgresql-init stop ExecReload=/usr/lib/postgresql-init reload # The server might be slow to stop, and that's fine. Don't kill it SendSIGKILL=no [Install] WantedBy=multi-user.target ``` [color=blue] > Note: this must be created if a person installs postgresql from scratch > rather than through their distro.[/color] Irrelevant with an enterprise distribution, right? You could also steal one from anybody else; creating from scratch is basically something developers (of the original application) will do most of the time. The only one I’ve created was for a client’s home-grown application, and they moved from SLES 11 to SLES 12 and wanted to do it right (not rely on the init script backward compatibility. [color=blue] > PostgreSQL autostart under runit: > > ## Code: > > #!/bin/sh > exec setuidgid postgres /usr/lib/postgresql/bin/postmaster \ > -D /var/lib/postgres/data 2\>&1 > --------------------[/color] That worked for your system, I presume. Things I would ask bout, though, are how the system stops the service, how you can define environment variables, how it handles failure at runtime, how it handles slow stops (because PostgreSQL is a bit relational database engine, so it may be slow to stop), how it is configured to start at one runlevel vs. another (you mentioned symlinking already, so that answers one of the questions), and so on. For a simple startup of a simple service, the script works, but this is far simpler than ‘init’ ever made things, and it is far less functionality than the dozen lines of a systemd-controlled service. Again, if that is what you want, then the more power to you (that phrase seems ironic to me in this context). Life’s too short to use crappy software; run what you feel is best, but I’m 99.9% sure that SUSE’s distros, like most others, are exclusively systemd-based as of SLES 12. That could change, as things often do, but the whole enterprise distro industry have moved, so it seems unlikely as most of the big arguments against systemd are essentially preference. We all had to relearn when moving to systemd from init, so moving back and learning again needs to have some concrete benefits; I just do not see that happening (for whatever that’s worth, likely nothing). – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often. ---
**Author:** ![susecmail](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@susecmail](https://forums.suse.com/u/susecmail)\ **Post date:** [February 8, 2018, 10:37pm UTC](https://forums.suse.com/t/sled-systemd/31988/5 "2018-02-08T22:37:20Z")
Not sure if your familiar with runit as part of a system init manager, but it’s extremely simple to manage services: `$> sv status $> sv restart $> sv stop/start ` Anything that resides in /var/service/ is a service and is automatically started and managed; conversely, if it does not exist in /var/service/ it will not be automatically started. More info on runit can be found both on [github](https://github.com/vulk/runit)and the [developer’s site](http://smarden.org/runit/faq.html). What’s even better is that PID1 is reserved solely for init purposes and everything else is processed afterwards; systemd doesn’t [necessarily follow that](https://lists.freedesktop.org/archives/systemd-devel/2015-February/028585.html), AFAIK, and that’s why I was asking if SUSE could be re-configured, maintaining support, without systemd or if all the other creep could be stripped from systemd, and maintain support. And, as far as being OSS and trusting it, that’s not always the case: [Shellshock](https://en.wikipedia.org/wiki/Shellshock_(software_bug)) which had existed since 1989. Then, of course, [systemd has had a few hiccups](https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/). As for systemd, I just don’t like nor trust the developers. It’s a [morass of code](https://github.com/systemd/systemd) and, after having stared at it for hours, I decided that I don’t have the time. If I have to dig through the code to decide to trust something, I can usually find something else to do the job. For example, until SUSE adopted systemd, I trusted the support team who put out the updates & patches. In the early days, I would look at every dependency and who coded it (around 1998-2000), and decide if I wanted that software on my server bad enough, usually I didn’t. With systemd’s system creep (it now has DNS, web server, ip-forwarding, mount, logging, udev…), it becomes harder to keep the tasks separate, when one area of systemd fails, it affects all others. You’re right, though, I may have to provide that support; not sure that I wanted to get back into that as a business (that could take up a LOT of time, depending on the customer), but I really don’t trust Windows, either! 😛 ---
**Author:** ![ofvergara](https://avatars.discourse-cdn.com/v4/letter/o/df788c/32.png) [@ofvergara](https://forums.suse.com/u/ofvergara)\ **Post date:** [February 10, 2018, 1:03am UTC](https://forums.suse.com/t/sled-systemd/31988/6 "2018-02-10T01:03:19Z")
[COLOR="#B22222"]Hi SuseCmail, my suggestion for a systemd-free Suse Linux Enterprise, is to use either SLED11SP4 (unfortunately no more updates or patches since last year) or SLES11SP4 (still with active patches until 2019 or 2022, i don’t remember exactly). They both are excellent and reliable pre-systemd versions using sysV init. I am using SLED11SP4 and i love it although it is aging a bit these days and it’s getting harder to find updated software for it. i am reluctant to go to SLED15 due to systemd as well. i don’t trust it either. like the old saying goes "if it ain’t broke, don’t fix it). when SLED11SP4 becomes very old, then i might switch to [devuan.org](http://devuan.org); at this point i don’t know because i love SLED11SP4 very much, especially the gnome 2.28 interface (never liked gnome3 and i don’t like MATE either) I tried SLES11SP4 and installed it but it was cumbersome in the sense that it is more restrictive when doing common tasks (for instance, you have to provide the root password to shutdown or restart your computer, go figure; plus it has less software on the installation dvd than SLED11SP4, ie: openoffice is not on SLES11SP4 dvd yet it is included in SLED11SP4 dvd), plus the subscription price to keep active patches is too high for me and i am an individual, not a company (the last time i checked it is US$800 a year; unfortunately i cannot afford that ☹ in the meantime, i am a happy camper with SLED11SP4 until my laptop breaks (it is a 6-year-old dell xps l502x laptop). still very fast with this linux version. i have win7 in the other partition, and this laptop becomes very slow, so slow it gets to your nerves. luckily i only use win7 to download security updates, so 99.5% of the time i’m on SLED11SP4. hope this info helps… cheers![/COLOR] ---
**Author:** ![susecmail](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@susecmail](https://forums.suse.com/u/susecmail)\ **Post date:** [February 14, 2018, 6:27am UTC](https://forums.suse.com/t/sled-systemd/31988/7 "2018-02-14T06:27:58Z")
Thank you, I had purchased SLED 11/12 awhile back and definitely liked 11 better; however, I’m too nervous about security holes and patches; for example, did SLED 11 get Meltdown/Spectre patches, or is the kernel stuck at a certain point after no further update releases? I just remembered one of the reasons that I started disliking systemd, the r! fiasco where Poettering demonstrated a complete lack of understanding about how UNIX file processing works: “I am not sure I’d consider this much of a problem. Yeah, it’s a UNIX pitfall, but “rm -rf /foo/.\*” will work the exact same way, no?” Lennart Poettering, systemd [issue 5644](https://github.com/systemd/systemd/issues/5644) Wow. ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [February 14, 2018, 2:57pm UTC](https://forums.suse.com/t/sled-systemd/31988/8 "2018-02-14T14:57:12Z")
On 02/13/2018 09:34 PM, susecmail wrote:[color=blue] > Thank you, I had purchased SLED 11/12 awhile back and definitely liked > 11 better; however, I’m too nervous about security holes and patches; > for example, did SLED 11 get Meltdown/Spectre patches, or is the kernel > stuck at a certain point after no further update releases?[/color] SLE 11 SP3 LTSS and SLE 11 SP4 should be patched per the main TID from SUSE: [https://www.suse.com/support/kb/doc/?id=7022512](https://www.suse.com/support/kb/doc/?id=7022512) – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often. ---
**Author:** ![Andreas1](https://avatars.discourse-cdn.com/v4/letter/a/d26b3c/32.png) [@Andreas1](https://forums.suse.com/u/Andreas1)\ **Post date:** [February 14, 2018, 8:56pm UTC](https://forums.suse.com/t/sled-systemd/31988/9 "2018-02-14T20:56:59Z")
SLED 11 is End of Life. [https://www.suse.com/lifecycle/](https://www.suse.com/lifecycle/) ---
**Author:** ![susecmail](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@susecmail](https://forums.suse.com/u/susecmail)\ **Post date:** [February 20, 2018, 10:31pm UTC](https://forums.suse.com/t/sled-systemd/31988/10 "2018-02-20T22:31:21Z")
Update: I sent an email asking for clarification on this question to SUSE and have not received an official response. I’m leaning towards the “it’s not supported” picture. My quest continues.