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.



InitWare isn't ready to use yet!! Unless you are doing so for fun, to experiment, or to contribute, you most likely do not want to try to install InitWare until a first stable release is made!

Installation is not yet automatic even on 'supported' platforms!! It is a complex and involved process requiring an understanding of the intricacies of how the platform boots, and it is quite easy to render the system unbootable.

The InitWare Suite of Middleware allows you to manage services and system resources as logical entities called units.

Units are manageable by a uniform interface, may specify dependencies and other relationships to other units, and are automatically scheduled by the InitWare Manager, a service management (or "init") system.

Added to this is a login and user session manager which facilitates the tracking and management of users and their sessions, integrating with the system service manager to assist in tracking. A dedicated user service manager is provided each user so that they may manage services of their own.


InitWare is a fork of systemd.

The systemd project is comprised by many programs and utilities. InitWare excludes from its scope a number of these. See Dropped components for details on these.

Compatibility with systemd

InitWare aims for a high level of compatibility with the core interfaces of systemd. Unit-files, the systemctl and loginctl commands (provided as iwctl and iwloginctl), the systemd1 and Login1 D-Bus APIs, the sd_notify API, and several other interfaces are all subject to this aim.

Comprehensive compatibility with every interface is impractical on some platforms; some unit options are entirely GNU/Linux-specific and while most have alternatives in spirit on other platforms (e.g. Linux namespaces and FreeBSD jails), a perfect mapping of semantics between these is not practical. Nonetheless, it is important to us that InitWare should be able to run with little or no modification the vast majority of systemd unit-files, and that they should behave reasonably.

Differences from systemd

InitWare differs from systemd in three principal manners:

  1. InitWare is highly portable.
  2. InitWare aims to be significantly more modular.
  3. InitWare is of significantly smaller scope, concerning itself only with system, service, session, and login management.

The Roadmap details some plans for the future development of the InitWare Suite.

Platform Support

The following platforms are supported:

  • NetBSD (9.0+): InitWare's native platform. System, user, and login management are all supported.
  • DragonFly BSD (5.8+) as user manager.
  • FreeBSD (13.0+) as user manager.
  • GNU/Linux (3.6+) as system or user manager. n.b. GNU/Linux support is complete but not yet set up to build; this will be corrected later.

We hope to support (recent versions of) OpenBSD, and possibly also Illumos, in the near future. Please see the Support Matrix for further information on platform support.

Required runtime dependencies:

  • D-Bus 1.4+
  • On all BSD platforms:
    • libinotify-kqueue v0.0.20180201+ (provided as libinotify in Ports, pkgsrc, and OpenPorts)

Optional runtime dependencies:

  • On GNU/Linux:
    • UDev or Eudev (for .device unit support)
  • On DragonFly BSD:
    • udevd running (for .device unit support)
  • On FreeBSD:
    • libudev-devd (for .device unit support)

To build InitWare, any libraries listed above must be present complete with their associated development libraries. Additionally required are the following:

  • a C toolchain supporting GNU C extensions, e.g. GNU CC or LLVM/Clang
  • Typical build prerequisites (e.g. build-essential on Debian)
  • CMake 3.9+
  • GPerf
  • M4, Awk

For building HTML documentation, OpenBSD's ManDoc is required.

Building is done in the typical CMake way, i.e. cmake && make && make install.


Most of InitWare is licensed under the GNU Library GPL, version 2.1 or later, but some files are under other terms. See doc/ for details. In particular, where a file does not implement any algorithm or technology eligible for copyright (e.g. where the functionality is basic and obviously implementable only in one way), these are released explicitly into the public domain, as copyright would be anyway uneforceable.

