cryo_utilities CLI fails writting cryoutilities.log to /root

[iweiny]

I ran the CLI per your video and got the following error. I got around this by creating the /root/.cryo_utilities directory and everything ran fine.

I did not use the CLI to configure anything. From what I can tell everything worked with the GUI. So this is likely not a big deal as most users are probably not going to use the CLI.

(deck@steamdeck .cryo_utilities)$ sudo ./cryo_utilities help
2023/03/23 20:00:43 open /root/.cryo_utilities/cryoutilities.log: no such file or directory
panic: open /root/.cryo_utilities/cryoutilities.log: no such file or directory

goroutine 1 [running, locked to thread]:
log.Panic({0xc00022feb0?, 0x27?, 0x42?})
/opt/hostedtoolcache/go/1.20.2/x64/src/log/log.go:384 +0x65
main.main()
/home/runner/work/steam-deck-utilities/steam-deck-utilities/cmd/cryoutilities/main.go:37 +0xb1

[CryoByte33]

Did you install CU using the script, or did you just download the binary?

[iweiny]

Installed with the script. Like you show in this video. https://youtu.be/C9EjXYZUqUs

…

On Thu, Mar 23, 2023, 10:14 PM CryoByte33 ***@***.***> wrote: Did you install CU using the script, or did you just download the binary? — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2RQVF3L5CPPXLARQXIADW5UUUZANCNFSM6AAAAAAWGBKSRQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[CryoByte33]

Interesting, I'll try to replicate today but I'm curious why it thinks $HOME is /root when using sudo on your device but not mine.

Thank you for the report!

[iweiny]

Yea NP.

FWIW I don't see anything set in my sudoers file which would preserve the environment.

Removing my hack and using 'sudo -E .cryo_utilities/cryo_utilities help' works.

Perhaps there is a difference here:

(130)(deck@steamdeck ~)$ sudo cat /etc/os-release
NAME="SteamOS"
PRETTY_NAME="SteamOS"
VERSION_CODENAME=holo
ID=steamos
ID_LIKE=arch
ANSI_COLOR="1;35"
HOME_URL="https://www.steampowered.com/"
DOCUMENTATION_URL="https://support.steampowered.com/"
SUPPORT_URL="https://support.steampowered.com/"
BUG_REPORT_URL="https://support.steampowered.com/"
LOGO=steamos
VARIANT_ID=steamdeck
BUILD_ID=20230313.1
VERSION_ID=3.4.6
(deck@steamdeck ~)$ sudo cat /etc/lsb-release
DISTRIB_ID="SteamOS"
DISTRIB_RELEASE="rolling"
DISTRIB_CODENAME="Holo"
DISTRIB_DESCRIPTION="SteamOS Holo"

[someburner]

This happened for me as well. I believe by default sudo does not pass the majority of the env when invoked. See here.

Here is sudo env:

(130)(deck@steamdeck ~)$ sudo env
COLORTERM=truecolor
LANGUAGE=
XAUTHORITY=/run/user/1000/53ae5570-b101-13e1-a124-521e3c501831
LANG=en_US.UTF-8
TERM=xterm-256color
DISPLAY=:0
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/home/deck/.local/share/flatpak/exports/bin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/deck/.local/bin:/home/deck/.local/podman/bin
MAIL=/var/mail/root
LOGNAME=root
USER=root
HOME=/root
SHELL=/bin/bash
SUDO_COMMAND=/usr/bin/env
SUDO_USER=deck
SUDO_UID=1000
SUDO_GID=1000

I have only glanced at the code. Assuming most of the commands are things needed to be ran as root, this should be okay. But anything touching user (e.g. deck) data, should be handled with care. Appears the game data move cmd only uses mv so that should preserve the user.

It's a little tricky with the deck, since you can't install a binary to, say, /usr/sbin, can't create custom sudo accounts, or make permanent changes outside of home. I guess that is why flatpack is the tool of choice for a lot of things.

You can see how the decky installer handles this. Pretty much what the stackoverflow link says. Although they also mix root and deck ownership in the homebrew directory. In general it's best to avoid that but given the constraints mentioned, it makes sense.

