| View previous topic :: View next topic |
| Author |
Message |
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
 Posted: Sat Aug 24, 2019 9:41 am Post subject: openrc-0.42.2 and sysv-utils |
 |
|
Just going through my update and I see openrc-0.42.1 -> openrc-0.42.2
Curious as to what this is I looked at the ebuild
| Code: | sysv-utils? ( !sys-apps/sysvinit )
!sysv-utils? ( >=sys-apps/sysvinit-2.86-r6[selinux?] )
virtual/tmpfiles
|
Essentially this puts a block on sysvinit, which currently provides /sbin/init. Now for some time openrc has come with its own init (making it a more complete init/daemon manager) openrc-init ( https://forums.gentoo.org/viewtopic-t-1064510-highlight-openrcinit.html https://wiki.gentoo.org/wiki/OpenRC/openrc-init ) and for some time I have been thinking of switching over but not really had the time.
The caveats on this have been that sysvinit type commands (halt, reboot, init ....) will not work as there would be a namespace clash (easily managed via alias OR if you really wanted to mess with the low-level system... symlink [not a good idea imho])
The other was getty's as these would not be launched by default ... ok for manual steps
Doing a quick search, systemd ran into a similar issue a while back ( https://www.gentoo.org/support/news-items/2018-01-23-systemd-blocker.html) and this is where this sysv-utils flag was added to "magically" create expected symlinks to mitigate namespace clashes... seems reasonable and under the system control.
So How does this impact OpenRC
The default is OFF (ok) so OpenRC still uses sysvinit and inittab
| Quote: |
[ebuild U ] sys-apps/openrc-0.42.1::gentoo [0.41.2::gentoo] USE="ncurses netifrc pam (split-usr) unicode -audit -bash -debug -newnet (-prefix) (-selinux) -static-libs -sysv-utils%" 238 KiB
|
Setting the flag causes the expected block.
| Quote: | [ebuild U ] sys-apps/openrc-0.42.1::gentoo [0.41.2::gentoo] USE="ncurses netifrc pam (split-usr) sysv-utils%* unicode -audit -bash -debug -newnet (-prefix) (-selinux) -static-libs" 238 KiB
[blocks B ] sys-apps/sysvinit ("sys-apps/sysvinit" is blocking sys-apps/openrc-0.42.1)
|
So the rhetorical question is... if I fix the blockage (emerge -C sysvinit) will portage
1) create expected sysvinit commands (mitigating issues with elogind: https://forums.gentoo.org/viewtopic-t-1100642-highlight-openrcinit.html)
2) will it create any getty's
| Code: |
# emerge -C sysvinit
* This action can remove important packages! In order to be safer, use
* `emerge -pv --depclean <atom>` to check for reverse dependencies before
* removing packages.
sys-apps/sysvinit
selected: 2.95
protected: none
omitted: none
emerge openrc -va
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-apps/openrc-0.42.1::gentoo [0.41.2::gentoo] USE="ncurses netifrc pam (split-usr) sysv-utils%* unicode -audit -bash -debug -newnet (-prefix) (-selinux) -static-libs" 238 KiB
|
The symlinks are setup
| Code: | readlink $(which init halt reboot)
openrc-init
/lib/rc/bin/halt
/lib/rc/bin/reboot |
and six agetty's are created
| Quote: | readlink /etc/init.d/agetty*
/etc/init.d/agetty
/etc/init.d/agetty
/etc/init.d/agetty
/etc/init.d/agetty
/etc/init.d/agetty
/etc/init.d/agetty |
This seams a smooth migration to a complete OpenRC init
EXCEPT for the expected ... such commands won't work until openrc-init is the init
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
 |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Aug 24, 2019 11:32 pm Post subject: |
|
|
I've been watching openrc evolution, not perfect, but way better than i first think it would goes, i must say williamh isn't doing all good, but more or less, it's good.
It doesn't seem a stupid idea (for a change) to have openrc able to boot by itself, more than just an rc, a true init.
And i think he is going the right way, i must admit i still use sysvinit because, well, it just works, and it's 100% trustable ; but from what i see, again, looks good.
Maybe if i had a clean system i would just goes full openrc, but even migration looks good, well, too much efforts for too less bonus (for now, maybe openrc init will really had some value one day, i mean same value of stability as sysvinit, but maybe a little more value in some addition to it, no idea, maybe shutdown could get something new and useful)
except the stupid "localmount failure to start and cascading errors from it" change (that is awful), openrc (as for 0.42.1) isn't that bad (i consider the systemd modules autoloaded directory really crap, but easy avoidable, so "bad, but not that bad"), but williamh have a bad habit to change/undo/rechange something good for no apparant reason (a kind of last bug report to ask something win, but as soon as another user report to unset it, he wins too and change are undone), and from version to version you could be surprise, which gave an overall bad feeling, but at least, he is one of the few devs i have interract with that take care to listen (it doesn't mean he agree to all, but you are heard). |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sun Aug 25, 2019 9:37 am Post subject: |
|
|
Well it isn't as smooth sailing as it could have been...
While the relaying out of the system was fine (with the small catch22 of... how to shutdown when the init command and thus the halt command no longer exists...), a full openrc-init shutdown has a slight difference and one I don't understand why...
| Quote: | shutdown -h
/sbin/openrc-shutdown --halt
* openrc-shutdown: No shutdown time specified
Usage: openrc-shutdown -c | --cancel
or: openrc-shutdown -R | --reexec
or: openrc-shutdown -w | --write-only
or: openmrc-shutdown -H | --halt time
or: openrc-shutdown -K | --kexec time
or: openrc-shutdown -p | --poweroff time
or: openrc-shutdown -r | --reboot time
or: openrc-shutdown -s | --single time
Options: [ cdDfFHKpRrswChqVv ]
-c, --cancel cancel a pending shutdown
-d, --no-write do not write wtmp record
-D, --dry-run print actions instead of executing them
-H, --halt halt the system
-K, --kexec reboot the system using kexec
-p, --poweroff power off the system
-R, --reexec re-execute init (use after upgrading)
-r, --reboot reboot the system
-s, --single single user mode
-w, --write-only write wtmp boot record and exit
-h, --help Display this help output
-C, --nocolor Disable color output
-V, --version Display software version
-v, --verbose Run verbosely
-q, --quiet Run quietly (repeat to suppress errors) |
For some REALLY odd reason this options have different case from sysvinit shutdown. Thus a lightDM shutdown doesn't actually power off the machine...
https://linux.die.net/man/8/shutdown
| Quote: | Options
-r
Requests that the system be rebooted after it has been brought down.
-h
Requests that the system be either halted or powered off after it has been brought down, with the choice as to which left up to the system.
-H
Requests that the system be halted after it has been brought down.
-P
Requests that the system be powered off after it has been brought down.
-c
Cancels a running shutdown. TIME is not specified with this option, the first argument is MESSAGE.
-k
Only send out the warning messages and disable logins, do not actually bring the system down. |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Aug 25, 2019 12:00 pm Post subject: |
|
|
| you could point it and suggest -p should be -P option |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Sun Aug 25, 2019 1:36 pm Post subject: |
|
|
I was reading some of those links out of curiosity, mainly to see what if any actual advantages there were to using this. The answer seems to be none, unless you count "so openrc can be a complete init system". No thanks to all that...makes me even more glad I've just stuck with sys-apps/openrc-0.17. Maybe I'm missing something, but I don't think I am.
Tom |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54578
Location: 56N 3W
|
| Posted: Sun Aug 25, 2019 1:40 pm Post subject: |
|
|
I'll give it a try when its as mature as sysvinit. I'll be 96 then :)
Meanwhile, sys-apps/openrc-0.17 is hard to beat.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun Aug 25, 2019 6:31 pm Post subject: |
|
|
| NeddySeagoon wrote: | I'll give it a try when its as mature as sysvinit. I'll be 96 then 
Meanwhile, sys-apps/openrc-0.17 is hard to beat. |
Is there a link to a post or story, or anything, to help one understand (a) why an older OpenRC is better (fwiu it has to do with williamh and anti-features?) and (b) why 0.17 specifically? I understand steveL has some patches for it as well, but I don't know where I should be looking for those.
This information will help in my system planning for the overlay/future fork. Compiling all of this into a site or wiki would prove useful, too, but that's for a later time. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Sun Aug 25, 2019 7:08 pm Post subject: |
|
|
| spork_kitty wrote: | | Is there a link to a post or story, or anything, to help one understand (a) why an older OpenRC is better (fwiu it has to do with williamh and anti-features?) and (b) why 0.17 specifically? |
The real question is "what's improved since openrc 0.17", and the answer is nothing whatsoever. What has happened is that unnecessary changes keep getting made that accomplish nothing aside from screwing with end users. I think many settled on 0.17 simply because it predated most of that BS and just plain works.
The very topic of this thread is yet another example as to why many of us went this route: Forcing everyone to abandon a perfectly stable / mature sysvinit, and for no other reason than the usual systemd inspired wheel re-inventing bullshit for no good reason at all.
Tom |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Sun Aug 25, 2019 7:13 pm Post subject: |
|
|
| The above is really a non-answer to what spork_kitty was probably asking for; Replace 'openrc' with any desktop environment you have been using, 'sysvinit' with the toolkit iteration it is depending on, and you get a criticism template that turns up on many version bumps. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Aug 25, 2019 7:14 pm Post subject: |
|
|
I had locked my openrc at 13.11 (not much difference between that and 17.0) because early on I didn't like the changes that were happening to it.
I also have eudev locked at 1.10-r2, it works well and apart from having to modify a few ebuilds to include my version there's been no problems.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Sun Aug 25, 2019 7:30 pm Post subject: |
|
|
| asturm wrote: | | The above is really a non-answer to what spork_kitty was probably asking for; Replace 'openrc' with any desktop environment you have been using, 'sysvinit' with the toolkit iteration it is depending on, and you get a criticism template that turns up on many version bumps. |
To be honest, I'm not sure there is a good answer to the question frankly. The fact that I have to stick with that version just to ensure that some ass-hat doesn't break my system in the process of improving literally nothing at all sort of sucks...but it's the only solution I'm aware of at the moment. As to the original topic, I've also yet to read even one good reason for moving to openrc-init.
Tom |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Sun Aug 25, 2019 8:15 pm Post subject: |
|
|
Really? So LightDM just does nothing? As far as I can tell, elogind calls halt, poweroff or reboot with no arguments, ConsoleKit2 does either /sbin/shutdown -h now or /sbin/shutdown -r now, and everything else, including LightDM, just goes through one of those two. May be it is more convoluted that I thought.
| tld wrote: | | I was reading some of those links out of curiosity, mainly to see what if any actual advantages there were to using this. The answer seems to be none, unless you count "so openrc can be a complete init system". |
Yep, I think that was pretty much the intention. To allow OpenRC to be a complete init system instead of just its service manager.
Personally, I'm not interested in using OpenRC that way. Currently, openrc-init has one flaw: it doesn't supervise any other processes, so theoretically if enough of them die, it would no longer be possible to log in to the machine, so it would need a hard reboot. The author of s6 explains it here (yeah, that's a Reddit link). How likely that is is a different story, but the possibility exists, and that makes openrc-init unreliable. Neither sysvinit, nor runit, nor s6-based init systems have this problem, and, as far as I know, neither does systemd  |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Mon Aug 26, 2019 12:17 am Post subject: |
|
|
| tld wrote: | | spork_kitty wrote: | | Is there a link to a post or story, or anything, to help one understand (a) why an older OpenRC is better (fwiu it has to do with williamh and anti-features?) and (b) why 0.17 specifically? |
The real question is "what's improved since openrc 0.17", and the answer is nothing whatsoever. What has happened is that unnecessary changes keep getting made that accomplish nothing aside from screwing with end users. I think many settled on 0.17 simply because it predated most of that BS and just plain works.
The very topic of this thread is yet another example as to why many of us went this route: Forcing everyone to abandon a perfectly stable / mature sysvinit, and for no other reason than the usual systemd inspired wheel re-inventing bullshit for no good reason at all.
Tom |
Okay, so it's just a convenient place to cut things off. Good to know. Which changes caused the most damage IYO?
I can probably just consult `git log` for specifics, but I figured discussion about it would lead me to meaningful answers and/or anecdotes. I'd like to read any stories you have to share.
(my bad for spawning a tangent; split off of this thread if you can, please, mods. OpenRC-the-init is a separate concern from masking >sys-apps/openrc-0.17) |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Mon Aug 26, 2019 2:37 pm Post subject: |
|
|
| tld wrote: | . As to the original topic, I've also yet to read even one good reason for moving to openrc-init.
Tom |
That's the thing, its PID1, its meant to be simple, non-sexy... It has a couple of VERY simple tasks, manage the handover from kernel to userspace, kick off service manager, reep zombies... That is it so you could say OpenRC didn't need an init, but to be "complete" as an init system it needed it.
Sysvinit and sysvrc co-existed
sysvinit and openrc co-existed..
Part of the problem is people blaming sysvinit for the poor startup of linux systems (part of the PR/FUD from the Systemd crowd to sell their snakeoil). Those who understood knew the issue was with redhat sh coding, but the weaknesses of sysvrc was clear (dependancies etc...). So if distro's wanted to ditch sysvrc because there is performance issues and maintainability issues and feature issues, then yes SystemD looked appealing, but OpenRC (which did the needed shinies) was still dependent on sysvinit "but that is slow, and poorly coded" FACEPALM.
So I sort of see the benefit of OpenRC having an init process and if you look at the code it is simple, as it should be... larger than sysvinit or runit ( look here for some size comparisions https://forums.gentoo.org/viewtopic-t-1064510-highlight-openrcinit.html )
If you now look at the comparison of init systems, for these metrics its comparable to systemd, only major difference is logind (but elogind does that... not init job) and socket-based launching.
https://wiki.gentoo.org/wiki/Comparison_of_init_systems
| GDH-gentoo wrote: |
Really? So LightDM just does nothing? As far as I can tell, elogind calls halt, poweroff or reboot with no arguments, ConsoleKit2 does either /sbin/shutdown -h now or /sbin/shutdown -r now, and everything else, including LightDM, just goes through one of those two. May be it is more convoluted that I thought. |
I don't use elogind, straight lightDM (more for convenience with the wify and kids about... otherwise it would be SLiM+awesomeWM... instead LightDM+{awesomeWM,xfce).
I am going to issue a poweroff command from a terminal right now to see if the issue is with OpenRC-init or with lightDM+OpenRC-init (NOTE: worked with sysvinit so there is definitely a correlation)
| GDH-gentoo wrote: |
Personally, I'm not interested in using OpenRC that way. Currently, openrc-init has one flaw: it doesn't supervise any other processes, so theoretically if enough of them die, it would no longer be possible to log in to the machine, so it would need a hard reboot. The author of s6 explains it here (yeah, that's a Reddit link). How likely that is is a different story, but the possibility exists, and that makes openrc-init unreliable. Neither sysvinit, nor runit, nor s6-based init systems have this problem, and, as far as I know, neither does systemd |
It can supervise daemons since v0.21 via supervise-daemon
_________________
| Quote: | | Removed by Chiitoo |
Last edited by Naib on Mon Aug 26, 2019 4:28 pm; edited 1 time in total |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Mon Aug 26, 2019 4:25 pm Post subject: |
|
|
Just to clarify: You're last quote there was from GDH-gentoo and not me.
Tom |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Mon Aug 26, 2019 5:47 pm Post subject: |
|
|
| Naib wrote: | | I don't use elogind, straight lightDM (more for convenience with the wify and kids about... otherwise it would be SLiM+awesomeWM... instead LightDM+{awesomeWM,xfce). |
Is ConsokeKit2 installed, then?
| Naib wrote: | | It can supervise daemons since v0.21 via supervise-daemon |
It ships with a supervise-daemon program that can supervise its child process, but the supervise-daemon processeses themselves are not supervised by openrc-init. If any of them terminates, it doesn't come back to life. That's where OpenRC's supervision model fails. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Mon Aug 26, 2019 6:04 pm Post subject: |
|
|
| GDH-gentoo wrote: | | Naib wrote: | | I don't use elogind, straight lightDM (more for convenience with the wify and kids about... otherwise it would be SLiM+awesomeWM... instead LightDM+{awesomeWM,xfce). |
Is ConsokeKit2 installed, then? |
Yes. I just went and installed elogind and all working again. Still odd how this stopped
| Quote: |
| Naib wrote: | | It can supervise daemons since v0.21 via supervise-daemon |
It ships with a supervise-daemon program that can supervise its child process, but the supervise-daemon processeses themselves are not supervised by openrc-init. If any of them terminates, it doesn't come back to life. That's where OpenRC's supervision model fails. |
That is true but this is probably still a WIP.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1699
Location: South America
|
| Posted: Tue Aug 27, 2019 2:54 am Post subject: |
|
|
| Naib wrote: | | GDH-gentoo wrote: | | Naib wrote: | | I don't use elogind, straight lightDM (more for convenience with the wify and kids about... otherwise it would be SLiM+awesomeWM... instead LightDM+{awesomeWM,xfce). |
Is ConsokeKit2 installed, then? |
Yes. I just went and installed elogind and all working again. Still odd how this stopped |
Strange indeed. The setup with ConsoleKit2 should have worked. I believe it calls /sbin/shutdown -h now when asked to power off, and that should have been handled by OpenRC's shutdown compatibility script. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Tue Aug 27, 2019 3:53 am Post subject: |
|
|
The "Supported services (in Gentoo)" section only lists openrc & systemd, though I'm not certain if or how that might be significant.
_________________
Quis separabit? Quo animo? |
|
| 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
