On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 3:02 a.m., Roger Price wrote:
The "low limit" is not detected on the Linux box. Did it crash?
How are you viewing that? I didn't see much in dmesg and I don't see any files that refer to system log. Even doing a google search doesn't turn up much.
I used the command journalctl -b -1 -n 14 but I was sitting in front of a Debian box. On my opensuse boxes, with that command, I get a similar but more laborious logging since opensuse seems to have more stuff running. Roger
On 2021-04-10 2:23 p.m., Roger Price wrote:
How are you viewing that? I didn't see much in dmesg and I don't see any files that refer to system log. Even doing a google search doesn't turn up much.
I used the command journalctl -b -1 -n 14 but I was sitting in front of a Debian box. On my opensuse boxes, with that command, I get a similar but more laborious logging since opensuse seems to have more stuff running.
ournalctl -b -1 -n 14 Specifying boot ID or boot offset has no effect, no persistent journal was found.
On Sat, 10 Apr 2021 15:22:18 -0400 James Knott <james.knott@jknott.net> wrote:
On 2021-04-10 2:23 p.m., Roger Price wrote:
How are you viewing that? I didn't see much in dmesg and I don't see any files that refer to system log. Even doing a google search doesn't turn up much.
I used the command journalctl -b -1 -n 14 but I was sitting in front of a Debian box. On my opensuse boxes, with that command, I get a similar but more laborious logging since opensuse seems to have more stuff running.
ournalctl -b -1 -n 14 Specifying boot ID or boot offset has no effect, no persistent journal was found.
Well, is the journal stored on a persistent filesystem or not? If not - what do you expect, and why not?
On 2021-04-10 4:00 p.m., Dave Howorth wrote:
ournalctl -b -1 -n 14 Specifying boot ID or boot offset has no effect, no persistent journal was found. Well, is the journal stored on a persistent filesystem or not? If not - what do you expect, and why not?
I have never used that command before, so I don't know what to expect with it.
On Sat, 10 Apr 2021 16:17:32 -0400 James Knott <james.knott@jknott.net> wrote:
On 2021-04-10 4:00 p.m., Dave Howorth wrote:
ournalctl -b -1 -n 14 Specifying boot ID or boot offset has no effect, no persistent journal was found. Well, is the journal stored on a persistent filesystem or not? If not - what do you expect, and why not?
I have never used that command before, so I don't know what to expect with it.
Which is why I suggested RTFM in my other reply :)
On 10/04/2021 22.17, James Knott wrote:
On 2021-04-10 4:00 p.m., Dave Howorth wrote:
ournalctl -b -1 -n 14 Specifying boot ID or boot offset has no effect, no persistent journal was found. Well, is the journal stored on a persistent filesystem or not? If not - what do you expect, and why not?
I have never used that command before, so I don't know what to expect with it.
This is a command you have to know about. Any problem you have in a systemd Linux, you have to use it. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 2:23 p.m., Roger Price wrote:
How are you viewing that? I didn't see much in dmesg and I don't see any files that refer to system log. Even doing a google search doesn't turn up much.
I used the command journalctl -b -1 -n 14 but I was sitting in front of a Debian box. On my opensuse boxes, with that command, I get a similar but more laborious logging since opensuse seems to have more stuff running.
ournalctl -b -1 -n 14 Specifying boot ID or boot offset has no effect, no persistent journal was found.
In file /etc/systemd/journald.conf I have [Journal] Storage=persistent Perhaps that is why I see the log of previous boots. Roger
On 10/04/2021 22.19, James Knott wrote:
On 2021-04-10 4:07 p.m., Roger Price wrote:
In file /etc/systemd/journald.conf I have
[Journal] Storage=persistent
[Journal] #Storage=auto
As I have just said, create directory "/var/log/journal/". "Auto" will take care of the rest. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 4:07 p.m., Roger Price wrote:
In file /etc/systemd/journald.conf I have
[Journal] Storage=persistent
[Journal] #Storage=auto
« "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. » So the question is "Do you have a file /var/log/journal?" Roger
On 10/04/2021 22.34, James Knott wrote:
On 2021-04-10 4:32 p.m., Roger Price wrote:
So the question is "Do you have a file /var/log/journal?"
I just created that directory. I didn't have it before.
That is the default in openSUSE, after a lot of criticism. On Leap you get a volatile journal and there should be a permanent syslog. I think TW doesn't have syslog and uses the journal instead. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 4:32 p.m., Roger Price wrote:
So the question is "Do you have a file /var/log/journal?"
I just created that directory. I didn't have it before.
Now is the time to pull the power cord from the wall and test the shutdown process. It will be interesting to see the log. Roger
On Sat, 10 Apr 2021, Roger Price wrote:
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 4:32 p.m., Roger Price wrote:
So the question is "Do you have a file /var/log/journal?"
I just created that directory. I didn't have it before.
Now is the time to pull the power cord from the wall and test the shutdown process. It will be interesting to see the log.
After the system shutdown, the UPS will probably go on beeping. When this stops you might hear the "clunk" of the relays as the output sockets are disconnected. It would be interesting to know if you hear the "clunk". It would also be interesting to see the output of command "apcaccess status" when the system resumes. It is possible to speed up testing by setting BATTERYLEVEL to say 85 instead of the default 5 %. Roger
On 11/04/2021 12.30, Roger Price wrote:
On Sat, 10 Apr 2021, Roger Price wrote:
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 4:32 p.m., Roger Price wrote:
So the question is "Do you have a file /var/log/journal?"
I just created that directory. I didn't have it before.
Now is the time to pull the power cord from the wall and test the shutdown process. It will be interesting to see the log.
After the system shutdown, the UPS will probably go on beeping. When this stops you might hear the "clunk" of the relays as the output sockets are disconnected. It would be interesting to know if you hear the "clunk".
It would also be interesting to see the output of command "apcaccess status" when the system resumes.
It is possible to speed up testing by setting BATTERYLEVEL to say 85 instead of the default 5 %.
Which also improves "battery suffering", ie, not suffering ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-04-10 4:41 p.m., Roger Price wrote:
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 4:32 p.m., Roger Price wrote:
So the question is "Do you have a file /var/log/journal?"
I just created that directory. I didn't have it before.
Now is the time to pull the power cord from the wall and test the shutdown process. It will be interesting to see the log.
I pulled the plug and waited for it to shut down. # journalctl|head -- Logs begin at Sat 2021-04-10 08:05:02 EDT, end at Sun 2021-04-11 10:55:57 EDT. -- Apr 10 08:05:02 linux kernel: microcode: microcode updated early to revision 0x21, date = 2019-02-13 Apr 10 08:05:02 linux kernel: Linux version 5.3.18-lp152.69-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Tue Apr 6 11:41:13 UTC 2021 (d532e33) Apr 10 08:05:02 linux kernel: Command line: BOOT_IMAGE=/vmlinuz-5.3.18-lp152.69-default root=UUID=6eea2df3-3ff3-4d25-b73c-fa782d63a217 splash=silent resume=/dev/disk/by-uuid/6af126cc-6d55-478e-b2d4-249fcc92277c mitigations=auto quiet Apr 10 08:05:02 linux kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Apr 10 08:05:02 linux kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Apr 10 08:05:02 linux kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Apr 10 08:05:02 linux kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Apr 10 08:05:02 linux kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Apr 10 08:05:02 linux kernel: BIOS-provided physical RAM map: There is nothing here that shows the power cut. I also was watching apcupsd Power Events and this was all I saw. I didn't see what was happening immediately before the shut down, as I was busy elsewhere at that time. 2021-04-11 10:17:57 -0400 Running on UPS batteries. 2021-04-11 10:17:51 -0400 Power failure.
On 2021-04-11 11:20 a.m., James Knott wrote:
I also was watching apcupsd Power Events and this was all I saw. I didn't see what was happening immediately before the shut down, as I was busy elsewhere at that time.
2021-04-11 10:17:57 -0400 Running on UPS batteries. 2021-04-11 10:17:51 -0400 Power failure.
Correction. I just checked again after power up and found this: 2021-04-11 10:54:39 -0400 apcupsd 3.14.14 (31 May 2016) suse startup succeeded 2021-04-11 10:48:54 -0400 apcupsd shutdown succeeded 2021-04-11 10:48:54 -0400 apcupsd exiting, signal 15 2021-04-11 10:48:54 -0400 User logins prohibited 2021-04-11 10:48:54 -0400 Initiating system shutdown! 2021-04-11 10:48:54 -0400 Reached remaining time percentage limit on batteries. 2021-04-11 10:17:57 -0400 Running on UPS batteries. 2021-04-11 10:17:51 -0400 Power failure.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2021-04-11 at 11:20 -0400, James Knott wrote:
On 2021-04-10 4:41 p.m., Roger Price wrote:
On Sat, 10 Apr 2021, James Knott wrote:
On 2021-04-10 4:32 p.m., Roger Price wrote:
So the question is "Do you have a file /var/log/journal?"
I just created that directory. I didn't have it before.
Now is the time to pull the power cord from the wall and test the shutdown process. It will be interesting to see the log.
I pulled the plug and waited for it to shut down.
# journalctl|head -- Logs begin at Sat 2021-04-10 08:05:02 EDT, end at Sun 2021-04-11 10:55:57 EDT. -- Apr 10 08:05:02 linux kernel: microcode: microcode updated early to revision 0x21, date = 2019-02-13 Apr 10 08:05:02 linux kernel: Linux version 5.3.18-lp152.69-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Tue Apr 6 11:41:13 UTC 2021 (d532e33) Apr 10 08:05:02 linux kernel: Command line: BOOT_IMAGE=/vmlinuz-5.3.18-lp152.69-default root=UUID=6eea2df3-3ff3-4d25-b73c-fa782d63a217 splash=silent resume=/dev/disk/by-uuid/6af126cc-6d55-478e-b2d4-249fcc92277c mitigations=auto quiet
This is the kernel booting. As you are at the very start of the logs, the powerdown will be much further down. Around 10:17:51 Typical "less" keyboard commands work in that screen. Press 'h' for help. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYHM4hhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVjBUAoI3prN1Zd2WnJnu57xzV hhvgR+ZxAJwLTcagpvaWufD4bmQlVkJl2QmD+g== =uOFA -----END PGP SIGNATURE-----
On 2021-04-11 1:57 p.m., Carlos E. R. wrote:
This is the kernel booting. As you are at the very start of the logs, the powerdown will be much further down. Around 10:17:51
Here's some info: Apr 11 10:17:51 linux apcupsd[2748]: Power failure. Apr 11 10:17:57 linux apcupsd[2748]: Running on UPS batteries. Apr 11 10:17:58 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device Apr 11 10:48:54 linux apcupsd[2748]: Reached remaining time percentage limit on batteries. Apr 11 10:48:54 linux apcupsd[2748]: Initiating system shutdown! Apr 11 10:48:54 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device Apr 11 10:48:54 linux apcupsd[2748]: User logins prohibited Apr 11 10:48:54 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device Apr 11 10:48:54 linux systemd[1]: Stopping Session c3 of user jknott. Apr 11 10:48:54 linux systemd[1]: Stopping Session 2 of user jknott. Apr 11 10:48:54 linux su[26033]: pam_unix(su-l:session): session closed for user root Apr 11 10:48:54 linux kernel: usb 1-1.5: reset high-speed USB device number 4 using ehci-pci Apr 11 10:48:54 linux apcupsd[2748]: apcupsd exiting, signal 15 Apr 11 10:48:54 linux sddm[3298]: Auth: sddm-helper crashed (exit code 15) Apr 11 10:48:54 linux apcupsd[2748]: apcupsd shutdown succeeded There are also many lines about stuff shutting down.
On Sun, 11 Apr 2021, James Knott wrote:
On 2021-04-11 1:57 p.m., Carlos E. R. wrote:
This is the kernel booting. As you are at the very start of the logs, the powerdown will be much further down. Around 10:17:51
Here's some info:
Apr 11 10:48:54 linux apcupsd[2748]: Reached remaining time percentage limit on batteries. Apr 11 10:48:54 linux apcupsd[2748]: Initiating system shutdown!
If you are using the default value for the MINUTES directive, 3 minutes, this means that you are at 3 minutes from a system crash as the system shutdown begins. This may work most of the time for a simple hobby box, but many production systems take more than 3 minutes to shutdown. It seems to me irresponsible of APC to set such default values. The argument is "get the most out of your UPS!". But this leads to emergency shutdowns, with no reserve if the utility power returns and then cuts again. I live in an area with frequent power failures. My boxes run with a managed shutdown after a 2 minute power loss. I get the most out of my UPS's by being able to shut down again and again after each successive power loss. Roger
On 11/04/2021 20.31, James Knott wrote:
On 2021-04-11 1:57 p.m., Carlos E. R. wrote:
This is the kernel booting. As you are at the very start of the logs, the powerdown will be much further down. Around 10:17:51
Here's some info:
Apr 11 10:17:51 linux apcupsd[2748]: Power failure. Apr 11 10:17:57 linux apcupsd[2748]: Running on UPS batteries. Apr 11 10:17:58 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device
Apr 11 10:48:54 linux apcupsd[2748]: Reached remaining time percentage limit on batteries. Apr 11 10:48:54 linux apcupsd[2748]: Initiating system shutdown! Apr 11 10:48:54 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device Apr 11 10:48:54 linux apcupsd[2748]: User logins prohibited Apr 11 10:48:54 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device Apr 11 10:48:54 linux systemd[1]: Stopping Session c3 of user jknott. Apr 11 10:48:54 linux systemd[1]: Stopping Session 2 of user jknott. Apr 11 10:48:54 linux su[26033]: pam_unix(su-l:session): session closed for user root Apr 11 10:48:54 linux kernel: usb 1-1.5: reset high-speed USB device number 4 using ehci-pci
Apr 11 10:48:54 linux apcupsd[2748]: apcupsd exiting, signal 15 Apr 11 10:48:54 linux sddm[3298]: Auth: sddm-helper crashed (exit code 15) Apr 11 10:48:54 linux apcupsd[2748]: apcupsd shutdown succeeded
There are also many lines about stuff shutting down.
Yes, this is the text I would expect. :-) This seems to indicate a bug:
Apr 11 10:17:58 linux apcupsd[2748]: wall: cannot get tty name: Inappropriate ioctl for device
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (4)
-
Carlos E. R. -
Dave Howorth -
James Knott -
Roger Price