For a log file, as long as you're not logging a ton it's probably okay to leave in the home directory. If the log needs to persist through reboots, you can't really do /tmp. Maybe best to just get the user home dir, so it writes to the right place, and the ideally it would truncate itself every so often or after reaching a certain number of lines.

Also, would be nice to have the option to put the binary in .local/bin and add that to PATH, but would complicate setup.

edit:

So the GUI does not attempt to write the log as root, which makes sense. It's run as deck and then runs sudo commands where necessary. I'd say since the CLI will always be run in desktop mode, just make a logfile in /var/log and note that in docs. Otherwise there could be permission issues. IDK if this is an arch thing or just the deck but oddly if you create a file as deck then try appending as root, you get permission denied. Very strange! I'm guessing this is a SteamOS feature.

edit2: this occurs on debian as well. Haha TIL! Looks like I have more to learn.

edit3: This is actually a recent-ish linux feature specifically regarding writing to /tmp. See here. My thinking was that users should be instructed to run the GUI once, in order for the logfile to be created by deck user, and then running commands from CLI as root user could just append to the already-created file. I suppose that would still work.

[amosher-github]

This is occurring for myself as well.

(deck@steamdeck .cryo_utilities)$ env | egrep -i "deck|root|home"
egrep: warning: egrep is obsolescent; using grep -E
SESSION_MANAGER=local/steamdeck:@/tmp/.ICE-unix/8198,unix/steamdeck:/tmp/.ICE-unix/8198
XDG_CONFIG_DIRS=/home/deck/.config/kdedefaults:/etc/xdg
GTK_RC_FILES=/etc/gtk/gtkrc:/home/deck/.gtkrc:/home/deck/.config/gtkrc
PWD=/home/deck/.cryo_utilities
LOGNAME=deck
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/deck/.gtkrc-2.0:/home/deck/.config/gtkrc-2.0
HOME=/home/deck
PROFILEHOME=
USER=deck
XDG_DATA_DIRS=/home/deck/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
MAIL=/var/spool/mail/deck
OLDPWD=/home/deck
(deck@steamdeck .cryo_utilities)$ sudo env | egrep -i "deck|root|home"
egrep: warning: egrep is obsolescent; using grep -E
MAIL=/var/mail/root
LOGNAME=root
USER=root
HOME=/root
SUDO_USER=deck

[spkane]

@CryoByte33 I ran into this error as well. I worked around it it by running sudo mkdir -p /root/.cryo_utilities/ once.

Using sudo -E is another option until there is a proper fix, but it might introduce other concerns.

Due to the use of the sudo command, it appears like the CLI is trying to use root's home directory instead of using deck's home directory and then panicking because it can't open the log file.

(deck@sdeck ~)$ sudo env
LANG=en_US.UTF-8
TERM=xterm-256color
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/home/deck/.local/share/flatpak/exports/bin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
MAIL=/var/mail/root
LOGNAME=root
USER=root
HOME=/root
SHELL=/bin/bash
SUDO_COMMAND=/usr/bin/env
SUDO_USER=deck
SUDO_UID=1000
SUDO_GID=1000

(5)(deck@sdeck-spk ~)$ sudo -E env
SHELL=/bin/bash
LIBVA_DRIVER_NAME=radeonsi
EDITOR=vim
PWD=/home/deck
LOGNAME=root
XDG_SESSION_TYPE=tty
MOTD_SHOWN=pam
HOME=/home/deck
LANG=en_US.UTF-8
SSH_CONNECTION=192.168.15.171 52665 192.168.15.42 9022
XDG_SESSION_CLASS=user
TERM=xterm-256color
USER=root
DRACUT_NO_XATTR=1
SHLVL=1
MOZ_ENABLE_WAYLAND=1
MOZ_USE_XINPUT2=1
XDG_SESSION_ID=5
XDG_RUNTIME_DIR=/run/user/1000
SSH_CLIENT=192.168.15.171 52665 9022
DEBUGINFOD_URLS=https://debuginfod.archlinux.org
XDG_DATA_DIRS=/home/deck/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/home/deck/.local/share/flatpak/exports/bin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/deck
SSH_TTY=/dev/pts/0
_=/usr/bin/sudo
SUDO_COMMAND=/usr/bin/env
SUDO_USER=deck
SUDO_UID=1000
SUDO_GID=1000