Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
systemd ???
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2403
Location: The Peanut Gallery

PostPosted: Wed Apr 02, 2014 7:49 pm    Post subject: Reply with quote

Depontius, yes, that's all correct; it's what many of us have been saying for quite a while now. Split out another process, that inittab respawns, and then fork again to handle services and cgroups, perhaps with an xinetd in there. If you sketch it out you end up having about 3 or 4 main daemons sitting around sleeping on events, and making sure the others are still around; you need backstops for pretty much everything, so it makes sense to split them into control, monitor and worker processes, the first two in close cooperation, reacting to events from the system and the monitored service respectively, the workers in a cgroup handled by the monitor, though delete_on_empty in-kernel should cover most uses.

I've been saying for ages that prctl(PR_SET_CHILD_SUBREAPER) a patch Alan Cox accepted from Sievers about two years ago, means there is no reason at all for systemd to run as pid1, and countless good reasons for it not to. That's all that was ever needed, and there simply is no reason to confuse sysvinit with sysv-rc, unless you're obfuscating the truth. (Such as the fact that your distro "experts" are in fact not even amateur-grade shell-scripters, but you're too full of yourselves to admit that, so blame shell instead of your own ignorance; it is designed for human input at a terminal, so ofc it does what you told it to, albeit in the cack-handed manner you asked for.)

But as Anon said, that would imply you can swap it out and use something else, which is contrary to the "strategic vision" so it's up to us to show a better path (of stealing^W liberating other people's code. ;)
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2439

PostPosted: Wed Apr 02, 2014 7:51 pm    Post subject: Reply with quote

While it's semi-on-topic, systemd is at it again...

Systemd Is Working Towards Its Own Super Fast DHCP Server, Client
http://www.phoronix.com/scan.php?page=news_item&px=MTY1Mjc

Wonder what Uberlord (Roy Marples) thinks of this. I did a quick search of his name combined with "systemd" and every hit left the "d" off of the end of "system".

One comment though... It doesn't matter how fast your dhcp client is, if the server is a pig. At home on my tiny network the dhcp negotiation is fast on my work laptop. At work the same laptop is quite slow.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2403
Location: The Peanut Gallery

PostPosted: Wed Apr 02, 2014 8:11 pm    Post subject: Reply with quote

The road to dependency-hell is paved with premature optimisations. ;)
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Wed Apr 02, 2014 8:21 pm    Post subject: Reply with quote

depontius wrote:
While it's semi-on-topic, systemd is at it again...

Systemd Is Working Towards Its Own Super Fast DHCP Server, Client
http://www.phoronix.com/scan.php?page=news_item&px=MTY1Mjc


And people thought I was full of...um, fertilizer, when I said that networking would be subsumed into sysd.
Though I did say iptables instead of just networking. But I could see where they were going.

Up next, Redhat windoze™. ;)
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4001

PostPosted: Wed Apr 02, 2014 10:22 pm    Post subject: Re: systemd ??? Reply with quote

Anon-E-moose wrote:
Interesting article, though a lot of what I read is his view without facts, ie an opinion.

I must admit that I have cited it without reading it completely: I had glanced only over the first part concerning PID1. So, please, don't blame me for the content of the rest.
Quote:
Though I did say iptables instead of just networking.

This is an enormous difference: I think that (basic) networking should be part of an (extended) init-system; this was already so with openrc (though netifrc was split recently, it is still strongly tied to openrc), and IMHO networking was one of the things which really had been missing in systemd. But of course to reimplement a dhcp client instead of relying on an external program is yet another systemd crazyness. Probably it will not take long until it is no longer possible to use another than the internal dhcp client with systemd.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Wed Apr 02, 2014 10:44 pm    Post subject: Reply with quote

Again, I don't think that init should be doing anything but initialization, reaping and shutdown.

If systemd had done that with everything else as a secondary process, ala openrc, then people would have less concerns.
But as I've said they want people to take it all.
Does anyone truly believe that they aren't talented enough to have designed the kitchen sink as separate pieces.

The kitchen sink gives great power over those who use it, pieces can be swapped in and out.
Therein lies the reason it is the way it is.

On an RH distro, even if you opt for kde, xfce, lxde or just a wm like openbox, you're still stuck with systemd whether you want/need it or not.

Edit to add: and woe be to those who have taken the poisoned fruit, like centos, ubuntu, etc.
I would guess that within the next year, two at the outside, that everyone else except RH
using systemd will be second class citizens. And if anyone thinks that RH wouldn't do such
a thing, they don't understand corporations.

