When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
poc
On Thu, Aug 22, 2024 at 7:36 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
Use systemd-analyze:
DESCRIPTION systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging.
Patrick O'Callaghan writes:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
There must be a reason, or some kind of a malfunction, that causes that. Unfortunately, this is one of those things for which there is no "press X and push Y to figure out why", paint-by-numbers, recipe for troubleshooting. It's unclear whether you are describing a delay before the reboot actually starts and things start shutting down, or if there's a delay during the subsequent boot. I would take a different approach depending on which is the case here. If there's a hang during boot, it's systemd-analyze time. If there's a delay initiating a reboot the first thing I would try is dropping to a shell, su-ing to root, manually executing "reboot", and then seeing what happens.
On 22 Aug 2024, at 11:36, Patrick O'Callaghan pocallaghan@gmail.com wrote:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
There will be a user service that is being slow to shutdown. You can see which one by pressing ESC to close the splash screen.
However there are some services that will go on for a very long time and hit the TimeoutStop limit.
What I do is set the default timeout shorter to speed up shutdown.
I have these overrides for timeouts:
/etc/systemd/user.conf.d/10-barry.conf [Manager] DefaultTimeoutStopSec=15s
/etc/systemd/system.conf.d/10-barry.conf [Manager] DefaultTimeoutStopSec=20s
Barry
poc
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, 2024-08-22 at 07:15 -0400, Sam Varshavchik wrote:
Patrick O'Callaghan writes:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
There must be a reason, or some kind of a malfunction, that causes that. Unfortunately, this is one of those things for which there is no "press X and push Y to figure out why", paint-by-numbers, recipe for troubleshooting. It's unclear whether you are describing a delay before the reboot actually starts and things start shutting down, or if there's a delay during the subsequent boot. I would take a different approach depending on which is the case here. If there's a hang during boot, it's systemd-analyze time. If there's a delay initiating a reboot the first thing I would try is dropping to a shell, su-ing to root, manually executing "reboot", and then seeing what happens.
Sorry if that wasn't clear. I'm talking about the time between initiating a reboot, either from the Shell or from the GUI, and the actual system going down (either for reboot or shutdown) as determined by the display turning off. During that time I'm looking at a screen with a spinner and the Fedora logo.
poc
On Thu, 2024-08-22 at 12:25 +0100, Barry Scott wrote:
On 22 Aug 2024, at 11:36, Patrick O'Callaghan pocallaghan@gmail.com wrote:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
There will be a user service that is being slow to shutdown. You can see which one by pressing ESC to close the splash screen.
Good idea.
However there are some services that will go on for a very long time and hit the TimeoutStop limit.
What I do is set the default timeout shorter to speed up shutdown.
I have these overrides for timeouts:
/etc/systemd/user.conf.d/10-barry.conf [Manager] DefaultTimeoutStopSec=15s
/etc/systemd/system.conf.d/10-barry.conf [Manager] DefaultTimeoutStopSec=20s
Thanks, I'll take a look at those.
poc
On Thu, 2024-08-22 at 07:57 -0300, George N. White III wrote:
On Thu, Aug 22, 2024 at 7:36 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
Use systemd-analyze:
DESCRIPTION systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging.
Boot up is reasonably fast (actually the firmware take a long time before I get to the boot splash screen but that's a separate issue). My question is about stopping the system prior to shutdown or reboot.
poc
Patrick O'Callaghan writes:
On Thu, 2024-08-22 at 07:15 -0400, Sam Varshavchik wrote:
Patrick O'Callaghan writes:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
There must be a reason, or some kind of a malfunction, that causes that. Unfortunately, this is one of those things for which there is no "press X and push Y to figure out why", paint-by-numbers, recipe for troubleshooting. It's unclear whether you are describing a delay before the reboot actually starts and things start shutting down, or if there's a delay during the subsequent boot. I would take a different approach depending on which is the case here. If there's a hang during boot, it's systemd-analyze time. If there's a delay initiating a reboot the first thing I would try is dropping to a shell, su-ing to root, manually executing "reboot", and then seeing what happens.
Sorry if that wasn't clear. I'm talking about the time between initiating a reboot, either from the Shell or from the GUI, and the actual system going down (either for reboot or shutdown) as determined by the display turning off. During that time I'm looking at a screen with a spinner and the Fedora logo.
All right. So, as I suggested: when you dropped to a shell, su-ed to root, and then typed "reboot", what happened then?
On Thu, 2024-08-22 at 07:48 -0400, Sam Varshavchik wrote:
Sorry if that wasn't clear. I'm talking about the time between initiating a reboot, either from the Shell or from the GUI, and the actual system going down (either for reboot or shutdown) as determined by the display turning off. During that time I'm looking at a screen with a spinner and the Fedora logo.
All right. So, as I suggested: when you dropped to a shell, su-ed to root, and then typed "reboot", what happened then?
I just repeated this in two ways:
1) Logged into KDE, ran 'sudo -i' in a Konsole and typed 'reboot'. Screen went black except for a message saying 'System will reboot now'. Then a 60 second wait until a brief line flashed up (unreadable), screen went black and the reboot started.
2) Didn't log into KDE but switched to another virtual console, logged in as root and typed 'reboot'. This time I got the splash screen (mobo logo, Fedora logo and spinner), then again a 60 second delay and reboot as above.
Evidently something is taking a long time to timeout. I then followed Barry Scott's advice (see his reply) and changed the default timeout values. That seems to have fixed the problem.
poc
On Thu, 2024-08-22 at 12:42 +0100, Patrick O'Callaghan wrote:
I have these overrides for timeouts:
/etc/systemd/user.conf.d/10-barry.conf [Manager] DefaultTimeoutStopSec=15s
/etc/systemd/system.conf.d/10-barry.conf [Manager] DefaultTimeoutStopSec=20s
Thanks, I'll take a look at those.
That seems to have worked, thanks.
poc
On 8/22/24 5:36 AM, Patrick O'Callaghan wrote:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
Hey, Patrick -
You probably already know this but... When the system is shutting down, if you hit the escape key, it will change from graphical to text mode. You should be able to see what it's hung doing while shutting down.
On Thu, Aug 22, 2024 at 8:44 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Thu, 2024-08-22 at 07:57 -0300, George N. White III wrote:
On Thu, Aug 22, 2024 at 7:36 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
When I reboot the system, there's a delay of around a minute before anything happens. This is a single-user desktop and I really don't need to stare at a spinner for so long. Is there a setting somewhere that lets me change this? I'm aware of 'reboot -f' but I assume that would normally be too drastic.
Use systemd-analyze:
DESCRIPTION systemd-analyze may be used to determine system boot-up performance statistics and retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging.
Boot up is reasonably fast (actually the firmware take a long time before I get to the boot splash screen but that's a separate issue). My question is about stopping the system prior to shutdown or reboot.
So you want to "retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging."
The web has some examples using systemd-analyze to investigate shutdown issues.
I always had long reboots as well, then I realized I'm not running anything like a database that needs to be properly flushed to disk, etc. So I changed DefaultTimeoutStopSec from 90 seconds to 5 seconds in /etc/systemd/system.conf and /etc/systemd/user.conf and now my system reboots fairly quickly. It still wastes time spinning up a USB drive that isn't mounted (no idea why).
On Thu, 2024-08-22 at 11:24 -0400, Tom Horsley wrote:
I always had long reboots as well, then I realized I'm not running anything like a database that needs to be properly flushed to disk, etc. So I changed DefaultTimeoutStopSec from 90 seconds to 5 seconds in /etc/systemd/system.conf and /etc/systemd/user.conf and now my system reboots fairly quickly. It still wastes time spinning up a USB drive that isn't mounted (no idea why).
That's essentially what I did.
I also get the long wait for USB (an external dock in my case). AFAIK it happens before the kernel boot sequence runs, because there are some flashing lights from the dock before the Grub menu appears. There might be a way of disabling it in the UEFI but I haven't figured it out yet.
poc
On Thu, 2024-08-22 at 11:28 -0300, George N. White III wrote:
So you want to "retrieve other state and tracing information from the system and service manager, and to verify the correctness of unit files. It is also used to access special functions useful for advanced system manager debugging."
I haven't changed any unit files other than the default timeouts mentioned in another reply, which fixed the issue.
The web has some examples using systemd-analyze to investigate shutdown issues.
I'll take a look for future reference.
poc
On Thu, 2024-08-22 at 07:15 -0400, Sam Varshavchik wrote:
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
Although that pretty much describes what I see on a friend's iMac. When you go to shutdown, there's a warning and a countdown before it does. With a button to skip waiting and do it now.
My friend had been waiting for it to close down, needlessly for a very long time (before I saw it), he thought it was actually doing something and shouldn't be interrupted. But it was a merely an "are you sure?" prompt, stopping whoopsies and allowing you to (manually) save something you mightn't have before it shuts down. It's just sitting there counting down, doing nothing.
Sam Varshavchik wrote:
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
Tim:
Although that pretty much describes what I see on a friend's iMac. When you go to shutdown, there's a warning and a countdown before it does. With a button to skip waiting and do it now.
For the purposes of clarity, this is MacOS on a Mac. But just pointing out that computer programmers often do things that don't make much sense (the lack of explanation of why you're waiting).
On 8/22/24 15:18, Thomas Cameron wrote:
You probably already know this but... When the system is shutting down, if you hit the escape key, it will change from graphical to text mode. You should be able to see what it's hung doing while shutting down.
Unfortunately somebody thinks that showing a useless spinning logo is more "elegant" than letting the user understand what's (mis)happening. People do not even know they have to press esc to see things.
Regards.
On Fri, Aug 23, 2024 at 7:31 AM Roberto Ragusa mail@robertoragusa.it wrote:
On 8/22/24 15:18, Thomas Cameron wrote:
You probably already know this but... When the system is shutting down,
if you hit
the escape key, it will change from graphical to text mode. You should be able to see
what it's hung doing while shutting down.
Unfortunately somebody thinks that showing a useless spinning logo is more "elegant" than letting the user understand what's (mis)happening. People do not even know they have to press esc to see things.
A lot of work has gone towards default configurations intended for large deployments of systems with pre-installed Fedora and users who leave problems to their IT group. I'm fine with that as I will probably buy one of those systems from a reseller in a few years.
If you want to "see things", remove the `rhgb quiet` from the kernel command-line.
Ralf Corsépius composed on 2024-08-23 14:01 (UTC+0200):
schrieb George N. White III:
If you want to "see things", remove the `rhgb quiet` from the kernel command-line.
Also, consider to set the plymouth-theme to "detail" (cf. man plymouth-set-default-theme)
Or take the green route, purge *plymouth* from your Fedora system.
On Fri, 2024-08-23 at 12:30 +0200, Roberto Ragusa wrote:
Unfortunately somebody thinks that showing a useless spinning logo is more "elegant" than letting the user understand what's (mis)happening. People do not even know they have to press esc to see things.
Doesn't have that cool hacker vibe. Needs elevator music to go along with it (imagining The Girl from Ipanema, right now, from the elevator scene where the Blues Brothers go to pay the taxes owed on the orphanage just before they get arrested).
On Fri, Aug 23, 2024 at 1:36 AM Tim via users users@lists.fedoraproject.org wrote:
Sam Varshavchik wrote:
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
Tim:
Although that pretty much describes what I see on a friend's iMac. When you go to shutdown, there's a warning and a countdown before it does. With a button to skip waiting and do it now.
For the purposes of clarity, this is MacOS on a Mac. But just pointing out that computer programmers often do things that don't make much sense (the lack of explanation of why you're waiting).
Back in time, there was only 'shutdown'. And it had a default timeout of 5 minutes to allow the shutdown message to be delivered and seen by all the users so that they could gracefully end their edit sessions, etc. before the machine stopped.
At some point 'halt/halt' and 'reboot' were added.
But 'shutdown' provided all the housekeeping work such as: - disabling logins - sending out messages to users screen warning them of the impending doom - providing grace time - unmounted file systems - killed the system
On Sun, 2024-08-25 at 10:17 -0400, Fulko Hew wrote:
On Fri, Aug 23, 2024 at 1:36 AM Tim via users users@lists.fedoraproject.org wrote:
Sam Varshavchik wrote:
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
Tim:
Although that pretty much describes what I see on a friend's iMac. When you go to shutdown, there's a warning and a countdown before it does. With a button to skip waiting and do it now.
For the purposes of clarity, this is MacOS on a Mac. But just pointing out that computer programmers often do things that don't make much sense (the lack of explanation of why you're waiting).
Back in time, there was only 'shutdown'. And it had a default timeout of 5 minutes to allow the shutdown message to be delivered and seen by all the users so that they could gracefully end their edit sessions, etc. before the machine stopped.
At some point 'halt/halt' and 'reboot' were added.
But 'shutdown' provided all the housekeeping work such as:
- disabling logins
- sending out messages to users screen warning them of the impending
doom
- providing grace time
- unmounted file systems
- killed the system
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
poc
On Sun, Aug 25, 2024 at 10:40 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2024-08-25 at 10:17 -0400, Fulko Hew wrote:
On Fri, Aug 23, 2024 at 1:36 AM Tim via users users@lists.fedoraproject.org wrote:
Sam Varshavchik wrote:
I find it highly improbable that there is a "delay reboot for X minutes for no reason whatsoever" setting somewhere, that simply needs to be changed. As Mr. Spock would say: "this is not logical".
Tim:
Although that pretty much describes what I see on a friend's iMac. When you go to shutdown, there's a warning and a countdown before it does. With a button to skip waiting and do it now.
For the purposes of clarity, this is MacOS on a Mac. But just pointing out that computer programmers often do things that don't make much sense (the lack of explanation of why you're waiting).
Back in time, there was only 'shutdown'. And it had a default timeout of 5 minutes to allow the shutdown message to be delivered and seen by all the users so that they could gracefully end their edit sessions, etc. before the machine stopped.
At some point 'halt/halt' and 'reboot' were added.
But 'shutdown' provided all the housekeeping work such as:
- disabling logins
- sending out messages to users screen warning them of the impending
doom
- providing grace time
- unmounted file systems
- killed the system
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Then you can simply use 'shutdown now'.
On Sun, 2024-08-25 at 10:48 -0400, Fulko Hew wrote:
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Then you can simply use 'shutdown now'.
I don't want to shutdown. I want to reboot, but allow a shorter timeout than the default.
This has now been solved.
poc
On Sun, Aug 25, 2024 at 11:08 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2024-08-25 at 10:48 -0400, Fulko Hew wrote:
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Then you can simply use 'shutdown now'.
I don't want to shutdown. I want to reboot, but allow a shorter timeout than the default.
This has now been solved.
Sorry, I was just addressing the shutdown comment.
Even so, there would be 'shutdown -r now'.
and replace 'now' with the amount of time you wanted to wait.
On Sun, 2024-08-25 at 11:14 -0400, Fulko Hew wrote:
On Sun, Aug 25, 2024 at 11:08 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2024-08-25 at 10:48 -0400, Fulko Hew wrote:
Same here. However these are reasonable measures on a multi- user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Then you can simply use 'shutdown now'.
I don't want to shutdown. I want to reboot, but allow a shorter timeout than the default.
This has now been solved.
Sorry, I was just addressing the shutdown comment.
Even so, there would be 'shutdown -r now'.
and replace 'now' with the amount of time you wanted to wait.
Thanks.
poc
On Sun, 2024-08-25 at 16:48 +0100, Patrick O'Callaghan wrote:
On Sun, 2024-08-25 at 11:14 -0400, Fulko Hew wrote:
On Sun, Aug 25, 2024 at 11:08 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2024-08-25 at 10:48 -0400, Fulko Hew wrote:
Same here. However these are reasonable measures on a multi- user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Then you can simply use 'shutdown now'.
I don't want to shutdown. I want to reboot, but allow a shorter timeout than the default.
This has now been solved.
Sorry, I was just addressing the shutdown comment.
Even so, there would be 'shutdown -r now'.
and replace 'now' with the amount of time you wanted to wait.
Thanks.
Just one further comment: the 'time' argument for shutdown is hours:minutes, so the minimum would be 1 minute. As the default for reboot is already 60 seconds and it doesn't take a time argument, adjusting the DefaultTimeoutStopSec value in a special systemd config file is the only option.
poc
On 25 Aug 2024, at 15:17, Fulko Hew fulko.hew@gmail.com wrote:
Back in time, there was only 'shutdown'. And it had a default timeout of 5 minutes to allow
Yeah back 15 or more years ago...
That 5 mins is the delay before starting the shutdown.
What POC want to avoid is the slow progress of shutdown once it's been started.
Barry
Fulko Hew:
But 'shutdown' provided all the housekeeping work such as:
- disabling logins
- sending out messages to users screen warning them of the impending
doom
- providing grace time
- unmounted file systems
- killed the system
Patrick O'Callaghan:
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Things really oughta order unmounts, unmounts should happen pretty quickly, be flagged as done, and the progress of shutting down be monitored. Not, order unmounts, wait some time, and assume it worked. Likewise for various other shutdowns.
Things may have terminated almost instantly without issues, things may have jammed and it still wouldn't have waited long enough. If something sticks you really ought to be prompted about it. If you don't have network mounts, databases running, mail servers currently dealing with a queue, etc, I see no excuses for prolonged shutdowns.
On Mon, 2024-08-26 at 13:23 +0930, Tim via users wrote:
Fulko Hew:
But 'shutdown' provided all the housekeeping work such as:
- disabling logins
- sending out messages to users screen warning them of the
impending doom
- providing grace time
- unmounted file systems
- killed the system
Patrick O'Callaghan:
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Things really oughta order unmounts, unmounts should happen pretty quickly, be flagged as done, and the progress of shutting down be monitored. Not, order unmounts, wait some time, and assume it worked. Likewise for various other shutdowns.
Things may have terminated almost instantly without issues, things may have jammed and it still wouldn't have waited long enough. If something sticks you really ought to be prompted about it. If you don't have network mounts, databases running, mail servers currently dealing with a queue, etc, I see no excuses for prolonged shutdowns.
+1
poc
On Sun, Aug 25, 2024 at 11:55 PM Tim via users users@lists.fedoraproject.org wrote:
Fulko Hew:
But 'shutdown' provided all the housekeeping work such as:
- disabling logins
- sending out messages to users screen warning them of the impending
doom
- providing grace time
- unmounted file systems
- killed the system
Patrick O'Callaghan:
Same here. However these are reasonable measures on a multi-user system. On a single-user desktop they just get in the way, especially with journal-based filesystems.
Things really oughta order unmounts, unmounts should happen pretty quickly, be flagged as done, and the progress of shutting down be monitored. Not, order unmounts, wait some time, and assume it worked. Likewise for various other shutdowns.
Things may have terminated almost instantly without issues, things may have jammed and it still wouldn't have waited long enough. If something sticks you really ought to be prompted about it. If you don't have network mounts, databases running, mail servers currently dealing with a queue, etc, I see no excuses for prolonged shutdowns.
I think part of the problem is the behavior of sync(8) and sync(2) (which the sync command uses) are poorly specified.[1,2] The man pages don't even clearly state whether the command or api call block or return immediately. If it blocks until complete, then the sync family are synchronous; if they return immediately they are asynchronous. If the sync family is asynchronous (returns immediately), then a script will need to insert sleeps in hopes there's enough time for the write-backs to get done.
The sync(2) man page does say this:[2]
According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)
But that leaves additional questions since the wait or blocking appears to be an incomplete wait.
[1] https://linux.die.net/man/8/sync [2] https://linux.die.net/man/2/sync
Jeff
On 26 Aug 2024, at 14:38, Jeffrey Walton noloader@gmail.com wrote:
I think part of the problem is the behavior of sync(8) and sync(2)
Sync is not used on shutdown. It is the action of umount that causes all data to be flushed out to the disk. As you say that may take a while if the disk is slow, USB, or has just had a huge amount of data written to it just before shutdown us triggered.
However it has always been user services that are slow to exit, and often are timed out, that are the cause of slow shutdowns in my experience.
Barry
On Tue, 2024-08-27 at 08:01 +0100, Barry wrote:
Sync is not used on shutdown. It is the action of umount that causes all data to be flushed out to the disk. As you say that may take a while if the disk is slow, USB, or has just had a huge amount of data written to it just before shutdown us triggered.
However it has always been user services that are slow to exit, and often are timed out, that are the cause of slow shutdowns in my experience.
I used to get the impression that some user things don't pay any attention to being told to shutdown.
A long time ago the biggest pain I had when trying to get something to shutdown, but couldn't, was when something had started swapping. That was usually a web browser which had suddenly barfed on some badly designed website, or one with badly encoded video streaming content.
I would still get something similar back in Fedora 36 era with some badly encoded video MPEG files. Suddenly the player would start making a mess on the screen, and if you weren't quick enough to kill the player immediately you might have to pull the power plug out to stop it.
-
Andy Paterson -
Barry -
Barry Scott
-
Felix Miata -
Fulko Hew -
George N. White III -
Jeffrey Walton -
Patrick O'Callaghan -
Ralf Corsépius -
Roberto Ragusa -
Sam Varshavchik -
Thomas Cameron -
Tim -
Tom Horsley