Pass and parse arguments to running/online systemd daemon

I'm in the process of creating a systemd daemon from a C/C++-compiled executable. However, while the program runs, I'd like to be able to change some of the program parameters. (As is possible with other daemons on Linux).

By this I mean changing, for instance, a "destination_server_ip" variable in my process through the command line, perhaps with something like

systemctl myProgram --destIP="1::2::3::4:5"

Is there a standard way / framework to implement this?

Solution

As Vollfeiw suggested in their comment on your question, you really probably want to make your own interface within your application for doing this.

I really don't think this is basically ever a good design choice for updating internal state to an application - but if you are extremely intent on being able to use the systemctl utility to update the state of your program, one mechanism you could take advantage of is UNIX signalling.

implement a signal handler within your program (ways of doing this vary by language and framework, if you're not familiar go find some tutorials). On UNIX, there are two signals reserved for you to use however you see fit - SIGUSR1 and SIGUSR2. To use any other signals would also work but would violate conventions, so you probably shouldn't do it.
thereafter, you can use the --signal flag to systemctl to alert the program that it should do something
UNIX signals can't carry payloads, so you are going to have to get the program to know how to load the data it wants some other way (eg write to a file prior to sending the signal, maybe).

Honestly, at this point you are basically at functionally the same level of complexity as exposing a web socket or something like that. Not to beat a dead horse, but you should therefore probably just bite the bullet and make a web interface. :) BUT you are technically able to get what you want done this way, too.

If you want to be able to do everything locally and not have people use curl or a browser or whatever to do their configuration, you could write your own CLI client for managing your daemon, for which you'd probably want to use UNIX sockets (as opposed to TCP or UDP sockets for example) as your fundamental communication technique. This is a pattern in a few daemon projects out there (seeing the daemon part of a service ending with "d," for "daemon", and then the client part of the service, which is for controlling the daemon, ending with "c" or "ctl," for "control". One example of a service which does this is the NTP service chrony, which uses chronyd to manage your computer's timekeeping and provides a chronyc CLI interface to the user for telling chronyd to do things differently.

Most programmers are going to find it easier to expose a web interface.