My personal opinion is that they are a little too late with this push for the desktop.
The desktop isn't going away, but it's not growing by leaps and bounds either.
Tablets, smartphones, etc are what many people use nowadays.
And quite frankly, there's next to no need for things like cgroup mgmt, etc on tablets.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2439

PostPosted: Wed Apr 02, 2014 11:12 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Again, I don't think that init should be doing anything but initialization, reaping and shutdown.


I'll throw the question back... Let's assume that services and daemons are handled by PID2. Does PID1 need to handle orphans by itself, or is there a mechanism for it to pass that job off to some other process, say PID3? In other words, can PID1 be reduced to initialization, starting a service/daemon manager, a reaper, and shutdown?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Wed Apr 02, 2014 11:30 pm    Post subject: Reply with quote

depontius wrote:
Anon-E-moose wrote:
Again, I don't think that init should be doing anything but initialization, reaping and shutdown.


I'll throw the question back... Let's assume that services and daemons are handled by PID2. Does PID1 need to handle orphans by itself, or is there a mechanism for it to pass that job off to some other process, say PID3? In other words, can PID1 be reduced to initialization, starting a service/daemon manager, a reaper, and shutdown?


Orphans default to being owned by pid 1, I'm not aware of a method for it to hand it to another process.

init starts openrc now, which in turn starts daemons and services.
Openrc does need to be enhanced, with something like monit for monitoring services/daemons dieing and restarting them.
But the framework is there for your query. Unless I'm not understanding what you're asking.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2403
Location: The Peanut Gallery

PostPosted: Thu Apr 03, 2014 12:12 am    Post subject: Reply with quote

depontius wrote:
I'll throw the question back... Let's assume that services and daemons are handled by PID2. Does PID1 need to handle orphans by itself, or is there a mechanism for it to pass that job off to some other process, say PID3? In other words, can PID1 be reduced to initialization, starting a service/daemon manager, a reaper, and shutdown?

Yes, and that's what it's meant to do. The prctl gives the ability for a service manager, ie the top-level system control and monitoring process pair to reap the process-tree under them. So we'd take all the service related processes out of the equation as far as pid 1 is concerned (unless something goes wrong and it has to restart the control, which would be quite a bug, as it should do very little as well.) P1 would simply reap the orphans we don't care about, the throwaway stuff from user sessions, and in this model could slim down if needs be, simply passing signals to p2, including for shutdown. Though it does need the ability to restart p2, and to my mind there's no real need to change sysvinit at this stage.

Just don't let people confuse your discussion with talk of "sysvinit" when they mean "sysv-rc". It's not Gentoo's fault they didn't progress to the next stage as we did with openrc, thanks to Roy Marples and his work with NetBSD; trying to move forward in this field without understanding that work, and how it was a qualitative progression, is simply foolish, imo.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Thu Apr 03, 2014 11:36 am    Post subject: Reply with quote

Short of cgroup mgmt, logind and daemon restart capability, what does systemd offer that openrc doesn't right now?

And openrc working with monit would add monitor/restart capability better than what systemd offers.

So a cgroup mgmt package, being started by openrc would fulfill that missing feature

I suppose that using ubuntu's logind and possibly enhancing it and making it an openrc started service would just about do it.

Dbus is already in existence, as a daemon/service.

Binary logging is a foolish idea, IMO.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4150

PostPosted: Thu Apr 03, 2014 4:35 pm    Post subject: Reply with quote

Anon-E-moose wrote:
And openrc working with monit would add monitor/restart capability better than what systemd offers.

Specially as you don't need any monitoring for a desktop, vital services cannot crash without you see them crashing, and you might never see trivial ones have crash, just because you don't care.
if something crash, you'll see it, you're using it. Not like a server that should be able to "live its life" alone.

And the binary logging will do wonder with rootkit... No need to look and hack any logger the computer use to hide your presence, just hack the tool the user must use to read his log, sweet...
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Thu Apr 03, 2014 4:38 pm    Post subject: Reply with quote

krinn wrote:
Anon-E-moose wrote:
And openrc working with monit would add monitor/restart capability better than what systemd offers.

Specially as you don't need any monitoring for a desktop, vital services cannot crash without you see them crashing, and you might never see trivial ones have crash, just because you don't care.
if something crash, you'll see it, you're using it. Not like a server that should be able to "live its life" alone.


I agree, and that's why things like that should be optional not part of the init pkg.

You want to use it, start the service and use it.
You don't want to use it, it's not part of init leaving an attack vector to possibly use.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
ArneBab
Guru
Guru


Joined: 24 Jan 2006
Posts: 368
Location: Graben-Neudorf, Germany

