rcd(8) - new service manager daemon

checkpoint said:
It IS replacing systemd! Once rcd is implemented, there will be no need for init and I'm sure its functionality will be put into rcd soon, ceasing init to exists.
Click to expand...
I am sure cannot replace systemd, as FreeBSD does not use systemd.
In other notes, sh is shitty, lua is fine, one can do better, but the FreeBSD loader already uses lua it goes fine.

In other notes: What is checkpoint notes?
 
checkpoint said:
At some point in time we will have two sets of startup scripts: some ports will provide both rc and ucl
Click to expand...

UCL is a configuration format. Not a script in and of itself.

checkpoint said:
And why Lua ?
Click to expand...

Because Lua is incredibly flexible for its resource footprint (the interpreter is very small). Think it's of as Python or Perl, but for system management and automation. Lua is optional too, you don't have to use it.

checkpoint said:
It IS replacing init! Once rcd is implemented, there will be no need for init and I'm sure its functionality will be put into rcd soon, ceasing init to exists.
Click to expand...

You didn't read the thread entirely.

Baptiste Daroussin specifically stated in that very thread that is it not replacing init. That would be a mistake. Eventually, once the community gets acquainted with rcd and most port scrips get converted - it'll replace classic rc.d.
 
usbdetach said:
Psst. Read the docs on libucl. It accepts json but does not require it.
Click to expand...
When systemd was first introduced with unit files the promise was you'd be able to continue using good old scripts. Then they eventually dropped it. Just because something is supported now doesn't mean it will continue to be supported into the future.

I don't understand why all these different service managers and attempts at re-doing rc scripts are still developed in-house when skarnet's s6 has been around for a long time now. Perhaps if the author wasn't so opposed to actually providing good documentation some OS would have picked it up by now as the primary init+service manager instead of it only being used as an option for a handful of Linux distros.

Regardless, it's good software and I think it solves the problem better than any of the other attempts. It keeps the PID1 really small while splitting out all the complicated stuff to other PIDs and it doesn't break traditional text-based logging (or require you to route it through a horrible system like journald). It is also very stable in my experience and execline is a nice little language to work with which allows you to use whatever you want through it with no ability for that support to be yanked out from under you in the future.

I don't know why people are so interested in re-inventing things like XML with a different syntax. XML is considered too "verbose" these days and maybe that's true. But JSON isn't any better. It's all just the same crap with a different syntax. I'm sure in another decade people will be crying about how JSON is too verbose and we need yet another text format to represent data on disk. But like most things in the past it'll just be yet another new standard everyone will swoon over for a little while then grow to hate with time. Since none of this stuff solves any actual problems we didn't already have solved by using plaintext.

I wasted so many man hours converting all our HTML (and things generating it) over to standard complaint xhtml just to see the W3C sell out and now we're back to HTML again with DRM baked right into the standard. Which these days most people can't even write directly because it's "too hard" so now you get multiple javascript frameworks and it's standard practice to send 100+MB of stuff down the wire for each page load. This is not progress. If anything everything about the systems I use has regressed since the mid-90s and they're all now more overly complicated and give far less useful feedback when things go wrong. At every part of the stack I've seen something that was working most of the time tossed aside for something new and shiny that figures out how to break everything in new and more creative ways. The only real difference now is you can't call it crap and religions seem to form around the new garbage. At least when the only holy wars happening were vi and emacs you had the choice between converting to the other church. Now you just get forcefully converted or burned at the stake like a heretic.
 
Ferocious1881 said:
I am sure cannot replace systemd, as FreeBSD does not use systemd.
Click to expand...
Of course it does not, I just mistyped. Sorry.

Ferocious1881 said:
In other notes, sh is shitty, lua is fine, one can do better, but the FreeBSD loader already uses lua it goes fine.
Click to expand...
I know that bootloader scripts are written in Lua, but how often do you need to alter them or even look into them ? I'm using FreeBSD for quite some time (since '96) and I have never had any reason to. Yet, I do fix rc scripts occasionally and I write my own. What's more, I do very often debug startup issues which takes me look into, read and understand all these scripts. Now you tell me to learn Lua to perform my work ? Thank you bro!

And, how come Lua is better than Shell anyway ?

One more thing regarding rcd. It says rcd runs services in parallel. Now imagine what a mess of intermixed diagnostic messages from different services will we get in our dmesg and in /var/log/messages ? One will get one's brain broken apart trying to resolve issues using such output. To overcome this an analog of systemd-journald has to be introduced. And it will be, I'm sure.
 
Ferocious1881 said:
Looks like every system gets it's own systemd apocalypses.
Click to expand...

You have to understand; systemd was greatly inspired by SMF/launchd. New rcd uses native FreeBSD interfaces/features to provide similar functionality of its predecessors. Much of the Solaris and Mach kernels were mangled to allow what SMF/launchd does. FreeBSD avoids a lot of this.
 
Beastie7 said:
UCL is a configuration format. Not a script in and of itself.
Click to expand...

I watched the video an looked into the code, Lua is inevitable.

