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:
[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:
[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.
