| View previous topic :: View next topic |
| Author |
Message |
ballsystemlord
Tux's lil' helper
Joined: 26 Feb 2013
Posts: 88
|
 Posted: Tue Jul 01, 2014 12:44 am Post subject: systemd bad for dev and gentoo? |
 |
|
This post is not intended to start a war or express anger, it is here to check if systemd being a problem is a real problem and what can be done to solve it. Hopefully, it is written is such a lighthearted manner as to cause amusement vs irritation.
Hello, I'm ballsystemlord from the opensuse forums. I wanted to learn about init and I soon discovered that there was only one choice for an init, sytemd. Puzzled, I asked why out of all the software that linux manages to duplicate, did it fail to create competition for systemd. I soon learned that there was much dispute about losing sysVinit and that it boiled down to a lack of volunteers to maintain it. I also learned about many problems that systemd was causing and I decide to read the docs to see what was up. I read much of Lennart Poettering's works as well as many pages from feedesktop.org. As I read about how systemd is supposed to be written so that processes can't escape it's control desires, and about how unportable it was from the start, I began to experience allergic reactions, including, but not limited to, my terminal suddenly started getting input in the form of and executing, to not avail, killall systemd, flash backs of the my windowz days, etc. I decided to check if others were in agreement with me and I decided to also see if something could, or already was being done. I discovered a small project to boot your system using busybox and Upstart which also seems to be difficult to configure. I poked my nose around it the bsd forums and they agree that systemd is bad. There is a small group of devs working here https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systemd-utl.git and I'm guessing, though I've not read the code yet and the docs are imprecise, that they are trying to create an alternate init. I desire to know, is there a desire to replace systemd here? Is there something being done? I'm asking this so I don't try to recreate an init and windup discovering later that there are now 10 different inits lying around and I've been wasting my time. Hopefully, I can aid in coordinating some kinda solution to the systemd problem.
Thanks.
PS: systemd does do one thing and do it well, that is (it breaks things,) it polices all of the processes in the system; it's meant to be the dameon that controls everything, the dameon to end all dameons, which in the systemd devs minds is one thing.
PPS: If firefox complains that the page is incomplete then download it with curl and open the saved version of the page, I've notified that devs.
Mod edit: Typo correction in title. — JRG |
|
| Back to top |
|
 |
