This is a good approach, but I could not tell you about how much time is required. It depends on circumstances.
Normally I would use command line “
sudo shutdown -h now”, and this performs a full and normal shutdown. This method of shutdown can be “nice” to applications, but performance during shutdown will depend on what is running. In cases where an UPS (providing about 1 to 5 minutes of run power) is used this would pretty much always be all that you need.
Normally I would consider something known as “Magic SysRq” to be a feature for development or for emergencies, and this provides an ability to perform an emergency sync (of the disk) and remount of the filesystems to read-only. This would not necessarily be as kind to a user space application in the sense of allowing the application to flush its own buffer, but it would pretty much guarantee that whatever is buffered for hard drive write gets written and the filesystem protected in a shorter time than normal shutdown. This could possibly work as a reliable method of protecting the system with 5 seconds of power.
Regarding Magic SysRq, normally a system which has a local keyboard attached can enter certain keystrokes, and these are bound to a debug set of code listening for those keystrokes. These keystrokes tend to work even if much of the system is otherwise failed. For example, if I have a system lock up on me, I might run the following key bindings (“ALT” and “SYSRQ” are actual keys):
# Call sync twice:
# Remount read-only ("u" for "umount" and then read-only mount):
# Force immediate boot (which is ok because we have flushed buffers and switched to read-only):
You won’t have a keyboard, but you can also “echo” combinations into “
/proc/sysrq-trigger” to achieve the same effect. The history is that people using kernel debuggers over a serial UART do not have access directly to a keyboard, but need to stop and start the kernel or enter different modes (check out KGDB and KGDBOC), and
sysrq-trigger is used for this. Stopping a kernel or starting it for a debugger is not particularly different from stopping or starting parts of the kernel due to a bug or other failure.
Note that for security purposes one has to be user
sudo) to work on this, and that different parts of Magic SysRq can be enabled or disabled through a mask. To see current settings:
If the value is “
1”, then all Magic SysRq which is supported by that CPU will be allowed (a desktop x86 PC might have different options than an ARM64 CPU). If the value is not “
1”, then you can add the configuration to enable this from “
/etc/sysctl.conf” (not normally required on a Jetson, but if the value is not “
1”, then edit this in):
1" enables all functions because it is a mask…different bits being off will have a value of other than “
1”, and will disable functions from bits which are not “
Different software releases might or might not default to “
1” in “
cat /proc/sys/kernel/sysrq”, and so if you worry about one release behaving differently, then you could enable this in “
/etc/sysctl.conf” even if it is not technically required.
Note that whenever you flush a buffer to solid state memory you are producing “wear”. The more often you sync (“flush”) the lower the lifetime is for your solid state memory. It certainly is not going to change the life to sync right before a shutdown since normal shutdown would do this anyway, and testing this a few times also is not going to wear this out any more than shutting down and restarting would. Just don’t overuse sync.
The reason for using sync twice is because no disk will guarantee that just because the sync has begun that the sync will have actually completed before forcible loss of power. A while back @snarky mentioned that the second sync will not complete if the first sync is still in progress…the second sync returning implies the first sync actually finished its buffer right (versus simply starting the buffer flush). Following this by the forcible remount to read-only is your best bet. Once that read-only state is enabled you can cut power any time you want and there will be no filesystem corruption issues.
There are other ways to do this, but the Magic SysRq was designed to run in emergency situations, and you wouldn’t need to invent new code. This is probably the fastest way to go read-only. You could use an actual keyboard to input those commands, or even a bash script, and see how much time it takes to complete remount to read-only. Make sure to test when any application you have which writes to disk is actually writing…if nothing is writing at the time of the remount read-only, then you will always get a fast response to remount.
Note: There are also Magic SysRq commands to kill processes other than init…this could cause programs which normally write to terminate, and then follow this with sync and there would be less worry about some process doing a lot of writing in the middle of calling sync since those processes would have ended.