On Tue 11 Feb 2025 at 23:04:42 (+0700), Max Nikulin wrote: > On 11/02/2025 08:08, David Wright wrote: > > On Mon 10 Feb 2025 at 17:18:34 (-0000), Greg wrote: > > > On 2025-02-10, Max Nikulin wrote: > > > > > > > > I am against suggestions to *kill* applications as well, unless it is > > > > the last resort measure. It increases chance to lost data stored in > > > > browser profile (list of opened tabs, passwords, etc.). > > > > > > If Firefox is killed or crashes I believe you get the 'Restore Session' > > > page instead of the home page when you restart it (i.e. exactly the > > > option to retrieve your open tabs at the moment of the kill or crash). > > Are you killing Firefox just to avoid a couple of extra clicks to open > menu and to select "restore previous session" there?
Your writing "restore previous session" suggests that you're talking about /restarting/ FF, as suggested by Eyal. I never do that, and am not in the habit of monitoring its memory usage either. Leaving aside killing FF if it needs putting out of its misery, I'm talking about when I close down the machine for the night. As I described in last evening's post, I'm unlikely to be looking at FF when I closedown, let alone be actually using it. I don't know whether there are people who "save previous session", if such an option exists, but I've never felt the need. > I hope, the code, > that saves current state to disk, is written having in mind that the > process can crash any time, so some consistent (but may be a bit > obsolete) state may be restored afterwards. I am in doubts if this > scenario is heavily tested (perhaps besides sqlite). Except insofar as I do it most evenings without consequence. AFAICT the current state that's important is held in databases (sqlite, as you say), and AIUI they typically use atomic methods for updating.¹ > From my point of > view, killing a process may noticeably increase a chance to get > corrupted data in comparison to closing the same application. That may be true if you time the kill to when it's busy writing, but that's not likely to be a time when I kill it (unless it's crashing, when it could be doing anything). BTW, I've never checked which signals, if any, are sent to processes when I zap fvwm (which kills the X server). Is it different from clicking on the X and closing the window it's running in? Or quitting with ^Q, or destroying the window? IDK. How do other people stop FF? > > then I zap fvwm and touch > > the power button. (First zapping fvwm avoids occasionally having to > > wait for a 90-second timeout to expire.) > > journalctl usually allows to identify processes causing timeouts. > Perhaps they should be just properly wrapped into systemd user units. I'm not going to boot up again just to look at the logs. Neither is it likely that I'm going to be sufficiently interested the next day to chase it down. So I just prevent the snag from occurring with a zap. On Tue 11 Feb 2025 at 17:05:25 (+0800), Bret Busby wrote: > I would not access the wunderground web site with Firefox. Too destructive. FF is not quick to start with this target, but once the window has mapped on the right viewport, I open mutt and start reading emails before going back to it. Like Roy, I've had no trouble with the site. ¹ It's debatable what is important with this browser. The FF instance I use for financial/governmental business is entirely separate, and after I've concluded whatever I ran it for, I open a new tab, and then close all the tabs (the new one last) so it disappears. Cheers, David.
