The InitWare Suite of Middleware allows you to manage services and system resources as logical entities called units. Its main component is a service management ("init") system.

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.

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.

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.

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.

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.

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?

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?

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

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

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

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: https://github.com/InitWare/InitWare/blob/81c9ea03afbc1142c4b24ddb3211ef257988ad0a/cmd/manager/manager.c#L2270-L2277

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

Consider: https://github.com/InitWare/InitWare/blob/81c9ea03afbc1142c4b24ddb3211ef257988ad0a/cmd/manager/unit.c#L484-L491 We don't release the ptgroup nor remove it from the ptgroups-to-unit hashmap during reloads, because we need that data around to serialise. Yet we do clear the hashmap and release all ptgroups during the reload operation: https://github.com/InitWare/InitWare/blob/81c9ea03afbc1142c4b24ddb3211ef257988ad0a/cmd/manager/manager.c#L2520-L2522 So what then is going on that there is already an entry in the map for [email protected]? Maybe there are two copies during serialisation for some reason?

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 ?

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!

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.

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.

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.