New mender server, new mender artifact, old mender client

Spinola62 · August 30, 2023, 4:00pm

I’ve build a new mender artifact using the kirkstone branch (==> v3)
I’ve installed a mender 3.4.0 server, which is up and running.
I’ve an existing device that’s running with mender client 1.5.0
This device can connect to the new server and is authenticated, so far so good.
When I try to deploy the new mender artifact to the device, I see that device doesn’t accept artifacts of version v3.

How should I proceed to get the device updated?

Spinola62 · August 31, 2023, 10:19am

I added MENDER_ARTIFACT_EXTRA_ARGS = “–version 2”, to get an artifact version 2. (which is supported both by the mender server 3.4.0 and mender client 1 5.0)

The mender client 1.5.0 now starts the download from the mender server 3.4.0, but after a while the mender client reports: ‘fatal error: runtime: out of memory’ and as a result the mender client service is terminated on the device ;-(

Any toughts?

Tamis · September 22, 2023, 7:10pm

Have the exact same issue.
Mender server gone from version 2.4 to 3.4 and mender client is at version 1.6.
I also use MENDER_ARTIFACT_EXTRA_ARGS:append = " -v 2"

When I try to upgrade some devices will fail with:

error: Could not execute fw_setenv: fork/exec /sbin/fw_setenv: cannot allocate memory
or
error: error calling enter script for (error) update-install state: error running enter state script(s) for ArtifactInstall state: statescript: error executing ‘ArtifactInstall_Enter_50’: -1 : fork/exec /var/lib/mender/scripts/ArtifactInstall_Enter_50: cannot allocate memory

I was starting to search a bit about this issue and it seems that with the new server version while mender downloads a new image its memory explodes and goes to almost 30% of the RPI3 device I am using which has 1GB or RAM.

And then while mender tries to fork / exec new processes it fails.
I think also this issue might affects it:

github.com/golang/go

syscall: use posix_spawn (or vfork) for ForkExec when possible

opened 12:42AM - 05 Jul 13 UTC

closed 11:53PM - 22 Mar 17 UTC

owenthereal

Performance FrozenDueToAge

<pre>Why: At a basic level posix_spawn(2) is a subset of fork(2). A new child p…rocess from fork(2): 1) gets an exact copy of everything that the parent process had in memory, and 2) gets a copy of all the file descriptors that the parent process had open. posix_spawn(2) preserves #2, but not #1. In some cases, say, shelling out a command, it's unnecessary to get a copy of memory of the parent process. With copy-on-write, fork will be less expensive but still, not necessary. What's out there: <a href="https://github.com/rtomayko/posix-spawn#benchmarks">https://github.com/rtomayko/posix-spawn#benchmarks</a> I am wondering if it makes sense to have this API and let developers decide which one to use (fork/exec vs. posix_spawn)</pre>

Because when I use the trick with the overcommit_memory it works all the times.

But I cannot do this in an AftifactScript if I cannot execute any ArtifactScripts.

Has anything changed in the way mender client download the image from the server?
Or maybe better how the server serves the image to the client?

Because changing the memory usage only from server change seems very bizarre.

Thanks!