How to perform "safe" stop of mender-client


I am trying to stop the mender-client after a software update. At first I was doing this with a state-script ArtifactCommit_Leave_…, but doing so made the status of the mender-server stuck at “rebooting”.

My second try was to create a flag when running ArtifactCommit_Leave… and then stop mender-client with a script Idle_Enter…, that seems to work, now the mender-server reports “success”, but …
When starting the client again the system always reboots and looking into the logfiles I found:

{“level”:“info”,“message”:“State transition: cleanup [none] -\u003e update-status-report [none]”,“timestamp”:“2020-09-23T09:13:23Z”} N.B. Last message before stopping client.
{“level”:“info”,“message”:“Running Mender client version: 2.3.0-dirty”,“timestamp”:“2020-09-24T09:18:05Z”}
{“level”:“error”,“message”:“Mender shut down in state: update-status-report”,“timestamp”:“2020-09-24T09:18:05Z”}
{“level”:“info”,“message”:“State transition: init [none] -\u003e rollback [ArtifactRollback]”,“timestamp”:“2020-09-24T09:18:05Z”}
{“level”:“info”,“message”:“Performing rollback”,“timestamp”:“2020-09-24T09:18:05Z”}

So even though I stopped the client with the state script name Idle_Enter…, there seems to be a “sub-state” or something “update-status-report” that has not finished.

How can I perform a stable stop of the mender-client. Is it better to do it in Idle_Leave…

Best regards,

Just a question first:

  • If you are going to kill the daemon anyhow, why are you not using standalone mode?

my picture is that when you use standalone mode you point out an URI to something to install, but we would like to use the mender-server as well.

sudo systemctl stop mender-client

should do it.

@drewmoseley That is what I do in a state-script Idle_Enter… but somehow when restarting mender-client it writes “Mender shut down in state: update-status-report” in the log-file ???

What exactly is the use-case here, I’m curious? Does the Mender daemon consume too many resources? Do you need it to check for updates at specific times? Or what is going on here?

It is a measurement system. We do not want to be interrupted by the client asking for new software. One customer can have 40 units and choosing to run the free Mender-Server version another 5 or 100 units and want to have the hosted version of the server. The system collects data, so there is already an existing data server platform. And via this interface we could decide when and which units that should perform the software upgrade. When new software arrives the customer will probably first test this on a couple of units, when satisfied, upgrade the units that is not currently on an assignment and then upgrade these when their assignments are finished.

I know it doesn’t solve the “Mender client interrupts” problem, but we do have phased rollouts implemented in Enterprise. Which means that updates can by dynamically assigned to a group of devices based on your chosen device metric, and then even roll it out to a small group of devices in a first stage, and only proceed if this update is succesful. Would this fit you use-case?

For the running and stopping of the client, Maybe this can be done in the Sync state? based on some condition instead? This should keep you out of trouble with the spontanaeous reboot self-checks I think.

Thank you for the information. Moving the stop command to Sync_Enter… solved the problem. Now I do not get any errors in the deployment logs.

For many customers your suggestion would probably work, but not for all, some companies do not want to have their data stored on hosted servers.

1 Like

Great :slight_smile: Glad to hear it!

For many customers your suggestion would probably work, but not for all, some companies do not want to have their data stored on hosted servers.

Yes, we are aware, and I totally understand. That’s why we also support a self-hosted version :wink:

Best of luck!