search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.78k stars 496 forks source link

Snap applications not visible when auto boot as dietpi user to desktop #5074

Closed gouthamravee closed 2 years ago

gouthamravee commented 2 years ago

Creating a bug report/issue

Required Information

Additional Information (if applicable)

Steps to reproduce

  1. Install Dietpi with Mate desktop, FFMPEG, and set default desktop to MATE
  2. Install the Xibo-player as described here - https://snapcraft.io/install/xibo-player/debian
  3. Set the auto start tool to desktop with auto logon as the dietpi user

Expected behaviour

Actual behaviour

Extra details

MichaIng commented 2 years ago

I'm not sure where snaps are supposed to appear, whether when you install them as root user, they are expected to be available for non-root users, whether they usually come with desktop menu/application entries or not, where you do expect them and whether you tried to run the Xibo Player executable command from command line? Also did you check the status of the snap daemon, whether it runs correctly does not show any error messages, particularly about Xibo Player?

I have zero experience with snap, but what I expect is, that similar to Docker containers, snap apps install, run and appear exactly the same way on all snap-capable Linux distributions, which is somehow the point of using them. So if you do the same you did on DietPi on a plain Debian image, does it have a different result?

gouthamravee commented 2 years ago

The snap software usually appears in the 'other' section of the programs menu. What's weird is when I manually start the desktop environment with the 'startx' command after logging in to the CLI as the dietpi user the snap program appears exactly as expected. Its also accessible from the terminal GUI using the 'xibo-player' command.

If I auto start the desktop as the dietpi user the 'xibo-player' application is not show in the programs menu OR available as a command through the terminal GUI.

Yes the Snap daemon is running correctly in all scenarios.

I haven't tried plain debian, but plain ubuntu 21.x works as expected. Installing through snap shows the app in the 'other' section of program menu. Auto starting the desktop env as the non-root user also shows xibo-player in the programs menu.

I might be using the wrong terminology, by programs menu I mean the start menu equivalent on linux desktop environments.

This is my first time using snap too, and there's no alternative method for the xibo-player application. Honestly its not the only problem I'm having with Xibo. Really wanted to use dietpi as the base OS for this, but I might end up doing vanilla Debian or try to find a completely different program for my digital signage needs.

MichaIng commented 2 years ago

Okay, thanks for clarifying. Basically there is an application entry like /usr/share/applications/xibo-player.desktop or /usr/local/share/applications/xibo-player.desktop then, which are used by desktops to fill their "start menu" (yes I'm also not sure how it is correctly called on Linux desktops šŸ˜„).

So you boot into console, login manually as "dietpi" user, then run startx, and the Xibo Player is there? And you select "Desktop automatic login" as "dietpi" user and it is not there? That is pretty strange indeed. The only difference is that the latter starts the desktop via LightDM, since startx cannot be reliably called by non-root users, depending on the GPU hardware and drivers. Can you test it again with "LightDM login mask"?

dietpi-autostart 16
reboot

This should boot into the LightDM login mask, where you can login as "dietpi" user manually. Would be interesting if the entries are then missing as well, which would indicate the LightDM environment to somehow cause this. Between this and desktop autologin is only a single LightDM option, so this actually cannot make any difference regarding desktop menu entries.

gouthamravee commented 2 years ago

So you boot into console, login manually as "dietpi" user, then run startx, and the Xibo Player is there? And you select "Desktop automatic login" as "dietpi" user and it is not there?

Yes that's exactly what I'm experiencing.

Can you test it again with "LightDM login mask"?

dietpi-autostart 16
reboot

Same situation here. With the LightDM login mask option, signed in as dietpi, xibo-player is not available.

I reverted back to the default boot behavior, and was able to access xibo-player after running startx manually. Just doble checking here.

Ideally, the process would be the desktop env starts and then xibo-player starts. I tried the foreground script option for auto start and that also did not work as expected. The two commands in there were

startx
xibo-player

I selected the dietpi user when prompted. This started the desktop env as expected, but again xibo-player was missing.

MichaIng commented 2 years ago

Does the following work?

xinit "$(which xibo-player)"

First startx, then xibo-player cannot work as the latter needs to start within the X session šŸ˜‰. The above command wraps it, though with fewer environment that startx sets up on top of xinit.

The case with LightDM is very strange indeed, the result should match startx. Through there is a difference: LightDM starts the X server as root user (or as lightdm user, not 100% sure how it is split currently) and only the X client (desktop) starts as the user you login with. When you run startx, then the X server itself runs as your login user. However, for things like menu entries only the client user should be relevant šŸ¤”.

gouthamravee commented 2 years ago

Hey sorry, but did you mean for me to add the xinit command into the foreground start script?

The case with LightDM is very strange indeed, the result should match startx. Through there is a difference: LightDM starts the X server as root user (or as lightdm user, not 100% sure how it is split currently) and only the X client (desktop) starts as the user you login with. When you run startx, then the X server itself runs as your login user. However, for things like menu entries only the client user should be relevant šŸ¤”.

I sort of understand what you mean here. I'm way more familiar with Linux CLI than desktop envs. I figured it might be some sort of permission issue. When I login as the root user, then startx, xibo-player is accessible too.

The issue happens only when auto starting the desktop env.

MichaIng commented 2 years ago

Probably, though it is strange since the /usr/share/applications//usr/local/share/applications should be accessible by every user, and of course when already accessible by dietpi, then definitely by lightdm, and even if not, it's not the X server which scans those directories for application entries but the logged in user. Can you check whether there is a xibo-player.desktop (or similar) in one of those directories, and in case what the owner/modes of it is?

Hey sorry, but did you mean for me to add the xinit command into the foreground start script?

Yes exactly. You can also run it directly on console. And of course you can hardcode the path, running:

which xibo-player

first to get the path, e.g. /usr/local/bin/xibo-player and then

xinit /usr/local/bin/xibo-player

in the script.

gouthamravee commented 2 years ago

Putting the path for xibo-player directly with xinit in the autostart foreground script worked! It even works from the dietpi user if I prepend the command with sudo.

Other details below:

Probably, though it is strange since the /usr/share/applications//usr/local/share/applications should be accessible by every user,

There are no links to xibo-player in the /usr/share/applications folder. The applications folder does not exist in /usr/local/share on my install.

Wow yeah idk what I was thinking that I didn't fully realize what your command did. I think after xinit I just spaced out.

Results of which xibo-player /snap/bin/xibo-player

I also tried whereis xibo-player and got xibo-player: /snap/bin/xibo-player.options /snap/bin/xibo-player /snap/bin/xibo-player.disabled-watchdog

ls-ing with options -halt on that path I get 

lrwxrwxrwx  1 root root   13 Dec 13 00:19 snap-store -> /usr/bin/snap
lrwxrwxrwx  1 root root   13 Dec 13 00:19 snap-store.ubuntu-software -> /usr/bin/snap
lrwxrwxrwx  1 root root   13 Dec 13 00:19 snap-store.ubuntu-software-local-file -> /usr/bin/snap
lrwxrwxrwx  1 root root   13 Dec 13 00:14 xibo-player -> /usr/bin/snap
lrwxrwxrwx  1 root root   13 Dec 13 00:14 xibo-player.disabled-watchdog -> /usr/bin/snap
lrwxrwxrwx  1 root root   13 Dec 13 00:14 xibo-player.options -> /usr/bin/snap

Details for /usr/bin/snap -rwxr-xr-x 1 root root 15M Jun 6 2019 snap

MichaIng commented 2 years ago

It even works from the dietpi user if I prepend the command with sudo.

Ah, did you run startx as well with sudo or does this work as plain dietpi user? It you used sudo, it would all make sense with the permissions and the application as the desktop session then were a root session and not one of the dietpi user.

Okay so snap applications are stored in /snap, interesting. Not sure how those are added to the desktop then, I guess snap does this on install somehow as it is not one of the default directories that are used for desktop applications. I guess then that indeed by default those are only added for the root user by default. ~/Desktop/ contains really desktop icons, I think somewhere in ~/.config/ additional menu items can be added, aside of the global ones in /usr/share/applications.

gouthamravee commented 2 years ago

Ah, did you run startx as well with sudo or does this work as plain dietpi user?

I did the commands without sudo at first, including startx. I then chose the auto login user in the following prompt. I saw the same issue regardless of which user; root or dietpi when using startx.

I found this on the snapcraft docs page if it helps - https://snapcraft.io/docs/desktop-menu-icon-support

But either way, the issue is solved for me as of now. I am able to auto start the xibo-player. Not a fan that its starting with sudo, but I can sandbox the device that's running this so it shouldn't be a problem.

gouthamravee commented 2 years ago

@MichaIng since this issue is solved for me are you okay with me closing this issue? Not sure if y'all have a process for that.

MichaIng commented 2 years ago

So application/desktop entries are installed to /var/lib/snapd/desktop/applications/ if I understand it right. Since this is no default desktop/XDG path, the question is how it is injected into the desktop session. I assume that snapd on install creates a hook/config that is loaded by startx to inject this path, while LightDM seems to skip this hook. Very fragile, compared to simply using the default paths which are assured to be loaded regardless how the desktop is invoked. Also LightDM is the default display manager for LXDE and recommended/used often for many other desktops as well.

When you find the app in /var/lib/snapd/desktop/applications/, you can link it to the default path to enable it with LightDM/autologin, e.g.:

ln -s /var/lib/snapd/desktop/applications/xibo-player.desktop /usr/share/applications/xibo-player.desktop

However, this is a Snap issue, and as long as we do not provide Snap as install option in dietpi-software, there is nothing we can do about it. Also since we use default desktop packages and a default login/display manager with LightDM, to be sure it could be tested on plain Debian and then reported to the Debian bug tracker (snapd package maintainer).

So yes, I mark this as closed. But interesting to dig a bit into the Snap setup, so we are prepared if we decide to implement it into dietpi-software šŸ™‚.