| View previous topic :: View next topic |
| Author |
Message |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
 Posted: Thu Jun 02, 2016 5:38 pm Post subject: |
 |
|
"rc is deprecated, please use openrc"
What a cute message to see at boot. I'm *already* using openrc. I don't see openssh or openntpd leaving similar turds in my logs. I'm getting really tired of this deckchair-shuffling ivory tower bullshit.
Guess I should mention I've been planning on making a total replacement for openrc for a while now. The runit stuff I've been doing these past few months has been building towards that; I've gotten pretty comfortable at ripping out spaghetti plumbing and writing my own service scripts. No guarantees it'll turn out good, but I *can* promise no more bending over backwards to appease pen-pushers at other distros who don't matter. How many here are interested? |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Jun 02, 2016 6:16 pm Post subject: |
|
|
| Ant P. wrote: | | How many here are interested? |
Ant ... me, though I should ask, is it runit based, or will it be supervision agnostic?
best ... khay |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Jun 02, 2016 6:37 pm Post subject: |
|
|
| khayyam wrote: | | Ant P. wrote: | | How many here are interested? |
Ant ... me, though I should ask, is it runit based, or will it be supervision agnostic?
best ... khay |
ditto, including question |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Jun 03, 2016 5:01 pm Post subject: |
|
|
| Ant P. wrote: | | "rc is deprecated, please use openrc" |
It means that you should replace /sbin/rc by /sbin/openrc, probably for compatibility with other init systems. Not a big deal. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Jun 03, 2016 10:02 pm Post subject: |
|
|
| khayyam wrote: | | Ant P. wrote: | | How many here are interested? |
Ant ... me, though I should ask, is it runit based, or will it be supervision agnostic?
best ... khay |
Almost all of what I've got up to now is system-agnostic, POSIX shell, one-liners; there is some runit-specific code in there where I used their programs to run daemons as a specific user, enforce a service startup order, or have 1 shot "services" that don't restart on exit. But all of those concepts are common to all supervision systems, it's easy to fix. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Fri Jun 03, 2016 11:08 pm Post subject: |
|
|
| Perhaps the runit specific code could be selected by useflag? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Fri Jun 03, 2016 11:29 pm Post subject: |
|
|
| Ant P. wrote: | "rc is deprecated, please use openrc"
What a cute message to see at boot. I'm *already* using openrc. I don't see openssh or openntpd leaving similar turds in my logs. I'm getting really tired of this deckchair-shuffling ivory tower bullshit.
Guess I should mention I've been planning on making a total replacement for openrc for a while now. The runit stuff I've been doing these past few months has been building towards that; I've gotten pretty comfortable at ripping out spaghetti plumbing and writing my own service scripts. No guarantees it'll turn out good, but I *can* promise no more bending over backwards to appease pen-pushers at other distros who don't matter. How many here are interested? |
Count me in. I have a former CentOS box I keep meaning to rebuild.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Sat Jun 04, 2016 1:37 pm Post subject: |
|
|
| Ant P. wrote: | "rc is deprecated, please use openrc"
What a cute message to see at boot. I'm *already* using openrc. I don't see openssh or openntpd leaving similar turds in my logs. I'm getting really tired of this deckchair-shuffling ivory tower bullshit.
Guess I should mention I've been planning on making a total replacement for openrc for a while now. The runit stuff I've been doing these past few months has been building towards that; I've gotten pretty comfortable at ripping out spaghetti plumbing and writing my own service scripts. No guarantees it'll turn out good, but I can promise no more bending over backwards to appease pen-pushers at other distros who don't matter. How many here are interested? |
I am in... although I am already on a similar supervision take over there for a while now. I could even give a hand... if your solution is more elegant/KISS compared to mine. Actual bigger TODO: complete services for sysinit or stage-0 for a supervision terminology; and add services for boot or stage-1 for base system ((u)mount local and network filesystems, console, keymaps... and how to implement a killprocs service if any? quite the task).
Big deal? Pretty much for portability concerns ad yes it's quite a big task in its own than I anticipated. And that TODO is not that much planned either; it may be done or not because it requires much more testing/portability testing. Everything is or should be functional at the present time and I took care of a KISS POSIX compliant shell and C code. Build system would need a quite a refresh with a proper configure script if the TODO and focus goes to that init-system way which was/were only on the service-manager from the beginning.
EDIT: the pacage is supervision agnostic; only nosh is not supported for now because it goes to systemd route from the start. I don't want to chase that systemd monster everywhere. Else, (busybox-)runit, daemontools(-encore) and s6 are supported.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Sat Jun 04, 2016 3:55 pm Post subject: |
|
|
| Ant P. wrote: | "rc is deprecated, please use openrc"
...
to appease pen-pushers at other distros who don't matter. |
Gentoo would not work that well were it met with such sentiment by upstreams. It does happen though from time to time, so all the more I am not okay with that statement. I'm not really part of this discussion and very much have to guess that talk about a replacement is not just coming from that... |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Jun 04, 2016 4:09 pm Post subject: |
|
|
| Tony0945 wrote: | | Perhaps the runit specific code could be selected by useflag? |
That's overcomplicating things. It's a runtime decision ("who owns PID 1?"), enforcing it at compile-time means if something breaks and you're unlucky, you need a chroot boot to fix it. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Sat Jun 18, 2016 8:57 am Post subject: |
|
|
| Ant P. wrote: | | Almost all of what I've got up to now is system-agnostic, POSIX shell, one-liners; there is some runit-specific code in there where I used their programs to run daemons as a specific user, enforce a service startup order, or have 1 shot "services" that don't restart on exit. But all of those concepts are common to all supervision systems, it's easy to fix. |
You're talking about chpst and utmpset I assume? |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Sat Jul 23, 2016 12:43 pm Post subject: |
|
|
| tclover wrote: | | Ant P. wrote: | "rc is deprecated, please use openrc"
What a cute message to see at boot. I'm *already* using openrc. I don't see openssh or openntpd leaving similar turds in my logs. I'm getting really tired of this deckchair-shuffling ivory tower bullshit.
Guess I should mention I've been planning on making a total replacement for openrc for a while now. The runit stuff I've been doing these past few months has been building towards that; I've gotten pretty comfortable at ripping out spaghetti plumbing and writing my own service scripts. No guarantees it'll turn out good, but I can promise no more bending over backwards to appease pen-pushers at other distros who don't matter. How many here are interested? |
I am in... although I am already on a similar supervision take over there for a while now. I could even give a hand... if your solution is more elegant/KISS compared to mine. Actual bigger TODO: complete services for sysinit or stage-0 for a supervision terminology; and add services for boot or stage-1 for base system ((u)mount local and network filesystems, console, keymaps... and how to implement a killprocs service if any? quite the task).
Big deal? Pretty much for portability concerns ad yes it's quite a big task in its own than I anticipated. And that TODO is not that much planned either; it may be done or not because it requires much more testing/portability testing. Everything is or should be functional at the present time and I took care of a KISS POSIX compliant shell and C code. Build system would need a quite a refresh with a proper configure script if the TODO and focus goes to that init-system way which was/were only on the service-manager from the beginning.
EDIT: the pacage is supervision agnostic; only nosh is not supported for now because it goes to systemd route from the start. I don't want to chase that systemd monster everywhere. Else, (busybox-)runit, daemontools(-encore) and s6 are supported. |
FOLLOW UP:
So I did add an init-system to it after all.
I started by adding init-system services here and there to see and check the feasibility of the endeavor. Just picked the most difficult at first an tried to make something simple out of them which took several try and errors at first. And then, a few things have to be changed to be able to do the job. So many simple steps made it possible to advance untill something functional was put together. Major contribution was writing the services (+3500 lines out of +5000 lines addition, plus configuration script, another +800 lines); and then some re-writing, improvement; and then finally sanitize what should be. Et voila! And yes, it's quite a job to do... the (init-system) job. Remain testing the whole thing in *BSD to be able to roll an *_rcN cycle--before releasing a stable release which is still in beta (testing) for now. I can boot in 10 seconds with ZFS on top of dmcrypt and LVM2 on top of dmcrypt (set up /{var/,}tmp with ZRAM and set up /var/{lib,db} with an unionfs (AUFS|OverlayFS)--there are services included for this...), and shutdown in 20 seconds! Yes, that's the double. Culprit? Trying to shutdown device-mapper and dmcrypt when some volumes (at least rootfs is blocking) are used.
And yes, the +3500 lies for services were for... basic/essential init-system services for sure plus a few quite hard ones to write which I needed to boot and do some real world testings;--namely, iptabes et al. So, anyone can use the package with a minimum effort because what should be done to boot can be easily added with a very few lines. --Example, just added in *_beta3 cups-browsed supervision service with a one liner service! That's all! One line to define a dependency to cupsd and result-equal-service-functional. Nothing more, nothing less. And this was the main purpose of the pre-release: be able to add supervision services without having to write and re-write everything down each time a simple service has to be added. --Who have the time to repeat the same simple steps again and again? It's certainly necessary at times...
Cheers.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sat Jul 23, 2016 1:19 pm Post subject: |
|
|
more relevant update. the topic of killing the symlinks has been raised again in gentoo (by william) and it is again due to a "feature" in Systemd that cannot tolerate it
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Sat Jul 23, 2016 3:44 pm Post subject: |
|
|
| Wouldn't it be better to patch systemd so that it can tolerate symlinks, rather than try to change everything else to tolerate a systemd limitation? Even if all the current symlink uses get removed, if systemd cannot tolerate them, then every new contributor needs to avoid them as well. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Sat Jul 23, 2016 6:08 pm Post subject: |
|
|
| Hu wrote: | | Wouldn't it be better to patch systemd so that it can tolerate symlinks, rather than try to change everything else to tolerate a systemd limitation? Even if all the current symlink uses get removed, if systemd cannot tolerate them, then every new contributor needs to avoid them as well. |
williamh isn't so much the official lead of openrc, as he is the saboteur looking to push systemd by crippling openrc.
It's been this way for years and he keeps his position of power on the Council and such despite repeatedly directly abusing it, lying to fellow Council members, being too incompetent to even know what an API is (and yes, I can and have repeatedly backed all of that up with his public mailing list posts, so it isn't libel), etc, but since enough devs don't care, or perhaps feel threatened given the committees he and his direct friends sit on, it continues. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sat Jul 23, 2016 9:30 pm Post subject: |
|
|
| Naib wrote: | | more relevant update. the topic of killing the symlinks has been raised again in gentoo (by william) and it is again due to a "feature" in Systemd that cannot tolerate it |
Is this something about some specific use of symlinks? I hadn't heard about this one.
As far as I know...and I've always found this very annoying...openrc itself can't handle symlinks in /etc/init.d. I never understood why there would ever be such a limitation in just about anything in Linux frankly. It wreaks of someone just plain doing something the wrong way. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Sat Jul 23, 2016 9:46 pm Post subject: |
|
|
tld,
What about | Code: | | lrwxrwxrwx 1 root root 6 May 14 2013 net.eth0 -> net.lo |
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Sat Jul 23, 2016 9:47 pm Post subject: |
|
|
| tld wrote: | | As far as I know...and I've always found this very annoying...openrc itself can't handle symlinks in /etc/init.d. I never understood why there would ever be such a limitation in just about anything in Linux frankly. It wreaks of someone just plain doing something the wrong way. |
I have /etc_manually_modified and have the following symlink in /etc/init.d which seems to work
| Code: | | net.eth0 -> ../../etc_manual_modified/init.d/net.eth0 |
I dont remember creating symlink
| Code: | | functions.sh -> /lib64/rc/sh/functions.sh |
I can't remember whether it was /etc/passwd or /etc/shadow but one of them being a symlink caused problems ... so this is not systemd specific. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sat Jul 23, 2016 10:00 pm Post subject: |
|
|
| NeddySeagoon wrote: | tld,
What about | Code: | | lrwxrwxrwx 1 root root 6 May 14 2013 net.eth0 -> net.lo |
|
You're correct, that does work. However what I ran into is that an init script there that's a symlink to an entirely separate location doesn't work.
My companies product (which we run in the field using a CentOS 6 VM) has a number of services that are all symlinks to files in the directory containing our code (actually with multiple services that link to the same file). I don't recall the specifics, but that in fact doesn't work in openrc, so for doing development and testing on this system I had to copy the actual file.
Tom |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sat Jul 23, 2016 10:03 pm Post subject: |
|
|
| jonathan183 wrote: |
I have /etc_manually_modified and have the following symlink in /etc/init.d which seems to work
| Code: | | net.eth0 -> ../../etc_manual_modified/init.d/net.eth0 |
|
That's interesting. The situation I ran into that didn't work was trying to link to a fully qualified path. It may be that only relative links like yours work. I'll have to try that.
Tom |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sat Jul 23, 2016 10:05 pm Post subject: |
|
|
| tld wrote: | | Naib wrote: | | more relevant update. the topic of killing the symlinks has been raised again in gentoo (by william) and it is again due to a "feature" in Systemd that cannot tolerate it |
Is this something about some specific use of symlinks? I hadn't heard about this one.
As far as I know...and I've always found this very annoying...openrc itself can't handle symlinks in /etc/init.d. I never understood why there would ever be such a limitation in just about anything in Linux frankly. It wreaks of someone just plain doing something the wrong way. |
https://archives.gentoo.org/gentoo-dev/message/4348e3a1d72cba2029efdf233a1acb1c
| Quote: | Moving away from the lib symlink has been discussed before, and there is
a bug on it that stalled [1].
I am interested in picking up this project again and actually making it
happen.
I am not an expert in how the profiles are set up, so, can someone give
me input on how/where to create the new profiles? |
=> https://bugs.gentoo.org/show_bug.cgi?id=506276
| Quote: | While trying to debug systemd-212 with gdb or valgrind, symbols of systemd binaries cannot be found. They are installed in the wrong location.
I've symlinked /usr/lib/debug/usr/lib64/systemd to ../lib/systemd and then it works - symbols are found.
That means, it is wrong to install symbols to /usr/lib/debug/usr/lib/systemd because gdb and co evaluate the real path of systemd binaries to be within /usr/lib64/debug (after all, lib is only a symlink to lib64), and then they fail to find them in /usr/lib/debug/usr/lib64...
This seems to apply to many other packages, too. So maybe it would be best to place a symlink for /usr/lib/debug/{,usr/}lib to .../lib64, too? But I'm not sure how well that works if I'd try that now.
OTOH, the ebuild should probably install its files to /usr/lib64 and not through the symlinked directory. |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Sat Jul 23, 2016 10:34 pm Post subject: |
|
|
| FFS...Everything I read from him (including the stuff that started this topic) is always "has been discussed before" or "is coming up again" or the like, when it's in fact always just him bringing it up. |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Sun Jul 24, 2016 4:47 am Post subject: |
|
|
| tld wrote: | | FFS...Everything I read from him (including the stuff that started this topic) is always "has been discussed before" or "is coming up again" or the like, when it's in fact always just him bringing it up. |
The self-referential thing is like the image of the "Alabama Search Warrant" that the folk musician Gamble Rogers had in one of his stories. "An Alabama search warrant is where the sheriff goes to the front door, the deputy goes to the back door, the sheriff knocks, and the deputy calls out 'come in!'"
You can do a lot when you make your own noise.
One of the comments to the bug in question is telling: | Quote: | | i don't think it's really worth the effort, especially considering how few people have run into it, and how easy it is to workaround. |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 24, 2016 2:20 pm Post subject: |
|
|
| tld wrote: | | a number of services that are all symlinks to files in the directory containing our code |
Are you sure that these files are on the same partition as /etc/{conf,init}.d/?
Of course, no other partition is mounted at the moment when openrc runs and resolves the dependencies.
On the other hand, there is e.g. the resolving bug and also calculation dependencies bug which might be related to (or even be the same as) this symlink bug.
It seems that all these problems are related with the necessity to calculate implicitly SVCNAME from the filename. Strictly speaking, such an implicit dependency on the filename indeed is not nice for a unix system but it lies somewhat at the heart of the openrc concept. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 24, 2016 2:30 pm Post subject: |
|
|
| Naib wrote: | https://archives.gentoo.org/gentoo-dev/message/4348e3a1d72cba2029efdf233a1acb1c
| Quote: | Moving away from the lib symlink has been discussed before, and there is
a bug on it that stalled [1]. |
|
Indeed, in the time when gentoo has introduced the layout structure for 64 bit nothing was standardized. Meanwhile the standard in all distributions has been settled and is even reflected in FHS. Unfortunately, it is opposite to the preliminary choice which gentoo had made many years ago. So it is really time to return to FHS.
| Quote: | | Quote: | | While trying to debug systemd-212 with gdb or valgrind, symbols of systemd binaries cannot be found |
|
So in fact the whole thing has absolutely nothing to do with systemd: It is a gdb-only thing, and systemd was just used as an example.
But of course, one couldn't do mindless bashing, if one would stick to the truth.
The personal attacks and insults in this thread are really a shame for gentoo! |
|
| Back to top |
|
|
|
Gentoo Chat
