GNOME Bugzilla – Bug 413494
Enable closing normally the application with kill -TERM
Last modified: 2018-06-29 21:28:20 UTC
If you have to close all the open applications, because there is a power failuer and the SAI is going to stop the computer, you need to stop gnucash. When I have tried to close gnucash with kill (-TERM) <gnucash-pid>, the application is not correctly closed, as the next start says: gnucash can not obtaing the lock for the database, it may be in use .... In case the database is not saved, you could select "close and not save", or end the application as is done now. Best Regards and thank you for such a great accounting application.
Because this can mean the loss of data, I rate this issue as critical. This also happens if you finish your gnome/KDE/whatelse session: there might be another program in the foreground and you get no warning. Some Programs block the shutdown by a modal dialoge until you answer save or discard - next morning you wonder, why did the computer not shut down or is the battery empty. Other like openoffice run a temporal save and ask on startup.
Sorry for the long inactivity on this report. I wonder what the expected behaviour for kill -TERM is: If the file has the autosave feature switched on and was saved recently, terminating is fine anyway (but in 2007 that feature didn't exist). Same for SQL backends, which get "saved" anyway. If there are unsaved changes, should a "file save" be triggered? But this can require significant time. Is this the expected behaviour though?
For me the solution could be: If gnucash knows there are unsaved changes, then an "autosave" sould be triggered (probably sending a passive notification of the action, avoiding a modal dialog that prevents the shutdown). In any case, closing the opened files/database in an ordered way is mandatory. I prefer to wait 30 seconds more in a logout to loose recent data. And, of course, there should be no dialog when it is started again complaining about the file being already opened (I still use file).
Ok. From what I understand here, the feature can be implemented as follows. Keep in mind that the "autosave-feature" in itself can be switched on or off. - If gnucash is using any other backend than the file backend, no additional step is taken on kill -TERM - If gnucash is using the XML file backend and there are no unsaved changes, no additional step is taken on kill -TERM - gnucash+file backend: If there are unsaved changes and the autosave-feature is switched off (=time interval equal to zero), no additional step is taken on kill -TERM - gnucash+file backend: If there are unsaved changes and the autosave-feature is switched on, an automatic saving of the file should be triggered before closing the application. This way, no data will be lost. This is an enhancement that needs to be implemented.
I would prefer to save also in case 3. Coming from ancient times ("Save often ...") I don't use autosave features - they often block the machine and take a snapshot in the wrong moment - e.g. in the middle of an experiment. But I would like to have a save before the shutdown. One question arises: If you are in the middle of editing a transaction, usually a dialog pops up "Save or cancel txn edit" - I don't know how you solved it in the autosave feature.
(In reply to comment #5) > Coming from ancient times ("Save often ...") I don't use autosave features - > they often block the machine and take a snapshot in the wrong moment - e.g. in > the middle of an experiment. But I would like to have a save before the > shutdown. But what if the autosave was switched off by the user intentionally? Having an automatic saving at the kill signal IMHO is not what a user expects who intentionally has switched off autosave. (And no, I don't want any extra option just for the behaviour at the kill signal.) To me it rather sounds that your behaviour is the deviation from the expected. > One question arises: If you are in the middle of editing a transaction, usually > a dialog pops up "Save or cancel txn edit" - I don't know how you solved it in > the autosave feature. No, this question isn't a problem for autosave, because the autosave will save the unedited state of the transaction. The question comes because the GUI still has unsaved changes, but those changes have not yet been "committed" to an actual transaction. For the kill signal, this question is indeed a problem. Have you checked what happens if you have edited some transaction so that this question would appear on Ctrl+Q, but then close gnucash by the kill signal? Does it present this question and block the signal? Well, probably not, and it also shouldn't do that. The GUI changes itself are small enough to tolerate them being lost.
(In reply to comment #6) But what if the autosave was switched off by the user intentionally? Having an > automatic saving at the kill signal IMHO is not what a user expects who > intentionally has switched off autosave. (And no, I don't want any extra option > just for the behaviour at the kill signal.) To me it rather sounds that your > behaviour is the deviation from the expected. How about Auto-save time interval: -1 = Only on shutdown?
(In reply to comment #7) > How about > Auto-save time interval: -1 = Only on shutdown? No. I said no extra option. This includes no extra magic number in any existing option. However, why don't you activate the auto-save interval with a very long time, such as 12 hours?
Cool, it's accepting bigger numbers. :)
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=413494. Please continue processing the bug there and please update any external references or bookmarks.