[Bug 218266] New: Need article about Linux shutdown process

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218266

            Bug ID: 218266
           Summary: Need article about Linux shutdown process
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: man-pages
          Assignee: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: aralni@mail.ru
        Regression: No

Hi,

I try make correct shutdown (reboot/poweroff) process for applications, but not
find info about it.

There are several opinions about this but none of them are confirmed.

1. You need to process the SIGTERM signal. But no one has been able to do this
successfully in the context of system shutdown. This is a very common belief or
misconception. For example:
https://bugzilla.mozilla.org/show_bug.cgi?id=1837907

2. There is no need to save the data at all - let me get lost. But the system
will turn off faster. http://freepascal.ru/forum/viewtopic.php?f=1&t=43642

These two directions lead to data loss.

3. It is necessary to process the signal from systemd PrepareForShutdown using
dbus. This is a cleaner approach, but more complex and higher level than the
kernel signal. In addition, the program must support dbus, and this may seem
cumbersome.

Some programming languages (the finalization section in Pasal) contain a system
shutdown handler in rtl, while for others this must be separately in each
program.

We need a detailed article (apparently not only in man, but also on the web),
describing in detail for programs and programming languages (at least C and
Pascal) the situation of shutting down the system with working examples.
Otherwise, there is serious confusion, leading to disputes among programmers
and, ultimately, to data loss.

Thank You.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.