We are running mender-client in Managed Mode and using mender-convert for generating our images.
Due to synchronisation reasons we cannot auto-start the mender-client daemon on our device immediately after each boot as a systemd service (/etc/systemd/system/multi-user.target.wants/mender-client.service)
which would be the default behaviour with images generated by the mender-convert tool.
Instead, I need to start the mender-client daemon a little later programmatic from one of our applications while the idea is to use systemctl start/stop mender-client here.
Also I must ensure, that mender-client’s auto-start is initially disabled after each boot.
Now I found the following setting in mender_convert_config: MENDER_ENABLE_SYSTEMD=y
Is it sufficient/safe to use this flag to achieve the above described goal or is there more to consider ?
Or put differently, when I set “MENDER_ENABLE_SYSTEMD=n”:
Does the file /etc/systemd/system/multi-user.target.wants/mender-client.service furthermore exist then in the image generated by mender-convert
and would it be enough then, to start/stop the service on the device manually/programmatically ?
looks like you wont get the symlink and hence the service will not be registered so systemctl start/stop will not work for you until its enabled.
If you have a synchronization issue on startup of your services then take a look at the systemd service docs as you could update and replace the mender service file with one of your own that fixes the dependencies execution graph to suit your requirements.
If its the case that mender manage-mode needs to never startup until driven by some programmatic event some time in the future that’s not related to bootup, then i would look into wrapping the starting of the mender client in daemon mode in a script with some ipc mechanism (unix socket/dbus) to start/stop the process. Systemd service itself supports sockets, but i don’t think you can stop a service this way (i could be wrong)
Many thanks for your quick answer and pointing me into the right direction.
I wasn’t aware that generating the symlink is the only action that is carried out by
if [ “${MENDER_ENABLE_SYSTEMD}” == “y” ], but now I am.
Our use case is in deed the latter one from both you are describing ("… needs to never startup until driven by some programmatic event some time in the future that’s not related to bootup"), therefore it seems that it would be the best to follow your corresponding suggestion.