TobiSGD
n00b
Joined: 14 Apr 2014
Posts: 36
|
| Posted: Tue Jul 01, 2014 1:19 am Post subject: |
|
|
How funny that you start with how you don't want to start a war and don't want to express anger, but then most of your post is nothing more than a rant against systemd.
Last edited by TobiSGD on Wed Jul 02, 2014 12:10 am; edited 1 time in total |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9824
Location: almost Mile High in the USA
|
| Posted: Tue Jul 01, 2014 1:28 am Post subject: |
|
|
To rid ourselves of systemd one would have to write a complete alternative that provides what the user wants and maintains it.
The problem is RedHat. They apparently have good cash flow and designed a system that looks good and works well for the end user. Now the only real way to stop this is to design an alternate system that works for the end user that works equally as well. Nobody has stood up to the task.
Debian, SuSE, and Ubuntu can be the only distributions I can see that have the money to make a difference. Perhaps only SuSE as they provide SLES - I don't know about the funding for Debian or Ubuntu. But they all have chosen to go systemd. The other popular distribution - Mint - I don't recall if they are in the black (or care to be.)
I personally think Linux is doomed to go systemd because of this - all the major distributions now have systemd. Even Gentoo now has it as an option. Honestly though systemd is complex, it does work OK - my systemd boxes come up in their GUI just fine, everything looks great. I don't know yet what this all means when the day comes that the system stops booting, but I don't want to deliberately break it to try to debug it just yet.
There are plenty of inits out there already, but it seems none of them have the clout to overtake systemd... You should go ahead and install Gentoo with its default, OpenRC to see what it's like. Just that don't try to install Gnome3 with it...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
defer-
Tux's lil' helper
Joined: 11 Jun 2007
Posts: 140
Location: Finland
|
| Posted: Tue Jul 01, 2014 8:05 am Post subject: Re: systemd bad for dev and getoo? |
|
|
| ballsystemlord wrote: | | This post is notI soon learned that there was much dispute about losing sysVinit and that it boiled down to a lack of volunteers to maintain it. |
init
http://git.suckless.org/sinit/
example:
/bin/rc.init
| Code: | #!/bin/sh
PATH=/bin:/sbin
export PATH
umask 022
echo "starting system"
echo "mounting virtual filesystems"
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t tmpfs -o nosuid,mode=0755 dev /dev
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
echo "starting udev"
[ -c /dev/console ] || mknod -m 600 /dev/console c 5 1
[ -c /dev/tty1 ] || mknod -m 620 /dev/tty1 c 4 1
[ -c /dev/tty ] || mknod -m 666 /dev/tty c 5 0
[ -c /dev/null ] || mknod -m 666 /dev/null c 1 3
[ -c /dev/kmsg ] || mknod -m 660 /dev/kmsg c 1 11
/lib/systemd/systemd-udevd --daemon
echo "mounting filesystems"
mount -o remount,rw /
mount -a
echo "setting hostname"
hostname dfr-laptop
ifconfig lo up
echo "starting agetty"
/sbin/agetty --noclear 38400 tty1 linux |
service management
Something like:
| Code: | for i in /etc/init.d/*;
do exec $i;
done |
Or good old openRC:
http://www.gentoo.org/proj/en/base/openrc/
_________________
https://github.com/defer- |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 452
|
| Posted: Tue Jul 01, 2014 9:38 am Post subject: |
|
|
Infact there are more than just 2 or 3 init systems out there: sinit, minit, runit, openrc, sysvinit, busybox, epoch and a lot more. Only systemd, upstart and sysvinit are known by a lot of people.
[1] http://www.fefe.de/minit/
[2] http://en.wikipedia.org/wiki/Init |
|
| Back to top |
|
|
defer-
Tux's lil' helper
Joined: 11 Jun 2007
Posts: 140
Location: Finland
|
| Posted: Tue Jul 01, 2014 10:16 am Post subject: |
|
|
Yes and init is very trivial task.
| Code: | #define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>
int main()
{
sigset_t set;
int status;
if (getpid() != 1) return 1;
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, 0);
if (fork()) for (;;) wait(&status);
sigprocmask(SIG_UNBLOCK, &set, 0);
setsid();
setpgid(0, 0);
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
} |
https://gist.github.com/rofl0r/6168719
Someone recommended this "supervisor suite" as alternative to systemd:
http://skarnet.org/software/s6/
_________________
https://github.com/defer- |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Tue Jul 01, 2014 9:00 pm Post subject: |
|
|
I'm the author of s6.
For a long time, supervision suites were niche software, something that had mostly artistic appeal for die-hard fans of reliability and efficiency in Unix.
We never bothered to advertise supervision projects because writing quality code was where the fun was; and also, there is a definite entry barrier, because supervision suites are based on a very different paradigm from traditional systems - they requestion the whole design of an init system.
However, it's becoming more and more obvious that we need to come out and make our work better known.
I'm committed to maintaining and enhancing s6 so that it becomes a real alternative to other init systems. It works for me, it works for other people, the only thing it is missing is fame and actual distributions using its framework, with packages organized around it.
The problem with Linux init systems is that they mix policy and mechanism. Making a distribution, and packaging software, is by definition about deciding and enforcing policies; but writing quality Unix software is about providing mechanism, and leaving policy decisions to the user. Both aspects are complementary.
systemd, in its all-encompassing wisdom (cough), provides a lot of mechanism, and a lot of policy too - so it's basically a ready-to-wear solution, it decides how your system is going to be and you just have to follow. That is one of the big reasons why it's been widely adopted - systemd folks are doing all the work. (So who cares if the design is horrible, if they tell us it's better and we can be lazy and believe them ?)
s6, and other supervision suites, on the other hand, only provide mechanism, and all the work regarding policy (deciding where to put the scripts, actually writing them, how to organize the services, etc.) remains to be done. s6 provides the basic building blocks, and distributions have to piece them together, as was the case with System V init - except it's actual work, because the framework is different so System V scripts cannot really be reused.
I'm committed to providing sane mechanisms, and well-designed, working, technically superior software; but I won't do policy work, because I'm writing software, not making distributions, and my role is to provide mechanism and steer clear away from policy. (And the small amount of policy I use for myself, and recommend to others, generally isn't well received by mainstream distributions, because it is based on different needs and different concepts than their existing codebase.)
So, distributions maintainers will also have to step up and do something: providing a full-fledged, ready-to-use init system for Linux is a collaborative effort. LFS is actively developing a runit-based system and a s6-based system; I'm there to answer their questions, and modify s6 if it is needed; I have faith that they will come up with something that works and is distributable. I am, of course, ready to do the same with gentoo, or any other distribution.
If gentoo wants to build a real, believable alternative to systemd, I claim that s6 is a sane base to do so, and have technical arguments to back it up; so if you're up to it, upstream is willing to help. Please talk to me.
_________________
Laurent |
|
| Back to top |
|
|
djdunn
l33t
Joined: 26 Dec 2004
Posts: 812
|
| Posted: Tue Jul 01, 2014 11:08 pm Post subject: |
|
|
well systemd without any sort of vision or set goals or milestones, what we will eventually see with systemd is it growing out in any and all available directions each in a different way different speed with differing quality.
its going to be interesting to see what sort of tangled mess systemd is going to weave in 10-15 years
_________________
“Music is a moral law. It gives a soul to the Universe, wings to the mind, flight to the imagination, a charm to sadness, gaiety and life to everything. It is the essence of order, and leads to all that is good and just and beautiful.”
― Plato |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Wed Jul 02, 2014 12:50 am Post subject: |
|
|
| djdunn wrote: | well systemd without any sort of vision or set goals or milestones, what we will eventually see with systemd is it growing out in any and all available directions each in a different way different speed with differing quality.
its going to be interesting to see what sort of tangled mess systemd is going to weave in 10-15 years |
I would have two responses to that...
First response is a quasi-quote of what I read somewhere - "Systemd writes to the Linux kernel, and everyone else writes to systemd." In other words, it appears that systemd has usurped Linux, and people who were once "Linux hackers" no longer are, because systemd is smack in the way. No wonder there's vitriol. One would expect to see systemd continue to wrap the kernel until there is no direct interface left - Linux becomes Windows.
Second response is that now that "systemd has won" with its inclusion into RHEL7, they will find that perhaps victory wasn't really that sweet. They now have to:
1 - Become stable - no more of this constant churn. Enterprise customers may make the jump to systemd, but they're not going to buy continued churn.
2 - Make sure it works - no more walking away and letting some other team get it working. (**cought** pulseaudio **cough**)
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
jonnevers
Veteran
Joined: 02 Jan 2003
Posts: 1594
Location: Gentoo64 land
|
| Posted: Wed Jul 02, 2014 1:26 am Post subject: |
|
|
frankly, i'm very happy with systemd.
but it might be that i admin systems that are different from many people ( though i hope not ). I utilize docker heavily, something systemd can work with directly. CoreOS ( which happens to be based on Gentoo ) also presents an extremely compelling distro for _very_ large server deployments ( aka cloud level shit ). One thing that makes CoreOS so attractive is systemd.
so while i get both the anti-systemd and pro-systemd arguments. I fall pro-systemd b/c at a certain level of system count having something like systemd is a very big positive in terms of cognitive load.
for just some computar sitting in someone's room... it doesn't really have as much flavor. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Wed Jul 02, 2014 1:44 am Post subject: |
|
|
It's fine that you're happy with systemd, go ahead and use it. I have no problem with that - at least not until the first big security exploit pops up, but that's true of any software, not just systemd.
What I'm ANGRY about is having systemd shoved down my throat, and being called a 'tard for not loving it.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mackal
Tux's lil' helper
Joined: 04 Aug 2011
Posts: 92
|
| Posted: Wed Jul 02, 2014 3:35 am Post subject: |
|
|
| depontius wrote: | | What I'm ANGRY about is having systemd shoved down my throat |
It's not, unless you're trying to use software the maintainers have decided to depend on systemd for. Which in that case, being angry about a maintainer doing something with their software is very very silly. If it angers you that much, you should fork the software and maintain a non-systemd variant (Gentoo does do a lot of this) |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 452
|
| Posted: Wed Jul 02, 2014 5:21 am Post subject: |
|
|
@skarnet: At todays evening i will take a look at s6 and try to use it on a test system  |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Wed Jul 02, 2014 11:40 am Post subject: |
|
|
| mackal wrote: | | depontius wrote: | | What I'm ANGRY about is having systemd shoved down my throat |
It's not, unless you're trying to use software the maintainers have decided to depend on systemd for. Which in that case, being angry about a maintainer doing something with their software is very very silly. If it angers you that much, you should fork the software and maintain a non-systemd variant (Gentoo does do a lot of this) |
I tried systemd a few years ago, because it looked interesting. At the time it wasn't ready to run any of my systems, so I dropped it for the time.
My next intro to systemd whas when it got "shoved down my throat" last November, without warning, when I was doing my regular weekly software updates. That set the initial tone. Then one starts seeing goals of the systemd developers - to make sure upstream "supports systemd best", and the way systemd has steamrolled its way to the default init system practically everywhere but Gentoo and Slackware. Feels like a shove-job to me.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Jul 02, 2014 1:37 pm Post subject: |
|
|
| mackal wrote: | | [...] being angry about a maintainer doing something with their software is very very silly. If it angers you that much, you should fork the software [...] |
mackal ... and so were it the case the gentoo dropped support for systemd someone would, without fuss, fork gentoo and maintain the entire tree on their own? Were this to happen I would not be surprised if there were some number of "angry" systemd users.
@skarnet: I keep looking at s6 and wondering how it might be intergrated with openrc (for supervision) but don't think it can be done without some (possibly significant) changes to the latter. Of course thats entirely "policy" and so I don't expect you to have considered this use case ... though any comments ITR welcome.
Oh, and BTW ... on the seperation of "policy and mechanism", I believe thats "rule 4" in the unix philosophy, the "rule of separation: separate policy from mechanism; separate interfaces from engines."
best ... khay |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Wed Jul 02, 2014 10:48 pm Post subject: |
|
|
| khayyam wrote: | | @skarnet: I keep looking at s6 and wondering how it might be intergrated with openrc (for supervision) but don't think it can be done without some (possibly significant) changes to the latter. Of course thats entirely "policy" and so I don't expect you to have considered this use case ... though any comments ITR welcome. |
I don't know exactly how OpenRC works, but if it's a way of organizing the system boot scripts, then there's nothing that prevents it from having s6 as a backend. All of a regular init's features can be implemented by scripting around s6's primitives. For instance, s6 has no concept of runlevels, but a runlevel is just a collection of services; switching to a runlevel mostly implies stopping certain services and starting others, which s6 makes easy. (s6-svc -d /path/to/oldservice ; s6-svc -u /path/to/newservice. Done.)
The design key is that one-time initlalization scripts and management of long-lived processes (daemons) have to be separated; and so, the init scripts must not start daemons themselves, but run on top of a supervision tree that is rooted in process 1, and send commands to it (via s6-svc and s6-svscanctl); the tree will start and control daemons itself. All of the daemon configuration, command line, etc. is contained in run scripts, which is the main additional concept that supervision suites bring; and the brunt of the work needed to build a supervision-based distribution is about writing suitable run scripts for all the services. This is no different from writing a start script for a SysVinit system; it's just organized differently.
If there is a mailing-list, or a subforum, with OpenRC maintainers interested in this, please point me to it. Alternatively, discussions about s6, runit, and the like, happen in the supervision@list.skarnet.org mailing-list, and we'd be delighted to have OpenRC developers join us.
_________________
Laurent |
|
| Back to top |
|
|
mackal
Tux's lil' helper
Joined: 04 Aug 2011
Posts: 92
|
| Posted: Thu Jul 03, 2014 12:29 am Post subject: |
|
|
| khayyam wrote: | | and so were it the case the gentoo dropped support for systemd someone would, without fuss, fork gentoo and maintain the entire tree on their own? Were this to happen I would not be surprised if there were some number of "angry" systemd users. |
People can be upset, but the amount of bitching and whining that goes on over developers deciding to depend on systemd is ridiculous, don't like? Change it. (As in fork in this case, or civially approach the Dev, although you can't do either with skype, but who uses Skype anyways?)
And to your question, I would probably just switch back to OpenRC, but luckily, neither systemd nor OpenRC is going nowhere on Gentoo. There maybe some tough spots supporting both, but all for the crying people have done, I had no issues continuing to use OpenRC. (Which I used until very recently, and the switch to systemd was also painless) |
|
| Back to top |
|
|
ballsystemlord
Tux's lil' helper
Joined: 26 Feb 2013
Posts: 88
|
| Posted: Thu Jul 03, 2014 2:44 am Post subject: |
|
|
| TobiSGD wrote: | | How funny that you start with how you don't want to start a war and don't want to express anger, but then most of your post is nothing more than a rant against systemd. |
If I don't give a reason for needing a competitor to systemd how well will my post work out? That said, If I was in fact to rantish I apologize, ranting was not my intent but a summery of why something should be done was. Basically this whole effort of mine is based on the writings of one admin on the opensuse list which seemed to me to be highly enlightening (I've shortened it a little) http://forums.opensuse.org/showthread.php/498290-systemd/page6
"> Well, if they work with rc but fail with systemd, it's not my problem. Who cares.
Ultimately, that's the problem here. A willingness to complain about
perceived shortcomings in systemd, but no willingness to help fix the
problems or shortcomings.
> I know you want numbers, but I will not file bug reports against software I don't even use.
Which also is ultimately part of the problem here. Just wanting to
complain about systemd without wanting to get in and help make openSUSE
better.
> You'll have to find someone else, cause I removed systemd months ago.
Well, that's fine. But then there's not really reason to complain, is
there? Either you care enough to want to help fix things, or you just
want to complain about systemd just to have something to complain about."
So, I took his advice. I don't claim to be the ideal candidate for the task, I claim to be willing, so if you can do it better then I welcome the help.
About the piece of software I pointed out earlier; I asked the dev what it was supposed to do and he responded
"it is meant to provide a few very basic DBus
interfaces who expose an API similar to systemd ones. this is necessary
for porting some GNOME components that depend on them. most of these
DBus interfaces (hostnamed, localed, timedated) have method/properties
that map straight to OpenBSD's standard library. the last one, logind,
is quite complicated and most of my work will concern setting up a
framework for future development."
How well this might work with linux is uncertain but I'll post updates.
A for where I got the idea that nobody wanted to maintain the older init scripts see http://forums.opensuse.org/showthread.php/498290-systemd/page4 in particular these two paragraphs
"Basically because the developers did not want to maintain the old system
more, and there was a chap in town with new ideas for a new toy.
Developers love developing new toys, not maintaining the toys of their
elders
If you think me cynical, they said the above, in similar words. They did
say that if you wanted system V, you volunteer to keep it. So, if nobody
volunteered, we were stuck with the new toy."
jonnevers if you like systemd that's fine. I'm not out to purge it, just see if I can create or find a competitor.
skarnet, I'm most interested in your project and will make attempts at porting to opensuse but I need to know first, what exactly depends on sytemd so that I don't break something and think it's your projects fault. (In other words I don't think your project is a drop in replacement from what I read.) I'm using KDE. I actually prefer icewm and fvwmII (and wm* in general,) but I'm kinda stuck on networkmanger (I really should not have become, but, some of us are not to familiar with the CLI equivalents and did not have the time to experiment.) |
|
| Back to top |
|
|
10w.st
n00b
Joined: 03 Jul 2014
Posts: 12
|
| Posted: Thu Jul 03, 2014 6:07 am Post subject: |
|
|
| ballsystemlord wrote: |
A for where I got the idea that nobody wanted to maintain the older init scripts see http://forums.opensuse.org/showthread.php/498290-systemd/page4 in particular these two paragraphs
"Basically because the developers did not want to maintain the old system
more, and there was a chap in town with new ideas for a new toy.
Developers love developing new toys, not maintaining the toys of their
elders |
Maintainers did that to make their job easier, and I don't really blame them for adopting it, but for excluding everything else.
My problem is not inclusion of systemd, but removal of sysvinit from minimal X (which is their base), without providing sufficient alternative.
With systemd comes shell script incompatibility and all custom services need to be translated into .service files.
Previously I just unpack the scripts and call it a day, as they were compatible between all major releases.
Now I need to study redhat docs or hire certified redhat person to maintain a system which isn't even supported by redhat.
So, it's less work for distro maintainer, more bug reports for redhat, and everyone's happy.
Except for me, because I lose either money or time. (I'm finders @ suseforums) |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Thu Jul 03, 2014 6:08 am Post subject: |
|
|
| eccerr0r wrote: | To rid ourselves of systemd one would have to write a complete alternative that provides what the user wants and maintains it.
The problem is RedHat. They apparently have good cash flow and designed a system that looks good and works well for the end user. Now the only real way to stop this is to design an alternate system that works for the end user that works equally as well. Nobody has stood up to the task.
Debian, SuSE, and Ubuntu can be the only distributions I can see that have the money to make a difference. Perhaps only SuSE as they provide SLES - I don't know about the funding for Debian or Ubuntu. But they all have chosen to go systemd. The other popular distribution - Mint - I don't recall if they are in the black (or care to be.)
I personally think Linux is doomed to go systemd because of this - all the major distributions now have systemd. Even Gentoo now has it as an option. Honestly though systemd is complex, it does work OK - my systemd boxes come up in their GUI just fine, everything looks great. I don't know yet what this all means when the day comes that the system stops booting, but I don't want to deliberately break it to try to debug it just yet.
There are plenty of inits out there already, but it seems none of them have the clout to overtake systemd... You should go ahead and install Gentoo with its default, OpenRC to see what it's like. Just that don't try to install Gnome3 with it... |
a better solution in all fairness would be for sysd to be aggressively adopted by distro's so much so that they become the dominant committees to sysd to shape it. Doesn't matter how much cash flow redhat has they will be unable to hire or fund enough ppl just to work on sysd to offset other commits and thus sysd can be unpicked in places to become what ditros need NOT what red hat wants
This massive objection only keeps the power with red hat for something that is gaining momentum. I am not saying genroo and others should also adopt but those that have should ramp up their submissions from nothing....
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
EmaRsk
Apprentice
Joined: 07 Sep 2004
Posts: 158
Location: Italy
|
| Posted: Thu Jul 03, 2014 2:34 pm Post subject: |
|
|
| ballsystemlord wrote: | | I'm kinda stuck on networkmanger (I really should not have become, but, some of us are not to familiar with the CLI equivalents and did not have the time to experiment.) |
Just a side note about this. I solved my dislike for networkmanager with wicd: it's easy to configure and it has all kinds of clients: CLI, ncurses, gtk and kde (ncurses is my pick). |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Thu Jul 03, 2014 6:03 pm Post subject: |
|
|
| EmaRsk wrote: | | ballsystemlord wrote: | | I'm kinda stuck on networkmanger (I really should not have become, but, some of us are not to familiar with the CLI equivalents and did not have the time to experiment.) |
Just a side note about this. I solved my dislike for networkmanager with wicd: it's easy to configure and it has all kinds of clients: CLI, ncurses, gtk and kde (ncurses is my pick). |
Too bad wicd is unmaintained and relies on kernel options that are marked for removal, like CONFIG_CFG80211_WEXT, and obsolete tools like wireless-tools (replaced by "iw" long time ago) |
|
| Back to top |
|
|
Shamus397
Apprentice
Joined: 03 Apr 2005
Posts: 218
Location: Ur-th
|
| Posted: Fri Jul 04, 2014 1:42 pm Post subject: |
|
|
| What's wrong with wpa_supplicant? It even comes with a GUI tool, wpa_gui. It's light years better than NetworkManager, that's for sure. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jul 06, 2014 5:04 am Post subject: |
|
|
| skarnet wrote: | I don't know exactly how OpenRC works, but if it's a way of organizing the system boot scripts, then there's nothing that prevents it from having s6 as a backend. All of a regular init's features can be implemented by scripting around s6's primitives. For instance, s6 has no concept of runlevels, but a runlevel is just a collection of services; switching to a runlevel mostly implies stopping certain services and starting others, which s6 makes easy. (s6-svc -d /path/to/oldservice ; s6-svc -u /path/to/newservice. Done.)
The design key is that one-time initlalization scripts and management of long-lived processes (daemons) have to be separated; and so, the init scripts must not start daemons themselves, but run on top of a supervision tree that is rooted in process 1, and send commands to it (via s6-svc and s6-svscanctl); the tree will start and control daemons itself. All of the daemon configuration, command line, etc. is contained in run scripts, which is the main additional concept that supervision suites bring; and the brunt of the work needed to build a supervision-based distribution is about writing suitable run scripts for all the services. This is no different from writing a start script for a SysVinit system; it's just organized differently. |
It's also a summary of how openrc works, and has worked for quite a few years now. man runscript (s6-svc sounds very similar to rc-update.)
It would be cool to have a small daemon handling that (not pid 1 itself, but started from pid1, and staying around) to react to events, but the key is to keep that minimal, and add incrementally to what we already have, without needing to reinvent what's been reinvented very nicely already.
In essence that could start from a blank slate since we already have the pieces to call on upon to do all the dependency resolving and service starting. The most useful thing it could do is to be a monitor process of some sort, that would ideally fork a monitor-per-service as well, and the top one would be an overall control/monitor pair. Perhaps it could have an xinetd equivalent for ephemeral services (that would need to be somewhat customised to the situation.)
sysvinit doesn't need to go; though it could potentially simplify to passing signals through, there's no real need to, imo.
We haven't used a sysv-rc for a decade or so.
I'd be loath to give up the runscript format myself: it's very clean and very elegant, and I think Roy got the demarcation between sh and C just about right. I'd call it prior art that shouldn't be lost; nor is there any real point in rewriting all our initscripts, when we already have a format that's superior to anything else out there.
WRT networking, I'd look at the dhcpcd setup page first: you likely don't need any of the bloated network managers. (It'll work well with wpa-supplicant as well.) Note that's written by Roy Marples (uberLord) just like openrc was. (He's a netbsd developer now, afaik.) |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Mon Jul 07, 2014 8:29 am Post subject: |
|
|
| steveL wrote: | | It's also a summary of how openrc works, and has worked for quite a few years now. man runscript (s6-svc sounds very similar to rc-update.) |
Not quite. rc-update looks like it manages runlevels; s6-svc is simply a command to send signals to a process managed by s6. From what I see in the documentation, the OpenRC architecture is really a dependency management system, which can have several backends; s6 would be suited to be one of these backends.
| steveL wrote: | | It would be cool to have a small daemon handling that (not pid 1 itself, but started from pid1, and staying around) to react to events, but the key is to keep that minimal, and add incrementally to what we already have, without needing to reinvent what's been reinvented very nicely already. |
I agree. s6 is not competing with OpenRC in that regard, it's complementary. For instance, you say "a daemon to react to events" and my reaction is "sure, but that daemon needs to be supervised". In my view, dependency management is a higher-level concept that can be performed on top of s6. s6 would simply supervise the event/runlevel watcher daemon, like everything else.
| steveL wrote: | | In essence that could start from a blank slate since we already have the pieces to call on upon to do all the dependency resolving and service starting. |
From what I can see, OpenRC has all it needs to do the dependency resolving, but not the service starting. The daemons are still forked by the "runscript start" processes, which use start-stop-daemon and pid files; in that respect, it is not an improvement over sysvinit. Supervision suites provide a different model, where daemons are not scions of the init scripts, but scions of the supervision tree, which is totally independent from the init scripts. The point is that the monitor ("supervisor") process is the parent of the daemon, which allows precise control - always start the daemon in the same, reproducible environment, send it signals without pid files, instantly notice when it dies, etc.
| steveL wrote: | | The most useful thing it could do is to be a monitor process of some sort, that would ideally fork a monitor-per-service as well, and the top one would be an overall control/monitor pair. |
This is exactly what s6 does. The s6-svscan and s6-supervise programs are the monitors you speak of; and the s6-supervise processes are parents of the daemons.
| steveL wrote: | | Perhaps it could have an xinetd equivalent for ephemeral services (that would need to be somewhat customised to the situation.) |
Network services are a higher-level consideration, outside of the scope of a supervision suite and even of a dependency management system. They are services, to be handled like any other service by the supervision suite / dependency management.
I have a s6-networking package that provides xinetd-like functionality - one daemon per service, which is the most flexible way of doing that. But it's a discussion for another time.
| steveL wrote: | | sysvinit doesn't need to go; though it could potentially simplify to passing signals through, there's no real need to, imo. |
The whole point of this discussion is to provide an alternative to systemd. If your proposed alternative is sysvinit, well, why not - it's certainly simpler than systemd and it works, but there are good reasons why people want to switch to systemd in the first place: sysvinit is incomplete and does not make service supervision and management easy. I think s6 is a better init choice. OpenRC does not compete with s6, just as it does not compete with sysvinit; it would simply benefit from running on top of s6.
| steveL wrote: | | I'd be loath to give up the runscript format myself |
And you wouldn't have to.
The contents of the start() and stop() functions, however, would need to change in a s6-based system. Instead of starting and stopping the daemons directly, you'd call s6-svc to tell the supervision tree to start and stop them. The daemon command line itself would go into a "run script" (not the same thing as OpenRC's runscript program... naming is hard) that would be provided with the daemon package, and would be started by s6-supervise, not the user running the runscript command. This is the key point.
_________________
Laurent |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