Beastie7 said:
Because Lua is incredibly flexible for its resource footprint (the interpreter is very small). Think it's of as Python or Perl, but for system management and automation. Lua is optional too, you don't have to use it.
Click to expand...

We have Shell and Perl, that's sufficient. Lua is ok for bootloader where resource is scarce, nowhere else.

Beastie7 said:
You didn't read the thread entirely.

Baptiste Daroussin specifically stated in that very thread that is it not replacing init. That would be a mistake.
Click to expand...
Again, I read and watched the video, I looked into the code. I think I got he's idea quite well. FreeBSD will have systemd.

Beastie7 said:
Eventually, once the community gets acquainted with rcd and most port scrips get converted - it'll replace classic rc.d.
Click to expand...
I'm quite old to know how this all ends, see my comment above. To add to that, we will have lots of broken ports which will be deprecated and removed becauase noone will want (have time) to fix them.
 
checkpoint said:
One more thing regarding rcd. It says rcd runs services in parallel. Now imagine what a mess of intermixed diagnostic messages from different services will we get in our dmesg and in /var/log/messages ? One will get one's brain broken apart trying to resolve issues using such output. To overcome this an analog of systemd-journald has to be introduced. And it will be, I'm sure.
Click to expand...
With all the charm of prettified colorized logs.
 
checkpoint said:
One more thing regarding rcd. It says rcd runs services in parallel. Now imagine what a mess of intermixed diagnostic messages from different services will we get in our dmesg and in /var/log/messages ? One will get one's brain broken apart trying to resolve issues using such output. To overcome this an analog of systemd-journald has to be introduced. And it will be, I'm sure.
Click to expand...
journald was added mostly because....hell I don't know. Probably because the entire ecosystem was designed by people that refuse to learn from the past and are smug about their ignorance of it.

"Parallel startup" and "faster boot times" is mostly an ugly hack. Ironic from systems that claim they want to do away with other ugly hacks like PID files.

What happens is you have daemon B that needs daemon A up and running first. The old tried and true way was you start daemon A, wait 1-2 seconds (whatever) then check it's up and you can connect to it then you can start daemon B. Hopefully, daemon B has any logic it needs to restart itself or reconnect if something happens to daemon A or daemon A has logic to talk to daemon B. Or you resort to polling. Which a lot of things still do.

"parallel start up" works like this: We make a new daemon called daemon C. Daemon C comes up first and pretends to be daemon A, B, D, E, F, G etc. It fakes state that makes everything think daemon A is both up and that you can communicate with it. It holds whatever daemon B sends at start up in a queue and tells daemon B everything is a-okay and/or to wait. Once daemon A is really up our new daemon C spams it with all the crap in the queue from daemon B. daemon A can finally really respond to daemon B. daemon A and B go on about their merry way.

In time you end up with an ecosystem where everything expects daemon C to be 1) on the system and 2) managing all daemons.

This can be a bad or a good thing depending on how daemon C is programmed and the team that makes daemon C. Ideally, daemon C would be as small as possible and would change as little as possible once it's good enough to be considered the expected default.

The issue with things like daemon C is it usually ends up growing at rapid pace, swallowing up old defaults/ecosystems and since it serves as a means to control everything but the kernel abusive things to the entire ecosystem typically end up happening there. The thought of having control over daemon C typically attracts the exact type of people you don't want to be in control of something crucial like daemon C. Usually people with big ideas that don't like to learn from the past, listen to reason or otherwise have some type of agenda they're eager to push upon everyone else. In other words: people that are very opinionated about what other people do with their systems.

Daemon C usually ends up just being an example of why we can't have nice things.
 
Service startup is always about ordering. Even if you are not trying to do as much in parallel. Ordering is very dependent on proper dependencies which means someone has to correctly identify "What I need before I can do anything and what do I provide when I am done". Not always trivial, but 100% needed.

Once that is correly identified, needs to be specified clearly in a "configuration file" of some sort. Some formats are better than other.

Part of the dependencies problem is they cascade and may have variations:
Simple example, NTP.
NTP depends on networking to be up
Networking depends on getting an IP address, which may be static or may be DHCP
Getting an IP address depends on the interface: WiFi may need to be loaded and associated with some external device.

Now toss in a service that depends only on NTP and you have the hidden dependencies.

Startup is often a choice between thundering herd of starting everything at once, each thing is responsible for determining "are my needs met, if yes, continue, if not go back and wait or retry". Often results in lots of things restarting themselves until they are running.
Other choice is orderly startup, but as I tried to point out that means real effort must be done to identify and define dependencies.

My opinion on rcd is I'm going to wait and see but based on current documentation (emails, videos, etc) I don't see it becoming systemd/journald. Solaris/SMF and SunOS: sometimes people hate a thing because it's different, not because it has zero improvement. People hated SysV Init when it first came out.
 
