| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 48:09:33 |
| Calls: | 422 |
| Files: | 1,024 |
| Messages: | 90,421 |
Note: the "shutdown" command belongs the package "sysvinit"
and probably has been replaced within the junk Systemd that
has grabbed the balls of most, but not all (and certainly
not mine), GNU/Linux distros.
As I said, I feel very sorry for the helpless distro lackey.
There are cases where systemd systems can have shutdown installed but it doesn't work. I don't recall how it happened, but I borked something and
got systemd error messages out of the shutdown command.
One I have saved (from 2016) looks like this:
# shutdown -r now
Failed to start reboot.target: Failed to activate service 'org.freedesktop.systemd1': timed out
See system logs and 'systemctl status reboot.target' for details.
Failed to open /dev/initctl: No such device or address
Failed to talk to init daemon.
# systemctl status reboot.target
Failed to get properties: Connection timed out
#
# systemctl status reboot.target
Failed to get properties: Connection timed out
#
Just having a look at what your above situation might be about:
root@theon:~ # ls -l /dev/initctl
lrwxrwxrwx 1 root root 12 Apr 13 17:40 /dev/initctl -> /run/initctl
So this is a named pipe used for communicating with init. Why would it
be deleted? Because there is no way to stop the init process without
bringing down your system (pid 1 is special that way). Perhaps
something else deleted the pipe. If it was just the symlink that was
removed, it should have been possible to put it back.
I've been using Linux since about the same time as you, but Unix before
then. I have systems with and without systemd and there are pluses and minuses.
Someone suggeted "magic sysrq keys" as an alternative way to shutdown
the system, but what a mess.
https://en.wikipedia.org/wiki/Magic_SysRq_key
I don't remember if I ever used sync; sync; halt
on linux, but certainly on older *nixes
Eli the Bearded wrote:
I've been using Linux since about the same time as you, but Unix before
then. I have systems with and without systemd and there are pluses and
minuses.
I don't remember if I ever used sync; sync; halt
on linux, but certainly on older *nixes
On Fri, 18 Apr 2025 12:27:25 +0200, Marc Haber
<mh+usenetspam1118@zugschl.us> wrote in <vtt9ee$heug$1@news1.tnib.de>:
Farley Flud <ff@linux.rocks> wrote:
Just checked the man page for shutdown(8), and it says it was
added to systemd 250. It supports the timespec and wall parameters,
but I'm not sure how well...
Anyway, I'm running 255 on Linux Mint 22.1, which
seems to have been pulled in from the System76 repo that I use:
$ systemd --version
systemd 255 (255.4-1ubuntu8.6pop0~1742486928~24.04~40a1bd7~dev)
[...]
You don't get file system corruption, but databases will not be
guaranteed to be happy.
On Fri, 18 Apr 2025 08:53:05 +0100, Andy Burns wrote:
I don't remember if I ever used sync; sync; halt
on linux, but certainly on older *nixes
The need for multiple “sync” calls was a bit of voodoo black magic leftover from a bug/misfeature in early Unix kernels.
I don’t think it’s ever been necessary on Linux.
On 2025-04-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 18 Apr 2025 08:53:05 +0100, Andy Burns wrote:
I don't remember if I ever used sync; sync; halt
on linux, but certainly on older *nixes
The need for multiple ???sync??? calls was a bit of voodoo black magic
leftover from a bug/misfeature in early Unix kernels.
I don???t think it???s ever been necessary on Linux.
The story I heard was that typing "sync" three times takes long
enough that the system has time to flush all its buffers before
you do anything else.
On 2025-04-19, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
On 2025-04-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 18 Apr 2025 08:53:05 +0100, Andy Burns wrote:
I don't remember if I ever used sync; sync; halt
on linux, but certainly on older *nixes
The need for multiple “sync” calls was a bit of voodoo black magic
leftover from a bug/misfeature in early Unix kernels.
I don’t think it’s ever been necessary on Linux.
The story I heard was that typing "sync" three times takes long enough
that the system has time to flush all its buffers before you do
anything else.
But sync shouldn't return until the buffers have flushed.
So repeats are not needed.
On 2025-04-19, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
The story I heard was that typing "sync" three times takes long
enough that the system has time to flush all its buffers before
you do anything else.
But sync shouldn't return until the buffers have flushed.
So repeats are not needed.
On Linux (or any other sensible platform), with the normal user tools,
no explicit syncs are needed at all. The normal shutdown process takes
care of the whole question
In short there’s no number of syncs that will guarantee your data is all actually on disk.
Richard Kettlewell wrote:
In short there’s no number of syncs that will guarantee your data is
all actually on disk.
Out of idle curiosity, what will guarantee all pending writes are
flushed to disk, apart from shutdown/reboot?
I seem to remember (from decades back) the actual advice was:
$ sync; sleep 10;
Or some suitable sleep period, rather than multiple sync;
If they can do it for shutdown, presumably this is some method,
some acknowledgement?
"mount -o ro /deb/sda3" should do the first part during normal
operation too
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives to >> have
their own cache.
Not at all. There is a huge speed improvement.
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives to have
their own cache.
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush all
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives to >>> have
their own cache.
Not at all. There is a huge speed improvement.
those caches on power off.
On 2025-04-22 11:03, The Natural Philosopher wrote:
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush all
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>>> to have
their own cache.
Not at all. There is a huge speed improvement.
those caches on power off.
Or power off by command, not pulling the cable.
On 2025-04-22 11:03, The Natural Philosopher wrote:
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush all
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>>> to have
their own cache.
Not at all. There is a huge speed improvement.
those caches on power off.
Or power off by command, not pulling the cable.
On 22/04/2025 10:27, Carlos E.R. wrote:
On 2025-04-22 11:03, The Natural Philosopher wrote:The reason you pull the cable is
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush all
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself, >>>>>> making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>>>> to have
their own cache.
Not at all. There is a huge speed improvement.
those caches on power off.
Or power off by command, not pulling the cable.
(i) the electricity company did it for you
(ii) the power off button/command didn't work.
(iii) There was no swap left and you couldn't even log in to issue the shutdown command
On 4/22/25 12:13, The Natural Philosopher wrote:
On 22/04/2025 10:27, Carlos E.R. wrote:
On 2025-04-22 11:03, The Natural Philosopher wrote:The reason you pull the cable is
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself, >>>>>>> making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>>>>> to have
their own cache.
Not at all. There is a huge speed improvement.
all those caches on power off.
Or power off by command, not pulling the cable.
(i) the electricity company did it for you
(ii) the power off button/command didn't work.
(iii) There was no swap left and you couldn't even log in to issue the
shutdown command
My Orange Pi 5 freezes all the time. I don't know if the power off
button is any better than pulling the power cable.
One thing I have been pondering, is a hardware heartbeat.
I vaguely
remember reading that such a thing exists. I wondered if it was possible
to hang a clean-up routine off it. i.e if something stops the heartbeat
try to flush writes to disk, before the power reset.
It is probably aSomething has to reset the heartbeat. You need a loop and sleep that
stupid idea, because by the time the computer was frozen enough to
prevent the heartbeat, it is probably too sick to run any clean-up code, and/or the pending disk writes may still leave the disk in an
inconsistent state.
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:Not at all. There is a huge speed improvement.
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>> to have
their own cache.
The key is to have a large enough capacitor in the drive to flush all
those caches on power off.
... I think it’s a dumb idea for drives to have their own cache.
Not at all. There is a huge speed improvement.
Storage devices need _some_ internal buffering, to manage the
relationship between the logical blocks visible to the host device and
the physical storage. If that’s too small then a hard disk risks
spending all its time seeking between tracks rather than actually
reading or writing anything (or some differently structured waste of
time on an SSD).
Storage devices need _some_ internal buffering, to manage the
relationship between the logical blocks visible to the host device and
the physical storage. If that’s too small then a hard disk risks
spending all its time seeking between tracks rather than actually
reading or writing anything (or some differently structured waste of
time on an SSD).
The key is to have a large enough capacitor in the drive to flush all
those caches on power off.
One thing I have been pondering, is a hardware heartbeat. I vaguely
remember reading that such a thing exists.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:Not at all. There is a huge speed improvement.
It sounds like they're talking about the cache in the drive itself,
making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>>> to have
their own cache.
The key is to have a large enough capacitor in the drive to flush all
those caches on power off.
You still need to protect caches and buffers higher up the stack, or (if possible) design your system to be resilient against power failure. (For example, a mail server will only tell an SMTP client that it’s recieved
a message when it’s completed an fsync() on the queue file.)
Storage devices need _some_ internal buffering, to manage the
relationship between the logical blocks visible to the host device and
the physical storage. If that’s too small then a hard disk risks
spending all its time seeking between tracks rather than actually
reading or writing anything (or some differently structured waste of
time on an SSD).
On Tue, 22 Apr 2025 10:35:48 +0200, Carlos E.R. wrote:
... I think it’s a dumb idea for drives to have their own cache.
Not at all. There is a huge speed improvement.
Not as fast as the OS can achieve by caching things in main RAM.
Remember, the on-drive cache is on the wrong side of an interface (SATA,
NVME etc) that is not designed to run at main RAM speeds. Whereas the interface between CPU and main RAM is. That’s why on-drive cache is a
waste of time.
On 22/04/2025 12:38, Pancho wrote:
On 4/22/25 12:13, The Natural Philosopher wrote:I have herd several tinmes that orange Pis are not as good as raspberry..
On 22/04/2025 10:27, Carlos E.R. wrote:
On 2025-04-22 11:03, The Natural Philosopher wrote:The reason you pull the cable is
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself, >>>>>>>> making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for >>>>>>> drives to have
their own cache.
Not at all. There is a huge speed improvement.
all those caches on power off.
Or power off by command, not pulling the cable.
(i) the electricity company did it for you
(ii) the power off button/command didn't work.
(iii) There was no swap left and you couldn't even log in to issue
the shutdown command
My Orange Pi 5 freezes all the time. I don't know if the power off
button is any better than pulling the power cable.
One thing I have been pondering, is a hardware heartbeat.
A watchdog timer?
On 22/04/2025 10:27, Carlos E.R. wrote:
On 2025-04-22 11:03, The Natural Philosopher wrote:The reason you pull the cable is
On 22/04/2025 09:35, Carlos E.R. wrote:
On 2025-04-21 02:29, Lawrence D'Oliveiro wrote:The key is to have a large enough capacitor in the drive to flush all
On 21 Apr 2025 08:24:22 +1000, Computer Nerd Kev wrote:
It sounds like they're talking about the cache in the drive itself, >>>>>> making sure data is physically written out before power-off.
Unfortunately, you could be right.
I say “unfortunately“, because I think it’s a dumb idea for drives >>>>> to have
their own cache.
Not at all. There is a huge speed improvement.
those caches on power off.
Or power off by command, not pulling the cable.
(i) the electricity company did it for you
(ii) the power off button/command didn't work.
(iii) There was no swap left and you couldn't even log in to issue the shutdown command
I thought there's an OOM killer built in to prevent running out of ram?
On 2025-04-23 00:43, Lawrence D'Oliveiro wrote:
On Tue, 22 Apr 2025 10:35:48 +0200, Carlos E.R. wrote:
... I think it’s a dumb idea for drives to have their own cache.
Not at all. There is a huge speed improvement.
Not as fast as the OS can achieve by caching things in main RAM.
Remember, the on-drive cache is on the wrong side of an interface
(SATA, NVME etc) that is not designed to run at main RAM speeds.
Whereas the interface between CPU and main RAM is. That’s why on-drive
cache is a waste of time.
The on drive cache is on the right side to take advantage of the drive
own algorithms to move the head. The firmware takes decisions on where sectors actually are, and what sectors to actually read or write and in
what order. The operating system doesn't have actual knowledge of the internal layout of the disk platters and can not optimize for the actual situation.
On Wed, 23 Apr 2025 19:20:05 -0000 (UTC), candycanearter07 wrote:
I thought there's an OOM killer built in to prevent running out of ram?
The dreaded Linux OOM killer is part of a mechanism where the kernel never says no when processes ask for more RAM. This is configurable.
There are still people who don’t like the way the OOM killer works, even
if its algorithm is well-documented. So they implement their own process killers (e.g. Android) to try to stop things getting to the point where
the kernel itself has to take action.
On Wed, 23 Apr 2025 13:35:14 +0200, Carlos E.R. wrote:
On 2025-04-23 00:43, Lawrence D'Oliveiro wrote:
On Tue, 22 Apr 2025 10:35:48 +0200, Carlos E.R. wrote:
... I think it’s a dumb idea for drives to have their own cache.
Not at all. There is a huge speed improvement.
Not as fast as the OS can achieve by caching things in main RAM.
Remember, the on-drive cache is on the wrong side of an interface
(SATA, NVME etc) that is not designed to run at main RAM speeds.
Whereas the interface between CPU and main RAM is. That’s why on-drive >>> cache is a waste of time.
The on drive cache is on the right side to take advantage of the drive
own algorithms to move the head. The firmware takes decisions on where
sectors actually are, and what sectors to actually read or write and in
what order. The operating system doesn't have actual knowledge of the
internal layout of the disk platters and can not optimize for the actual
situation.
Yes it can. It uses algorithms I previously mentioned -- scatter read,
gather write, elevator seeking -- to assemble together large sequences of
I/O requests, larger than any on-drive cache can handle.
All the on-drive cache can offer is another potential point where things
can go wrong, leading to data loss.
No, it can not. It does not have the access.
Fair enough. As long as those solutions work..
Yes it can. It uses algorithms I previously mentioned -- scatter read,
gather write, elevator seeking -- to assemble together large sequences of
I/O requests, larger than any on-drive cache can handle.
No, it can not. It does not have the access.
On 25/04/2025 22:20, Carlos E.R. wrote:
Yes it can. It uses algorithms I previously mentioned -- scatter read,No, it can not. It does not have the access.
gather write, elevator seeking -- to assemble together large sequences of >>> I/O requests, larger than any on-drive cache can handle.
For SSD, no. SSD is a device that mimics a hard drive with 'sectors'
and 'tracks'.
It *dynamically* (for wear levelling) maps between a 'virtual hard
drive' and its underlying weirdness of flash RAM blocks and pages.
There is nothing the operating system can do to optimise this except
not do multiple writes to a 'sector' if possible.
[Flash storage] *dynamically* (for wear levelling) maps between a
'virtual hard drive' and its underlying weirdness of flash RAM
blocks and pages.
There is nothing the operating system can do to optimise this ...
The reality is that storage devices are in a better position to manage
this than OS kernels are ...
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Fair enough. As long as those solutions work..
Or you could, you know, simply configure your kernel to say “no,
sorry, there’s not enough RAM for that”.
The whole idea of *not* doing that - pretending that resources are
infinite and arbitrarily murdering on the sly to maintain the fiction
- is utterly baffling to me. I'm curious what the rationale is behind
it.
On Fri, 25 Apr 2025 23:15:25 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Or you could, you know, simply configure your kernel to say “no,
sorry, there’s not enough RAM for that”.
The whole idea of *not* doing that - pretending that resources are
infinite and arbitrarily murdering on the sly to maintain the fiction -
is utterly baffling to me. I'm curious what the rationale is behind it.
John Ames <commodorejohn@gmail.com> writes:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Fair enough. As long as those solutions work..
Or you could, you know, simply configure your kernel to say “no,
sorry, there’s not enough RAM for that”.
The whole idea of *not* doing that - pretending that resources are
infinite and arbitrarily murdering on the sly to maintain the fiction
- is utterly baffling to me. I'm curious what the rationale is behind
it.
The choice is between memory allocation failing (generally leading to processes existing or not even starting in the first place) when there
is plenty left due to pessimistic book-keeping, or killing processes
only when you genuinely run out of memory.
The default is overcommit (i.e. the latter). It’s just a default, so if
you don’t like it, you can disable it.
Richard Kettlewell wrote:
The default is overcommit (i.e. the latter). It’s just a default, so
if you don’t like it, you can disable it.
*You* can Richard. Most of the rest of us wouldn't know where to start
:-)
The Natural Philosopher <tnp@invalid.invalid> writes:
Richard Kettlewell wrote:
The default is overcommit (i.e. the latter). It’s just a default, so
if you don’t like it, you can disable it.
*You* can Richard. Most of the rest of us wouldn't know where to start
:-)
Most people have no reason to change the setting, so that works out OK l-)