PostPosted: Thu Apr 03, 2014 4:40 pm    Post subject: Reply with quote

For “speed issues” of bash scripts: I recently did a test with running Guile scripts via a shell-delegate trick. This meant running the Guile script as a shell script and in the shell script starting the script with guile. The overhead was a whopping 6ms. That’s what it costs to start a shell from bash. See the numbers in the article draft: http://draketo.de/proj/py2guile/#sec-5-3-2-1

So you would have to start almost 200 scripts just to get to a combined cost of one single second. And remember that after the first run the shell binary will be in the filesystem cache, so it does not even need a second filesystem access.
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )

pkgcore: So fast that it feels unreal - by doing only what is needed.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4001

PostPosted: Fri Apr 04, 2014 7:23 pm    Post subject: Reply with quote

ArneBab wrote:
For “speed issues” of bash scripts

Startup of bash is a terribly slow. Indeed, several ms are normal even on fast machines. Moreover, this time is already lost for starting a subshell, i.e. every usage of (...) or $(...) in a bash script costs this time. For testing on your machine:
Code:
bash -c 'time for i in {1..10000}; do (:); done'

dash, in comparison, is several factors quicker, even if you use slower code:
Code:
time sh -c 'for i in $(seq 1 10000); do (:); done'

This is one of the main reasons why openrc+dash gives such a dramatic improvement over openrc+bash. It is not surprising that systemd is faster than openrc+bash, but that systemd is slower than openrc+dash shows that its configuration complexity is already even much worse than that of a shell language. Already the "philosophy" is broken: "shell is bad, because it is too complex, powerful and slow". "Solution": Replace it by a much more complex and slower kitchen sink, but taking away the freedom of the user to choose the tools. So the only problem that it actually solves is the ego problem of its main developer.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Fri Apr 04, 2014 7:37 pm    Post subject: Reply with quote

I used to use ksh (liked it quite well) before bash became the defacto shell.

I'll have to time ksh vs dash someday and see what it shows.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2175

PostPosted: Fri Apr 04, 2014 8:26 pm    Post subject: Reply with quote

mv wrote:
This is one of the main reasons why openrc+dash gives such a dramatic improvement over openrc+bash.

mv ... indeed, I've been using that combination for some time and from the point of entering the luks key (from the initramfs) to being provided a login prompt is about 2 (maybe 2.5) seconds. That said, I don't think speed is the primary concern, other factors, such as dependability, transparency, etc, I would place above speed (I generally hibernate anyhow, so that lessens the time spent booting considerably). That said, I'd definitely recommend replacing bash with dash (which can be managed via app-admin/eselect-sh) as the default posix shell (and app-shells/zsh for interactive use). If it were not for portage using bash explicitly, and the fact that bashisms seem to creep from all directions I could probably do without bash entirely. As I've written elsewhere the reason that bash is the default shell on linux, is because bash is the default shell on linux :)

best ... khay
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Fri Apr 04, 2014 8:49 pm    Post subject: Reply with quote

So, khayyam, no problems with any of the init.d scripts using dash?

I'm in the process of emerging it, but don't want the system to have problems booting.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4150

PostPosted: Fri Apr 04, 2014 8:50 pm    Post subject: Reply with quote

mv wrote:
"Solution": Replace it by a much more complex and slower kitchen sink, but taking away the freedom of the user to choose the tools. So the only problem that it actually solves is the ego problem of its main developer.

So true, it's even worst, it seems so odd to see a dedicated tool for linux only manage to do worst than others ones that are portable.
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Fri Apr 04, 2014 10:08 pm    Post subject: Reply with quote

Anon-E-moose wrote:
So, khayyam, no problems with any of the init.d scripts using dash?

All the basic stuff in openrc itself works perfectly with dash. I've also never run into any init scripts (or even other shell scripts using #!/bin/sh) that fail with dash, but it's possible some may exist somewhere. It seems that a lot of the cleanup work that was done a few years ago to lessen the reliance on bash (outside of ebuilds) was very successful.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2245
Location: Dallas area

PostPosted: Fri Apr 04, 2014 10:17 pm    Post subject: Reply with quote

Thanks broken_chaos and khayyam.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2175

PostPosted: Fri Apr 04, 2014 11:15 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Thanks broken_chaos and khayyam.

Anon ... heh, I get thanks for doing nothing ... well, let me earn that thanks now, but none the less ... you're welcome.

So, as broken_chaos stated, there has been some QA on rcscripts, and bashisms are generally fixed. That said you shouldn't have any problems with dash as /bin/sh. If you're worried and want to check you can run dev-util/checkbashisms on any/all of the installed rcscripts and see if it brings up any issues ...

