from the top of my head i’d say mount-observe … but could also be system-observe, not sure
Thanks, this time we are playing audio and video in our app, but there is no sound heard at all. What is the interface to use for sound?
The various interfaces are documented at https://snapcraft.io/docs/supported-interfaces - please spend some time to read that page and familiarise yourself with them and the sub-documentation for each. As you can see on that page, for audio playback there is the appropriately named audio-playback interface.
After test using the ‘mount-observe’ or ‘system-observe’, notice that all the mount points are changed to become:
| Filesystem | 1024-blocks | Used | Available | Capacity | Mounted on |
|---|---|---|---|---|---|
| /dev/loop8 | 56320 | 56320 | 0 | 100.00% | / |
| udev | 1986036 | 0 | 1986036 | 0.00% | /dev |
| tmpfs | 2014196 | 0 | 2014196 | 0.00% | /dev/shm |
| /dev/sda5 | 61145932 | 15709316 | 42300872 | 28.00% | /etc |
| tmpfs | 2014196 | 0 | 2014196 | 0.00% | /sys/fs/cgroup |
The root ‘/’ information, which is originally to be the proper storage information (available, used, and 60GB total), is now incorrect (56MB only), then how to get the proper information?
check $SNAP_DATA it usually reflects the size of /
ogra@pi4:~$ snap run --shell fabrica.web
ogra@pi4:/home/ogra$ df -h $SNAP_DATA
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 458G 96G 339G 23% /var/snap
ogra@pi4:/home/ogra$
By checking $SNAP_DATA, is it always return 1 mounted path only?
When your snap uses strict confinement, it is run in a special mount namespace providing a known set of libraries from your chosen base snap (e.g. core18). This is generally a good thing, since it means your app will behave the same way on different systems. The base snap is a read only compressed file system, which is why / shows as having no free space.
If your aim is to determine how much space is available to store files in a particular directory, then the statfs system call is probably more appropriate. Even without snaps, there is no guarantee that the directory is on the same file system as /. In particular, multiplying the f_bsize and f_bavail members from the result should give you the amount of free space available in that part of the file system.
1 Like
My aim is to query the storage information in the root directory (/) only, which results is originally not correct (only 56MB) in strict confinement. But then by checking $SNAP_DATA (df -h $SNAP_DATA), it returns the correct information, but I just want to guarantee it is only one mounted path only, so to avoid confusion in code level in case there are two or more mounted path.
My point was that the amount of free space in the root directory is usually only relevant by coincidence. Imagine that I have two hard drives in my computer, with one mounted at / and the other at /home. It’s now possible that there could be space available in /, but no space in the user’s home directory (or vice versa).
A more useful question is “how much space is available to store files in directory $foo?”. In that case, calling statfs on that directory will give you the answer. In general, you can’t assume that there’s only one pool of free space for file storage, or that one directory will be using the same pool as another.
1 Like
I got your point, root and home directory might be mounted from different physical disk. But I see statfs is not installed by default. Because of it, our app will not behave properly, so is there a way to install it automatically during our app installation?
Even after installing gocryptfs and I can run statfs in terminal, but our ‘strict’-confined app seems not allowed to execute the statfs command.
statfs is a system call rather than a binary you call. It is how the df utility gets its information, and would probably be a bit easier to deal with than parsing the output of a utility whose output is intended for humans.
How you’d call it would depend on the programming language you’re using.
1 Like
Do you have an example in Node.js? Does strict confinement allow system call like that?
This package looks like it should do what you want:
It looks like there is no binding available in the standard library, but that might change in future:
1 Like
At this point it appears that this snap could likely be a strict mode snap. I suggest questions related to getting your snap to work with strict mode and how to develop strict mode snaps be new topics in the ‘snapcraft’ category so the right people see your questions and can help you.
I’m removing this from our review queue from now.
Hello, can we request those interfaces to be auto-connected? Our customer don’t have technical skill to operate on CLI.
Yes, to ensure this request gets the appropriate attention, can you please change the subject of this post to be something like Request for auto-connect xxx for appspace-app and then state specifically which interfaces you would like to request auto-connection for?
Thanks, actually we created a new post for it, but no one replied us for quite long.
So should we continue with this topic by changing the subject?
Hello, we have set our App to strict mode, but we need to request auto-connect for these interfaces for our App:
- Hardware-observe
- Network-observe
- System-observe
- Shutdown
- Mount-observe
- Physical-memory-observe
- Process-control
This request applies to the snaps:
- appspace-app
- appspace-app-qa
- appspace-app-dev
Apologies, I see we had already added the other request to the queue - no need to change this thread, we will follow up via the other thread. Thanks.