Creation of units and services?

[senderic]

I just recently found your project and it seems to have a great set of API calls for managing and monitoring units and services. However, after searching around, I can't seem to find any functions that help in the creation of new units and services.

I am working on a program that dynamically creates services for systemd to manager and I am hoping to leverage your API for both monitoring, managing and also creating these units. Currently I create the units via a template:

[Unit]
Description=Transcoding StreamID %%i

[Service]
ExecStart=/bin/echo TEST %1$s/%%i :: Random num: %2$s
User=%1$s
Restart=always
RestartSec=3
StandardOutput=journal+console
StandardError=journal+console
SyslogIdentifier=transcoding_streamid_%%i

[Install]
Alias=transcoding-streamid-%%i
WantedBy=multi-user.target

I use String.format to create a file called transcoding-stream@i.service and the %%i works with the @ aspect of the service unit.

Then I run this command to enable it and fire it up:

new ProcessBuilder()
        .command("sudo", "systemctl", "enable", "--now", serviceFile.getPath())
        .redirectErrorStream(true)
        .start();

I have various other code to read the stdout/stderr and also check the exit value, ensuring it returns 0. All that said, is there functionality in your system to create and register services?

If not, I may be interested in extending this ability into your API (if time allows). Do you have a thought on where it would be best to implement this ability? Would you recommend sub classing and/or implementing any particular interfaces in your code to make this happen properly?

[thjomnx]

Hi,

well, to answer most of your questions, see below a screenshot from some Trello board, where I gathered all ideas and roadmap items for this project so far:

That shown, I regret there isn't any support for unit creation/modification, out of the code. Also, I didn't have the time to think about concepts yet, i.e. how to integrate it into the API (until today).

Most probably I'd go for introducing some new builder-like set of classes and/or loader code for templates, like you describe here. Then, putting code in place to write files to the known locations (https://www.freedesktop.org/software/systemd/man/systemd.unit.html), by making use of already defined constants (like EXEC_START etc.). Finally the code should return some reference to the newly created unit, so that it can be controlled via D-Bus.

Do you have a thought on where it would be best to implement this ability? Would you recommend sub classing and/or implementing any particular interfaces in your code to make this happen properly?

Nearly all of the code (interfaces etc.) is used to make method/property/signal interaction via D-Bus work (and to simplify access to all the stuff that systemd provides on units). I don't think there is a particular class/interface, that is worth to derive from, in order to make this new feature more compliant to the existing code.

[senderic]

@thjomnx, would you be okay with using lombok to help reduce boilerplate code in the making of these builder classes?

[senderic]

I have something working with minimal changes to your code base. See PR #7

Basically did some research on the underlying java-dbus and looked at a few scattered examples and found the need to introduce a Struct and Tuple class and use it as a return type to the enableUnitFiles and disableUnitFiles

Since these are live units, I ran tests in my actual code base (not shared on github) and found that it works with the unit files I generate.

[thjomnx]

@thjomnx, would you be okay with using lombok to help reduce boilerplate code in the making of these builder classes?

Okay for me, if it remains a compile time dependency. I'm not a big friend of lombok and similar, though...

[thjomnx]

Will comment directly on the PR.

[senderic]

@thjomnx, would you be okay with using lombok to help reduce boilerplate code in the making of these builder classes?

Okay for me, if it remains a compile time dependency. I'm not a big friend of lombok and similar, though...

Sorry for the back-and-forth, I ended up not using lombok. I was considering it when I thought I'd need to make a builder but that is not the case anymore.

[thjomnx]

OK, no problem.