So. I invested some time and solved this issue. See here:
I would have liked to get some pointers earlier from Jolla instead of a blacklisting (which is not needed on unencrypted devices including all Jolla 1, C, Tablets). As I think someone more experienced in systemd would have seen this immediately.
Many thanks to DrYak for this bug report here and confirming my thoughts and needed code changes.
First: BIG THANK YOU for investigating and fixing the bug!
I had indeed confused the hard/soft requirement, but the final result is the same.
Just for the tiny details:
Wants/WantedBy is the soft dependency,
which may fail.
Yes, it tolerates a fail (if the units fails, it will not break, but continue starting).
But it will always initiate a unit start before, no matter what.
And is will always wait for unit completion
One-shot type service units will wait for script’s exit
(modern, sysd-aware) daemons service units will wait for successful backgrounding (there’s a systemd dbus signal for that)
old-school (SysVInit) daemons service units will wait for the typical double-fork
things which are not technically daemon but scripts service units (a.k.a the I wrote a Perl 1-liner and don’t bother with all the daemony stuff) will wait a timeout (i.e.: the script needs to survive without crashing for some time for it be considered a successful start)
and path-triggers units require the path to be available (seems logical).
So even if it is a “WantedBy” (so if an actual script did crash booting would have continued), we still end up in a waiting loop, where multi-user waits for the (path trigger) unit to be ready, but the path trigger depends on a mount path (/home) that isn’t mounted yet and thus waits, but the that mount path will never become available before the encryption has been unlocked which is set to happen much later in the boot process order, and that depends on the multi-user target having been already reached (Whereas it’s currently still stuck waiting).
circular dependency hell.
The way you solved it (making sure that the path trigger unit is loaded ONLY AFTER the point at which the GUI is ready and the encryption has been unlocked and mounted) is nice.
There’s a tiny catch in your solution, but not dramatic:
if the main (admin) user is called “default user” but there’s a secondary (non admin) user created which happens to be called “nemo”, that user gets to do the updates too, even if apparently, according to Jolla’s design only UID 100000 should be able to.
(but that’s a problem that is shared with any other app which predates the username switch from nemo to default)
if the users has renamed the admin user to something which is neither defaultuser nor nemo (i.e.: non standard), this line will fail. Best would be to use whatever is the pythonic equivalent of the bash getent passwd 100000 and get the correct path from column 6)
(but if a user goes to play around with usernames and paths, they should are advanced power users enough to fix this too).
Maybe this is what I could not read out of any information I read about systemd:
This makes it more or less clear. And I would have started earlier…
Any pointer to that? (please, even it is now obsolete ) As I would have expected that unit to dangle around but not stop multi-user.target to finish.
About the tiny catches:
I guess I did it to my best knowledge:
This is handled as the existence of /home/defaultuser is checked first. Only if this does not exist it is falling back to old (beloved ) nemo.
This is something that cannot happen as the user names “defaultuser” resp. “nemo” are hard-wired and cannot be changed, afaik. I read that on zendesk, only the clear (UI) name displayed may be changed like on other OSes.
Pythonic could look something like:
This works for AlienDalvik for Android 4.x (devices from original Jolla 1 up to Xperia X), as they share the same filesystem as the main linux (the isolation is just inside the Java-like VM that old Android use).
A completely different way to handle this would be to use DNS forwarder daemon on the linux side
(i.e.: it’s own DNS server, e.g.: dnsmasq, systemd-resolved, etc.) (note: on other laptops/smartphomes NetworkManager can even automate that, I don’t know if connman on Sailfish can automate it).
And then configure Android to always use that as a DNS server in the default connection.
The main advantage:
defender wouldn’t need to modify actual host files. It can modify some include configuration of dnsmasq and normal DNS name solution is handled by the latter.
The main disadvantage:
much more complex solution involving multiple components (installing dnsmasq, having connman update dnsmasq configuration instead of /etc/resolv.conf, etc.)
I am using the Android /system/etc/hosts (which gets updated by Defender as well) for the lxc mount.
Furthermore I added the option ‘ro’ so Android side cannot mess with SFOS file(s).
And I put option ‘optional’ as when I tried to add also /system/etc/hosts.editable it caused aliendalvik to fail starting (ro file system, could not add that file, alien service failing). This is not needed for system/etc/hosts as this file is present. Just for the records.
I’m encountering a problem with the list updating: it’s already trying to update when I launch the app and it never ends. If I try to update manually it doesn’t change anything.
As lists are not up-to-date, the filtering is ineffective .
Does anybody else has the same behaviour ?
AFAIK Jolla tries to get away from all the “hardcoded” configuration. Becoming independent of the fixed “admin user” name “nemo” was just one step in this direction, AFAIU.
Hence UID 10000 may not necessarily be an “admin user”, at least after some configuring.
Plus theoretically there may be multiple “admin users”.
What one can supposedly rely on, is that “admin users” are members of the group “sailfish-system” (since SFOS 3.4.0, before that: “system”). Edit:Or useloginctlto determine who is logged in at the “primary seat”; see Jolla’sudisksctl-userscript for details.
P.S.: To take this into account would just add an indirection to the pythonic one-liner, AFAICS.