Code:
# checkbashisms -f killprocs ; echo $?
0

I do have a number of patches sitting in /etc/init.d but these are from a period of time when I was trying to get ash (from busybox) working and I'm not entirely sure these are needed. I thought I'd attached these to the dependent bugs on the the tracker but it seems not (they are definitely here on the forum, but I can't find them right now). Anyhow, it was ash that had issues and I don't remember any issues with dash (though, I may still have some changes made here and there ... I can't remember to be honest). So you probably won't have any issues, if you do (ie, with swapfiles or xdm ... or any others) then let me know and I'll take a closer look.

best ... khay
Back to top
View user's profile Send private message
AgBr
Apprentice
Apprentice


Joined: 06 Nov 2010
Posts: 186

PostPosted: Sat Apr 05, 2014 12:49 pm    Post subject: Reply with quote

Anon-E-moose wrote:
So, khayyam, no problems with any of the init.d scripts using dash?

I'm in the process of emerging it, but don't want the system to have problems booting.

I do not have problems so far
Back to top
View user's profile Send private message
FastTurtle
Guru
Guru


Joined: 03 Sep 2002
Posts: 388
Location: Shake & Bake

PostPosted: Sat Apr 05, 2014 4:23 pm    Post subject: Reply with quote

And my system boots as fast as it needs because I boot once and rarely have to reboot for anything other then a changed kernel. I don't even like the initrm.fs setup as it's just another kludge to work around DOS limits that shouldn't be a concern on a 64bit CPU.

As to boot speed, I don't care since it's such a rare occurence. Hell even with Windows, the only time I reboot is when forced to by WinUpdate. Otherwise, I put the system into S4/5 sleep mode and walk away (system power demand is the same as being off in either).

One of the main issues I have with SystemD is the insistence on breaking the seperation of mount points by including everything on /root and is the same mistake MS made that they're now trying to work away from but everyone is used to it all being one blasted partition. I'll keep my /usr and such seperarte because once I have all the software installed, I set /usr to mount read-only and any software that insists on writing it's config and other files there doesn't stay on the system because that's simply Bad Design.

From my limited reading on SystemD (curousy at best) it appears to be a continuation of the MS Embrace/Extend/Extinguish policy that's being carried out even today against Android with their patent claims and Google is letting them get away with it instead of demanding the patent numbers that are being infringed. Who benefits from this? The only ones I can think of are the "Trusted Computing Platform" (founded by MS and Intel and owned by either the NSA or DHS (dept. homeland security - there's a shade of the Nazi's "For the Fatherland/Homeland!)).

Thankfully, the Linux Kernel is Torvald's and he controls the development with a hot iron fist at times so I don't think the issue in regards to SystemD taking over Linux is going to happen. There are to many people involved who don't like the idea and will do everything possible to prevent it from taking over entirely because once it does, then Linux is dead and should be buried because at that point, I will no longer trust the computer as it's not mine even though I paid for it.
Back to top
View user's profile Send private message
ArneBab
Guru
Guru


Joined: 24 Jan 2006
Posts: 368
Location: Graben-Neudorf, Germany

PostPosted: Thu Apr 10, 2014 11:09 am    Post subject: Reply with quote

mv wrote:
ArneBab wrote:
For “speed issues” of bash scripts

Startup of bash is a terribly slow. Indeed, several ms are normal even on fast machines. Moreover, this time is already lost for starting a subshell, i.e. every usage of (...) or $(...) in a bash script costs this time. For testing on your machine:
Code:
bash -c 'time for i in {1..10000}; do (:); done'

Are we using the same unit of measure when we talk about ms (milliseconds)?

Several Milliseconds is not slow - especially not in a system which needs seconds to start. Essentially this is one of the least important issues for init-scripts.

mv wrote:
"Solution": Replace it by a much more complex and slower kitchen sink, but taking away the freedom of the user to choose the tools. So the only problem that it actually solves is the ego problem of its main developer.


Full ack here.
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )

pkgcore: So fast that it feels unreal - by doing only what is needed.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4001

PostPosted: Thu Apr 10, 2014 3:34 pm    Post subject: Reply with quote

ArneBab wrote:
Several Milliseconds is not slow

It is, especially in a "language" which permanently must spawn subshells. For a decently complex script with some successively calliing functions/scripts you are easily executing hundreds of subshells. If one subshell takes 10ms just to start, you are already losing seconds only due to the subshell calls - the actual time to actually execute the script and do something useful is not even counted here.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
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