| *** zbenjamin is now known as Guest85911 | 01:24 | |
| *** zbenjamin_ is now known as zbenjamin | 01:24 | |
| *** frinring_ is now known as frinring | 02:35 | |
| *** svartoyg_afk is now known as svartoyg | 05:58 | |
| jrayhawk | nemo-devicelock claims to support a "number of tries", but, as near as I can tell, this is a fanciful lie and it just uses the LUKS header instead. How can I convince it to use policy-protected storage? | 06:16 |
|---|---|---|
| jrayhawk | https://together.jolla.com/question/220695/sailfish-3-numeric-pin-as-luks-passphrases-make-device-encryption-useless/ wait, this is seriously an unresolved problem after six months? | 06:36 |
| AJAX555 | horray for 5 number long pin, gets cracked in 2 microseconds | 06:43 |
| dcaliste | Hello chriadam ! | 07:07 |
| chriadam | hi dcaliste | 07:07 |
| chriadam | I hope your week went well! | 07:08 |
| dcaliste | Yes, thanks. What about yours ? | 07:09 |
| chriadam | my week was ok, thanks | 07:09 |
| chriadam | although, due to branching etc approaching, I didn't manage to spend any time reviewing your PRs unfortunately. although I saw that Pekka reviewed your qmf change, which is good | 07:10 |
| dcaliste | I would like to ask you about contactsd, see https://together.jolla.com/question/229248/carddav-sync-draining-battery-by-continiously-resyncing-due-to-an-error | 07:10 |
| chriadam | let me check | 07:11 |
| dcaliste | No problem for the pending MRs, they will be checked and included after the branching no problem. | 07:12 |
| dcaliste | About the problem at hand in the TJC question, the reporter see continuous sync attempts, something like every 10s of contacts. | 07:13 |
| dcaliste | I was blaming Buteo first but looking closely at the logs he provided, I convinced the problem come from repeated DBus calls to startSync(). | 07:13 |
| dcaliste | Not Buteo that requeue failing sync by itself. | 07:14 |
| dcaliste | My first thought for external calls every seconds went to a daemon, it cannot be UI. So I suspected contactsd. | 07:14 |
| chriadam | could very well be | 07:15 |
| dcaliste | I don't know much its code, but grepping for "startSync" in a DBus call triggered the plugin that is supposed to upsync local changes in automatically sync mode. | 07:15 |
| chriadam | my memory is very hazy, but there are a couple of possibilities at least: | 07:16 |
| dcaliste | There is a timer there to coaless multiple changes to the contact db, and this timer is indeed 10s… | 07:16 |
| chriadam | huh, well, that sounds like a smoking gun | 07:16 |
| dcaliste | The possible scenario is then : | 07:17 |
| chriadam | I thought it had a backoff though? | 07:17 |
| dcaliste | Carddav is called at normal time, and is making a change to the db, but fails at one point and does not complete the sync. The modification is catched by contactsd and 10s later it asked for a sync. Then carddav apply the same failing modification and abort. 10s later contactsd see the modification and ask for a sync… | 07:18 |
| dcaliste | So the backoff is not triggered, its a loop between carddav and contactsd. | 07:19 |
| dcaliste | My question is more related to carddav in fact ;) | 07:19 |
| dcaliste | Do you think it's possible to actually do a modification then fail, and at next sync redo the same modification ? | 07:19 |
| dcaliste | In caldav, like some etags that would not be updated ? | 07:19 |
| chriadam | anything's possible, due to bugs | 07:20 |
| dcaliste | Yeh, but would design allow this kind of scenario, I mean a modification that is always redone at each sync ? | 07:20 |
| dcaliste | When sync fails of course. | 07:20 |
| dcaliste | From the logs, the syncs are failing. | 07:20 |
| chriadam | contact sync is so hideously complex because of a terrible design decision we made back before jolla 1 launched, so that contacts aren't properly separated into addressbooks, but are aggregated for the appropriate sync target according to heuristics, basically. | 07:21 |
| dcaliste | The reporter sent the carddav sync log yesterday, but I didn't have time to investigate it yet. | 07:21 |
| dcaliste | Ok, there is a design point in contactsd that I would like to ask about also : | 07:22 |
| chriadam | ooi what triggers the contactsd side again? does it listen to a QContactManager for change signals, or what? | 07:22 |
| dcaliste | Yes that's the case : QContactManager, as far as I remember. | 07:22 |
| chriadam | because my naive assumption is that carddav plugin would do all changes in transaction, and if anything fails, entire transaction should be rolled back | 07:22 |
| dcaliste | Let me check again… | 07:22 |
| chriadam | in which case there should be no signals sent from QContactManager --> but perhaps I'm mistaken | 07:22 |
| dcaliste | Yes indeed, it's QContactManager. | 07:24 |
| dcaliste | That's why I was asking, because the fact that carddav could trigger a modification signal at each trial seems a bit suspicious even if all other pieces seems to match. | 07:25 |
| dcaliste | Otherwise, do you have any idea which daemon (or UI) that could call "startSync" on DBus every 10 s ? | 07:25 |
| dcaliste | That part I pretty sure that the sync process in Buteo comes from a DBus call. | 07:26 |
| chriadam | I definitely expect it's contactsd | 07:26 |
| chriadam | but I think it might not directly be related to the carddav failure per se | 07:26 |
| chriadam | but rather, the non-privileged to privileged database sync | 07:27 |
| dcaliste | Because in the logs, it all starts with "Start sync requested for profile:" with schedule = false, which from my investigation in buteo, can only come from a DBus call. | 07:27 |
| chriadam | contactsd is responsible to syncing non-privileged database changes to the privileged database (and vice versa for some specific subset of the data in the privileged database) | 07:27 |
| dcaliste | Yes, it's in the same exporter plugin from what I see. | 07:28 |
| dcaliste | Let me show you what I know from contactsd : | 07:28 |
| dcaliste | - startSync DBus call is done from Syncrigger object in src/synctrigger.cpp. | 07:28 |
| dcaliste | - this synctrigger exports itself on DBus, see ./src/contactsd.cpp: mSyncTrigger(new SyncTrigger(&mDBusConnection)) | 07:29 |
| dcaliste | - only exporter plugin is calling "SyncTrigger" from DBus. | 07:30 |
| dcaliste | see ./plugins/exporter/cdexportercontroller.cpp: QStringLiteral("/SyncTrigger" | 07:30 |
| chriadam | yes, the syncTrigger exists as a horrible hack to implement "sync automatically / sync on change" support. it is e.g. invoked by jolla-contacts whenever the app is opened, or if a contact is modified, IIRC. | 07:30 |
| chriadam | but the fact that the contactsd exporter plugin ALSO calls it is ... very suspicious (the exporter plugin exists SOLELY to export data to non-privileged db etc) | 07:31 |
| dcaliste | Well, I think that this automatically sync on change is called by the exporter plugin in contactsd, isnt't it ? | 07:31 |
| chriadam | so I highly suspect that the non-privileged to privileged db sync is causing the issue here. i.e. a change is made in non-privileged, which gets synced to privileged by exporter, then that change itself triggers the exporter again | 07:31 |
| dcaliste | In this exporter plugin there is a onSyncTimeout call, as there is a onExportTimeout. | 07:32 |
| chriadam | and each time its "privileged to non-privileged" sync process finishes, it is triggering the syncTrigger (to export changes to sync plugins) | 07:32 |
| dcaliste | This exporter plugin is doing the two things from what I understand from the code. | 07:32 |
| chriadam | you're right | 07:33 |
| chriadam | yes, its scheduleSync() method is the problem | 07:33 |
| dcaliste | On each modification, it is calling scheduleSync(), that fire both timeouts. | 07:33 |
| dcaliste | So my best guess is that carddav is triggering a false modification which is creating a loop. | 07:34 |
| dcaliste | Sadly the reporter scratched it's DB. | 07:34 |
| dcaliste | its | 07:34 |
| dcaliste | So there is no reproducer available, only buteos logs. | 07:34 |
| chriadam | (it might not have been carddav, e.g. it could have been some third party app which writes to non-privileged database, e.g. some android app or something) | 07:34 |
| dcaliste | Ah, I see your point. | 07:35 |
| chriadam | well, two possibilities that I see: | 07:35 |
| chriadam | 1) carddav sync failure is somehow still sending QContactManager signals even though the transaction fails/rollback | 07:35 |
| chriadam | 2) carddav is merely being triggered each time, but the "actual" cause is the non-privileged to privileged sync causing endless sync cycle loop, which as side-effect triggers carddav sync | 07:36 |
| chriadam | my bets would be on (2) because of the fragility of that non-privileged to privileged etc code. | 07:36 |
| chriadam | but I may be wrong, and (1) may be the case | 07:36 |
| dcaliste | I think your 2) is more probable. Particularly after I quickly looked yesterday at the carddav logs and couldn't fine any debug messages dealing with modifications. The failure appended after the delta calculation after downloading the upstream changes but before applying them, as far as I can see. I don't know carddav code at all. | 07:37 |
| chriadam | all that sync code will change when we update qtpim and fix the addressbook separation issues. coming soon tm. | 07:38 |
| dcaliste | I will try to investigate possible endless loop in the export part of the plugin, by triggering a change in the non priv db that cannot be commited or something similar. | 07:39 |
| chriadam | thanks very much. fwiw I'd just suggest to the user if they hit the issue again, to do: dconf write /org/nemomobile/contacts/export/disabled 1 | 07:40 |
| dcaliste | Yes, I wanted to tell him this also, but he scratched the db before I could ;) | 07:40 |
| chriadam | well, I don't blame him | 07:41 |
| chriadam | his device might have been about to catch fire | 07:42 |
| dcaliste | Of course, otherwise he killed the battery within hours. | 07:42 |
| dcaliste | About pending MR, I thank Blam again for her Help on the ContextMenu dynamic changes. The MR on keeping existing remainder time is much cleaner now, without using private properties anymore. | 07:44 |
| chriadam | excellent! | 07:45 |
| dcaliste | Still remains the oddity for the user to see remainder values for some entries that don't appears for others, but … no idea for this. | 07:45 |
| dcaliste | May be solved later on when we add UI for arbitrary values. | 07:45 |
| chriadam | indeed | 07:45 |
| chriadam | arbitrary value selector makes most sense to me, but let's see what MartinS thinks when the time comes. for now, fine to have it this way I think | 07:46 |
| dcaliste | But this by itself requires some design brainstorm on how to enter an arbitrary duration and an arbitrary unit. | 07:46 |
| dcaliste | Sure Martin could help on this. We can wait for him to enjoy his vacations ;) | 07:47 |
| chriadam | yup, design work always takes time and iteration and testing / user feedback | 07:47 |
| dcaliste | Well, thank you chriadam for the discussion today and the idea about the non-priv to priv possible failure. | 07:49 |
| chriadam | thank you for your time and efforts as always! | 07:49 |
| dcaliste | I'll try to look closer in that direction, but without reproducer or even log in that domain, it may be unsuccessful. Let's see. | 07:49 |
| chriadam | as mentioned, contact sync stuff is likely to change significantly in the near future, and not sure what the end result will be for the non-privileged database (it might not exist at all, let's see..) | 07:50 |
| chriadam | so if it proves super tricky to reproduce, bear in mind that the whole lot might vanish in a few months | 07:50 |
| chriadam | ;-) | 07:50 |
| chriadam | yes, without repro it becomes very hard :-( | 07:50 |
| chriadam | if nothing else to discuss, have a great week | 07:51 |
| chriadam | and thanks again for your efforts, much appreciated | 07:51 |
| dcaliste | Sure, I won't spend too much time if I cannot find anything solid. It's good anyway that this is being actively worked on from your side, I didn't have the problem but there are some reports about contactsd eating battery. | 07:52 |
| dcaliste | Have a nice week too. | 07:52 |
| chriadam | yeah, lots of contact sync things should hopefully be solved in the nearish future once we update things. | 07:53 |
| chriadam | related note: that carddav sync shouldn't have failed anyway, so even if it isn't the root cause of the issue that community member saw, it is still a problem that sync couldn't recover | 07:54 |
| chriadam | I will take a look also if I get a chance | 07:54 |
| chriadam | probably something inside twowaycontactsyncadaptor in qtcontacts-sqlite | 07:54 |
| chriadam | anyway, I gotta head off - gnight! :-) | 07:55 |
| kalipus8 | hello | 13:18 |
| kalipus8 | just got a nice xperia 10 | 13:18 |
| kalipus8 | but it has already been upgraded to android 10 | 13:18 |
| kalipus8 | so, do i have to downgrade it or can i use the sony android 10 asop kernel? | 13:19 |
| *** kalipus8 is now known as kalipus | 15:14 | |
| *** Ischwitch is now known as Ingvix | 23:10 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!