SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
...while its detractors are demonized, marginalized, and slandered.
And even censored by the promoters of systemd as well. And yes, the fanboyism surrounding systemd is maddening. Sadly enough... even Slackware has it's share...
I will just address this one, regarding the documentation of systemd behavior.
This is from the man page of systemd.service, which describes the options commonly used in .service files:
Code:
Restart=
Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but it may also be one of the processes specified
with ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts
include missing the watchdog "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.
Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service
process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to
on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementiond four signals), when an operation (such as
service reload) times out, and when the configured watchdog timeout is triggered. If set to on-abnormal, the service will be restarted when the process is terminated by a signal (including on core dump, excluding the
aforementioned four signals), when an operation times out, or when the watchdog timeout is triggered. If set to on-abort, the service will be restarted only if the service process exits due to an uncaught signal not
specified as a clean exit status. If set to on-watchdog, the service will be restarted only if the watchdog timeout for the service expires. If set to always, the service will be restarted regardless of whether it exited
cleanly or not, got terminated abnormally by a signal, or hit a timeout.
Table 1. Exit causes and the effect of the Restart= settings on them
┌──────────────────────────┬────┬────────┬────────────┬────────────┬─────────────┬──────────┬─────────────┐
│Restart settings/Exit │ no │ always │ on-success │ on-failure │ on-abnormal │ on-abort │ on-watchdog │
│causes │ │ │ │ │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Clean exit code or signal │ │ X │ X │ │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean exit code │ │ X │ │ X │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean signal │ │ X │ │ X │ X │ X │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Timeout │ │ X │ │ X │ X │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Watchdog │ │ X │ │ X │ X │ │ X │
└──────────────────────────┴────┴────────┴────────────┴────────────┴─────────────┴──────────┴─────────────┘
As exceptions to the setting above the service will not be restarted if the exit code or signal is specified in RestartPreventExitStatus= (see below). Also, the services will always be restarted if the exit code or signal
is specified in RestartForceExitStatus= (see below).
Setting this to on-failure is the recommended choice for long-running services, in order to increase reliability by attempting automatic recovery from errors. For services that shall be able to terminate on their own
choice (and avoid immediate restarting), on-abnormal is an alternative choice.
Seems pretty extensive to me, what are you missing from this?
A version that's understandable.
To the extent that I *can* understand what was written, I didn't see how a service that failed repeatedly wouldn't "flap".
And even censored by the promoters of systemd as well. And yes, the fanboyism surrounding systemd is maddening. Sadly enough... even Slackware has it's share...
Yes, Slackware most certainly does. This is about the only distro forum I peruse from time to time. Oh, and the BSD one periodically as well. There is almost always a thread saturated with passion (among other less enlightening qualities at times) with an overtone of some catastrophic impending doom.
I've read a bit on systemd and have a loose understanding of some of the fighting over it. I've used it in ChromeOS in docker images. The company for whom I work is dedicated to automation which in this case involves puppet/github/docker.
My work environment will migrate to RH7 sometime in the future, at that point I'll be thrust into a world of systemd, like it or not. At this point I can't say I have any real complaints, although my experience with it is limited. I'll adapt to its requirements.
I wouldn't be any less inclined to use Slackware if it migrated to systemd, but to be honest about it, I don't often use it as it stands now. Slackware was my distro for a number of years in first decade of this century, when I enjoyed working on the OS to meet whatever requirement I had at the time. Now I consider the OS a tool, a means to an end.
However this contentious issue works out in the end, I'll be able to work with either one.
In 14.1, there is a /usr/lib/systemd/system folder, with a unit file for hplip in it; comes with hplip package and so creates the whole folder.
Well that is one of the most irritating things about systemd as far as I'm concerned. Dependencies for no good reason. I don't care if hard drive space is cheap in the first world, useless bits are just that. It is cracking me up lurking the -devel list, now discussing "unwants". Oh yeah it is going to be so simple to configure (said with a sarcastic tone). Mmm, spaghetti .
Yes, Slackware most certainly does. This is about the only distro forum I peruse from time to time. Oh, and the BSD one periodically as well. There is almost always a thread saturated with passion (among other less enlightening qualities at times) with an overtone of some catastrophic impending doom.
I've read a bit on systemd and have a loose understanding of some of the fighting over it. I've used it in ChromeOS in docker images. The company for whom I work is dedicated to automation which in this case involves puppet/github/docker.
My work environment will migrate to RH7 sometime in the future, at that point I'll be thrust into a world of systemd, like it or not. At this point I can't say I have any real complaints, although my experience with it is limited. I'll adapt to its requirements.
I wouldn't be any less inclined to use Slackware if it migrated to systemd, but to be honest about it, I don't often use it as it stands now. Slackware was my distro for a number of years in first decade of this century, when I enjoyed working on the OS to meet whatever requirement I had at the time. Now I consider the OS a tool, a means to an end.
However this contentious issue works out in the end, I'll be able to work with either one.
Yes, but oddly when systemd is proposed upon Slackware few debate goes into the cons of using it, only the whimsical pros that honestly are meaningless and very little if any gains. Even in my last few statements regarding service supervision, it's a well known fact that service supervision is still fairly problematic in implementation due to the fact dependency trees must be solved perfectly or else nothing works, and even then if the system isn't shutdown properly, it can cause various filesystem problems to which has been attributed to the journald issue. Yes, the init system is causing the logging system to screw itself because a service doesn't shut down properly. I've personally dealt with this issue on every init system from SysVinit to s6 and runit. To me systemd is no real benefit, only another headache to deal with that's more lather, rinse, repeat of the same problems but now rolled into one bigger problem that has a problem due to its design and the fact supervised services and failure to halt services properly cause another headache. And to be honest after dealing with numerous inits with their own problems, having one less problem to worry about is always a treasure which is why I don't like systemd. Too many age old problems creating one bigger problem. No thank you.
Yes, but oddly when systemd is proposed upon Slackware few debate goes into the cons of using it, only the whimsical pros that honestly are meaningless and very little if any gains.
Are you being serious? Is this real life? What forum have you been reading? For every one post pointing out systemd 'pros' there are at least 10 denouncing it, either by multiple people or, commonly, by a few people that like very much to talk but have little to say.
With all the stuff going on here, I'm not surprised it's not worse T.
Yes, enough refutes come in, from even the technical to the passionate. Let's hope sanity and wisdom do win out. I think they will honestly and Slackware has the prime chance to be next leader of GNU/Linux by staying the course and not jumping off the bridge like the other distributions have so blindly done. At least Slackware is led by someone who can be trusted without question, unlike other distributions.
Let's hope sanity and wisdom do win out. I think they will honestly and Slackware has the prime chance to be next leader of GNU/Linux by staying the course and not jumping off the bridge like the other distributions have so blindly done. At least Slackware is led by someone who can be trusted without question, unlike other distributions.
During the entirety of this thread I've never lost faith in our BDFL's ability to chart a sane course for Slackware. I trust Mr. Volkerding's judgement. I'm not concerned at all about the development of Slackware 14.2; it will be another first rate release.
I can't beat ReaperX7: he has authored 150 posts in the thread, me only 47 before this one.
To make this 48th just a tiny little bit useful: to display these statistics about a thread, click on the number of posts on the right of its title in the Slackware forum.
Last edited by Didier Spaier; 01-25-2015 at 04:42 PM.
Reason: typo corrected
I will just address this one, regarding the documentation of systemd behavior.
This is from the man page of systemd.service, which describes the options commonly used in .service files:
Code:
Restart=
Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but it may also be one of the processes specified
with ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts
include missing the watchdog "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.
Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service
process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to
on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementiond four signals), when an operation (such as
service reload) times out, and when the configured watchdog timeout is triggered. If set to on-abnormal, the service will be restarted when the process is terminated by a signal (including on core dump, excluding the
aforementioned four signals), when an operation times out, or when the watchdog timeout is triggered. If set to on-abort, the service will be restarted only if the service process exits due to an uncaught signal not
specified as a clean exit status. If set to on-watchdog, the service will be restarted only if the watchdog timeout for the service expires. If set to always, the service will be restarted regardless of whether it exited
cleanly or not, got terminated abnormally by a signal, or hit a timeout.
Table 1. Exit causes and the effect of the Restart= settings on them
┌──────────────────────────┬────┬────────┬────────────┬────────────┬─────────────┬──────────┬─────────────┐
│Restart settings/Exit │ no │ always │ on-success │ on-failure │ on-abnormal │ on-abort │ on-watchdog │
│causes │ │ │ │ │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Clean exit code or signal │ │ X │ X │ │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean exit code │ │ X │ │ X │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean signal │ │ X │ │ X │ X │ X │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Timeout │ │ X │ │ X │ X │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Watchdog │ │ X │ │ X │ X │ │ X │
└──────────────────────────┴────┴────────┴────────────┴────────────┴─────────────┴──────────┴─────────────┘
As exceptions to the setting above the service will not be restarted if the exit code or signal is specified in RestartPreventExitStatus= (see below). Also, the services will always be restarted if the exit code or signal
is specified in RestartForceExitStatus= (see below).
Setting this to on-failure is the recommended choice for long-running services, in order to increase reliability by attempting automatic recovery from errors. For services that shall be able to terminate on their own
choice (and avoid immediate restarting), on-abnormal is an alternative choice.
Seems pretty extensive to me, what are you missing from this?
Mainly that it lacks sane defaults. I spun up a CentOS 7 instance on BHYVE, put a purposefully corrupted InnoDB database into MySQL, which caused it to crash. I then observed via Icinga that systemd continuously restarted the service until I intervened, each time ruining the database further. I don't normally mess with the default behaviour of something unless I specifically have to. On Runit and OpenRC they by default will give up after a few tries. I observed for nearly 15 minutes and determined systemd did not use such a function by default. But anyways, that's just one point out of many.
Mainly that it lacks sane defaults. I spun up a CentOS 7 instance on BHYVE, put a purposefully corrupted InnoDB database into MySQL, which caused it to crash. I then observed via Icinga that systemd continuously restarted the service until I intervened, each time ruining the database further. I don't normally mess with the default behaviour of something unless I specifically have to. On Runit and OpenRC they by default will give up after a few tries. I observed for nearly 15 minutes and determined systemd did not use such a function by default. But anyways, that's just one point out of many.
Unit files for different services are provided by the service developers, not by systemd developers. If a service does not provide a unit file it is the duty of the package maintainer of the distribution to provide that file if the distribution uses systemd (or offers it as an option). So you either have to blame MySQL developers or the Red Hat package maintainer, but not the systemd developers.
Systemd is RedHat, hello. The CentOS and RHEL repos are virtually identical, and if RedHat can't get systemd running with something essential like MySQL on their flagship OS, how in hell do you expect anyone else to make better use of it?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
.
