I know from the snappy-debug output that it’s a call to “sched_setattr” that is requiring “process-control”. I am not making that
call directly and my suspiscion is that it’s either gstreamer or ffmpeg that is setting a thread priority.
As for “network-bind”, the main Revere tray application does ONVIF camera discovery which requires binding to a multicast port. Furthermore,
the main video viewing app (included in the snap) Vision uses a socket to communicated with the main Revere camera recording process.
Note: As per James-Carroll’s suggestion I tried it without connecting “process-control” and it looks like it still works… So the request can be trimmed back to just “network-bind” if that makes it more likely to be accepted. “network-bind” is in fact a deal breaker for this app.
Hello from the otherside!
(Also, I’m not a reviewer so don’t worry too much about my individual opinions, I just thought I’d offer some advice since I’ve already been in your other thread).
Does the process-control interface actually need to be connected to work? The snappy-debug feedback for sched_setattr usually includes a line advising it might just be ignorable. I can understand why the media components would like to ensure the video playback is given top priority generally; but in a lot of cases this isn’t actually needed and the OS usually does a good job of managing workloads unless there’s a significant amount of stress already. In the context of home cameras, I cannot imagine 60fps temporarily dropping to 59fps ( or potentially more extreme ) would cause that much of a concern. (Might be me not being your target audience here, but do most survailance camera’s even record at 60fps? Feels like you could likely get away with far lower).
The network-bind interface from your description makes perfect sense and would likely be a blocker for people adopting your snap, and I’d have assumed this was more likely to be the problem with your app not loading at all than the process-control side of things.
Ideally it wouldn’t be spamming the system log with audit failures, but the majority of people wouldn’t notice and if for some reason we had a savvy sysadmin who did notice, they could be reasonably expected to connect that interface manually to avoid the audit logs if they were genuinely annoyed by them. The audit logs also get cleared regularly anyway, so it’s not problematic even in terms of e.g disk space usage.
Ok, it looks like “process-control” isn’t actually required. So, I guess I can reduce this request down to just “network-bind”. Thanks! I’ll add a note to my initial request.
Could it be the interface needs patching? If it’s expected this is automatic according to the documentation, I’d have to assume in absence of explicitness, it must be defaulting to not auto-connect; whether this is a recent change I wouldn’t know, but in my personal experience the network-bind interface has never autoconnected by default for as long as I’ve seen it around (intentional or otherwise).
(And unfortunately if the interface is supposed to autoconnect, OP might still need an override now anyway since while snapd can be updated, it’s not necessarily always going to be updated by default, e.g Debian could re-exec the snapd snap but it’s not obvious to users they should probably allow it to do so. For a lot of Debian users, they tend to be stuck with the snapd apt package which doesn’t change until the next stable release).
Interface properties default to true unless specified otherwise - so there should be no explicit need for an allow-auto-connection: true - the reason it is there like that for desktop is we want to specify that this interface should be auto-connected on classic systems only and not on Ubuntu Core - so by saying deny-auto-connection: on-classic: false this then translates to allow-auto-connection: true when on-classic is true but deny-auto-connection: true when on-classic is false.
So I went back to retest this and I noticed something interesting: The problem seems to be that it doesn’t start on the first run after installing. I have been doing a ‘snap connect revere:network-bind’ at that point… but it does look like it’s not that command that’s making it work, but simply running it again that does the trick.
I will take this question back to the normal support forums. Thanks for you’re help.
Thanks for the explanation Alex. It’s likely that my memory is imperfect here since this whole time I’ve been under the impression network-bind not connecting was the expectation, but the explanation on the interface properties is really appreciated :). (Heck, might even be worth adding to the README in the interfaces folder if it isn’t already). Given the followup that this appears to be a problem with the first-time run, looks like we’ve just been misattributing the connection results!
) would cause that much of a concern. (Might be me not being your target audience here, but do most survailance camera’s even record at 60fps? Feels like you could likely get away with far lower).