Home / server / Questions / 115069
In Process
Amos Shapira
Asked: 2010-02-22 00:05:30 +0800 CST

Is execution of sync(8) still required before shutting down linux?

  • 772

I still see people recommend use of sync; sync; sync; sleep 30; halt incantations when talking about shutting down or rebooting Linux.

I've been running Linux since its inception and although this was the recommended procedure in the BSD 4.2/4.3 and SunOS 4 days, I can't recall that I had to do that for at least the last ten years, during which I probably went through shutdown/reboot of Linux maybe thousands of times.

I suspect that this is an anachronism since the days that the kernel couldn't unmount and sync the root filesystem and other critical filesystems required even during single-user mode (e.g. /tmp), and therefore it was necessary to tell it explicitly to flush as much data as it can to disk.

These days, without finding the relevant code in the kernel source yet (digging through http://lxr.linux.no and google), I suspect that the kernel is smart enough to cleanly unmount even the root filesystem and the filesystem is smart enough to effectively do a sync(2) before unmounting itself during a normal shutdown/reboot/poweorff.

The "sync; sync; sync" is only necessary in extreme cases where the filesystem won't unmount cleanly (e.g. physical disk failure) or the system is in a state that only forcing a direct reboot(8) will get it out of its freeze (e.g. the load is too high to let it schedule the shutdown command).

I also never do the sync procedure before unmounting removable devices, and never hit a problem.

Another example - Xen allows the DomU to be sent a shutdown command from the Dom0, this is considered a "clean shutdown" without anyone having to login and type the magical sync; sync; sync first.

Am I right or was I lucky for a few thousands of system shutdowns?

synchronization filesystems

5 Answers

  1. The reason people would run sync; sync before a halt is because the halt command wouldn't shutdown the system cleanly on older linuxes. The correct way to do this on SYSVr4 systems has always be to tell init to move to a different run level.

    BSD and SunOS 4 aren't SYSVr4 operating systems which is why they differ. Solaris (SunOS 5) is SYSVr4 and Linux picks out bits of the SYSVr4 standard that it wants to use.

    Using halt is actually a pretty bad way of doing it on most UNIXes (Linux being one of the exceptions) since it doesn't actually run through the init scripts to perform things like stopping processes and unmounting disks - it just stops the processor.

    If you can guarantee that you'll never ever, ever use any kind of UNIX system than Linux then you can keep using halt - if there's a chance you're going to use other UNIXes then I'd recommend getting into the habit of using init _runlevel_ or shutdown.

    The shutdown command actually tells the init process to change its run level run level - in doing so init then proceeds to run each of the K* init scripts and S* init scripts associated with that run level. One of the scripts in run-level 0 performs the unmounting of the filesystems.

    On Linux the halt command just calls the shutdown command unless the run level is already 0 (shutting down) or 6 (rebooting) anyway; so no loss there.

    The act of unmounting a filesystem using umount will sync the data to the disk before it unmounts it.

    If you've been running sync; sync; halt on Linux you'll have been okay with the filesystem state because the developers have ensured that halt does the right thing; however it would be more correct to use: shutdown now

    • 18

  2. I can only speak to why you would issue sync multiple times. The command schedules the flush to disk but returns before the actual flush completes. Any subsequent sync command will block until any outstanding flush is in progress before scheduling another flush and exiting. Therefore, sync; sync ensures a synchronous flush. You do not need to do it more than 2 times, nor bring sleep into the mix.

    • 9

  3. The use of multiple sync calls was to allow the OS and disks time to flush the write queues. "sync; sync; sync" wasn't considered that useful; one did "sync<cr> sync<cr> sync<cr" and the delay while your ASR-33 did the carriage return/newline provided enough delay. Halt always did call sync; the question was whether there would be enough time to flush the queues before power was removed.

    The original poster's sync; sleep 30 is more in keeping with what was intended.

    • 8

  4. Those of you telling us all that "sync;sync;sync" has no purpose are revealing your age.

    Back in the good ol' days, before Unix was something for teenagers, we used to have to use TAPE for our streaming/backup needs. Often-times, we'd mount a tape-based filesystem to stream backups to, and so on. This one long thin band of magnetic plastic tape was all some of us had, to store our files on ..

    The 'sync;sync;sync' command was a way that these old tape machines could be told to rewind themselves all the way to the end (before shutdown) - they had firmware on board that would receive the sync cmd (like all good filesystems do), and if it was followed almost immediately by two more sync buffer commands, the tape drive itself would interpret this to mean "rewind the tape and unmount it". There wasn't any way to tell the tape drive to rewind, beyond this method, and it sort of stuck .. This habit then passed on into the word when hard drives became more available - us crusty old operators don't just realloc() our muscle memory you know! I believe it achieved folklore status soon after tapes become less common and hard-drives became more available, but it still has its uses for those of us with tape drives.

    • 4

  5. If your system is degenerate (such as /bin/sh is init) the ancient behavior reappears. halt will see that it doesn't know the runlevel and can't command a runlevel change and actually issue a halt system call and bring the system down immediately. However, sync is synchronous now (and has been since at least 2000) and you don't need to run it multiple times.

    In all other cases, issuing sync before halt doesn't do anything useful. This is a case of remembering your training but not the why behind it. On a normal system, there are background jobs, so sync;sync;sync;halt would not have worked had halt brought the system down immediately.

    • 0