# Will there be a new init for FreeBSD anytime soon?



## toxemicsquire (Jun 28, 2015)

I'm a 7+ year Linux user and I've been experimenting with FreeBSD for 1+ years, sometimes trying it out on my laptop and sometimes PC-BSD magically appearing on my sisters laptop which she asks to fix all the time. I find FreeBSD very stable the the new package management pkgng very useful, ports was super slow sometimes and would churn out the most annoying errors sometimes.

I couple of months to a year I remember some FreeBSD guy talking about how systemd was a great idea and that FreeBSD should have something like it, perhaps porting Upstart, Launchd, or that other Solaris init which everybody totally forgot about. Where did all that talk go and has there been anything so far?


----------



## Beastie7 (Jun 28, 2015)

No


----------



## wblock@ (Jun 28, 2015)

It's not impossible, it would just be a big deal.  For example, switching to `pkg` was a pretty big deal, but it happened.


----------



## Beastie7 (Jun 28, 2015)

wblock@ said:


> It's not impossible, it would just be a big deal.  For example, switching to `pkg` was a pretty big deal, but it happened.



I remember at last years BSDCan Jordan Hubbard spoke about his opinions on rc.d, and it seems like all the improvements he suggested has to do with mobile devices or ones that are run on a battery; so I'm assuming better power consumption management through implicit dependency tracking? Does the project plan on gravitating towards such devices in the future?

I've instrumented the current setup (from POST to login), and iI can't think of anything that would benefit (or at least improve) FreeBSD for it's intended purpose (servers) by using something else, or even altering current rc.d.

I still don't know why iXsystems is using launchd for FreeNAS 10 when our current init system is perfectly fine, IMO. If they have reasoned progression with what they're doing, maybe it could compelling enough for FreeBSD to adopt.

That's what I got out his spiel at least.

As a developer, what do you think?


----------



## Terry_Kennedy (Jun 28, 2015)

Beastie7 said:


> I've instrumented the current setup (from POST to login), and i can't think of anything that would benefit (or at least improve) FreeBSD for it's intended purpose (servers) by using something else, or even altering current rc.d.


My servers spend most of their boot time doing various BIOS and add-on card things - RAID controller w/ 16 drives, PCIe SSD, SAS adapter for external tape drives, and 10GbE network cards all demand their piece of BIOS initialization. I could disable some of the add-on card BIOSs, but I don't reboot often enough for it to be a big concern, and for some of the cards, "disabling" the BIOS means erasing it, so I would lose the ability to diagnose things pre-boot.

I think the "low-hanging fruit" for FreeBSD startup speed improvement is the memory test (or whatever it is doing) between the loader spin and the first line of kernel output. On large-memory (48GB and up) systems, this takes a lot of time and it isn't apparent what it is doing. There's some discussion here, but I don't think it was ever determined _what_ it was doing that took so long.

Desktop systems are generally a lot faster getting through their BIOS startup. With "fast boot" enabled on a Dell Optiplex, I barely have enough time to catch the BIOS and hit F2 for setup when I reboot Windows (which I do a lot more often than I reboot FreeBSD).


----------



## drhowarddrfine (Jun 28, 2015)

FreeBSD is a professional, Unix system. To do what Linux does would make it not a Unix system. Linux is not a Unix-like system. So, no, FreeBSD will not implement systemd or anything like it.


----------



## wblock@ (Jun 28, 2015)

I've spoken to several people who would really like to have launchd or something similar.  Like our present init system, but able to do more and react better.  Better power management is just one thing it allows, but that alone might be worth it.  Servers can save power (and money) by putting temporarily unused hardware in standby, too.  A faster startup and better power savings on my notebooks would be nice, and embedded hardware could benefit too.

It would be a relatively big project, possibly more for public relations than the technical side.  But big changes do happen in FreeBSD from time to time.  The switch from CVS to Subversion, and from GCC to Clang are other examples.


----------



## CurlyTheStooge (Jun 28, 2015)

drhowarddrfine said:


> FreeBSD is a professional, Unix system. To do what Linux does would make it not a Unix system. Linux is not a Unix-like system. So, no, FreeBSD will not implement systemd or anything like it.