Usagi said:
"Parallel startup" and "faster boot times" is mostly an ugly hack. Ironic from systems that claim they want to do away with other ugly hacks like PID files.
Click to expand...
These two features of proposed rcd is very very much questionable. Do we actually need faster boot ? How much faster and what is the tradeoff ? If the overall improvement is a couple of seconds for which we pay by having more complex startup system with lesser clarity - no, thanks. Parallel startup will make it a lot more difficult to debug startup issues besides the problem of having a dedicated logging subsystem (journald).

Another feature of rcd I do not like is having progress indicator shown on console instead of actual logging messages.
 
checkpoint said:
These two features of proposed rcd is very very much questionable. Do we actually need faster boot ? How much faster and what is the tradeoff ?
Click to expand...
This is the proverbial horse that has been completely flogged.
It always boils down to "if you reboot you want to get back to working quicker", so yeah, a few seconds doesn't sound like much, but a user booting a laptop it's forever. A server that has undergone a maintenance window and needs to be back up working to satisfy a fine nines SLA? Again huge.
For a home system, daily driver like mine that gets rebooted only after updates resulting in uptimes measured in at least months? Yeah, I don't care about a couple seconds because it's an extra sip of coffee.

Why do you think this needs a dedicated logging subsystem?
 
mer said:
Part of the dependencies problem is they cascade and may have variations:
Simple example, NTP.
NTP depends on networking to be up
Networking depends on getting an IP address, which may be static or may be DHCP
Getting an IP address depends on the interface: WiFi may need to be loaded and associated with some external device.

Now toss in a service that depends only on NTP and you have the hidden dependencies.
Click to expand...
Exactly. My laptop boots somewhat 15 secs, more than a half of that time is brining up wifi, dhcp, ntp, etc. Cannot see how this can be improved with rcd.

Again, currently rc scritps have all the data needed to build dependency tree (PROVIDE, REQUIRE is there). Why UCL is needed at all ? I think rcd can do its job without UCL, just treat existing rc scripts like first class citizens. No UCL, no Lua, no JSON. Just good old shell scripts. Zero work for ports mantainers, nothing new to learn for beardy sysadmins as long as "service" command remains to control rcd (not an rcdctl or whatever new tool). This is real BSD way of mproving things, methinks.
 
the "faster boot" BS is not a design goal of rcd, its various other aspects of service management that are currently lacking or sub-optimal in rcNG. E.g. try to find out if an enabled service isn't running or has crashed - since rcNG has no clue about what a service does after it has been started, there's no easy way to find out if something isn't running any more. (I absolutely love OpenBSDs 'rcctl ls failed/stopped/rogue' for this)


I'm not sure if I should address all the flat out wrong statements checkpoint is blabbering about or just hand out a tinfoil hat...
 
mer said:
This is the proverbial horse that has been completely flogged.
It always boils down to "if you reboot you want to get back to working quicker", so yeah, a few seconds doesn't sound like much, but a user booting a laptop it's forever. A server that has undergone a maintenance window and needs to be back up working to satisfy a fine nines SLA? Again huge.
Click to expand...
From my experience, system startup takes only a tiny fraction of overall booting time. BIOS (UEFI), RAID and other hardware init take much more. Improving system startup time make sense only for virtual machines, but you can also do that by clever ordering your rc scripts and by removing unnecessary stuff - just don't let every installed package to put it's script into rc.d. Ok, we can make it boot 2-3 seconds faster, but are we willing to pay for that by extra hours debugging and unwinding all these parallel running UCL scripts in case of trouble ?

mer said:
Why do you think this needs a dedicated logging subsystem?
Click to expand...

One of the reasons is when many daemons start in parallel, all the messages coming from them have to be separated and reordered, otherwise we will get a mess in /var/log/messages. In Linux they solved it by introducing systemd-journald.
 
checkpoint said:
Perl is incredibly expressive.
Click to expand...

Perl? You are kidding right?

Larry Wall has been gone from Perl for a VERY long time, and CPAN was completely awful when we were all supposed to be using it. Perl-7 development has not gone anywhere since 2021 and there is no launch date for Perl-7.

Let's not go back to the future.
 
checkpoint said:
just don't let every installed package to put it's script into rc.d.
Click to expand...
this is completely irrelevant. if you don't enable it in rc.conf it doesn't matter if you have 3 or 3000 scripts in [/usr/local]/etc/rc.d
I think you have a lot of misconceptions about how rcNG works and what rcd actually is and where it plugs into the whole system...
 
CShell said:
Perl? You are kidding right?

Larry Wall has been gone from Perl for a VERY long time, and CPAN was completely awful when we were all supposed to be using it. Perl-7 development has not gone anywhere since 2021 and there is no launch date for Perl-7.

Let's not go back to the future.
Click to expand...
sh(1) doesn't change much either.
 
didal said:
sh(1) doesn't change much either.
Click to expand...
The difference is that CPAN went down (as in they turned OFF CPAN) and then you literally could not use entire perl scripts because you had no way of getting the dependent perl modules that were dependent in those perl scripts. Not to mention that in (NON-INTERNET) connected environments there was no way to get all of the various perl script dependent modules - because you needed access to CPAN.

You honestly can't say that about sh(1) right?
 
You must log in or register to reply here.
Back
Top