View previous topic :: View next topic |
Author |
Message |
jhon987 Apprentice
Joined: 18 Nov 2013 Posts: 297
|
Posted: Tue Jun 06, 2017 2:36 pm Post subject: openRC instead of sysVinit? |
|
|
So I just learned about the new cool option that you can use openRC-init instead of sysVinit (https://wiki.gentoo.org/wiki/OpenRC#openrc-init)
However the Gentoo wiki is very silent on that matter.
I'm trying it right now actually and besides needing to add ttys to the runlevels myself and few commands differ in syntax, e.g. openrc shutdown, openrc reboot.... everything else pretty much feel the same
Does anyone knows what purpose it's used for i.e. what use-case?
Personally, I thought I might gain a tiny boot boost for the openrc code is more modern than sysV but it seems that is not the case.
Any thoughts? |
|
Back to top |
|
|
charles17 Advocate
Joined: 02 Mar 2008 Posts: 3664
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Tue Jun 06, 2017 6:18 pm Post subject: |
|
|
WilliamH-ware like current openrc is the biggest example of "this program comes with no warranty" in Gentoo today. Use its pid1 if you want, but be informed that it's likely to disappear with as little warning or consultation with the Gentoo community as which it appeared. |
|
Back to top |
|
|
Zucca Moderator
Joined: 14 Jun 2007 Posts: 3343 Location: Rasi, Finland
|
Posted: Tue Jun 06, 2017 6:38 pm Post subject: Re: openRC instead of sysVinit? |
|
|
jhon987 wrote: | Does anyone knows what purpose it's used for i.e. what use-case? | I'd like to know too.
It seems like it does not provide much functionality yet. I might be wrong though...
I wonder what's its goal? _________________ ..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote: | I am NaN! I am a man! |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Tue Jun 06, 2017 6:55 pm Post subject: Re: openRC instead of sysVinit? |
|
|
Zucca wrote: | jhon987 wrote: | Does anyone knows what purpose it's used for i.e. what use-case? | I'd like to know too.
It seems like it does not provide much functionality yet. I might be wrong though...
I wonder what's its goal? | PID1 isn't meant to provide "much functionality"
1) get launched by the kernel
2) spawn init
3) reap zombies.
Looking at the code ... give or take, that's what it does & that is all it needs to do. PID1 is meant to be boring, simple, reliable. The more you put into PID1 the increase chance that it might be unstable & this is one process you do NOT want to be unstable!
One one hand this is good! finally openRC is a full fledged init system that can stand on its own! On the other... knowing the steward of the codebase now, what would be shoehorned into PID1. _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
jhon987 Apprentice
Joined: 18 Nov 2013 Posts: 297
|
Posted: Tue Jun 06, 2017 7:30 pm Post subject: Re: openRC instead of sysVinit? |
|
|
Thanks guys for all the input
Charles17 your link to the commit is much appreciated.
Naib wrote: |
Looking at the code ... give or take, that's what it does & that is all it needs to do. PID1 is meant to be boring, simple, reliable. The more you put into PID1 the increase chance that it might be unstable & this is one process you do NOT want to be unstable!
One one hand this is good! finally openRC is a full fledged init system that can stand on its own! On the other... knowing the steward of the codebase now, what would be shoehorned into PID1. |
Naib you seem to know your way around the code and quite informed on the subject generally, can you give an insight perhaps what's the use of replacing sysV with openRC, I mean, why suddenly at version 0.25 an openRC replacement of sysV pops up? what's behind it do you think? what's the goal?
I'd ask the devs directly as I'm quite curious about it, but I don't know them personally and I'm assuming they're quite busy to answer random questions... |
|
Back to top |
|
|
charles17 Advocate
Joined: 02 Mar 2008 Posts: 3664
|
Posted: Wed Jun 07, 2017 5:01 am Post subject: Re: openRC instead of sysVinit? |
|
|
jhon987 wrote: | ... what's the use of replacing sysV with openRC, ... | And there are some more alternatives https://wiki.gentoo.org/wiki/Init_system. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Jun 07, 2017 5:35 pm Post subject: |
|
|
Whichever init you go with, be mindful of who owns the package as maintainer. Some of them have no interest in responding to system-breaking bugs at all. |
|
Back to top |
|
|
Zucca Moderator
Joined: 14 Jun 2007 Posts: 3343 Location: Rasi, Finland
|
Posted: Wed Jun 07, 2017 6:24 pm Post subject: Re: openRC instead of sysVinit? |
|
|
Naib wrote: | Looking at the code ... give or take, that's what it does & that is all it needs to do. PID1 is meant to be boring, simple, reliable. The more you put into PID1 the increase chance that it might be unstable & this is one process you do NOT want to be unstable!
One one hand this is good! finally openRC is a full fledged init system that can stand on its own! On the other... knowing the steward of the codebase now, what would be shoehorned into PID1. |
shellcmd: du -h /usr/lib/systemd/systemd : | 1.1M /usr/lib/systemd/systemd | ... what the wtf? Well... glibc adds quite a lot to binary size, but afaik systemd cannot be built against any other libc... This is what I "have to" keep up with.
Anyways, I do hope OpenRC-init never reaches this. _________________ ..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote: | I am NaN! I am a man! |
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Jun 07, 2017 6:36 pm Post subject: |
|
|
Might be a bit more meaningful to measure it this way:
Code: | ~ $ qsize --ignore /usr/share/'(doc|man)' openrc runit | column -ts ':'
sys-apps/openrc-0.26.3 198 files, 31 non-files, 106 names-ignored, 1,903.442 KiB
sys-process/runit-2.1.2-r9 26 files, 14 non-files, 37 names-ignored, 238.282 KiB |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Wed Jun 07, 2017 7:00 pm Post subject: |
|
|
Ant P. wrote: | Might be a bit more meaningful to measure it this way:
Code: | ~ $ qsize --ignore /usr/share/'(doc|man)' openrc runit | column -ts ':'
sys-apps/openrc-0.26.3 198 files, 31 non-files, 106 names-ignored, 1,903.442 KiB
sys-process/runit-2.1.2-r9 26 files, 14 non-files, 37 names-ignored, 238.282 KiB |
| Thats the entire init system scripts and all. comparing the size of the actual init (PID1) process makes sense.
Code: | ls -lh /sbin/openrc-init
-rwxr-xr-x 1 root root 11K Jun 2 16:29 /sbin/openrc-init
|
11k for openrc-init isn't too bad.
Code: |
ls -lh /sbin/runit
-rwxr-xr-x 1 root root 19K Jun 7 19:57 /sbin/runit |
much of muchness at this level.
1.1Meg for systemd PID1 is ridiculous _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Jun 07, 2017 7:12 pm Post subject: |
|
|
That ignores the size of /lib/librc.so.1 that openrc-init depends on.
But if we start counting what ldd adds, I imagine systemd's situation is even more dire. I hear they're big fans of XML. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Wed Jun 07, 2017 7:23 pm Post subject: |
|
|
good point:
Code: |
ldd /sbin/openrc-init
linux-vdso.so.1 (0x00007ffc8add1000)
librc.so.1 => /lib64/librc.so.1 (0x00007f8542d90000)
libc.so.6 => /lib64/libc.so.6 (0x00007f85429f5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8542f9e000)
#bash-fu failed me todo this in one go...
ls -lrt /sbin/openrc-init /lib64/libc.so.6 /lib64/librc.so.1 /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 12 May 13 20:37 /lib64/libc.so.6 -> libc-2.24.so
lrwxrwxrwx 1 root root 10 May 13 20:37 /lib64/ld-linux-x86-64.so.2 -> ld-2.24.so
-rwxr-xr-x 1 root root 55680 Jun 2 16:29 /lib64/librc.so.1
-rwxr-xr-x 1 root root 10248 Jun 2 16:29 /sbin/openrc-init
ls -lrt /sbin/openrc-init /lib64/libc.so.6 /lib64/librc.so.1 /lib64/ld-linux-x86-64.so.2 | awk '{ total += $5 }; END { print total }'
65950
ldd /sbin/runit
linux-vdso.so.1 (0x00007ffc28fdb000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb472cf7000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb473092000)
ls -lrt /sbin/runit /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 12 May 13 20:37 /lib64/libc.so.6 -> libc-2.24.so
lrwxrwxrwx 1 root root 10 May 13 20:37 /lib64/ld-linux-x86-64.so.2 -> ld-2.24.so
-rwxr-xr-x 1 root root 18656 Jun 7 20:12 /sbin/runit
ls -lrt /sbin/runit /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 | awk '{ total += $5 }; END { print total }'
18678
|
openrc-init is 3.5x larger but more than likely dwarfed by systemd. I might remote into my work ubuntu box and do a similar thing... I will need to sort my bash-fu I suspect 10-20 libraries and no chance am I pasting them when bash and cut can do that _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Wed Jun 07, 2017 7:36 pm Post subject: |
|
|
thats better:
Code: |
sizedep() { stat --format=%s $1 $(ldd $1 | cut -d' ' -f3 | tr '\n' ' ') | awk '{s+=$1} END {print s}'; }
$ sizedep /sbin/openrc-init
65940
$ sizedep /sbin/runit
18668
|
ill execute this on my NUbuntu box shortly _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Zucca Moderator
Joined: 14 Jun 2007 Posts: 3343 Location: Rasi, Finland
|
Posted: Wed Jun 07, 2017 9:59 pm Post subject: |
|
|
I don't know how accurate this is but... shellcmd: ldd /usr/lib/systemd/systemd | awk '{if ($4) if (!x[$3]++) printf $3 "\000"}' | xargs -0 readlink -zf | du --files0-from=- --apparent-size -hc : | 2.2M /usr/lib64/systemd/libsystemd-shared-233.so
31K /lib64/librt-2.24.so
259K /usr/lib64/libseccomp.so.2.3.2
59K /lib64/libpam.so.0.84.2
103K /lib64/libaudit.so.1.0.0
87K /lib64/libkmod.so.2.3.2
302K /lib64/libmount.so.1.1.0
128K /lib64/libpthread-2.24.so
1.6M /lib64/libc-2.24.so
23K /lib64/libcap.so.2.25
151K /lib64/liblzma.so.5.2.3
79K /usr/lib64/liblz4.so.1.7.5
1.1M /usr/lib64/libgcrypt.so.20.1.6
35K /lib64/libacl.so.1.1.0
207K /usr/lib64/libidn.so.11.6.16
273K /lib64/libblkid.so.1.1.0
160K /usr/lib64/libcryptsetup.so.4.7.0
15K /lib64/libdl-2.24.so
19K /usr/lib64/libcap-ng.so.0.0.0
91K /lib64/libz.so.1.2.11
83K /usr/lib64/libgpg-error.so.0.22.0
19K /lib64/libattr.so.1.1.0
19K /lib64/libuuid.so.1.3.0
346K /lib64/libdevmapper.so.1.02
138K /usr/lib64/libudev.so.1.6.6
979K /lib64/libm-2.24.so
8.3M total |
Aaaand SysVinit on my server: shellcmd: ldd /sbin/init | awk '{if ($4) if (!x[$3]++) printf $3 "\000"}' | xargs -0 readlink -zf | du --files0-from=- --apparent-size -hc : | 1.6M /lib64/libc-2.23.so
1.6M total |
These don't count the main binary in though... _________________ ..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
Quote: | I am NaN! I am a man! |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Fri Jun 09, 2017 8:19 am Post subject: |
|
|
Code: | sizedep /sbin/init
2306855 |
Code: | readlink /sbin/init
/lib/systemd/systemd |
Code: | ldd /sbin/init
linux-vdso.so.1 => (0x00007ffd285c0000)
libsystemd-shared-232.so => /lib/systemd/libsystemd-shared-232.so (0x00007f0a210cf000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f0a20e71000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0a20c69000)
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f0a20a24000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f0a20816000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f0a205ec000)
libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007f0a203d5000)
libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f0a201c4000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007f0a1ff79000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a1fd5b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a1f994000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f0a1f78c000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f0a1f566000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f0a1f34e000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f0a1f03f000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f0a1ee37000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f0a1ec04000)
/lib64/ld-linux-x86-64.so.2 (0x000055f444d69000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f0a1e98f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a1e78b000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f0a1e586000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f0a1e341000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f0a1e12d000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f0a1df26000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f0a1dd21000) |
Code: | uname -a
Linux ###### 4.10.0-20-generic #22-Ubuntu SMP Thu Apr 20 09:22:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
|
2.3Meg.... _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Leio Developer
Joined: 27 Feb 2003 Posts: 494 Location: Estonia
|
Posted: Fri Jun 09, 2017 9:05 pm Post subject: |
|
|
... of which almost everything is used by something else as well. Hint: shared memory. _________________ GNOME team lead; GStreamer; MIPS/ARM64 |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Jun 11, 2017 2:16 pm Post subject: |
|
|
And that isn't needed by PID1. Hint it just sweeps up orphans and launches startup processes. If PID2 needs additional complexity then so be it BUT PID1 doesnt. Chain load but I have covered this _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
saellaven l33t
Joined: 23 Jul 2006 Posts: 646
|
Posted: Sun Jun 11, 2017 3:48 pm Post subject: |
|
|
The issue isn't about how much RAM/disk space it consumes (though that is a valid issue in some circumstances), it's the fact that, the more complicated PID1 becomes and the more libraries it pulls in, the more likely it is to have an exploitable bug in it that becomes a security nightmare. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sun Jun 11, 2017 4:49 pm Post subject: |
|
|
saellaven wrote: | The issue isn't about how much RAM/disk space it consumes (though that is a valid issue in some circumstances), it's the fact that, the more complicated PID1 becomes and the more libraries it pulls in, the more likely it is to have an exploitable bug in it that becomes a security nightmare. |
Bingo! |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Jun 11, 2017 7:16 pm Post subject: |
|
|
I have to wonder how it makes meaningful use of selinux, pam, apparmor, capabilities and seccomp all at the same time. Maybe they're necessary for safely handling all the unicode domain name processing it needs to do? |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Thu Jun 15, 2017 10:28 am Post subject: |
|
|
ignoring the ignorant noise a few posts up...
anyone tried openrc-init? i am tempted to give it a go tonight _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
josephg l33t
Joined: 10 Jan 2016 Posts: 783 Location: usually offline
|
Posted: Thu Jun 15, 2017 11:01 am Post subject: Re: openRC instead of sysVinit? |
|
|
jhon987 wrote: | Personally, I thought I might gain a tiny boot boost for the openrc code is more modern than sysV but it seems that is not the case. |
hmm.. if not, then personally i'd plonk for runit reducing bloat, but for so much invested in openrc to get away from. _________________ "Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey |
|
Back to top |
|
|
josephg l33t
Joined: 10 Jan 2016 Posts: 783 Location: usually offline
|
Posted: Wed Jun 28, 2017 2:40 pm Post subject: |
|
|
Naib wrote: | anyone tried openrc-init? i am tempted to give it a go tonight |
i did that day itself.. and reverted back straight away as i didn't know how to get my preferred mgetty configs.
just tried again.. configured agetty in /etc/conf.d/agetty. still don't know how to config each individually. /etc/inittab is redundant. everything seems to be working for now.
i like how openrc-init is so much smaller and hopefully more efficient than sysvinit. _________________ "Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey
Last edited by josephg on Wed Jun 28, 2017 4:12 pm; edited 1 time in total |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Jun 28, 2017 3:53 pm Post subject: |
|
|
Personally, I think sysvinit is fine; the most I'd do to it is strip the src repo of the sysvrc code (which is what people confuse with sysvinit = pid1.)
I don't think it helps at all, to keep it in the same repo as your pid2 implementation; it's a pure violation of modularity, IMO.
That means you simply open yourself up to the temptation to tie the code to things it has no need to be tied-to; keeping separation means that can never happen.
It also means the admin has a harder time picking and choosing.
The component-based approach falls down when components are all in fact bundles.
It cannot be anything else, because there simply is no reason to share any (lib-type) code. (Even if there were, that should be split out; but there isn't, given a POSIX libc.)
The reason for that is that pid1 is supposed to be kept simple; sysvinit already does plenty, and what it does in pid1 is actually very useful there.
Given that you have a pid1, over time the "extras" it does, confusedly called "bloat", would just be reinvented: starting up the initsystem and consoles is practically-speaking mandatory. You need a way for unrelated processes run by or as root, to be able to shutdown or restart the machine. Runlevels end up being reused in one form or another, and it is useful to be able to defer something until its end (like xdm does.) Since you're handing over control to something else for everything, it is again useful to be able to specify whether you want to wait, fire-and-forget, or respawn. Hello inittab.
So, IMO the design space has already been explored well enough over the last 40 years, and sysvinit (pid1, without sysvrc) does it right. Merging it with something else doesn't go anywhere good, and there is nothing new to explore (people here want it to do less, not more than sysvinit. systemdiots want it to do more, which only makes it an attack vector for zero practical purpose, and they're doing that elsewhere, so kind of outta scope for our discussion) so it's hardly interesting, except as a first or second C project. The simple spec of a less useful impl, means you can do that in any language supporting fork and wait primitives (as we've seen on these forums.)
In software development terms, all that needs to happen is sysvinit pid1 needs to be kept maintained, for rc/initsystem developers to have a stable base to work from (if they would only see that..) |
|
Back to top |
|
|
|