I maintain a number of snaps whose default behaviour should different on an embedded, Ubuntu Core system and on a desktop “Classic” system.
It makes sense for them to run as a daemon on Core systems, but on Classic systems less so as they are more useful when started in a user session.
My latest iteration around this is to add an install hook that scans /proc/cmdline for snap_core= and sets a property accordingly:
snap_core=$(sed -n 's/.*snap_core=\([^ ]*\).*/\1/p' /proc/cmdline)
# On Ubuntu Core we default to daemon mode
if [ ! -z "${snap_core}" ]
then snapctl set daemon=true
else snapctl set daemon=false
fi
(I’m using a property as it is perfectly sensible for this default to be reconfigured by the user.)
That works on the systems I’ve tried, but I wondered whether this is reliable, or if there’s a better way to detect the type of host system.
True, that snippet could be simpler. But in the real install hook I have further logic:
# On Ubuntu Core18 we default to software cursor
if [[ "${snap_core}" =~ core18.*snap ]]
then snapctl set cursor=software
else snapctl set cursor=auto
fi
snapctl set daemon=false
snapctl set cursor=auto
if grep -q snap_core= /proc/cmdline; then
snapctl set daemon=true
if grep -q snap_core=core18 /proc/cmdline; then
snapctl set cursor=software
fi
fi
I’d also suggest to not use bash if avoidable but /bin/sh with POSIX compliant code. bash is usually slower and takes more ram (several MB vs a few kb). If there s a chance your snap gets installed on any low-end hardware this can have quite some impact (i.e. single-core/low-ram ARM CPUs running a digital-signage application).
Looking into kernel command lines no longer seems to be a solution. I’ve tested on core20-24 and the /proc/cmdline on neither of those contain snap_core=.
I’ve tried to detect by checking the value of ID inside /etc/os-release, but that also useless as ID is always set to ubuntu-core in the file available to the snap.