Where should I install Situations from for SFOS?
I just installed from here:
Then I deleted all running instances of situation with crest and started it with terminal:
systemctl --user start harbour-situations2application
Now I have two instances of …server in crest, is that intended?
`systemctl --user status harbour-situations2application
[defaultuser@Xperia10III ~]$ systemctl --user status harbour-situations2application
● harbour-situations2application.service - Situations Background Serv
ice
Loaded: loaded (/usr/lib/systemd/user/harbour-situations2application.service;
enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-07-30 14:34:29 CEST; 4min
11s ago
Main PID: 19208 (harbour-situati)
CGroup: /user.slice/user-100000.slice/user@100000.service/harbour-situations2
application.service
└─19208 /usr/bin/harbour-situations2application server
`
For me it’s still not working.
Situations is not recognizing that the background service is running. After I installed it, it is running as root. Anyway situations is closing when i tap on the check button. After manually starting the app again it wants me to install the background service again. Even so it is still running.
But there seems to be a firejail process running twice :
When I try to start situations via systemctl like @Speedy-10 done it, I just get:
[defaultuser@Xperia10II-DualSIM ~]$ systemctl --user start harbour-situations2ap
plication
Failed to start harbour-situations2application.service: Unit harbour-situations2application.service not found.
About that socket:
- I don’t see the name change , here it’s still
/tmp/com.pastillilabs.situations:server. Which exact package is that change in? the firejail config i think is not picked up. It needs to be referenced in/etc/firejail/whitelist-common.localto be considered. But please take care you don’t alter any entries already in there - or else patchmanager will stop working.
In PM, we do it like this:
- https://github.com/sailfishos-patches/patchmanager/blob/master/rpm/patchmanager.spec#L234
- https://github.com/sailfishos-patches/patchmanager/blob/master/rpm/patchmanager.spec#L199
EDIT: Ah I see you already do that in v1.0.1 of the daemon. BUT you do the uninstallation part it every time %postun runs - which is the case every time the rpm is updated or reinstalled - so you remove your own entry every time. Move it up into the “upgrade” test of the scriptlet.
EDIT2: Turns out the firejail file may not be necessary after all. A SailJail app profile works
just as well, is easier to install and can be expanded to include other permissions:
Manually restarting the daemon service and then looking at the status gives:
Jul 30 21:31:05 PGXperiiia10 systemd[1]: Started Situations Background Service.
Jul 30 21:31:05 PGXperiiia10 harbour-situations2application[30020]: 30020 21:31.05 unknown QObject::connect: Cannot
connect (null)::updated() to Controller::update()
Jul 30 21:31:05 PGXperiiia10 harbour-situations2application[30020]: su: user defaultuser does not exist
Jul 30 21:31:05 PGXperiiia10 harbour-situations2application[30020]: su: user defaultuser does not exist
Jul 30 21:31:05 PGXperiiia10 harbour-situations2application[30020]: 30020 21:31.05 unknown QObject::connect: No such
signal org::freedesktop::Notifications::CloseNotification(quint32,quint32)
… But here I have only nemo, not defaultuser. To find out the name of the ‘main’ or ’ device owner’ user, use its UID. It’s always 100000 and you can get the user name e.g. by parsing /etc/passwd, or getpwuid in C.
3 Likes
Another observation: the daemon/server process seems to need some seconds (a minute or so?) before it can be connected to by the client.
During that phase, the client will show the initial ‘please install the daemon’ screen, even though everything is working okay (or will be soon).
1 Like
Sorry about a mega reply. I started vacation, am traveling and won’t be able to respond or make changes as much for at least a few days.
The current export location is supposed to be the Downloads folder (like in Android). But yes, it seems I’ve managed to mess it up at some point. Will fix - or perhaps switch to Documents on Sailfish.
No, the exact same version will be available in Jolla Store - after all the fixing and assuming it will be accepted.
The idea of this version is that you wouldn’t need to do stuff like that.
Anyway, if you want to manually control the new service or try work on any issues, it is called “situations-daemon”. “harbour-situations2application” service came from Sonar which should have been uninstalled (obsoleted) if situations-daemon was successfully installed. So it is not supposed to work and/or not supposed to be started, especially as a user service.
Seems to be the normal behavior for some reason?
It didn’t seem to have any effect so I dropped the name change.
Thanks, will look into this as soon as I have time again!
Ok, I wonder why that is. Would recommending a reboot instead of just relaunching the app work better?
2 Likes
No idea why.
A reboot would hide the problem assuming the daemon has initialized before the UI is launched. But that doesn’t cover the case where e.g. the user restarted the service, or it failed and restarts through systemd.
But it seems to me there’s these cases:
- service installed, running, connectable
- service installed, running, not connectable
- service installed, not running
- service not installed
4.1 (corner case:) service installed but systemd has not loaded the unit file.
and to do it properly the client should be able to detect either state.
I guess 2. 3. 4. could be determined by querying systemd (e.g. via DBus from QML, or some Qt interface from Cpp - using dbus will require some additional permissions in SailJail).
Once checked, the client could then show a useful message, or for case 2 a “please wait” message - or just the spinner.
That all being said, maybe going the “DBus-activation” route as @attah suggested above would solve all these automatically - not sure. Also not sure if a client app can cause a dbus-activated service to be launched as root.
2 Likes
I have set up a situation where Newpipe opens when my phone is connected to a Bluetooth device called WI-SP510.
Unfortunately, the situation doesn’t start and it looks like the condition will never be fulfilled.
Has someone an idea where the issue is? Thanks in advance 
Ok, another updated version available. This time following changes were made:
- Switched server socket name back to “situationsserver”. Just to reduce the likelihood of connection to an old server instance
- Trying out using sailjail profile instead of just whitelisting as suggested by @nephros
- Switched to Documents as export location
- Removed remaining hardcoded references to ‘defaultuser’
- Added suggestion to reboot as an alternative action after installing situations-daemon
4 Likes
It is not entirely impossible that there are bugs left after all the refactoring 
I’ll check it. Helps if you can describe in more detail how you set up the condition.
Don’t know which change was the right one, but situations is now running. Thanx for your ongoing efforts!
Seems to work fine!
BTW, depending on how it is done, you might need to update the default path for the Log file (Log Action) too. I haven’t tested that.
Now that you have the Sailjail profile you can add permissions as-needed to it, for examples look at e.g.
1 Like
It helps to know that you seem to be using the “basic” version of the feature. Does it activate if you open it and scan for devices? Or if you do the same from system settings?
Just a tip - if it is an active connection to the device, it is better to enable the “Pro” version via Features page and select “Active connection” as the method.
Ok, I enabled the Pro version.
The situation is never activated. The App situation doesn’t list any active connection, instead it scans for new devices. So I managed to remove my Bluetooth device from SFOS, save the device as condition and pair again, but nothing changed.
Have you set active connection as mode or left it on scan?
As active connection.
I’m tinkering around at the moment with situations and there seem to be in deed some problems. @hhaveri has to look for.
For me it as well doesn’t work reliable. @pherjung has you established the connection and the switched inside situations the the staus of situations itself off and then on? For me in this case sitautions recognize the connection. So it seems that the service has problems to recognize a change of situations 
.
Question:
Which part is used to execute scripts using the ‘Command’ action?
The user/GUI app, or the root daemon?
Because if it’s the former it will certainly need more permissions to be able to find the commands or scripts.
If it’s the daemon, are they run as root? Or is a su involved?
The server process (daemon) executes everything. The command is executed as ‘defaultuser’ or ‘nemo’, i.e. su is involved.
Ps. I’m slowly working on the BT scanning issues. If I manage to get some fixes together during the weekend, will publish updated alpha latest by Monday. If not, there’s going to be over one week of silence since I will be traveling…
6 Likes