DietPi-Software | Mycroft AI: mycroft-cli-client fails as root on Bullseye

[berndverhofstadt]

Hi,
After a clean installation of the latest dietpi (bullseye) release, I was able to install the dietpi-software Mycroft AI. When I try to launch mycroft-cli-client, the following error is thrown. Any idea what can caused this? I've followed the instructions

root@DietPi2:~# mycroft-cli-client


Traceback (most recent call last):
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/identity/__init__.py", line 55, in load
    identity_lock.acquire()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/util/combo_lock.py", line 59, in acquire
    self.plock.acquire()
  File "/mnt/dietpi_userdata/mycroft-core/.venv/lib/python3.9/site-packages/fasteners/process_lock.py", line 151, in acquire
    self._do_open()
  File "/mnt/dietpi_userdata/mycroft-core/.venv/lib/python3.9/site-packages/fasteners/process_lock.py", line 123, in _do_open
    self.lockfile = open(self.path, 'a')
PermissionError: [Errno 13] Permission denied: '/tmp/identity-lock'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/client/text/__main__.py", line 71, in <module>
    main()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/client/text/__main__.py", line 44, in main
    config = Configuration.get()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/configuration/config.py", line 219, in get
    return Configuration.load_config_stack(configs, cache, remote)
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/configuration/config.py", line 255, in load_config_stack
    configs.append(RemoteConf())
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/configuration/config.py", line 146, in __init__
    if not is_paired():
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/api/__init__.py", line 498, in is_paired
    api = DeviceApi()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/api/__init__.py", line 223, in __init__
    super(DeviceApi, self).__init__("device")
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/api/__init__.py", line 56, in __init__
    self.identity = IdentityManager.get()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/identity/__init__.py", line 101, in get
    IdentityManager.load()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/identity/__init__.py", line 59, in load
    identity_lock.release()
  File "/mnt/dietpi_userdata/mycroft-core/mycroft/util/combo_lock.py", line 64, in release
    self.plock.release()
  File "/mnt/dietpi_userdata/mycroft-core/.venv/lib/python3.9/site-packages/fasteners/process_lock.py", line 180, in release
    raise threading.ThreadError("Unable to release an unacquired"
RuntimeError: Unable to release an unacquired lock

Thanks!
Bernd

[MichaIng]

Many thanks for your report.

Please try:

sudo -u mycroft mycroft-cli-client

Though I see you run it as root already. I'll try to replicate.

[berndverhofstadt]

The user does exist.

root@DietPi2:~# sudo -u mycroft mycroft-cli-client
sudo: mycroft-cli-client: command not found

[MichaIng]

The command is not in the users PATH. I btw verified the issue. What indeed works is running the command as user mycroft:

sudo -u mycroft /mnt/dietpi_userdata/mycroft-core/bin/mycroft-cli-client

Not very convenient, but it is actually a known limitation when "O_CREAT"-write files in a world-writable sticky bit directory like /tmp: Even the root user is not allowed to write to them, when not owned by itself, with a new default security setting sysctl fs.protected_regular being 2, which causes pretty unexpected behaviour. I explained the background here, since OctoPrint in the past in circumstances suffered from this: OctoPrint/OctoPrint#3882
This caused me quite some headache 😄: https://twitter.com/DietPi_/status/1334851698683244547

So now Mycroft "O_CREAT"-writes the lock file in /tmp which inherently means that nothing else but the owner of this file mycroft can do the same, not even root. Hence we have no other chance than for convenience creating a wrapper script to call this command with sudo.

[MichaIng]

For you to test:

echo "alias mycroft-cli-client='sudo -u mycroft /mnt/dietpi_userdata/mycroft-core/bin/mycroft-cli-client'" >> /etc/bashrc.d/mycroft.sh
. /etc/bashrc.d/mycroft.sh
mycroft-cli-client

[berndverhofstadt]

Thanks @MichaIng this works indeed! Many thanks!

[MichaIng]

Many thanks for testing. Solution for v8.0 is here: 0f99ab8
Little bonus: Reloading /etc/bashrc.d/mycroft.sh won't lead to duplicate $PATH entries anymore, though practically it has not negative effect, it just doesn't look nice when doing:

echo $PATH

and having the same path inside multiple times 😉. This was also the case when nesting shells, not only when manually re-sourcing the script.

EDIT: ... ah lol nope actually previously the $PATH was hardcoded. Unintended as well since custom additions were overwritten, e.g. when installing Go modules and having the default Go binary path in $PATH.

I.e. at best use the new version of the full script:

cat << '_EOF_' > /etc/bashrc.d/mycroft.sh
#!/bin/dash
case "$PATH" in *'/mnt/dietpi_userdata/mycroft-core/bin'*) :;; *) export PATH="$PATH:/mnt/dietpi_userdata/mycroft-core/bin";; esac
alias mycroft-cli-client='sudo -u mycroft /mnt/dietpi_userdata/mycroft-core/bin/mycroft-cli-client'
_EOF_