2021-08-24 GnuCash IRC logs
00:41:45 *** Mechtilde has joined #gnucash
01:14:29 *** fell has quit IRC
01:15:19 *** fell has joined #gnucash
01:15:20 *** ChanServ sets mode: +o fell
01:43:55 *** frakturfreak2 has quit IRC
01:44:49 *** sbluhm has joined #gnucash
01:48:01 *** nick_ has joined #gnucash
01:52:47 *** nick_ has quit IRC
01:54:37 *** jervin has quit IRC
01:57:56 *** frakturfreak2 has joined #gnucash
02:04:13 *** nick_ has joined #gnucash
02:07:29 *** Mechtilde has quit IRC
02:25:27 *** nick_ has quit IRC
02:37:15 *** gour has joined #gnucash
02:37:15 *** ChanServ sets mode: +v gour
02:43:49 *** fell has quit IRC
02:44:40 *** fell has joined #gnucash
02:44:41 *** ChanServ sets mode: +o fell
02:53:33 *** nick_ has joined #gnucash
03:06:58 *** nick_ has quit IRC
03:10:13 *** nick_ has joined #gnucash
03:31:40 <Simon> the lock file handling is broken... https://s85.org/ZR61LRyG
03:34:05 <Simon> it looks like GncXmlBackend::session_end() deletes the lock file even if it was locked when opening the session?
03:35:18 <Simon> m_lockfd should be initialised to 0
03:35:29 <Simon> well, -1
03:35:35 <Simon> if (m_lockfd > 0)
03:35:38 <Simon> close (m_lockfd);
03:35:39 <Simon> if (!m_lockfile.empty())
03:35:45 <Simon> rv = g_unlink (m_lockfile.c_str());
03:43:57 *** Mechtilde has joined #gnucash
03:46:27 *** David has quit IRC
03:46:46 *** David has joined #gnucash
03:52:12 *** nick_ has quit IRC
03:55:04 <Simon> SESSION_BREAK_LOCK does not function as documented
03:55:19 <Simon> it ignores the lock but does not acquire it
04:09:59 *** Jeanl has quit IRC
04:10:09 <Simon> // Don't pass on locked or readonly errors.
04:10:12 <Simon> QofBackendError berror = get_error();
04:10:14 <Simon> if (!(berror == ERR_BACKEND_LOCKED || berror == ERR_BACKEND_READONLY))
04:10:16 <Simon> set_error(berror);
04:10:35 <Simon> I don't understand what that is doing. If the error is already set then not setting it again won't change anything?
04:11:24 <Simon> it doesn't even clear the error
04:15:00 <Simon> I think SESSION_BREAK_LOCK should report when it fails to recreate the lock, it should not be implicitly allowing it to continue with no lock at all
04:15:46 <Simon> afaict the NFS link code does nothing at all to improve locking
04:16:02 <Simon> oh, it links to the lock file
04:16:51 <Simon> in the break lock case I'll just ignore the link check failure
04:21:07 <Simon> I don't think it should be unlinking the lockfile if the NFS link test indicates failure
04:21:25 <Simon> because that implies that another user has actually locked it, so deleting the lock file will break their lock
04:36:57 <Simon> https://github.com/Gnucash/gnucash/pull/1119
04:40:02 *** field^Zzz3 has joined #gnucash
04:56:26 *** Jeanl has joined #gnucash
04:58:48 *** ekleog has quit IRC
04:59:00 *** ekleog has joined #gnucash
04:59:27 *** Jeanl has quit IRC
05:01:04 *** nick_ has joined #gnucash
05:16:20 *** nick_ has quit IRC
05:16:33 *** nick_ has joined #gnucash
05:18:13 *** nick_ has quit IRC
05:29:19 *** Hamaryns has joined #gnucash
05:29:19 *** ChanServ sets mode: +v Hamaryns
05:40:30 *** ericdm9 has joined #gnucash
05:41:22 *** ericdm has quit IRC
05:41:22 *** ericdm9 is now known as ericdm
06:00:09 *** User_ has joined #gnucash
06:08:29 *** Hamaryns has quit IRC
07:16:01 *** PowaBanga has quit IRC
07:27:24 *** PowaBanga has joined #gnucash
07:40:59 <warlord> Simon, it CAN'T acquire the lock, because another instance of the application might have it.
07:41:59 <warlord> Simon, the "Open Anyways" will steal the lock. That is by design.
08:10:10 *** Jeanl has joined #gnucash
08:13:11 *** Jeanl has quit IRC
08:46:16 <Simon> warlord: except that it doens't
08:46:52 <Simon> at least in terms of being the process that created the lock file
08:46:57 <warlord> Correct.
08:47:25 <warlord> Because it another application has the lock, it can't really take it over. But it can still act as if it has the lock, and delete the lock file when it exits.
08:48:49 <Simon> but it should open the lock file
08:51:06 <Simon> and I would expect it to attempt to acquire the lock against a potential third application that is not trying to break the lock
08:51:47 <Simon> because the lock being broken is the earlier one, not any future attempts on it
09:15:26 <warlord> It can't open it, because it is still owned by another instance.
09:16:47 <warlord> Just being able to open the file is not sufficient (because on NFS, even if you "lock" the file, multiple instances can open it because locks are only advisory and are local)
09:50:05 *** Bambuzel has joined #gnucash
09:50:05 *** ChanServ sets mode: +v Bambuzel
09:57:05 *** Bambuzel has quit IRC
10:01:27 *** Mechtilde has quit IRC
10:46:52 *** andreas^ has joined #gnucash
10:46:53 *** ChanServ sets mode: +v andreas^
10:47:07 <andreas^> hello people.
11:02:03 *** sbluhm has quit IRC
11:03:30 <Simon> it can be a stale lock file
11:03:46 <Simon> in that scenario you only want to have one instance of the application attempting to break the lock
11:03:55 <Simon> all other instances should be making normal attempts
11:04:16 <Simon> you need to unlink and recreate the file to do that, although the break lock process carries on even if that fails
11:04:48 <Simon> but this is mostly irrelevant; I had to do something to make the break lock process not simply ignore the lock file and then not unlink it when I fixed the first bug
11:15:02 *** jervin has joined #gnucash
11:17:42 *** Pegasus_RPG has joined #gnucash
11:20:06 *** sbluhm has joined #gnucash
11:23:52 *** sbluhm has quit IRC
11:46:49 *** guak has joined #gnucash
11:50:29 <jralls> Simon, the primary intended purpose of breaking the lock is that GnuCash crashed. The primary intended purpose of the lock is to keep a single user on a single computer from opening two instances of GnuCash on the same book.
11:51:02 <jralls> Simon, if your use of GnuCash involves more than one person keeping the books then GnuCash is not the right solution for you.
11:51:36 <Simon> you're making a lot of assumptions here
11:51:48 <Simon> and ignoring the original bug
11:51:56 <jralls> No, I'm stating policy.
11:52:18 <Simon> the behaviour of 4.6 and probably everything since that code was converted to C++ is to delete the lock file if it cannot be acquired
11:52:23 <Simon> even if GnuCash is already running
11:54:09 <jralls> That was the case before I rewrote it to C++. There's no mechanism to determine if the lock is there because of a crash or because there's another instance of GnuCash running.
11:55:40 <Simon> no it wasn't
11:56:10 <Simon> it is unlinking the lock file when the session ends despite returning an error and not actually acquiring the lock
11:56:45 <Simon> I know this worked in 2.6 because I have a script running every hour that would be forced to wait if I had GnuCash open
11:56:53 <Simon> now with 4.6 it just deletes the lock file after the first attempt
12:00:37 <warlord> So you are saying it is not waiting for the "Open anyways" response?
12:03:57 <jralls> Hmm, that might be caused by https://github.com/Gnucash/gnucash/commit/170502c6c5c17e3138df1d4cb9669ca2803dc855.
12:13:04 <jralls> warlord, new subject: Is the Bugzilla API open? Last night's spams were apparently created by users that don't show up in user search so I wonder if there's a backdoor for spammers.
12:15:38 <Simon> it's python code, so there is no dialog
12:16:05 <Simon> GnuCash returns the error but closes the session which deletes the lockfile
12:16:11 <Simon> so the next attempt succeeds
12:16:56 <warlord> Simon, do you have your script set up to 'open anyways' as part of the session begin?
12:17:21 <jralls> Yeah, the commit I indicated above would cause that, it calls session_end() in the XML backends destructor.
12:17:50 <warlord> You can try to reproduce this by the app by running gnucash, then running another instance, do NOT select "open anyways", then exit... and see if it destroys the lock.
12:18:19 <Simon> no, I wouldn't do that
12:19:07 <Simon> try: session = gnucash.Session(args.file, is_new=False)
12:19:10 <Simon> except gnucash.gnucash_core.GnuCashBackendException as e:
12:20:34 <Simon> the second commit in https://github.com/Gnucash/gnucash/pull/1119 fixes it
12:43:16 *** sbluhm has joined #gnucash
12:44:04 *** Jeanl has joined #gnucash
12:44:23 *** kcin has joined #gnucash
12:47:04 *** Jeanl has quit IRC
12:52:28 *** Mechtilde has joined #gnucash
13:08:08 *** Jeanl has joined #gnucash
13:23:47 *** sbluhm has quit IRC
13:25:45 *** gour has quit IRC
13:39:22 *** andreas^ has quit IRC
13:46:41 *** Jeanl has quit IRC
14:07:15 *** sbluhm has joined #gnucash
15:41:15 *** sergiomiguelrp has joined #gnucash
16:00:12 *** jervin has quit IRC
16:05:23 *** kcin has quit IRC
16:24:47 *** Mechtilde has quit IRC
16:25:59 *** sbluhm has quit IRC
16:55:17 *** User_ has quit IRC
20:03:04 *** field^Zzz3 has quit IRC
20:16:24 *** bertbob has quit IRC
20:23:30 *** bertbob has joined #gnucash
20:23:30 *** ChanServ sets mode: +v bertbob
21:00:34 *** storyjesse has joined #gnucash
21:09:45 *** fell has quit IRC
21:11:04 *** fell has joined #gnucash
21:11:04 *** ChanServ sets mode: +o fell
21:32:07 *** alt_mikee has joined #gnucash
21:32:10 *** mikee has quit IRC
22:09:36 *** guak has quit IRC
22:40:45 *** bertbob has quit IRC
23:01:13 *** bertbob has joined #gnucash
23:01:13 *** ChanServ sets mode: +v bertbob
23:29:41 <fell> jralls, https://github.com/Gnucash/gnucash-docs/pull/204#issuecomment-905028804