initware / initware Goto Github PK

(You should've enabled the Discussions)

This is exactly what I was looking for today.

In this talk, Benno (FreeBSD dev) says that -

I think there is an important distinction to make be drawn between systemd the implementation and systemd as a set of ideas

And I absolutely agree. systemd the idea is amazing, it's what we need in every UNIX-like system. But systemd the implementation (by Lennart Poettering and Co.) is sub-par, IMO

I think that most of the people who are speaking against systemd the implementation, and most people who are speaking for systemd are giving counter-arguments from systemd the idea, which is why the fight still continues.

All we need is a systemd implementation that has a simple codebase, works properly on all OSes, and doesn't introduce a bunch of vulnerabilites, and everyone will be happy.

Hope this project picks up steam soon, and more people (devs and users) join it!

Recent Linux kernels provide the CGroups unified hierarchy. InitWare should support it.

InitWare currently boots as system manager on NetBSD by taking over from /etc/rc which is run by unmodified NetBSD init - that skeletal /etc/rc runs some of the early boot-up scripts before the remainder are converted by a generator invoking rcng2unit.

I am now looking to get a FreeBSD system booting with InitWare and want to eliminate some of the fragility of the current approach on NetBSD by instead using a portable program in place of BSD init.

Status messages continued to appear on the console after getty instances were already launched.

I suspect it's because systemd does some checking to see if an executed program could possibly touch the console which involves reading /sys/class/tty/tty0/active (the currently active virtual terminal) and other such malarky (see https://github.com/InitWare/InitWare/blob/main/lib/shared/util.c#L3397).

I'm not sure what it's up to there - why does it care about the currently active VT, doesn't /dev/console always point to the first, or are things different in Linux land? - but that's where the issue must lie.

Hey,
I casually tried to build initware with gnu guix (see #19). Guix usually tries to build with tests, and fails if it doesn't find any, which is the case with iw-cjson. fortunately i can just build iw-cjson separately (which is preferred anyways) and switch tests off. But: if i feed the result to initware as input(dependency), it doesn't react in any way and starts another iw-cjson build from the submodule dir. unfortunately guix's ability to skip tests seemingly ends here and the build crashes again...
This is pretty specific and could of course be fixed by my side but ig i think it would be good to be able to feed iw-cjson from the "system" via option and/or on the other side, intentionally build and execute those tests.

We have many service carrots (some aren't even mouldy) but we need a stick to gain traction and beat away the pesky competition. Atleast until Debian devs choose the easy option. I propose operation session chaos.

I've been k-lined from libera, so if you're interested, you can join the initware fan club IRC channel at zer0-one.net:6697.

Let's port InitWare to macOS.

There are five BSDs; InitWare runs on four of them. Now it's time to complete the support for BSD platforms.

These problems willl show up:

1. No NOTE_TRACK for the proc filter in MacOS. For some reason they deleted it. We could try racing against time to add child processes, I suppose
2. No credential passing over datagram sockets (#8)
3. No SOCK_CLOEXEC/SOCK_NONBLOCK. Tedious but easy to resolve.

macOS port needs process metadata fetching utilities (process name, command line, executable name, UID, GID, parent PID.)

Could probably use libproc or sysctl.

InitWare inherits the handrolled plaintext parser of systemd for its auto de/serialisation functionality, but we've since began using some JSON for PTGroups.
We should eliminate that custom format altogether in favour of using JSON.

The first problem we face here is that JSON natively doesn't any numeric datatypes other than Number, and cJSON will correspondingly not be so useful if we want to serialise e.g. a uint64_t. We can either emit strings and parse them back to the appropriate format, or we can modify cJSON to add other numeric datatypes (our output would then not be pure JSON, but as we only use the serialisation data internally, that is not a real issue.)

Decoding of CGroup paths into units, slices etc should be improved - right now, for example, if one runs InitWare under systemd using delegation, then the CGroup decoding will give you the systemd unit under which InitWare is running, rather than the InitWare unit.

One approach we could take is to look at unit names in reverse order of components rather than in forward order, as they currently do. This would require some care to avoid confusions.

Another option could be to require that a system-mode scheduler should always run when running InitWare under delegation from systemd, and any user managers run under that one. The system-mode scheduler could publish a file in /var/run/InitWare with its root CGroup path which would be removed before we attempt to resolve CGroup paths to units. This way has the merit of letting us keep these decoding functions with little alteration.

According to the wiki description, it looks like there is only one instance of PTGroup, so why use the plural form

Need another way to detect if a socket has had listen() called on it - for now disabling that check on OpenBSD.

We need to be able to receive credentials over datagram sockets in the Unix domain.

Refer to https://git.lysator.liu.se/lsh/lsh/-/blob/master/configure.ac for guidance on this.

We can easily support this for our FreeBSD, DragonFly BSD (both SCM_CREDS, sent explicitly by sender), and NetBSD (LOCAL_CREDS, received implicitly) ports, and I believe also for a future Illumos port via SO_RECVUCRED (also I believe implicitly.)

On FreeBSD and DragonFly BSD we encounter a problem with some use cases - namely the Journal's syslog-compatibility socket. syslog(3) probably doesn't attach credentials explicitly, and thus we won't receive credentials for those. We can maybe use LD_PRELOAD to load up a replacement

More problematic is OpenBSD. They don't have credentials-passing over datagram sockets at all, and don't seem keen on it. And somehow I can't foresee their minds being changed by the needs of a systemd fork! Using stream sockets instead would add unwanted extra complexity; sequenced-packet sockets would still require the tedium of tracking connections, but eliminate the need for buffering etc. The best way forward would be to write a good patch and convince them to accept it, though.

Inquiring minds want to know whether a standalone library implementing the bits of logind GNOME/KDE want to have is part of the roadmap.

Problem seems to go away when stepping in GDB.

waitid(2) is used by InitWare to inspect processes waiting to be reaped without actually reaping them. This function is unfortunately absent from OpenBSD. Unless OpenBSD will add it soon, it may be worth looking into replacing it with waitpid calls and adding the result to a queue for later inspection if necessary.

This is a daemon, right? It initializes the system, right?

I propose to rename it "initialD"

E-Poll is used extensively throughout InitWare, but on BSD platforms this relies on the E-Poll Shim library - which is a great work, but has some corner cases in which things seem to stop working properly.
It would be prudent to replace the E-Poll dependency with something else. Maybe libev could work, but more likely something like a portable sd-event would be better.

Is InitWare to systemd what pipewire is to pulseaudio ?
Is the aim to be a sane systemd alternative/replacement ?
Is there any distro that use InitWare by default, as proof of concept ?

Hey, this is an awesome project and I really appreciate all the work being done on this. I've just got one question that I'm unsure if this project really plans to deliver on this, does already, or doesn't plan to. Since I've not seen anything by searching, I'll just ask here; does Flatpak work? If not, is it ever planned to work?

fdset_new_fill is used by the manager in preparation for a daemon-reexec; this function iterates over either /proc/self/fd on GNU/Linux, /dev/fd (FDescFS) on FreeBSD, or /proc/curproc/fd on NetBSD, each of these contains files named the number of an open file descriptor in the PID which is readdir'ing it.

OpenBSD does not have this means of determining which files are open. The idiomatic way for OpenBSD seems to be kvm_getfiles(3) - surprising to me as this shows the open FDs of all processes. Nonetheless, we should support it.

We could also eliminate one dependency on the ProcFS or FDescFS on BSDs (where these are sometimes not mounted) by using that function (or its FreeBSD equivalent procstat_getfiles) by using the KVM interface on all the BSD platforms. I note also that at least journald-native.c wants to actually readlink the files to determine the associated filename, but FreeBSD's FDescFS does not create links for the filename (at least without linrdlnk) as far as I know - so journald can't check the filename.

After some big changes (switch to sd-event reimplemented using KQueue on BSD platforms; codebase re-syncing with systemd in some areas) the OpenBSD port isn't building.

Some issues to be addressed:

• sigfd relying on sigtimedwait()
• waitid() use with WNOWAIT

See https://github.com/InitWare/InitWare/blob/main/cmd/manager/socket.c#L676

Linux's proprietary extensions to ProcFS are used abundantly. Portable alternatives should be used where possible, and multiple implementations provided if necessary.

Intel's iNet wireless daemon already is already using iwctl as a binary name. Iwd has existed for 7 years, has been public since at least 2017, and is growing in popularity as a faster replacement for wpa_supplicant. As far as I know, iwd is only targeting Linux, but this project is also targeting linux so you're going to hit conflicts.

Man page: https://man.archlinux.org/man/community/iwd/iwctl.1.en
Arch Linux Wiki: https://wiki.archlinux.org/title/Iwd

The D-Bus C API is an unmitigated monstrosity, and using it directly after having any prior experience with a highly useable messaging system like Objective-C's Distributed Objects, or even just about any other system, is an exercise in misery. Apparently GLib's G-D-Bus is nicer to use, but GLib is an inappropriate dependency for systems software.

Let's put further efforts into something that isn't miserable and depressing to use. JSON-RPC over Unix domain sockets, or even VarLink, is a better option for some basic interfaces, e.g. the CGroups release agent's message. We might also look into whether sd-bus could be ported.

No NOTE_TRACK so we have to iterate over all subprocess PIDs each time (using libproc or sysctl) and add all to the kqeueue when we get a NOTE_FORK.

We need to work on getting the PAM integration working on the BSD ports. The exception, of course, is OpenBSD, for which I don't think a PAM implementation is available. There, we will have to look into BSD Auth instead, but that's a separate issue.

I am not sure exactly how much work will be necessary to make the PAM integration work on BSD. The Linux Pam against which the systemd code was written is a distinct implementation. Still, I'm sure it shouldn't be too much work.

If PTGroup can act as a libray, then other service monitoring tools will also benefit from it
To avoid possible licensing issues, it is recommended that PTGroup use a more lenient license, such as MIT

I encounter an error building on NetBSD-current:

/var/work/wip/initware-git/work/initware/lib/initware/syslog/catalog.c: In function 'write_catalog':                                                                       
/var/work/wip/initware-git/work/initware/lib/initware/syslog/catalog.c:360:70: error: macro "__ssp_bos_check3" passed 11 arguments, but takes just 4                       
  360 |  memcpy(header.signature, CATALOG_SIGNATURE, sizeof(header.signature));   
      |                                                                      ^    
In file included from /usr/include/string.h:127,                                  
                 from /var/work/wip/initware-git/work/initware/lib/initware/syslog/catalog.c:25:                                                                           
/usr/include/ssp/string.h:50: note: macro "__ssp_bos_check3" defined here     
   50 | #define __ssp_bos_check3(fun, dst, src, len) \                           
      |                                                                           
/var/work/wip/initware-git/work/initware/lib/initware/syslog/catalog.c:360:2: error: '__ssp_bos_check3' undeclared (first use in this function)                            
  360 |  memcpy(header.signature, CATALOG_SIGNATURE, sizeof(header.signature));   
      |  ^~~~~~                                                                   
/var/work/wip/initware-git/work/initware/lib/initware/syslog/catalog.c:360:2: note: each
undeclared identifier is reported only once for each function it appears in       
*** Error code 1  

Any ideas on how to fix this?

InitWare should be able to boot a NetBSD system. This will serve as a good starting point for FreeBSD and DragonFly BSD as well (less so for OpenBSD which doesn't use rcNG.)

The approach I mean to take for our first efforts are thus:

• Don't bother running as PID 1.
• Instead retain traditional /sbin/init as provided by the BSD.
• Implement a miniature /etc/rc. It should
  1. Run rc.d scripts up to mountcritlocal (or FILESYSTEMS on FreeBSD) so that the basic prerequisites to run InitWare - basic filesystems mounted, etc - are met.
  2. Daemonise the manager.
  3. Run a tool which opens some FIFO and waits for a byte to be written to it.
  4. A special service run by the manager, of type=idle and depending on the prerequisites for getty, will a byte of 0 to that FIFO when we are ready to launch getty.
  5. The aforementioned tool exits, satisfying init that it should run the gettys.

We need to then proceed to create an rcNG script-to-unitfile generator.

We should try to implement a way of flexibly transitioning rc scripts to unit-files on a file-by-file basis; rc scripts should perhaps check with InitWare too to see if a dependency is up yet. (do rcNG scripts actually check if their dependencies are up before they start themselves?)

In the future we can consider a /etc/ttys unit-file generator too.

InitWare needs support for delegated restarters.

All modern BSD platforms, including macOS, provide the Proc event filter for their Kernel Queues, which allows almost perfect process tracking.

We should do the following to support this:

• integrate a kernel queue into the event loop
• implement a simple CGroups-like abstraction, which we will call for short PCGroups, which provides a hierarchy of pseudo-CGroups which can contain PIDs and further PCGroups, and functions to put PIDs in these groups, and to iterate over their members.
• write out all the PCGroups state to the serialisation file, and rewatch all PIDs, for daemon-reexec events. (n.b. slightly racy)
• make fork()'d processes wait for the go-ahead from the manager before they begin to do anything, so we can be sure they are registered with the kernel queue by the parent, and assigned to the appropriate PCGroup.

n.b. In exceptional cases tracking will break down with this mechanism. Either allocation of the note for a forked process may fail in the kernel, or we may fail to allocate our own structures related to the tracking. I don't think there is an easy answer to this problem. The best we can do, probably, is to iterate over every process in the system/belonging to the user (for system or user instances respectively), and try to put it in the right place in the pcgroup hierarchy by reference to its parent PID.

Hi! First of all, I'm impressed with your work, great job :D

As you know systemd upstream uses Meson. Why did you choose to replace it with CMake instead? Does it have some issues that make it a bad choice for cross-Unix development? Could you please be specific?

I really like Meson, and I think its simplistic approach ensures a nice development experience. But nothing is perfect! If you'd share your concerns I might be able to work on fixing them (I'm not a Meson dev). Thanks :)

And again, your work is quite impressive, hope someone starts integrating it in some cool BSD project!

These will be modules (probably shared libraries) that can add hooks to the process launch procedure (used to launch .service units) that can do additional things. A good first such extension will be the ability to jail services on FreeBSD/DragonFly BSD.

As issue #2, only for DragonFly BSD.

We should better support running as an auxiliary service manager. Some rough thoughts:

1. General refactoring of the logic in the manager for behaving differently according to run mode - sometimes it uses getpid(), sometimes other things - it's a mess, needs to be cleaned up.
2. Probably wise to add a 'auxiliary' flag to the manager struct rather than a new RunningAs mode.
3. The special targets and services like dbus.socket and dbus.service - need to handle these

Exit codes are interpreted as systemd specific exit codes (>200), BSD sysexit.h codes, or LSB exit codes.

This is not necessarily correct - individual daemons have their own exit code conventions.

It might be wise to move the interpretation of exit codes into svcctl and let individual services list their exit code mappings, or introduce a more general mechanism for this.

OpenBSD doesn't use PAM internally (not in login, doas, sudo, and importantly sshd) so the InitWare PAM module is of little use. It might be usable for e.g. the GDM port to OpenBSD (which I believe does use PAM) but not for general purpose use. It uses BSD Auth isnstead.

BSD Auth has an approval script option which we can use, but it can't set environment variables for an SSH login as SSHD runs it in a privilege-separated process after forking the unprivileged process.

For now, let's just implement the approval script and we'll deal with SSH later.

In turn, iwctl status [email protected] shows no PTGroup. HOWEVER: iwctl status user.slice correctly shows:

   PTGroup: sys:/-.slice/user.slice
           ├─user-1000.slice
           │ ├─[email protected]
           │ │ ├─ 9697 (sd-pam)
           │ │ └─11398 /usr/local/libexec/InitWare/iw.manager --user
           │ └─session-c1.scope
           │   ├─10736 sshd: david [priv]
           │   └─11578 sshd: david@pts/0
           └─user-0.slice
             └─[email protected]
               ├─12941 (sd-pam)
               └─13475 /usr/local/libexec/InitWare/iw.manager --user

Something odd is going on there - for some reason the PTGroup is already in the hashmap:

I'm not sure why there is an existing entry - maybe we didn't clear out all old ptgroups?

Consider: