What generally happens at the first boot following an update that requires a restart?
I’m asking because I have an application that I’ve been slowly building for the past couple years that uses SQLite, and when it first loads it runs several queries to restore the previous session. I’ve placed timeout “catches” around those queries and they’re never reached unless I’ve made a coding error.
The mose recent update moved from SQLite 3.46.1 to 3.47.1; and, when I shutdown and rebooted, all was slow. Even just loading KDE. Then my queries started timing out.
I shutdown (not a restart) and turned it on again, and the result was the same.
That was about 2 AM; so, I left it for morning, assuming that the issue was a change in SQLite, such as a change in an optimization alogrithm that had a negative effect on one or more of my queries. (It’s happened before.)
However, when I booted up today from hibernation, everything is fast again–the system and the queries in my application; and all has been working well for the past three or four hours since.
My question is, Why? Does it take some time for the system to “complete” the updates after the initial restart and, if so, how can it be known when that has finished?
Thank you.
Running KDE and the 6.11.10-2 kernel on an HP EliteDesk 800 G3 SFF, and X11.
And all the updates from this most recent one and the previous larger one appeared to go well without any issues.
Updates are (typically) not applied to running processes. A restart of thoses processes or better a reboot is needed to fully apply the related changes. An updated kernel (or changed initramfs) is getting activated only after a reboot. Some updates run at bootup and will be staged for the next reboot.
That seems consistent with recent experience of only a few times following an update that the whole system seemed sluggish and I just rebooted a time or two and it was fast again.
Overall, it was a good thing for me to see how my application’s error handling strategy works in a non-fabricated test. I realize now that session restore must be all or nothing because the UI and the database will be out-of-sync if try to just restore for those queries that did not time out; but that’s not the question/topic here.
It must be stressed that this does not mean that some piece of pacman/pamac is holding packages and waiting to apply them until the next reboot.
They are applied already - but the version currently running before reboot is that still in memory.
(Your version of /etc/some/file on disk will already be the new version before the reboot.)
I’m confused what that means exactly. I understand that the files required for update are all written to disk at the time of the update. I use the GUI most of the time and when it says it’s done, I assume all the necessary files have been written.
What I’m not clear on is when those files are applied: always on a restart or is a shutdown/reboot required? And especially, when a reboot is required, is the remaining update work done by the time I can log in or could it be running in the background after logging in?
If something cannot be running after logging in then I don’t understand why there are times when the machine is slow for awhile after rebooting following an update and then speeds up to normal on another reboot or even after a hibernation.
I recall, when using Windows OS, that after an update and reboot the fan would run on high for awhile without doing anything but logging in. I found a process name that I don’t recall and looked it up, and it apparently ran to finish applying updates. I would just let it sit for about half and hour until the fan stopped.
I never experienced that on Manjaro; in fact, I hardly ever hear the fan run but there have been those few times when it appears that the system is working on something in the background and makes the software run slower for a period after an update.
With Linux, you aren’t forced to stop work to update. You can open KWrite and start writing, then apply updates (maybe KWrite will go up a version).
However, KWrite will keep running (the version you loaded BEFORE the update) and you won’t see the NEW version until you quit and reload Kate.
This is most obvious with Firefox, if you try to open a new tab - it will demand a restart to continue (i.e. it won’t load the new binary until you quit the application).
Updates are applied to disk, not to RAM.
I hope that’s clearer.
Sure, while your ‘game v1.1’ is running, you update and have ‘game v1.2’ on disk - you can still be playing with v1.1 and won’t actually run v1.2 until you quit and load from disk.
If you’re not busy working, this is a huge bonus - nobody’s gonna force you to quit and reboot.
This is different with the Kernel, where logging out/in again won’t cut it - you need to reboot. It’s worth opening your Manjaro Settings and opening the Kernel section there to see the list, whether you should select a new one, remove an EOL kernel, or select an LTS or whatever.
Does that mean, then, that if I update, shutdown completely, turn the machine on, and log-in, all the updating steps have definitely completed?
Or is it reasonable to experience instances when the system is sluggish for awhile in this scenario or until a second reboot?
Please understand that I’m not trying to start an argument but just wonder if I might be doing something wrong when updating that causes this to occur.
I almost always shutdown rather than restart just to make sure it is a full reboot; and still experience that sluggish behavior at times. And that is not only in the applicatoin I’ve been building but in the system in general. And after a short time or another reboot it’s very fast again.
The sluggishness you are experiencing may actually be nothing to do with updates.
Plasma can be sluggish upon login if the kactivitymanagerd database has grown excessively large, especially if it has been some time between logins.
The kactivitymanagerd keeps track of things such as your recently viewed files etc. From the kactivitymanagerd readme:
KActivities provides the infrastructure needed to manage a user’s activites, allowing them to switch between tasks, and for applications to update their state to match the user’s current activity. This includes a daemon, a library for interacting with that daemon, and plugins for integration with other frameworks.
The kactivitymanagerd database is located in the ~/.local/share/kactivitymanagerd/resources/ directory.
I recall that earlier this year my kactivitymanagerd database was several hundred MB in size, and it was really slowing down Plasma after logging in whenever I rebooted.
So, I cleared my history in System Settings => Security & Privacy => Recent Files, and changed the setting to only keep history for 3 months. The size of my kactivitymanagerd database has since then grown to 75.9 MB - a lot smaller than it was before I cleared the history and changed the settings.
Thanks. I just checked that and the SQLite database there is 29.1 MB and I’ve had this machine since August 2022. I’m likely a relatively light user in that, although I work a lot, I use only a few applications.
However, I just thought that I started using two desktops which I never did before and recently changed System Settings => Session, Session Restore to “On last logout”. Perhaps that causes it to store more information and slows down a log-in. I haven’t got that to work very well though.
I just made that change in System Settings and will see what happens at the next “big” update.
Yes - even assuming everything was perfect, it would slow down login, and would require things to be ‘put back in place’ … because you are restoring your previous session.
It would have little to do with updates except that
there have been recent bugs directly tied to saved sessions
if there were upgrades to the applications you left open in the previous session - I honestly dont know how that is handled, and may be down to each application in question, but it might add extra complexities to the tasks associated with restoration.