Client -d global option not working

General Discussions
1

Hi folks, I’m using the -d option to set the client data store directory but it doesn’t seem to be working as I expected (or as I need it to).

I’m running the client as:
/usr/bin/mender -d /userdata/temp daemon

and then expecting data files to be written to /userdata/temp. However, on starting up the client I see the following in these 2 different locations:

/ # ls -al /var/lib/mender
drwx------    2 root     root          1024 Apr 27 20:23 .
drwxr-xr-x    7 root     root          1024 Apr 27 18:48 ..
-rw-------    1 root     root          8192 Apr 27 20:23 mender-store
-rw-------    1 root     root          8192 Apr 27 20:24 mender-store-lock

/ # ls -al /userdata/temp
drwx------    2 root     root          1024 Apr 27 20:23 .
drwxr-xr-x    7 root     root          1024 Apr 27 18:48 ..
-rw-------    1 root     root         12288 Apr 27 20:23 mender-store
-rw-------    1 root     root          8192 Apr 27 20:24 mender-store-lock

After doing a test single-file update then I see the following in these directories:

/ # ls -al /var/lib/mender
drwx------    4 root     root          1024 Apr 27 20:29 .
drwxr-xr-x    8 root     root          1024 Apr 27 20:29 ..
-rw-------    1 root     root          8192 Apr 27 20:23 mender-store
-rw-------    1 root     root          8192 Apr 27 20:29 mender-store-lock
drwx------    3 root     root          1024 Apr 27 20:29 modules
drwxr-xr-x    2 root     root          1024 Apr 27 20:29 scripts

/ # ls -al /userdata/temp
drwx------    2 root     root          1024 Apr 27 20:29 .
drwxr-xr-x    8 root     root          1024 Apr 27 20:29 ..
-rw-------    1 root     root          1508 Apr 27 20:29 deployments.0001.6769bb70-b614-4844-a684-39ba1177aca4.log
-rw-------    1 root     root         32768 Apr 27 20:29 mender-store
-rw-------    1 root     root          8192 Apr 27 20:29 mender-store-lock

So, at startup it seems to write to mender-store and mender-store-lock in both directories.
During the update process it seems to write to mender-store-lock in both directories but only mender-store in the overridden -d directory.
It writes the deployments log file to the overridden -d directory.
It writes the artifact scripts to the scripts sub dir in the default directory.
It writes the downloaded payload to the modules sub dir in the default directory.

This is significant as the location for the downloaded payload has to be in an area which is large enough to hold it, therefore it must be possible to control where that location is otherwise the download will fail.

Can anyone shed any light on this?

Many thanks,
Grant

2

/var/lib/mender is symlinked to your data directory. Here is one of my devices:

image

3

Thanks Pat. I expect my device is different to yours, I don’t have that symlink on mine. But regardless of that, as shown in my post, 2 different directories are being written to when I specify one using the -d option.

4

@oleorhagen can you comment here?

5

Ok. Not sure if this is helpful, but I’m using mender with Yocto and that is the default setup as far as I know. I did not create that symlink and we map the data directory as follows.

MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}7"

we have additional partitions from the standard which is usually

MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}4"

I assume internally mender would use a symlink to the data location for ease of use, but in your case that appears to not be the case.

6

Thanks Pat. My device isn’t Yocto, so that mapping doesn’t apply to me.

Internally, from the source code, the client defaults to using /var/lib/mender for the data directory. It’s up to the OS if that is actually a symlink or not.

However, the main issue here is that the -d option isn’t overriding that default in all cases and both directories are being written to, which I think might be a bug as it doesn’t make sense.

7

Looks like a bug to me!

Ticket: https://tracker.mender.io/browse/MEN-4669

8

Many thanks @oleorhagen

2 Likes