Further reading

  • Repository Tour: A brief overview of the layout of the repository.
  • General Style Guide: Standards of style by which code and documentation alike are written in InitWare.
  • C Style Guide: The standards of style by which code in C-like languages is written in InitWare.
  • Roadmap: Future plans for InitWare.
  • PTGroups: Describes PTGroups, the simple abstraction layer over the PROC filter for Kernel Queues, which provides advanced (CGroups-like) process tracking on the BSD ports of InitWare.
  • Porting Notes: Informal notes on how InitWare's initial port (from GNU/Linux to NetBSD) was carried out.
  • Contributors' Study Guide: A short reading list mainly focused on problems of service management on Unix-like systems, written with potential contributors in mind.
  • Credential-passing over datagram sockets (support for non-Linux platforms)

    Credential-passing over datagram sockets (support for non-Linux platforms)

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

    Refer to 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.

    opened by netbsduser 7
  • Process tracking with Kernel Queues on BSD platforms

    Process tracking with Kernel Queues on BSD platforms

    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.

    opened by netbsduser 4
  • macOS port

    macOS port

    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.
    opened by netbsduser 3
  • Eliminate dependency on E-Poll and co.

    Eliminate dependency on E-Poll and co.

    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.

    opened by netbsduser 3
  • Alternative to using libdbus

    Alternative to using libdbus

    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.

    opened by netbsduser 3
  •  error: macro

    error: macro "__ssp_bos_check3" passed 11 arguments, but takes just 4

    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?

    opened by cirnatdan 2
  • Flatpak compatability?

    Flatpak compatability?

    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?

    opened by ribosomerocker 2
  • Re-port to OpenBSD

    Re-port to OpenBSD

    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
    opened by netbsduser 2
  • PTGroup as libray

    PTGroup as libray

    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

    opened by xxxxxliil 2
  • Name conflict, iwctl is already taken by the iNet wireless daemon

    Name conflict, iwctl is already taken by the iNet wireless daemon

    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: Arch Linux Wiki:

    opened by tomalexander 2
  • On `daemon-reexec`, sometimes see

    On `daemon-reexec`, sometimes see "Failed to insert PTGroup for unit [email protected] into hashmap: File exists"

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

       PTGroup: sys:/-.slice/user.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
                 └─[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: 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: 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?

    opened by netbsduser 2
  • last commit is old

    last commit is old

    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 ?

    opened by eoli3n 2
  • question: Meson

    question: Meson

    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!

    opened by Tachi107 2
  • Gnome should crash when Initware is not installed

    Gnome should crash when Initware is not installed

    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.

    opened by kevlar700 1
  • option for system iw-cjson

    option for system iw-cjson

    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.

    opened by florhizome 2
  • Exit codes shouldn't necessarily be interpreted

    Exit codes shouldn't necessarily be interpreted

    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.

    opened by netbsduser 0
Middleware suite for service and system resource management
Allows you to observe the status of your DotA 2 (Defense of the Ancients 2) match within the Discord, through the Rich Presence service. 🎮

DotA 2 RPC (dota2-rpc-client) Allows you to observe the status of your DotA 2 (Defense of the Ancients 2) match within the Discord, through the Rich P

Anderson Silva 28 Nov 26, 2022
Provide translation, currency conversion, and voting services. First using telnet you create a connection to a TCP socket, then the server connects to 3 UDP sockets hosted on other servers to do tasks.

to run micro servers g++ translator.cpp -o translator ./translator <port 1> g++ voting.cpp -o voting ./voting <port 2> g++ currency_converter.cpp -o c

Jacob Artuso 1 Oct 29, 2021
cuehttp is a modern c++ middleware framework for http(http/https)/websocket(ws/wss).

cuehttp 简介 cuehttp是一个使用Modern C++(C++17)编写的跨平台、高性能、易用的HTTP/WebSocket框架。基于中间件模式可以方便、高效、优雅的增加功能。cuehttp基于boost.asio开发,使用picohttpparser进行HTTP协议解析。内部依赖了nl

xcyl 29 Dec 17, 2022
A headers only high performance C++ middleware framework/lib. See README for details.

# README # hmbdc is an open source headers only C++ framework and library built on top of various real-world tested lockfree algorithms that facilit

null 15 Nov 6, 2022
RMW implementation for EmbeddedRTPS middleware

rmw_embeddedrtps This package is experimental rmw_embeddedrtps implements the ROS middleware interface using embeddedRTPS as a middleware. Quality Dec

micro-ROS 7 Jun 2, 2022
Open hardware to measure EC and pH, drive pumps, and otherwise manage a mid-size hydroponic grow over Wi-Fi.

Hydromisc This is a single PCBA with all the necessary I/O to automate a typical small to mid-size hydroponic grow, controllable over Wi-Fi

null 480 Dec 12, 2022
Mecha allows you to debug, study, and modify the League of Legends client

Mecha allows you to debug, study, and modify the League of Legends client Usage To use Mecha, you must compile it first. See this for more information

Kovács Bence 51 Dec 29, 2022
A modding SDK that allows you to interact with a modified version of Cocos 2DX v2.2.3 utilized by Geometry Dash

What is CappuccinoSDK CappucinoSDK is a modding utility that allows you to interact with a modified version of the game engine Cocos-2DX v2.2.3, which

null 18 Oct 29, 2022
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

Welcome! The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design

Microsoft 7.2k Dec 30, 2022
Wangle is a framework providing a set of common client/server abstractions for building services in a consistent, modular, and composable way.

Wangle C++ networking library Wangle is a library that makes it easy to build protocols, application clients, and application servers. It's like Netty

Facebook 2.9k Jan 8, 2023
Pushpin is a reverse proxy server written in C++ that makes it easy to implement WebSocket, HTTP streaming, and HTTP long-polling services.

Pushpin is a reverse proxy server written in C++ that makes it easy to implement WebSocket, HTTP streaming, and HTTP long-polling services. The project is unique among realtime push solutions in that it is designed to address the needs of API creators. Pushpin is transparent to clients and integrates easily into an API stack.

Fanout 3.2k Jan 2, 2023
Enabling services on your device 81 Jan 6, 2023
LAppS - Lua Application Server for micro-services with default communication over WebSockets. The fastest and most vertically scalable WebSockets server implementation ever. Low latency C++ <-> Lua stack roundtrip.

LAppS - Lua Application Server This is an attempt to provide very easy to use Lua Application Server working over WebSockets protocol (RFC 6455). LApp

null 48 Oct 13, 2022
C++ ChrysaLisp services and messaging.

ChrysaLib C++ ChrysaLib ! A version of ChrysaLisp system concepts written in C++. Dependencies Mac via Brew brew install libusb asio Linux via apt-get

Chris Hinsley 3 Jan 10, 2022
The near bare metal multi-container supervisor and OS management system.

Pantavisor What is Pantavisor? Pantavisor is the easiest way to build and manage embedded Linux projects with lightweight containers. Put your Linux d

Pantavisor 30 Dec 20, 2022
A modern C++ network library for developing high performance network services in TCP/UDP/HTTP protocols.

evpp Introduction 中文说明 evpp is a modern C++ network library for developing high performance network services using TCP/UDP/HTTP protocols. evpp provid

Qihoo 360 3.2k Jan 5, 2023
Examples for individual ROS2 functionalities inc. Subscribers, Publishers, Timers, Services, Parameters. ...

ROS2 examples This example package is meant to explore the possibilities of ROS2 from the point of view of current ROS1 features and how the ROS1 feat

Multi-robot Systems (MRS) group at Czech Technical University in Prague 50 Nov 17, 2022
A C++ async HTTP client library to use in asynchronous applications while communicating with REST services.

libashttp An asynchronous HTTP library using Boost.ASIO as the backend. This project is licensed under: Usage Here is a example usage which is taken f

Tolga Hoşgör 53 Dec 17, 2022
deserter is the first of its kind targeted DNS cache poisoner

deserter is the first of its kind targeted DNS cache poisoner. It is capable of DNS cache poisoning without bruteforcing the target ID and source port - instead, it sniffs out DNS probes and uses the information inside to craft poisoned responses and send them back to the target.

null 92 Dec 22, 2022