Dinit, the service manager and init system.

zoujiaqing · Sep 6, 2024

Dinit is designed to work on POSIXy operating systems such as Linux and OpenBSD. It is written in C++ and uses the Dasynq event handling library, which was written especially to support Dinit.

Source code:

GitHub - davmac314/dinit: Service monitoring / "init" system

Service monitoring / "init" system. Contribute to davmac314/dinit development by creating an account on GitHub.

github.com

Support files for launching dinit from /etc/rc.d/ on FreeBSD

To install dinit on FreeBSD, run the following commands as root:

Bash:

# (Optional) Install build dependencies

pkg install -y meson rsync


# Build dinit with correct path

pushd ../..

meson setup -Ddinit-control-socket-path=/var/run/dinitctl build2

cd build2

ninja install

popd


# Install dinit as rc.d service

rsync -r tree/ /

mkdir -p /etc/dinit.d/boot.d


# enable dinit (to start on next boot)

/etc/rc.d/dinit enable

# start dinit now

/etc/rc.d/dinit start

Dinit runs three times faster on Linux than systemd, and arguably faster on FreeBSD.

View: https://www.youtube.com/watch?v=lhBvXRsxT7s

Full documentation for Dinit is available in the form of manual (man) pages:

dinit(8) - the dinit daemon
dinit-service(5) -service description format and service settings
dinitctl(8) - dinitctl, autility to control the dinit daemon and manage services
dinitcheck(8) - dinitcheck,a utility to check service descriptions for errors/lint
dinit-monitor(8) -dinit-monitor, a utility to monitor a service and run a command when service state changes

MG · Sep 6, 2024

Running a 300 lines /etc/rc script as only post-kernel startup requirement for the past 10 years. It's sufficient for most PC's without exotic hardware that requires complex configuration. HP and Dell workstations, the real standard hardware never has problems with it. The only little problems that I have with it is the USB-stack coming in the final ready state. The moment is not entirely clear, like USB can appear ready loading wile a boot-memstick still isn't functioning properly yet. Network init behaves similar but that's only a matter of giving it a few seconds on all systems.

I believe the whole systemd discussion is the result of elitism. It's obfuscating the actual operations that are required to boot to a fully functional CLI and supposes it's beyond common user activities.

BaronBS · Sep 6, 2024

zoujiaqing said:
Dinit is designed to work on POSIXy operating systems such as Linux and OpenBSD. It is written in C++ and uses the Dasynq event handling library, which was written especially to support Dinit.

Source code:

GitHub - davmac314/dinit: Service monitoring / "init" system

Service monitoring / "init" system. Contribute to davmac314/dinit development by creating an account on GitHub.

github.com

Support files for launching dinit from /etc/rc.d/ on FreeBSD

To install dinit on FreeBSD, run the following commands as root:

Bash:

# (Optional) Install build dependencies pkg install -y meson rsync # Build dinit with correct path pushd ../.. meson setup -Ddinit-control-socket-path=/var/run/dinitctl build2 cd build2 ninja install popd # Install dinit as rc.d service rsync -r tree/ / mkdir -p /etc/dinit.d/boot.d # enable dinit (to start on next boot) /etc/rc.d/dinit enable # start dinit now /etc/rc.d/dinit start

Dinit runs three times faster on Linux than systemd, and arguably faster on FreeBSD.

View: https://www.youtube.com/watch?v=lhBvXRsxT7s

Full documentation for Dinit is available in the form of manual (man) pages:

dinit(8) - the dinit daemon

dinit-service(5) -service description format and service settings

dinitctl(8) - dinitctl, autility to control the dinit daemon and manage services

dinitcheck(8) - dinitcheck,a utility to check service descriptions for errors/lint

dinit-monitor(8) -dinit-monitor, a utility to monitor a service and run a command when service state changes

We definitely need more concurrency in the init and bootloader market, nice initiative.

mikew · 2024-11-22T00:28:40+0000

Chimera Linux has adopted dinit; it's an improvement over the simplistic (but effective) runit system that a similar project, Void Linux, has used for a number of years. The primary advantages of dinit over simpler schemes is being able to easily declare dependencies and waitfor conditions, as well as user services. Unlike systemd, these other init systems such as dinit, openrc, runit, have no aspirations of taking over other major system functionality.

Another advantage of systems like dinit (and runit) - writing daemon start up scripts becomes much, much simpler and the system helps encourage consistency between them.

Ogis · 2024-11-22T16:44:58+0000

mikew said:
Chimera Linux has adopted dinit

And Artix Linux adopted it.

mer · 2024-11-22T16:53:33+0000

mikew said:
Chimera Linux has adopted dinit; it's an improvement over the simplistic (but effective) runit system that a similar project, Void Linux, has used for a number of years. The primary advantages of dinit over simpler schemes is being able to easily declare dependencies and waitfor conditions, as well as user services. Unlike systemd, these other init systems such as dinit, openrc, runit, have no aspirations of taking over other major system functionality.

Another advantage of systems like dinit (and runit) - writing daemon start up scripts becomes much, much simpler and the system helps encourage consistency between them.

I think the biggest issue with adopting a new init system is "how do we transition".
BaseOS in theory should be limited work, but applications (packages/ports/apt things) raise a lot of questions. Someone must port and have local modifications to support the new init or someone must patch and ask for a pull request from the upstream, which may or may not get incorporated

I'm not opposed to a new init, but goals need to be clear: for me it would be consistent startup, speed is not even secondary. I want my system to always boot correctly, be easy to figure out order, be easy to find and correct errors. And everything related to init is text files, not binary. run files, logs all text. That is my biggest problem with systemd: tries to have too much control over everything and logs are binary. Get a failure on boot? Make sure you have another system that can get to the internet so you can find the reason for some obscure Windows-like error message.

mikew · 2024-11-22T17:38:12+0000

I agree with you on consistent startup being a primary want over speed, although boot speed is bound to improve if another init and supervisory approach is ever adopted.

Perhaps a transitional approach is possible, where base is moved at a major release and a bridge to rc remains, allowing time for ports/packages to be updated?

Of the two non-systemd init and supervisory systems I've used more than casually, I prefer dinit over runit. Both are relatively simple; while effective, runit is too simple and likely would not be a desirable target for such a big change. Neither engages in taking over logging, or anything else beyond init and daemon supervision, and the configuration is all plain text. One of the nice features of dinit is `dinitcheck` which scans all service definitions, computes all of the dependencies, and discovers configuration errors from syntax to cyclic dependency issues. Handy when writing new services before testing the service.

I haven't personally or at work run into serious limitations of any of the init/supervisory systems I've worked with over the years but generally our needs were pretty straightforward. I can see in some very complex environments a need for "more" though. In the meantime, I'm becoming reacquainted with writing rc scripts.