Mender logs misleading message when trying to execute an update module with erroneous hashbang

I noticed that an error in the module script hash bang executable path logs the error as if the module script does not exist, when it is the executable that does not exist.

I don’t know if this is a bug or a limitation of the way scripts are called.

For example, I have an update module called docker-compose where the executable had changed. The error I got was:

Feb 16 16:14:42 linux mender[5648]: time="2022-02-16T16:14:42-05:00" level=error msg="Module could not be executed: fork/exec /usr/share/mender/modules/v3/docker-compose: no such file or directory"

…suggesting the update module is non existent, while it is.


Hello @francoislefebvre ,

So you’re saying that the file does exist, is executable but misses a hashbang?

In that case I believe the error should be something else (exec format error or something similar).

@oleorhagen perhaps you know?

  • The script exists and has execute permissions
  • Hashbang is declared but the path to the executable is wrong (executable does not exist)

The error is directly returned from the Golang exec lib:, so there is not that much we can do around the returned error here.

However, some better logging prior to this error message would probably help.

We do have this debug log:

	log.Debugf("Calling module: %s Download %s", mod.programPath, payloadPath)

Would having this at the info level be acceptable @francoislefebvre, or do you think more effort is needed?

Yeah, that’s what I thought.

After some search, it seems like this message stems from the OS itself and is somewhat well recognized as a problem with the shebang line.

And since appending the OS/golang error message is quite useful, I think we can leave it like that. We learn every day!

Thanks for your help.

1 Like