FreeBSD is UNIX like, legally and technically, not UNIX. If you still think its a professional UNIX system, then please fix it's Wikipedia entry, we would be grateful.

Regards.


----------



## Beastie7 (Jun 28, 2015)

wblock@ said:


> I've spoken to several people who would really like to have launchd or something similar.  Like our present init system, but able to do more and react better.  Better power management is just one thing it allows, but that alone might be worth it.  Servers can save power (and money) by putting temporarily unused hardware in standby, too.  A faster startup and better power savings on my notebooks would be nice, and embedded hardware could benefit too.
> 
> It would be a relatively big project, possibly more for public relations than the technical side.  But big changes do happen in FreeBSD from time to time.  The switch from CVS to Subversion, and from GCC to Clang are other examples.



Hmm, I guess once you start scaling systems power starts to become issue, and being able dynamically control consumption would be nice. Makes sense.


----------



## Beastie7 (Jun 28, 2015)

CurlyTheStooge said:


> FreeBSD is UNIX like, legally and technically, not UNIX. If you still think its a professional UNIX system, then please fix it's Wikipedia entry, we would be grateful.
> 
> Regards.



FreeBSD is genetic UNIX (through heritage), but it can't legally use the UNIX trademark. So it has to be called "Unix-like". But it is UNIX.


----------



## ANOKNUSA (Jun 28, 2015)

If what you're hoping for is that your FreeBSD experience will soon closely resemble your Linux experience, you can do away with that notion right now. Many aspects of FreeBSD's development model and underlying philosophy are opposed to the way things are done in the Linux world. If a new init system ever appears, it will be because that init system does something the devs believe will be of benefit to FreeBSD while conforming to the FreeBSD way of doing things. Example:



toxemicsquire said:


> ...perhaps porting Upstart...



The chances of any new GPL project making it into the base system are (in my admittedly limited assessment) virtually nil--licensing consistency was one of the reasons Clang was adopted. What's more, a new init system would almost certainly have to be a re-imagining of the *BSD-style init, something that could both work with and improve upon the existing system without requiring drastic change. Hence the new packaging system being designed from the bottom up to work with (in fact, be _dependent upon_) the FreeBSD ports system. Simply having a binary package manager wasn't the point--it had to be a package manager that _was part of FreeBSD_, and _improved upon FreeBSD_, not just some extra convenience. As has been said, FreeBSD tends to put more weight on professionalism than experimentation or "what might be cool." That pkg(8) makes life easier for people administering multiple vital systems is more important than the fact that it makes life easier for noobs who don't understand or have the patience for ports.


----------



## drhowarddrfine (Jun 28, 2015)

Yes. A real Unix.


----------



## jrm@ (Jun 28, 2015)

The simplest thing you can do to speed up the boot time is to put `autoboot_delay="1"` in /boot/loader.conf.  On the (rare) occasions when you want to change the default selection or look at the Orb (or Beastie with `loader_logo="beastie"`) longer, just hit space at the right time.


----------



## wblock@ (Jun 28, 2015)

Just posted today to the freebsd-hackers mailing list:
The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging.

The site is at http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html, and


> nosh is of course simply licensed under the MIT Expat Licence, the ISC Licence, and the FreeBSD Licence (in the belief that they are all in essence identical and in order to avoid BSD Licence Hell).


----------



## protocelt (Jun 28, 2015)

wblock@ said:


> Just posted today to the freebsd-hackers mailing list:
> The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging.
> 
> The site is at http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html, and


This is quite interesting indeed. If I read the information on the site correctly, it would potentially fix some of the problems of ported applications that depend on/parts of systemd(among other things). That would be excellent in and of itself. A much better idea than trying to shoehorn launchd into FreeBSD in my humble opinion.


----------



## ANOKNUSA (Jun 29, 2015)

protocelt said:


> If I read the information on the site correctly, it would potentially fix some of the problems of ported applications that depend on/parts of systemd(among other things).



No, nosh just comes with a script to translate systemd service units into nosh service units, and wrappers to interact with nosh via systemd commands. It does nothing to obviate application dependencies on systemd components like logind, systemd.mount and udev.


----------



## protocelt (Jun 29, 2015)

ANOKNUSA said:


> No, nosh just comes with a script to translate systemd service units into nosh service units, and wrappers to interact with nosh via systemd commands. It does nothing to obviate application dependencies on systemd components like logind, systemd.mount and udev.


Ah, ok. Makes sense. I just skimmed the page and some of it _is_ a little over my head at this point so thanks for the correction.  Even with my limited understanding however,  I still think this is a much better idea than trying to make launchd work.


----------



## jrm@ (Jun 30, 2015)

I caught this on twitter, 





			
				jkh said:
			
		

> Well, we finally got launchd, libdispatch, notify(3) and ASL mostly running in FreeBSD with Mach IPC coming along for the ride.  Now what.


https://github.com/trueos/trueos/tree/freebsd10


----------



## Beastie7 (Jun 30, 2015)

Why are they using JSON for plists? Why not UCL?


----------



## vermaden (Jun 30, 2015)

toxemicsquire said:


> (...) I remember some FreeBSD guy talking about how systemd was a great idea and that FreeBSD should have something like it (...)


Kill it with fire! 



toxemicsquire said:


> Will there be a new init for FreeBSD anytime soon?


Fortunately, Nope.


----------



## protocelt (Jul 11, 2015)

vermaden said:


> Fortunately, Nope.


Not so sure... https://wiki.freebsd.org/launchd


> 20150629: The TrueOS fork of FreeBSD 10 has launchd running as init and a JSON-aware launchctl utility, along with notifyd, libdispatch and ASL integrated. *This work has also been forward-ported to FreeBSD -CURRENT*. FreeNAS 10, which is also based on FreeBSD 10.1, will be using launchd and a host of other tools ported from OS X / iOS. It has used the original, and latest, Apple sources and ported them along with MACH IPC.


----------



## Beastie7 (Jul 11, 2015)

I don't think launchd will be ready for FreeBSD 11. Since the init system touches so many parts of base, it would have be proven stable before customers adopt it, IMO. Who knows though. 

Exciting stuff nonetheless. This is going to be huge for FreeBSD on embedded devices, and server scaling.


----------



## protocelt (Jul 11, 2015)

Beastie7 said:


> I don't think launchd will be ready for FreeBSD 11. Since the init system touches so many parts of base, it would have be proven stable before customers adopt it, IMO. Who knows though.
> 
> *Exciting stuff nonetheless. This is going to be huge for FreeBSD on embedded devices, and server scaling.*


How so?


----------



## dinsdale (Sep 16, 2015)

wblock@ said:


> Just posted today to the freebsd-hackers mailing list:
> The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging.
> 
> The site is at http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html, and



I'm just drilling into this now, pretty exciting.


----------



## vermaden (Sep 16, 2015)

There is also another init system - * System XVI* (in development):
https://github.com/ServiceManager/ServiceManager/blob/master/README.md

... there are generally a lot of init systems:
http://blog.darknedgy.net/technology/2015/09/05/0/

... but *rc.d* in FreeBSD seems to do the job without all the bloat and bullshit.


----------



## abishai (Sep 16, 2015)

Well, the boot speed improvements can be handy


----------



## kpa (Sep 16, 2015)

abishai said:


> Well, the boot speed improvements can be handy



Those will come almost automatically if parts of the rc(8) infrastructure is replaced by C/C++ code. Shell scripts are very inefficient because the interpreter doesn't use any of the tricks used by more recent scripting languages such as python that compiles the source code into a binary representation that is much faster to execute.


----------



## vermaden (Sep 16, 2015)

abishai said:


> Well, the boot speed improvements can be handy


For servers the uptime is more important, the physical server boots for 10-20 minutes anyway, so saving 5 seconds upon operating system boot is pointless. Better solution is to implement KSPLICE alternative on BSD.

For laptops/workstations you do suspend/resume, so boot time does not affects You ...


----------



## Beastie7 (Sep 16, 2015)

vermaden said:


> For servers the uptime is more important, the physical server boots for 10-20 minutes anyway, so saving 5 seconds upon operating system boot is pointless. Better solution is to implement KSPLICE alternative on BSD.
> 
> For laptops/workstations you do suspend/resume, so boot time does not affects You ...



Boot speed increases can improve time to production when you're scaling hundreds of nodes, and for other "cloud-y" stuff. The faster you can get stuff up and running, the better. Businesses like that. As long as it doesn't affect stability, I don't see a problem increasing boot times.


----------



## vermaden (Sep 16, 2015)

Beastie7 said:


> Boot speed increases can improve time to production when you're scaling hundreds of nodes, and for other "cloud-y" stuff. The faster you can get stuff up and running, the better. Businesses like that. As long as it doesn't affect stability, I don't see a problem increasing boot times.


If You want to bring service back fast, You use a cluster ... or even fault tolerant solutions to eliminate downtime.


----------



## lodger (Sep 17, 2015)

toxemicsquire said:


> I couple of months to a year I remember some FreeBSD guy talking about how systemd was a great idea and that FreeBSD should have something like it, perhaps porting Upstart, Launchd, or that other Solaris init which everybody totally forgot about. Where did all that talk go and has there been anything so far?



What one may think is a great idea, others may object to. If FreeBSD will change its init system one day, I hope it only changes the init related part and that it won't be a huge, security neglecting and invasive solution like Systemd.


----------



## usdmatt (Sep 17, 2015)

Faster boot times is obviously nice and clearly it's silly to completely deny we should have faster boot / parallel service start-up, but I do think there's a bit too much emphasis being put on this like it's some sort of holy grail.

If you're scaling hundreds of production nodes, I would hope your system has been designed that you can scale them gradually without actually taking any services offline. As mentioned, a decent server can take 5 -10 minutes to boot. The rc subsystem is a tiny part of this; Literally just the last bit of the FreeBSD boot where the text changes colour. On all of my systems, even a 50% increase in rc performance would probably make about 5% or less difference to overall boot. In any production setting where downtime was a problem, that improvement would be irrelevant.

I don't think shell slows it down that much either. C might make it quicker but again, for me, the majority of the time is spent actually starting the services themselves than the bits of shell glue in-between.

From what I'm aware a lot of the interest behind systems like systemd and launchd in recent years are partly to do without faster start-up, but much more to do with modernising the rc system, improving dependency handling, streamlining all the various process control services (rc/inetd/cron) & allowing services to actually only start when needed rather than on boot. That last one is a big one as it can have a massive impact on battery powered devices, which is a hot topic for operating systems at the moment (not so much in FreeBSD). Also why try and get your services to start faster on boot if you can just start them later when they're actually needed? (Both those last sentences are fairly irrelevant for servers).

One place where it would make a noticeable 'start-up' improvement would be jails/containers, which are pretty popular these days. All a jail really does when it starts is run the rc subsystem, so a 25% speed improvement would make the jail start nearly 25% faster.


----------



## Crivens (Sep 17, 2015)

usdmatt said:


> I do think there's a bit too much emphasis being put on this like it's some sort of holy grail.


This is right for some advocates of the "more modern" startup systems. What I have heard is that certain parts of the embedded crowd are behind one of these, the reason being that modern car entertainment/navigation systems/takeover beachheads are booting too slow. These things start up once you come close enough to your fuel-to-noise converter for your keyless entry gadget to be in range so it is somewhat operational when you sit down and buckle the seat belt. That is the crowd needing faster boots times because the customers being presented with slower boot times are not the kind you can argue with about technology. They also want the crashed parts being restarted at once because no admin will be looking at things and check out *why* the mp3 player crashed. It crashed, restart at once.

That they create an unholy mess no user can manage in some years is of completely no concern to those.

Disclaimer - I have spent some years in that area, and boy did I see performance pigs being fed till they exploded...


----------



## abishai (Sep 17, 2015)

kpa said:


> Those will come almost automatically if parts of the rc(8) infrastructure is replaced by C/C++ code.


I think the ability to start daemons in parallel (where it's possible) will overcome even benefits of C code.



vermaden said:


> For laptops/workstations you do suspend/resume


If you can convince it to work. It's just panics for me.


----------



## vermaden (Sep 18, 2015)

abishai said:


> If you can convince it to work. It's just panics for me.


Have You submited a BUG over here?
https://bugs.freebsd.org/bugzilla/enter_bug.cgi


----------



## abishai (Sep 18, 2015)

vermaden said:


> Have You submited a BUG over here?


I can't get panic dump. And, actually, I'm assuming that that is the panic, as the screen remains black. According POST CODE, it hangs on E3 - "OS S3 wake vector call." If I do `sysctl debug.acpi.resume_beep=1`, it beeps endlessly.


----------



## vermaden (Sep 18, 2015)

abishai said:


> I can't get panic dump. And, actually, I'm assuming that that is the panic, as the screen remains black. According POST CODE, it hangs on E3 - "OS S3 wake vector call." If I do `sysctl debug.acpi.resume_beep=1`, it beeps endlessly.


If You cant get more I would submit a bug anyway, with as much information You can, You lose nothing and maybe someone else will 'push' the work forward, someone with similar hardware or with similar problem.


----------



## hedwards (Sep 18, 2015)

Systemd is one of the main reasons why I've come back to FreeBSD from Linux after the last few years. That and I finally found directions for installing Crashplan that seem to work on FreeBSD. Well that and I rebooted Mint yesterday and I couldn't get back in for whatever reason.

I'm not personally comfortable with the way that Systemd is being extended to include all sorts of functionality that doesn't belong. The recent decision to add sudo like powers to it is very strange. The explanation read like the developer didn't understand how sudo is supposed to work.

P.S. It's amazing how much better FreeBSD is than it was a few years ago when I last had and install and 15 or so years ago when I first installed 4.2. I'm looking forward to finishing my migration.


----------



## Crivens (Sep 20, 2015)

vermaden said:


> someone with similar hardware or with similar problem.


*raises hand* Similar hardware, I don't know, Similar problem, yes. I had gotten suspend & resume working some time ago, but now it (again) hangs on resume or simply reboots. Since this seems to be related to ACPI, the mess is likely not part of FreeBSD but more in the BIOS part. Working around bugs in ACPI implementations is something I would like to avoid.


----------



## vermaden (Sep 20, 2015)

Crivens said:


> *raises hand* Similar hardware, I don't know, Similar problem, yes. I had gotten suspend & resume working some time ago, but now it (again) hangs on resume or simply reboots. Since this seems to be related to ACPI, the mess is likely not part of FreeBSD but more in the BIOS part. Working around bugs in ACPI implementations is something I would like to avoid.



Then also submit a BUG, without BUG submitted FreeBSD developers do not even know that something does not work.


----------



## l2f (Apr 9, 2018)

Keep rc.d as simple and stupid, so easy to work with.

Do not repeat the same error as it was done with the new pkg system = dependency: sqlite, no more ascii files (The UNIX Way)...


----------



## ShelLuser (Apr 9, 2018)

First: you're responding to a thread which is roughly 3 year old, figured I'd mention it because there really isn't that much point to it.

Further more: what pkg mistake are you talking about?  You mention an SQLite dependency, how did you come up with that weird idea? I mean...


```
peter@unicron:/usr/ports/ports-mgmt/pkg $ ls
Makefile        distinfo        files/          pkg-descr       pkg-plist
peter@unicron:/usr/ports/ports-mgmt/pkg $ make all-depends-list |wc -l
       0
```

Not to mention:


```
peter@unicron:/home/peter $ ldd `which pkg` | grep sqlite
peter@unicron:/home/peter $
```
There really is no error what so ever here. Sure, your package database is stored in /var/db/pkg/local.sqlite but so what? It's still mostly an ASCII file (go view it), and this database format is _much_ better where storage is concerned (you are aware of block sizes I hope? So that 10 files which claim to be 10k each could actually take up 64kb per file?), and most of all: you shouldn't be messing with the system package files in the first place.

If you need information from the package database then use pkg, that's what it was made for. And if you insist on accessing the database directly, then go use sqlite. Couldn't be easier.


----------

