LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Closed Thread
  Search this Thread
Old 10-19-2014, 02:29 PM   #31
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843

Quote:
Originally Posted by Richard Cranium View Post
Why did you leave out "make it a child of init"?
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...
 
Old 10-19-2014, 02:48 PM   #32
ttk
Senior Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 1,038
Blog Entries: 27

Rep: Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484
Quote:
Originally Posted by T3slider View Post
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?

http://www.cyberciti.biz/howto/quest...b-man-page.php

Quote:
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.
 
1 members found this post helpful.
Old 10-19-2014, 03:02 PM   #33
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Original Poster
Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
Quote:
Originally Posted by ttk View Post
... parse failure
Sorry about that. It happens with some parsers dated back in 1994.

Quote:
Originally Posted by ttk View Post
PAM makes centralized authentication easier with nontrivial (read: corporate) and heterogeneous infrastructure.
It also happens that this "nontrivial back in 1994" infrastructure is a common workplace nowadays.

Quote:
Originally Posted by ttk View Post
Deploying PAM and PAM-enabled packages on Slackware systems is still an option, and also a reasonable decision for some people.
Could you give some examples where these "Slackware systems" are deployed. Your basement doesn't count.

Cheers
 
Old 10-19-2014, 03:19 PM   #34
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843
Quote:
Originally Posted by ttk View Post
Are you serious? What did you think /etc/inittab was for, or how agetty et al got respawned?

http://www.cyberciti.biz/howto/quest...b-man-page.php
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...
 
Old 10-19-2014, 03:23 PM   #35
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Original Poster
Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
Quote:
Originally Posted by metaschima View Post
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.

Cheers
 
Old 10-19-2014, 03:40 PM   #36
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,554
Blog Entries: 15

Rep: Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097
Quote:
Originally Posted by T3slider View Post
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.

Last edited by ReaperX7; 10-19-2014 at 03:56 PM.
 
2 members found this post helpful.
Old 10-19-2014, 03:43 PM   #37
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,257
Blog Entries: 24

Rep: Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193
Quote:
Originally Posted by ivandi View Post
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...
 
5 members found this post helpful.
Old 10-19-2014, 04:00 PM   #38
genss
Member
 
Registered: Nov 2013
Posts: 741

Rep: Reputation: Disabled
Quote:
Originally Posted by ivandi View Post
... 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
 
Old 10-19-2014, 04:06 PM   #39
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Original Poster
Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
Quote:
Originally Posted by ReaperX7 View Post
Cron, by definition, is a service supervisor!



 
Old 10-19-2014, 04:19 PM   #40
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247Reputation: 1247
Quote:
Originally Posted by metaschima View Post
How about "If there are so many alternatives, why is systemd locking everyone in to use only systemd and none of the alternatives ?"
You known, "Ein einzelnes Kernel, eine einzelne PID EINS!", the Major Linux Players want that, nothing special there...

In other hand, I can rhetorical ask, why is Linux kernel locking everyone in to use only Linux kernel and none of the alternatives?
 
Old 10-19-2014, 04:24 PM   #41
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843
Quote:
Originally Posted by ReaperX7 View Post
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 View Post
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 View Post
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 View Post
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 View Post
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.
 
1 members found this post helpful.
Old 10-19-2014, 04:24 PM   #42
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,554
Blog Entries: 15

Rep: Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097Reputation: 2097
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?

Last edited by ReaperX7; 10-19-2014 at 04:39 PM.
 
1 members found this post helpful.
Old 10-19-2014, 04:28 PM   #43
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Original Poster
Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
Quote:
Originally Posted by astrogeek View Post
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.

 
Old 10-19-2014, 04:33 PM   #44
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,257
Blog Entries: 24

Rep: Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193
Quote:
Originally Posted by ivandi View Post
IMO that applies perfectly for things like drugs or automatic rifles but not for a piece of software.

Why so?
 
Old 10-19-2014, 05:04 PM   #45
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian
Posts: 528

Original Poster
Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
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.

Cheers
 
  


Closed Thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: The Story Behind ‘init’ and ‘systemd’: Why ‘init’ Needed to be Replaced with ‘systemd’ in Linu LXer Syndicated Linux News 1 04-07-2017 11:33 PM
LXer: Is systemd as bad as boycott systemd is trying to make it? LXer Syndicated Linux News 0 09-03-2014 05:50 PM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM
First impression of 13.37 Cepoon Slackware 0 03-11-2011 06:37 PM
Impression caitus Slackware 4 02-09-2009 03:37 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:21 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration