Probably you need to change the path of the log too. Also, you have added network-manager so, I don’t think you need network-observe.
Regarding process-control isn’t necessary right now, because you’re using nothing of it. But, you can try to change to use the kill binary directly for snaps to kill or end a process. Because process-control allows that.
Not sure why do you need block-devices.
Okay, so, how do you find apps in your code? I did understand the code of the resources app, but your one seems a bit more complicated. Can you explain it a bit, how does that work here?
Another thing, today there is snapcraft clinic, if you can, you can join and can directly interact with the snapcraft and snapd team about this. Just add about your problems under this thread.
From the org.freedesktop.systemd1.Manager interface the following methods:
ListUnits
StartUnit
StopUnit
RestartUnit
EnableUnitFiles
DisableUnitFiles
From the org.freedesktop.systemd1.Unit the UnitFileState property
From the org.freedesktop.systemd1.Service the following properties:
MainPID
User
UID
Group
GID
Okay, so, how do you find apps in your code? I did understand the code of the resources app, but your one seems a bit more complicated. Can you explain it a bit, how does that work here?
The short version is as follows:
Go through all the .desktop files and extract the name/path of the binary and icon, and use the name of the file (without .desktop) as the unique id for the application
Iterate through the running processes and check each if they have a cgroup assigned and if so sanitize it
If the process has a cgroup then match it with the list of available applications (from step 1)
If the process doesn’t have a cgroup try to mach the name of the process with the name of the binary in the Exec= field
Is this properly sanitized to have the /snap/bin/firefox as binary? Or what are you taking here for binary, only firefox?
Not sure if you use any of these actually, cause even the docker-support plug doesn’t have these access. Can you double check if things are working with docker-support properly?
The app consists of two processes. The main app (the UI) that runs confined and the gatherer that is spawned on the host machine running outside the sandbox. And since the gatherer is responsible for interacting with the system, everything just works.
There is nothing called uncofined in snap confinement. Snaps doesn’t have such thing. It completely goes against the confinement model. Even your gatherer is confined. So, what you can do is just tweak the gatherer a bit to work with confinement. Something might not completely work, but it’s far far better than unsecure model, which gives you a false hope of security.
On another note, creating a system monitor app is not impossible even with the current confinement model.
Now, regarding to your original request, it’s not supported. This snap seems to doesn’t fall under category, where classic confinement is allowed.
The problem that I was trying to avoid is the Snap version of the app ending up a lesser version then what can be obtained by other means
I’m sure it’s not, but as you can see from the thread a lot of functionality offered by the app just doesn’t seem to work, in part or fully, with the current model.
That being said, I’ll revisit this after the next release is out and see what can be done within the confines of Snap’s current offering.
Your help and support was/is very much appreciated. Thank you.
This is the app, and see, it can’t recognize my firefox, frog, conjure which all are running as a snap. So, your current model is already not properly working.
May be fixing that can fix the snap also. I also saw, while installing the flatpak that it requires reading /snap folder. Why? /snap is just the mount point and doesn’t contain anything related to desktop, there can be snaps which are out and out just disabled.
Also, the firefox process is shown under gnome-shell. No idea why is it so.
On a side note, this might help you. Your app is putting firefox snap related process in the snap under systemd/gnome-shell. So, it seems there is something missing and can be fixed.
So, probably if things can be simplified and fixed up. There might nothing that is snap specific. I will also help in your code, once when I get free from my sem exams. So, thanks a lot for showing interest and keeping up with us. I am very sure, that we can fix this.
TBH I never really tested Snap apps that much (I don’t have any installed). We had a bug report a while back, I fixed it then, never got any feedback that it wasn’t working properly afterwards.
But this feedback is very good. The app detection logic needs a refactor it has quite a few bugs that I want it ironed out, and the UI needs a refresh too
The requirement of reading /snap comes from my lack of understanding the format. This will improve over time.
It’s shown under gnome-shell since that is the parent process. I assume you started it from the dock or from the overview. This can easily be checked cat /proc/<firefox_pid>/status | grep PPid. Or print out the name of the parent in one line with cat /proc/$(cat /proc/<firefox_pid>/status | grep PPid | cut -f2 -d':' | sed 's/^[[:space:]]*//g')/status | grep Name.
I plan on majorly refactoring the app code for the next release, and I can then properly test with snap also.
I’ll try to share you about build errors sometime later, cause I needed to cleanup the build due to low space.
But, this is the change.
Also, I am not sure if using the dbus to kill a process is the best way, but resources probably uses something else, which simply directly runs the kill command, which is actually allowed by the process-control plug.
