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.
If reparenting a process to init causes it to restart when it crashes, I have never heard of it and can find literally no evidence of this from Google. Care to elaborate? AFAIK you need something like restartd/monit/daemontools to handle this sort of thing...
If reparenting a process to init causes it to restart when it crashes, I have never heard of it and can find literally no evidence of this from Google. Care to elaborate? AFAIK you need something like restartd/monit/daemontools to handle this sort of thing...
Are you serious? What did you think /etc/inittab was for, or how agetty et al got respawned?
The inittab file describes which processes are started at bootup and during normal operation (e.g. /etc/init.d/boot, /etc/init.d/rc, gettys...). Init(8) distinguishes multiple runlevels, each of which can have its own set of processes that are started.
That is not the same thing at all...I don't want to hard-code standard system daemons in inittab! Do people actually do this!? What if I want to start a process manually and have it restart on fail? I'm not going to invent a runlevel for this...
So then why did you try systemd ? I thought speed was the main thing here, you didn't mention anything else. Either way "much faster" doesn't mean anything.
I tried it because everybody in the Linux world talks about it nowadays. And it looks like it will be the next init like it or not. And because there are hundreds of opinion about it in this forum from people who don't even want to try it but are eager to condemn it.
Why did you read the topic
Speed was the very first impression I had. And the least important for me.
That is not the same thing at all...I don't want to hard-code standard system daemons in inittab! Do people actually do this!? What if I want to start a process manually and have it restart on fail? I'm not going to invent a runlevel for this...
You didn't think inittab was supposed to be static and inflexible?
Come on! Learn your UNIX! Inittab can be heavy abused for plenty of purposes including managing cron and a cron daemon selfcheck script to auto manage daemons without needless extras. You can run cron just like a getty in inittab and you don't need a runlevel for it. Then you run the shell script to self-check daemons at regular intervals.
Why else would inittab be a plaintext script that's easily hackable and customizable? Why else do people use cron to manage time table based executions? Why else can you use if/else scripts to perform trigger commands in shell?
Cron, by definition, is a service supervisor! It's a child process of init, because it doesn't have to be init! Does every fucking daemon control matrix have to be crammed into bloody init?!
Just because the rest of the GNU/Linux world wants to willfully throw itself off a bloody high-rise building shouting "Look at me!!! This is cool!!! I'm being revolutionary!!!! *SPLAT!*" doesn't mean everyone else wants to follow suit and not think for themselves.
I tried it because everybody in the Linux world talks about it nowadays. And it looks like it will be the next init like it or not. And because there are hundreds of opinion about it in this forum from people who don't even want to try it but are eager to condemn it.
Having "tried it" is not a valid criteria for having an opinion on its use.
While I have read (far too much!) about it, and its clones and shims and alternatives - I have not tried it because I have no need for it! I have no need for any alternative to SysVinit.
It (systemd) is a very unnecessary, uninteresting and unwelcome, forced nuisance intrusion on my own use of my computing machines which fills no compelling need, offers no useful new features, and unnecessarily breaks compatibility across a broad front.
It breaks with the Unix-y principles which are the foundation of my computing uses and "how well it works" is absolutely irrelevant, and carries the same weight as arguments about the technical coolness of Window$' flavor of the week! My interest runs in the negative numbers...
Faced with the decision of "trying it out" or applying that same effort toward mitigating its future effect on my computing uses - I have chosen the latter. As such, systemd is still wasting massive amounts of my own time and resources and, yes, I feel very qualified to offer an opinion without test driving the latest version...
Last edited by astrogeek; 10-19-2014 at 04:08 PM.
Reason: tpos, typs, typos...
... And it looks like it will be the next init like it or not.
Speed was the very first impression I had. And the least important for me.
Cheers
i disagree that everyone will be forced
hell, even gnome3 has downstream (funtoo) patches to run without it
slackware's init is relatively slow as it spends most of it's time on some 4-5 things that don't strictly need to be ran
two of them because of gtk, and at least two of them because of X
none of them needed if nothing related to them was updated (gtk themes, X fonts and some more)
i'm sure that you didn't make .service files for those things, as you would get a lot slower boot with them
as for systemd per se, your average user wouldn't notice any difference between it or, say, upstart
so for most linux users these days, it's fine
for me it isn't and will never be (bad design is bad)
still, i think it's good you tried it
take no offense from my words
PS "ExecReload"...
the name makes no sense considering what it does
the documentation does not even imply that the "service" will be restarted if killall was used, making it even more unclear
You didn't think inittab was supposed to be static and inflexible?
I have treated inittab as a tool for system initialization and not process management but I'm prepared to partially eat my words; yes, inittab can be used for this. For services to start at an existing runlevel you can add a line to inittab, and for temporary services you can use ondemand A/B/C runlevels (alas, only three are supported). Because Slackware's init scripts are not sufficient for this (the scripts terminate after daemonizing the process), you would either have to write your own that uses `exec daemon` or add a `wait $!` or similar to the existing script. Doable but you're managing two systems now.
Quote:
Originally Posted by ReaperX7
Come on! Learn your UNIX! Inittab can be heavy abused for plenty of purposes including managing cron and a cron daemon selfcheck script to auto manage daemons without needless extras. You can run cron just like a getty in inittab and you don't need a runlevel for it. Then you run the shell script to self-check daemons at regular intervals.
I don't think I've ever seen dcron's crond crash so while this is possible (and done in many other distros) running cron from inittab to respawn is largely unnecessary. However, I think you've failed to grasp the point of my previous post -- cron will still have to wait up to a minute to restart a crashed service. You could launch everything from cron (and again, like the inittab solution, this requires writing/modifying init scripts for those daemons if you want it running under cron persistently) and it would only relaunch the service if an existing instance of the cron-launched service isn't running (so that eliminates the resource usage for service checking), but cron still only does its check once a minute.
Quote:
Originally Posted by ReaperX7
Cron, by definition, is a service supervisor!
*By definition* it has nothing to do with supervising at all. It merely executes commands at specified times. And shoehorning 'supervision' (via external scripts) into cron is possible but it isn't supervising anything.
Quote:
Originally Posted by ReaperX7
It's a child process of init, because it doesn't have to be init! Does every fucking daemon control matrix have to be crammed into bloody init?!
Well that escalated quickly. I didn't say anything about cramming stuff into init; you could use daemontools or s6 or similar on top of SysV. But that's as far away from Slackware as systemd is, and again I don't believe you can use the same init scripts with any of the process supervisors, so you're stuck dealing with two systems.
Quote:
Originally Posted by ReaperX7
Just because the rest of the GNU/Linux world wants to willfully throw itself off a bloody high-rise building shouting "Look at me!!! This is cool!!! I'm being revolutionary!!!! *SPLAT!*" doesn't mean everyone else wants to follow suit and not think for themselves.
Your dislike for systemd is a personal preference. Others may be informed and intelligent but may like (some of) what systemd brings to the table. Not *everyone* is a lemming. Your insisting that they are only weakens your arguments.
I moved all the gtk, glib, and gdk database sync into cron. I shaved off at least 15 seconds, but it's now ran as a background process through cron without being directly related to boot. Technically, I could run more out of cron if I wanted to.
We should start a wiki page on how to move stuff into cron and even start cron from inittab. Might be beneficial to get more good knowledge out there.
Yes cron would still have to wake up, but cron technically only needs to be ran once. The rest is handled by a check script that can execute on queue to relaunch if it's found down. This again, is doing more with less.
What exactly is systemd bringing to the table that can't already be done with existing tools?
Having "tried it" is not a valid criteria for having an opinion on its use.
...
I feel very qualified to offer an opinion without test driving the latest version...
IMO that applies perfectly for things like drugs or automatic rifles but not for a piece of software.
While having fun with this thread I started writing service files for my krb5+ldap setup. It took me some time to realize that ExecStartPre and may be all Execs ignore the lines w/o absolute paths. While its a good idea from security point of view I think it would be nice if the user is informed about the issue on the console and not only in the journal.
Overall I find service file format flexible enough. Its not principally different than xinetd for example.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.