1. On 9/5/20 9:55 PM, Carlos E. R. wrote:

On 06/09/2020 01.48, Doug McGarrett wrote:

...

I have had, in the last couple of days, a couple of incidents of system paralysis, where lights on the k/b flash, and the cursor disappears from the screen. This is on a "desktop" computer (that actually sits on the floor) that is only a couple of months old. Checking the temperatures with zypper shows the cpu temp is reasonable. I have  installed hddtemp, but it wants a name for the ssd: linux1:/usr/sbin # hddtemp Too few arguments: you must specify one drive, at least. What is it called, please? Run this first:

mount -vl > somefile.txt

(dash victor lima, lowercase)

and attach, not paste, that somefile.txt to your reply here.

OK, here it is.  --doug

On 9/5/20 8:00 PM, Doug McGarrett wrote:

...

1.

On 9/5/20 9:55 PM, Carlos E. R. wrote:

...

On 06/09/2020 01.48, Doug McGarrett wrote:

...

I have had, in the last couple of days, a couple of incidents of system paralysis, where lights on the k/b flash, and the cursor disappears from the screen. This is on a "desktop" computer (that actually sits on the floor) that is only a couple of months old. Checking the temperatures with zypper shows the cpu temp is reasonable. I have    installed hddtemp, but it wants a name for the ssd: linux1:/usr/sbin # hddtemp Too few arguments: you must specify one drive, at least. What is it called, please? Run this first:

mount -vl > somefile.txt

(dash victor lima, lowercase)

and attach, not paste, that somefile.txt to your reply here.

OK, here it is.  --doug

The "disk" name in this case would be /dev/nvme0n1.  But that's not a disk, it's a NVMe M.2 solid-state memory module, most likely directly mounted on your motherboard.  I don't think they have the capability of reporting their temperature, they're not really disk drives.

BTW, exactly what program did you use to check your CPU temps? Zipper wouldn't be the program to do that.  Maybe "sensors"?  What temperatures were you seeing?

How do you recover from the problem?  Reboot?  Does it come back by itself? I reboot. And the bios screen (if I access it) tells what the temo was just before reboot, but

On 9/5/20 11:40 PM, Lew Wolfgang wrote: the command  sensors  produces the temps. doug@linux1:~> sensors iwlwifi_1-virtual-0 Adapter: Virtual device temp1:        +31.0°C nvme-pci-0100 Adapter: PCI adapter Composite:    +36.9°C  (low  =  -5.2°C, high = +79.8°C)                        (crit = +84.8°C) coretemp-isa-0000 Adapter: ISA adapter Package id 0:  +31.0°C  (high = +86.0°C, crit = +100.0°C) Core 0:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 1:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 2:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 3:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 4:        +30.0°C  (high = +86.0°C, crit = +100.0°C) Core 5:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 6:        +30.0°C  (high = +86.0°C, crit = +100.0°C) Core 7:        +29.0°C  (high = +86.0°C, crit = +100.0°C) --doug

Regards, Lew

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 12:26 AM, Lew Wolfgang wrote:

On 9/5/20 9:04 PM, Doug McGarrett wrote:

...

...

On 9/5/20 8:00 PM, Doug McGarrett wrote:

...

1.

On 9/5/20 9:55 PM, Carlos E. R. wrote:

...

On 06/09/2020 01.48, Doug McGarrett wrote:

...

I have had, in the last couple of days, a couple of incidents of system paralysis, where lights on the k/b flash, and the cursor disappears from the screen. This is on a "desktop" computer (that actually sits on the floor) that is only a couple of months old. Checking the temperatures with zypper shows the cpu temp is reasonable. I have    installed hddtemp, but it wants a name for the ssd: linux1:/usr/sbin # hddtemp Too few arguments: you must specify one drive, at least. What is it called, please? Run this first:

mount -vl > somefile.txt

(dash victor lima, lowercase)

and attach, not paste, that somefile.txt to your reply here.

OK, here it is.  --doug

The "disk" name in this case would be /dev/nvme0n1.  But that's not a disk, it's a NVMe M.2 solid-state memory module, most likely directly mounted on your motherboard.  I don't think they have the capability of reporting their temperature, they're not really disk drives.

BTW, exactly what program did you use to check your CPU temps? Zipper wouldn't be the program to do that.  Maybe "sensors"? What temperatures were you seeing?

How do you recover from the problem?  Reboot?  Does it come back by itself? I reboot. And the bios screen (if I access it) tells what the temo was just before reboot, but

On 9/5/20 11:40 PM, Lew Wolfgang wrote: the command  sensors  produces the temps.

doug@linux1:~> sensors iwlwifi_1-virtual-0 Adapter: Virtual device temp1:        +31.0°C

nvme-pci-0100 Adapter: PCI adapter Composite:    +36.9°C  (low  =  -5.2°C, high = +79.8°C)                        (crit = +84.8°C)

coretemp-isa-0000 Adapter: ISA adapter Package id 0:  +31.0°C  (high = +86.0°C, crit = +100.0°C) Core 0:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 1:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 2:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 3:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 4:        +30.0°C  (high = +86.0°C, crit = +100.0°C) Core 5:        +29.0°C  (high = +86.0°C, crit = +100.0°C) Core 6:        +30.0°C  (high = +86.0°C, crit = +100.0°C) Core 7:        +29.0°C  (high = +86.0°C, crit = +100.0°C)

Wow, those temps look really good to me!  I'm jealous.

When you say the k/b lights flash, which lights are those?  Is there a pattern?

And when the cursor disappears, does the rest of the screen stay? Or does it go to black?

Regards, Lew To answer: The Num Lock and the Scroll Lock , I THINK--not the Caps lock. It was rather quick so I could be wrong. I couldn't tell about a pattern--it didn't look like Morse code! The desktop looks just the same, but no cursor, and the trackball does nothing. I have to pull the switch on the computer to reboot, since the system is completely off line. After reboot everything is normal. This is a couple hours later, but the machine  hasn't been used during most of that time--it was just in standby. I haven't tried anything crude, like kicking the machine!  Computer is Power Spec, a house brand ofMicro Center, a small chain of large computer stores. I could run lshw if you need more info. --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Le 06/09/2020 à 10:37, Carlos E. R. a écrit :

hddtemp /dev/nvme0n1

Doesn't work on mine: Telcontar:~ # hddtemp /dev/nvme0n1 ERROR: /dev/nvme0n1: can't determine bus type (or this bus type is unknown)

odd, given on some of these disks, temp can very hot :-( https://i.ebayimg.com/images/g/OKMAAOSwFOZbIShb/s-l640.jpg jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 4:37 AM, Carlos E. R. wrote:

On 06/09/2020 08.11, Doug McGarrett wrote:

...

On 9/6/20 12:26 AM, Lew Wolfgang wrote:

...

On 9/5/20 9:04 PM, Doug McGarrett wrote:

...

On 9/5/20 11:40 PM, Lew Wolfgang wrote:

...

On 9/5/20 8:00 PM, Doug McGarrett wrote:

...

On 9/5/20 9:55 PM, Carlos E. R. wrote: > On 06/09/2020 01.48, Doug McGarrett wrote: >> I have had, in the last couple of days, a couple of incidents >> of system paralysis, >> where lights on the k/b flash, and the cursor disappears from >> the screen. This is on >> a "desktop" computer (that actually sits on the floor) that is  >> only a couple of months >> old. Checking the temperatures with zypper shows the cpu temp >> isreasonable. I have >>    installed hddtemp, but it wants a name for the ssd: >> linux1:/usr/sbin # hddtemp >> Too few arguments: you must specify one drive, at least. >> What is it called, please? > Run this first: > > mount -vl > somefile.txt > > (dash victor lima, lowercase) > > and attach, not paste, that somefile.txt to your reply here. > > OK, here it is.

The "disk" name in this case would be /dev/nvme0n1.

Right. So,

hddtemp /dev/nvme0n1

Doesn't work on mine: Telcontar:~ # hddtemp /dev/nvme0n1 ERROR: /dev/nvme0n1: can't determine bus type (or this bus type is unknown) Telcontar:~ #

foesn't work on mine either. Same error message.  --doug

...

But that's

...

...

...

not a disk, it's a NVMe M.2 solid-state memory module, most likely directly mounted on your motherboard.  I don't think they have the capability of reporting their temperature, they're not really disk drives. ...

Wow, those temps look really good to me!  I'm jealous.

Yep.

...

...

When you say the k/b lights flash, which lights are those?  Is there a pattern?

And when the cursor disappears, does the rest of the screen stay? Or does it go to black?

...

To answer: The Num Lock and the Scroll Lock , I THINK--not the Caps lock. It was rather quick so I could be wrong. I couldn't tell about a pattern--it didn't look like Morse code!

Kernel panic. Look in console 10: press ctrl-alt-f10 if it still works. Take a photo, and upload to susepaste and post the link.

...

The desktop looks just the same, but no cursor, and the trackball does nothing. I have to pull the switch on the computer to reboot, since the system is completely off line. After reboot everything is normal. This is a couple hours later, but the machine  hasn't been used during most of that time--it was just in standby. I haven't tried anything crude, like kicking the machine!  Computer is Power Spec, a house brand ofMicro Center, a small chain of large computer stores. I could run lshw if you need more info.

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 06/09/2020 12.19, Manfred Hollstein wrote:

On Sun, 06 Sep 2020, 10:37:25 +0200, Carlos E. R. wrote:

...

Right. So,

hddtemp /dev/nvme0n1

Doesn't work on mine: Telcontar:~ # hddtemp /dev/nvme0n1 ERROR: /dev/nvme0n1: can't determine bus type (or this bus type is unknown) Telcontar:~ #

Smartctl works here on my NVME disks:

# smartctl -a /dev/nvme0n1 | grep -i temp Warning Comp. Temp. Threshold: 73 Celsius Critical Comp. Temp. Threshold: 76 Celsius Temperature: 27 Celsius Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 1: 27 Celsius Temperature Sensor 2: 32 Celsius

And in mine: Telcontar:~ # smartctl -a /dev/nvme0n1 | grep -i temp Warning Comp. Temp. Threshold: 85 Celsius Critical Comp. Temp. Threshold: 85 Celsius That is the temperature limit, not the current value. Temperature: 36 Celsius This one I think is a real value. Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 1: 36 Celsius Temperature Sensor 2: 38 Celsius These two I don't know what they are. Actual values somewhere. Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 06/09/2020 21.35, Doug McGarrett wrote:

On 9/6/20 7:43 AM, Carlos E. R. wrote:

...

The command works here, but I don't get the last two lines that the others are getting--Temperature  Sensor 1 and Temperature Sensor 2. It may not matter, since these sensors are undefined.

The lines are up to the manufacturer.

Does anyone have a suspicion as to what else might cause a sudden suspension of function?

Not till you get a view of console 10 with some message, or perchance if there is something in the logs. Look for the word "panic". If you are lucky, the kernel might had have time to write something. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 06/09/2020 22.27, Doug McGarrett wrote:

On 9/6/20 3:41 PM, Carlos E. R. wrote:

...

On 06/09/2020 21.35, Doug McGarrett wrote:

...

...

Does anyone have a suspicion as to what else might cause a sudden suspension of function?

Not till you get a view of console 10 with some message, or perchance if there is something in the logs. Look for the word "panic". If you are lucky, the kernel might had have time to write something.

What log should I look in? Can you give me a name, or names?

Lew told you in his post. It is the same file where it has been for decades: /var/log/messages

  Don't know what you mean by "console 10"

I told you today in another post. Press ctrl-alt-F10 when it happens. That's console number 10. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 9/6/20 5:47 PM, Carlos E. R. wrote:

On 06/09/2020 22.27, Doug McGarrett wrote:

...

On 9/6/20 3:41 PM, Carlos E. R. wrote:

...

On 06/09/2020 21.35, Doug McGarrett wrote:

...

...

...

Does anyone have a suspicion as to what else might cause a sudden suspension of function?

Not till you get a view of console 10 with some message, or perchance if there is something in the logs. Look for the word "panic". If you are lucky, the kernel might had have time to write something.

What log should I look in? Can you give me a name, or names?

Lew told you in his post. It is the same file where it has been for decades: /var/log/messages ran "locate messages" and there is no file in /var/log/ or anywhere that looks like it is related to the os. All related to some application file or other. --doug

...

  Don't know what you mean by "console 10"

I told you today in another post. Press ctrl-alt-F10 when it happens. That's console number 10.

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 4:06 PM, Patrick Shanahan wrote:

* Doug McGarrett [09-06-20 19:02]:

...

On 9/6/20 5:47 PM, Carlos E. R. wrote:

...

Lew told you in his post. It is the same file where it has been for decades: /var/log/messages

ran "locate messages" and there is no file in /var/log/ or anywhere that looks like it is related to the os. All related to some application file or other. --doug

...

...

so maybe no syslog invocation, ie: all systemd-journal

tell him how to find "panic" in the journal.

Good point, what version of Leap are you running, Doug?  If you're not sure you can "cat /etc/os-release". Can you try "journalctl | |grep -i panic" as root and see what happens? Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 8:02 PM, Lew Wolfgang wrote:

On 9/6/20 4:06 PM, Patrick Shanahan wrote:

...

* Doug McGarrett [09-06-20 19:02]:

...

On 9/6/20 5:47 PM, Carlos E. R. wrote:

...

Lew told you in his post. It is the same file where it has been for decades: /var/log/messages

ran "locate messages" and there is no file in /var/log/ or anywhere that looks like it is related to the os. All related to some application file or other. --doug

...

...

  so maybe no syslog invocation, ie: all systemd-journal

tell him how to find "panic" in the journal.

Good point, what version of Leap are you running, Doug?  If you're not sure you can "cat /etc/os-release". As someone else pointed out, the system is not Leap, it's Tumbleweed.

Can you try "journalctl | |grep -i panic" as root and see what happens?

locate does not find cournalctl --doug

Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 07/09/2020 04.34, Lew Wolfgang wrote:

On 9/6/20 7:20 PM, Doug McGarrett wrote:

...

On 9/6/20 8:02 PM, Lew Wolfgang wrote:

...

On 9/6/20 4:06 PM, Patrick Shanahan wrote:

...

* Doug McGarrett <> [09-06-20 19:02]:

...

On 9/6/20 5:47 PM, Carlos E. R. wrote:

...

Lew told you in his post. It is the same file where it has been for decades: /var/log/messages

ran "locate messages" and there is no file in /var/log/ or anywhere that looks like it is related to the os. All related to some application file or other.

...

...

...

...

...

>   so maybe no syslog invocation, ie: all systemd-journal > > tell him how to find "panic" in the journal. >

Good point, what version of Leap are you running, Doug?  If you're not sure you can "cat /etc/os-release". As someone else pointed out, the system is not Leap, it's Tumbleweed.

Ah, I missed that.  Some older releases of openSUSE didn't run syslog by default, which would explain why /var/log/messages was missing.

No, it doesn't, his install is fresh.

Leap 15.2 does run it by default, I don't know about Tumbleweed. journalctl should be there in any case.

...

...

Can you try "journalctl | |grep -i panic" as root and see what happens?

locate does not find cournalctl

You don't need to "locate" journalctl, it's a program that lives in /usr/bin.

And of course, locate finds it. He typed it with 'c' from Charlie, instead of 'j' from Juliett

You should find it by doing "which journalctl", or just typing "journalctl", assuming your paths are set correctly.

Right. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.1 x86_64 (Minas Tirith))

* Doug McGarrett [09-07-20 14:31]:

On 9/6/20 10:34 PM, Lew Wolfgang wrote:

...

On 9/6/20 7:20 PM, Doug McGarrett wrote:

...

On 9/6/20 8:02 PM, Lew Wolfgang wrote:

...

On 9/6/20 4:06 PM, Patrick Shanahan wrote:

...

* Doug McGarrett [09-06-20 19:02]:

...

On 9/6/20 5:47 PM, Carlos E. R. wrote: > > Lew told you in his post. It is the same file where it has been for > decades: /var/log/messages ran "locate messages" and there is no file in /var/log/ or anywhere that looks like it is related to the os. All related to some application file or other. --doug > >   so maybe no syslog invocation, ie: all systemd-journal > > > > tell him how to find "panic" in the journal. > >

Good point, what version of Leap are you running, Doug?  If you're not sure you can "cat /etc/os-release". As someone else pointed out, the system is not Leap, it's Tumbleweed.

Ah, I missed that.  Some older releases of openSUSE didn't run syslog by default, which would explain why /var/log/messages was missing.  Leap 15.2 does run it by default, I don't know about Tumbleweed. journalctl should be there in any case.

...

...

Can you try "journalctl | |grep -i panic" as root and see what happens?

locate does not find cournalctl

You don't need to "locate" journalctl, it's a program that lives in /usr/bin.

You should find it by doing "which journalctl", or just typing "journalctl", assuming your paths are set correctly.

Regards, Lew

linux1:/home/doug # journalctl | lgrep -i panic If 'lgrep' is not a typo you can use command-not-found to lookup the package that contains it, like this:     cnf lgrep linux1:/home/doug # journalctl | grep -i panic (return to linux1) Had to install lgrep: linux1:/home/doug # zypper install lv Retrieving package lv-4.51-149.12.x86_64 (1/1), 424.8 KiB (620.2 KiB unpacked) Retrieving: lv-4.51-149.12.x86_64.rpm .................................................................................................[done]

Checking for file conflicts: ..........................................................................................................[done] (1/1) Installing: lv-4.51-149.12.x86_64 ...............................................................................................[done] linux1:/home/doug # journalctl | lgrep -i panic linux1:/home/doug #

No panic anywhere. Ran memtest overnite. All clean.

Doug, it is *not* "lgrep" but "| grep", the verticle line ie: the pipe character. You MUST read and FOLLOW directions as presented. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

El 2020-09-07 a las 15:49 -0400, Doug McGarrett escribió:

On 9/7/20 3:27 PM, Patrick Shanahan wrote:

...

* Doug McGarrett <> [09-07-20 14:31]:

...

On 9/6/20 10:34 PM, Lew Wolfgang wrote:

...

On 9/6/20 7:20 PM, Doug McGarrett wrote:

...

On 9/6/20 8:02 PM, Lew Wolfgang wrote:

...

On 9/6/20 4:06 PM, Patrick Shanahan wrote: > * Doug McGarrett [09-06-20 19:02]: >> On 9/6/20 5:47 PM, Carlos E. R. wrote: >>> Lew told you in his post. It is the same file where it has been for >>> decades: /var/log/messages >> ran "locate messages" and there is no file in /var/log/ >> or anywhere that >> looks like it is related to the os. All related to some >> application file or other. >> --doug >>>>   so maybe no syslog invocation, ie: all systemd-journal >>>> >>>> tell him how to find "panic" in the journal. >>>> Good point, what version of Leap are you running, Doug?  If you're not sure you can "cat /etc/os-release". As someone else pointed out, the system is not Leap, it's Tumbleweed. Ah, I missed that.  Some older releases of openSUSE didn't run syslog by default, which would explain why /var/log/messages was missing.  Leap 15.2 does run it by default, I don't know about Tumbleweed. journalctl should be there in any case.

...

...

Can you try "journalctl | |grep -i panic" as root and see what happens?

locate does not find cournalctl You don't need to "locate" journalctl, it's a program that lives in /usr/bin.

You should find it by doing "which journalctl", or just typing "journalctl", assuming your paths are set correctly.

Regards, Lew

linux1:/home/doug # journalctl | lgrep -i panic If 'lgrep' is not a typo you can use command-not-found to lookup the package that contains it, like this:     cnf lgrep linux1:/home/doug # journalctl | grep -i panic (return to linux1) Had to install lgrep: linux1:/home/doug # zypper install lv Retrieving package lv-4.51-149.12.x86_64 (1/1), 424.8 KiB (620.2 KiB unpacked) Retrieving: lv-4.51-149.12.x86_64.rpm .................................................................................................[done]

Checking for file conflicts: ..........................................................................................................[done] (1/1) Installing: lv-4.51-149.12.x86_64 ...............................................................................................[done] linux1:/home/doug # journalctl | lgrep -i panic linux1:/home/doug #

No panic anywhere. Ran memtest overnite. All clean. Doug, it is *not* "lgrep" but "| grep", the verticle line ie: the pipe character.

You MUST read and FOLLOW directions as presented. If you look at the original post, it was lgrep, which didn't work.

No, it wasn't lgrep. Lew made a typo and wrote two vertical bars. Notice, vertical bars, not 'l' like in Lima. I did not make that mistake when I told you what command to paste in the terminal to run. When "journalctl | grep -i panic" returns nothing it is because there is nothing to return. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))

On 9/7/20 12:49 PM, Doug McGarrett wrote:

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada.

I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn...

I'm beginning to wonder if this was a fluke, but it happened twice. Now for a couple of days and all kinds of tests, nothing shows up.

Mechanic's curse?  That which is looked for is never found. I'd confirm that the journal is persistent at this point.  You wouldn't want evidence collected before a crash to be lost during the subsequent reboot.  Or make sure that syslog is running and putting persistent stuff in /var/log/messages. Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/7/20 2:13 PM, Dave Howorth wrote:

On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

...

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada. I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn... What makes you think that?

According to https://manpages.debian.org/stretch/lv/lgrep.1 "lv also provides multilingual grep (1) functionality by giving it another name, lgrep"

https://github.com/olmeca/lgrep lgrep "A variation on grep, targeting log files" "lgrep is a variation on grep, developed specifically for efficient searching through application log files. Though most of the time an entry in a log file consists of one line, sometimes it spans multiple lines. A log entry usually consists of some metadata (e.g date, time, code reference) and a message. Sometimes the message part takes up multiple lines, e.g. if it contains a whole JSON object or a whole stack trace." Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Mon, 7 Sep 2020 23:46:53 +0200 (CEST) "Carlos E. R." wrote:

El 2020-09-07 a las 14:30 -0700, Lew Wolfgang escribió:

...

On 9/7/20 2:13 PM, Dave Howorth wrote:

...

On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang <> wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

...

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada. I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn... What makes you think that?

According to https://manpages.debian.org/stretch/lv/lgrep.1 "lv also provides multilingual grep (1) functionality by giving it another name, lgrep"

https://github.com/olmeca/lgrep

lgrep

"A variation on grep, targeting log files"

"lgrep is a variation on grep, developed specifically for efficient searching through application log files. Though most of the time an entry in a log file consists of one line, sometimes it spans multiple lines. A log entry usually consists of some metadata (e.g date, time, code reference) and a message. Sometimes the message part takes up multiple lines, e.g. if it contains a whole JSON object or a whole stack trace."

Interesting. So there are two different versions of lgrep. And none is found on our repos.

https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.1&q=lgrep

Yes, it seems there are two different programs, both called lgrep, that do different things. But the one that Doug installed and that I linked to a manpage for is indeed in our repositories as part of the lv package,as cnf tells you: $ cnf lgrep The program 'lgrep' can be found in the following package: * lv [ path: /usr/bin/lgrep, repository: zypp (repo-oss) ] Try installing with: sudo zypper install lv -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

* Doug McGarrett [09-08-20 14:12]:

On 9/8/20 6:37 AM, Dave Howorth wrote:

...

On Mon, 7 Sep 2020 23:46:53 +0200 (CEST) "Carlos E. R." wrote:

...

El 2020-09-07 a las 14:30 -0700, Lew Wolfgang escribió:

...

On 9/7/20 2:13 PM, Dave Howorth wrote:

...

On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang <> wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote: > If you look at the original post, it was lgrep, which didn't > work. Then I ran grep -i etc. having looked up > grep in "Linux in a Nutshell" my Linux reference book. But it > turns out  there actually is an lgrep in > the system, and I installed it and ran it with the same result--nada. I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn... What makes you think that?

According to https://manpages.debian.org/stretch/lv/lgrep.1 "lv also provides multilingual grep (1) functionality by giving it another name, lgrep" https://github.com/olmeca/lgrep

lgrep

"A variation on grep, targeting log files"

"lgrep is a variation on grep, developed specifically for efficient searching through application log files. Though most of the time an entry in a log file consists of one line, sometimes it spans multiple lines. A log entry usually consists of some metadata (e.g date, time, code reference) and a message. Sometimes the message part takes up multiple lines, e.g. if it contains a whole JSON object or a whole stack trace." Interesting. So there are two different versions of lgrep. And none is found on our repos.

https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.1&q=lgrep Yes, it seems there are two different programs, both called lgrep, that do different things.

But the one that Doug installed and that I linked to a manpage for is indeed in our repositories as part of the lv package,as cnf tells you:

$ cnf lgrep The program 'lgrep' can be found in the following package: * lv [ path: /usr/bin/lgrep, repository: zypp (repo-oss) ]

Try installing with: sudo zypper install lv I already have the lgrep that I installed as above. If I install lv, then I will have two, possibly different, lgreps? Sounds too confusing to me!

yes, and you *really* need neither. better zypper -v rm lgrep and be back where you were. note: must happen as "root" and must be typed as presented here. Answer "yes". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Tue, 8 Sep 2020 18:20:04 -0400 Doug McGarrett wrote:

On 9/8/20 2:50 PM, Patrick Shanahan wrote:

...

* Doug McGarrett [09-08-20 14:12]:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

https://github.com/olmeca/lgrep

lgrep

"A variation on grep, targeting log files"

"lgrep is a variation on grep, developed specifically for efficient searching through application log files. Though most of the time an entry in a log file consists of one line, sometimes it spans multiple lines. A log entry usually consists of some metadata (e.g date, time, code reference) and a message. Sometimes the message part takes up multiple lines, e.g. if it contains a whole JSON object or a whole stack trace."

...

I already have the lgrep that I installed as above. If I install lv, then I will have two, possibly different, lgreps? Sounds too confusing to me!

yes, and you *really* need neither. better zypper -v rm lgrep

and be back where you were. note: must happen as "root" and must be typed as presented here. Answer "yes".

doug@linux1:~> su - Password: linux1:~ # zypper -v rm lgrep Verbosity: 2 Non-option program arguments: 'lgrep' Initializing Target Reading installed packages... Force resolution: Yes 'lgrep' not found in package names. Trying capabilities. No provider of 'lgrep' found. Resolving package dependencies... Force resolution: Yes

Nothing to do. linux1:~ # --doug

Unfortunately Patrick made a mistake. zypper operates on the names of packages, rather than binary programs as he gave you. So you need to substitute 'lv' for 'lgrep'. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Wed, 9 Sep 2020 07:49:37 -0400 Patrick Shanahan wrote:

* Dave Howorth [09-09-20 05:42]:

...

On Tue, 8 Sep 2020 18:20:04 -0400 Doug McGarrett wrote:

...

On 9/8/20 2:50 PM, Patrick Shanahan wrote:

...

* Doug McGarrett [09-08-20 14:12]:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

https://github.com/olmeca/lgrep

lgrep

"A variation on grep, targeting log files"

"lgrep is a variation on grep, developed specifically for efficient searching through application log files. Though most of the time an entry in a log file consists of one line, sometimes it spans multiple lines. A log entry usually consists of some metadata (e.g date, time, code reference) and a message. Sometimes the message part takes up multiple lines, e.g. if it contains a whole JSON object or a whole stack trace."

...

I already have the lgrep that I installed as above. If I install lv, then I will have two, possibly different, lgreps? Sounds too confusing to me!

yes, and you *really* need neither. better zypper -v rm lgrep

and be back where you were. note: must happen as "root" and must be typed as presented here. Answer "yes".

doug@linux1:~> su - Password: linux1:~ # zypper -v rm lgrep Verbosity: 2 Non-option program arguments: 'lgrep' Initializing Target Reading installed packages... Force resolution: Yes 'lgrep' not found in package names. Trying capabilities. No provider of 'lgrep' found. Resolving package dependencies... Force resolution: Yes

Nothing to do. linux1:~ # --doug

Unfortunately Patrick made a mistake. zypper operates on the names of packages, rather than binary programs as he gave you. So you need to substitute 'lv' for 'lgrep'.

no, actually they both exist and lv contains it's own version of lgrep, but ...

The quoted log that Doug posted clearly indicates that he does not have any repositories containing a package called lgrep. Neither do I. Perhaps you do. But what mattered is what Doug has and he has previously showed us a log of installing lgrep as part of the lv package. So that is what he needs to remove, not some mythical other package from some mythical non-standard repository. Your instructions were incorrect for Doug, which is what matters.

not actually sure in this case the electrons were disbursed into the ethereal.

and I will not post again on this subject in this forum.

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/8/20 2:50 PM, Carlos E. R. wrote:

Man, you installed 'lv', it is in your own email.

Apparently so. And it creates a humongous output of fonts and free-office icons and lots of other stuff. Apparently the file is in /usr/share, and if I don't need it--and I guess I don't-- I will zap it. Please advise.  --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Tue, 8 Sep 2020 14:05:27 -0400 Doug McGarrett wrote:

...

On Mon, 7 Sep 2020 23:46:53 +0200 (CEST) "Carlos E. R." wrote:

...

El 2020-09-07 a las 14:30 -0700, Lew Wolfgang escribió:

...

On 9/7/20 2:13 PM, Dave Howorth wrote:

...

On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang <> wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote: > If you look at the original post, it was lgrep, which didn't > work. Then I ran grep -i etc. having looked up > grep in "Linux in a Nutshell" my Linux reference book. But it > turns out  there actually is an lgrep in > the system, and I installed it and ran it with the same result--nada. I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn... What makes you think that?

According to https://manpages.debian.org/stretch/lv/lgrep.1 "lv also provides multilingual grep (1) functionality by giving it another name, lgrep" https://github.com/olmeca/lgrep

lgrep

"A variation on grep, targeting log files"

"lgrep is a variation on grep, developed specifically for efficient searching through application log files. Though most of the time an entry in a log file consists of one line, sometimes it spans multiple lines. A log entry usually consists of some metadata (e.g date, time, code reference) and a message. Sometimes the message part takes up multiple lines, e.g. if it contains a whole JSON object or a whole stack trace." Interesting. So there are two different versions of lgrep. And none is found on our repos.

https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=openSUSE%3ALeap%3A15.1&q=lgrep Yes, it seems there are two different programs, both called lgrep, that do different things.

But the one that Doug installed and that I linked to a manpage for is indeed in our repositories as part of the lv package,as cnf tells you:

$ cnf lgrep

The program 'lgrep' can be found in the following package: * lv [ path: /usr/bin/lgrep, repository: zypp (repo-oss) ]

Try installing with: sudo zypper install lv I already have the lgrep that I installed as above. If I install lv,

On 9/8/20 6:37 AM, Dave Howorth wrote: then I will have two, possibly different, lgreps? Sounds too confusing to me! --doug

Doug, reread your own mails and check what you installed!!! And nobody is suggesting that you install lgrep again anyway, some people are suggesting you remove the copy you do have! Oh, and please don't send me extra copies of your emails. I can read them on the list just fine. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

...

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada. I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn... What makes you think that?

According to https://manpages.debian.org/stretch/lv/lgrep.1 "lv also provides multilingual grep (1) functionality by giving it another name, lgrep"

...

...

I'm beginning to wonder if this was a fluke, but it happened twice. Now for a couple of days and all kinds of tests, nothing shows up. Mechanic's curse?  That which is looked for is never found.

I'd confirm that the journal is persistent at this point.  You wouldn't want evidence collected before a crash to be lost during the subsequent reboot.  Or make sure that syslog is running and putting persistent stuff in /var/log/messages. To do that, use:

# journalctl --list-boots

It will show a number of boots if there is a persistent journal Did that. It shows a bunch of boots. Some of them due to getting cds to boot the system. Whoever did the bios for this machine did not follow the old custom of booting on a cd if it is present, or booting on the os if not. It is necessary to go to

On 9/7/20 5:13 PM, Dave Howorth wrote: the bios screen EVERY TIME to set it to boot from cd, and then it is sometimes necessary to go back to the bios in order to get the CD out of the external drive. (There is no internal drive.) --doug

...

Regards, Lew

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/7/20 4:53 PM, Lew Wolfgang wrote:

On 9/7/20 12:49 PM, Doug McGarrett wrote:

...

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada.

I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn...

...

I'm beginning to wonder if this was a fluke, but it happened twice. Now for a couple of days and all kinds of tests, nothing shows up.

Mechanic's curse?  That which is looked for is never found.

I'd confirm that the journal is persistent at this point.  You wouldn't want evidence collected before a crash to be lost during the subsequent reboot.  Or make sure that syslog is running and putting persistent stuff in /var/log/messages.

Regards, Lew I did a locate for syslog, and there are a lot of them, all connected in some fashion to other directories, programs, etc. Four under /etc/apparmor.d, all the rest under /usr/something. where something is most often /lib. --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 08/09/2020 00.08, Doug McGarrett wrote:

On 9/7/20 4:53 PM, Lew Wolfgang wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

...

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada.

I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn...

...

I'm beginning to wonder if this was a fluke, but it happened twice. Now for a couple of days and all kinds of tests, nothing shows up.

Mechanic's curse?  That which is looked for is never found.

I'd confirm that the journal is persistent at this point.  You wouldn't want evidence collected before a crash to be lost during the subsequent reboot.  Or make sure that syslog is running and putting persistent stuff in /var/log/messages.

I did a locate for syslog, and there are a lot of them, all connected in some fashion to other directories, programs, etc. Four under /etc/apparmor.d, all the rest under /usr/something. where something is most often /lib.

What you are locating are the programs, libraries and configuration files that make up syslog, not the log created by it, which all live as files under /var/log/. If you want to know if syslog is active, you do instead: systemctl status syslog -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

* Doug McGarrett [09-08-20 11:14]:

On 9/8/20 4:40 AM, Carlos E. R. wrote:

...

On 08/09/2020 00.08, Doug McGarrett wrote:

...

On 9/7/20 4:53 PM, Lew Wolfgang wrote:

...

On 9/7/20 12:49 PM, Doug McGarrett wrote:

...

If you look at the original post, it was lgrep, which didn't work. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out  there actually is an lgrep in the system, and I installed it and ran it with the same result--nada.

I didn't know about lgrep either.  It's apparently a grep optimized for looking at logs.  We're never to old to learn...

...

I'm beginning to wonder if this was a fluke, but it happened twice. Now for a couple of days and all kinds of tests, nothing shows up.

Mechanic's curse?  That which is looked for is never found.

I'd confirm that the journal is persistent at this point.  You wouldn't want evidence collected before a crash to be lost during the subsequent reboot.  Or make sure that syslog is running and putting persistent stuff in /var/log/messages.

...

I did a locate for syslog, and there are a lot of them, all connected in some fashion to other directories, programs, etc. Four under /etc/apparmor.d, all the rest under /usr/something. where something is most often /lib.

What you are locating are the programs, libraries and configuration files that make up syslog, not the log created by it, which all live as files under /var/log/.

If you want to know if syslog is active, you do instead:

systemctl status syslog I guess it's not active: doug@linux1:~> systemctl status syslog Unit syslog.service could not be found. doug@linux1:~>

more than likely, not even installed. It is not included in a Tw install, but added after install if wanted. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/8/20 1:47 PM, Carlos E. R. wrote:

El 2020-09-08 a las 11:20 -0400, Patrick Shanahan escribió:

...

...

On 9/8/20 4:40 AM, Carlos E. R. wrote:

...

On 08/09/2020 00.08, Doug McGarrett wrote:

...

...

...

What you are locating are the programs, libraries and configuration files that make up syslog, not the log created by it, which all live as files under /var/log/.

If you want to know if syslog is active, you do instead:

systemctl status syslog I guess it's not active: doug@linux1:~> systemctl status syslog Unit syslog.service could not be found. doug@linux1:~>

more than likely, not even installed.  It is not included in a Tw install, but added after install if wanted.

That's curious. I didn't know that TW doesn't install it by default.

linux1:~ # zypper install syslog.service Loading repository data... Reading installed packages... 'syslog.service' not found in package names. Trying capabilities. No provider of 'syslog.service' found. Resolving package dependencies... Nothing to do. linux1:~ # --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

El 2020-09-08 a las 23:19 +0200, Atri Bhattacharya escribió:

Hi Doug and others, I hope I am not being discourteous, but would you mind drawing a line under this discussion on this mailing list please? 70-odd messages in and seems to have diverged from OP's initial query, and more into the territory of general discussions. Please either start a new topic (like "how to enable syslog on TW") or take the current discussion to the general mailing list. Doesn't help other searching for the same problem otherwise.

Thanks and best wishes.

I understand you are confused, but all we are doing is trying to help Doug with his problem. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))

On 9/8/20 5:19 PM, Atri Bhattacharya wrote:

Hi Doug and others, I hope I am not being discourteous, but would you mind drawing a line under this discussion on this mailing list please? 70-odd messages in and seems to have diverged from OP's initial query, and more into the territory of general discussions. Please either start a new topic (like "how to enable syslog on TW") or take the current discussion to the general mailing list. Doesn't help other searching for the same problem otherwise.

Thanks and best wishes.

NOTICE TO ALL: Somebody send me the email address of the general mailing list. However, I think it's just as well to stop this particular thread. Atri is correct--it has devolved into a lot of off-topic items. I will read and answer anything I have received up until now under this topic. and then I will not pursue it. I am thankful for all those who have dedicated their time and interest to the problem, which, up until now has not resurfaced. (Praise God!) --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 10:20 PM, Doug McGarrett wrote:

On 9/6/20 8:02 PM, Lew Wolfgang wrote:

...

On 9/6/20 4:06 PM, Patrick Shanahan wrote:

...

...

...

...

Good point, what version of Leap are you running, Doug?  If you're not sure you can "cat /etc/os-release". As someone else pointed out, the system is not Leap, it's Tumbleweed.

...

Can you try "journalctl | |grep -i panic" as root and see what happens?

locate does not find cournalctl OBVIOUS TYPO> I HAD IT RIGHT ON THE BASH SCREEN. --doug

...

Regards, Lew

Am starting memtest now and will not be able to access this machine until tomorrow. I'll let it run all nite. --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 9:51 PM, Carlos E. R. wrote:

On 07/09/2020 01.06, Patrick Shanahan wrote:

...

* Doug McGarrett <> [09-06-20 19:02]:

...

...

On 06/09/2020 22.27, Doug McGarrett wrote:

...

On 9/6/20 3:41 PM, Carlos E. R. wrote:

...

On 06/09/2020 21.35, Doug McGarrett wrote:

...

...

> Does anyone have a suspicion as to what else might cause a sudden > suspension of function?

Not till you get a view of console 10 with some message, or perchance if there is something in the logs. Look for the word "panic". If you are lucky, the kernel might had have time to write something.

What log should I look in? Can you give me a name, or names?

Lew told you in his post. It is the same file where it has been for decades: /var/log/messages ran "locate messages" and there is no file in /var/log/ or anywhere

On 9/6/20 5:47 PM, Carlos E. R. wrote: that looks like it is related to the os. All related to some application file or other.

...

...

...

...

   Don't know what you mean by "console 10"

I told you today in another post. Press ctrl-alt-F10 when it happens. That's console number 10.

so maybe no syslog invocation, ie: all systemd-journal There are two files the beginning of which are called systemd-journal  A whole bunch of others are called systemd-journald- One file called /usr/lib/systemd/system/systemd-journal-catalog-update.service and another called /usr/lib/systemd/system/systemd-journal-flush.service Neither of these seem to have anything suspicius in them.

Others in this list are called systemd-journald-*

Does tumbleweed now default to no syslog daemon?

...

tell him how to find "panic" in the journal.

--doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 12:35 PM, Doug McGarrett wrote:

Does anyone have a suspicion as to what else might cause a sudden suspension of function?

Could be lots of different things. Carlos' suggestion is a good one: "Kernel panic. Look in console 10: press ctrl-alt-f10 if it still works. Take a photo, and upload to susepaste and post the link." Let me throw some mud on the wall and see what sticks: I don't recall keyboard light flashing being done by the operating system, but I have seen it when there's a failure that the power-on self-test (POST) routine in the BIOS detects.  There are failures that would prevent even the BIOS from displaying the error on the screen, in which case it might flash the keyboard lights in coded flashes to point to the problem.  I've seen this happen with SIMM problems.  The computer manufacturer might even publish a list of the codes, SuperMicro does.  Three quick flashes followed by two long ones might be bad memory, for example.  So see if there's a pattern in the flashing lights. Have you considered booting off of the openSUSE DVD and running the memtest program?  It loads into ram and will run continuously until you stop it or it crashes.  I've had this running for hours before it finally crashed, or reported a problem. Over the years I've also seen bad plugin cards causing odd problems. Is your graphics adapter on a PCI card, or built into the motherboard? What kind o PCI cards do you have?  Even one that's not being used, but plugged in, could be causing problems. Did you check the logs for errors?  /var/log/messages would be one place to look.  Sometimes errors will be written right before a crash. I've also seen weak power supplies causing weird disk problems, and I've seen flaky SATA cables. Is there anything that stands out preceding the freeze?  I remember one version of Thunderbird that would freeze Plasma if I did a certain thing with it. Intermittent problems are always a bitch. Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/6/20 12:35 PM, Doug McGarrett wrote:

...

Does anyone have a suspicion as to what else might cause a sudden suspension of function?

Could be lots of different things.

Carlos' suggestion is a good one:

"Kernel panic. Look in console 10: press ctrl-alt-f10 if it still works. Take a photo, and upload to susepaste and post the link."

Let me throw some mud on the wall and see what sticks:

I don't recall keyboard light flashing being done by the operating system, but I have seen it when there's a failure that the power-on self-test (POST) routine in the BIOS detects.  There are failures that would prevent even the BIOS from displaying the error on the screen, in which case it might flash the keyboard lights in coded flashes to point to the problem.  I've seen this happen with SIMM problems.  The computer manufacturer might even publish a list of the codes, SuperMicro does.  Three quick flashes followed by two long ones might be bad memory, for example.  So see if there's a pattern in the flashing lights. I would have to have the failure again and try and catch the light sequence, if any. I suppose it WILL fail again, what ever causes it.

Have you considered booting off of the openSUSE DVD and running the memtest program?  It loads into ram and will run continuously until you stop it or it crashes.  I've had this running for hours before it finally crashed, or reported a problem. Will do that JUST HAD ANOTHER WEIRD THING< CAPS LOCK IS OFF ACCORDING TO CAPS_LOCK LAMP< BUt as you could see, for a few seconds, the system was running "inverted" as it were. (If I pushed the caps-lock key,

On 9/6/20 4:11 PM, Lew Wolfgang wrote: the light came on and I got lower case. Now it's running OK.)

Over the years I've also seen bad plugin cards causing odd problems. Is your graphics adapter on a PCI card, or built into the motherboard? What kind o PCI cards do you have?  Even one that's not being used, but plugged in, could be causing problems.

Did you check the logs for errors?  /var/log/messages would be one place to look.  Sometimes errors will be written right before a crash.

There does not appear to be a file called /var/log/messages There is a slew of files in /var/log, going as far back as June (I bought the machine in June) and just a few in September. There is a very long  file called /var/log> In it I found the following line, which I thought peculiar, but not threatening: "[  2702.896] (EE) event15 - Kensington      Kensington USB/PS2 Orbit: client bug: event processing lagging behind by 28ms, your system is too slow" Kensington is my trackball. Earlier in the file, I found this, which has nothing to do with failure, I guess, but I don't understand it: 8.669] (II) event16 - HP USB Webcam: HP USB Webcam: is tagged by udev as: Keyboard [     8.670] (II) event16 - HP USB Webcam: HP USB Webcam: device is a keyboard [     8.670] (II) event16 - HP USB Webcam: HP USB Webcam: device removed [     8.699] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/input/input16/event16" [     8.699] (II) XINPUT: Adding extended input device "HP USB Webcam: HP USB Webcam" (type: KEYBOARD, id 11) [     8.699] (**) Option "xkb_layout" "us" [     8.703] (II) event16 - HP USB Webcam: HP USB Webcam: is tagged by udev as: Keyboard [     8.703] (II) event16 - HP USB Webcam: HP USB Webcam: device is a keyboard [     8.704] (II) The webcam is connected, but I don't know why it would be listed as keyboard. I don't have a camera app installed yet in this new computer and even newer OS version.

I've also seen weak power supplies causing weird disk problems, and I've seen flaky SATA cables.

Is there anything that stands out preceding the freeze?  I remember one version of Thunderbird that would freeze Plasma if I did a certain thing with it.

I wish I could remember...I might have been using Thunderbird, AAMOF. I get a bunch of email, particularly with regard to this, and there are a number of long threads completely unrelated to Suse--some of them I read, many I don't.

Intermittent problems are always a bitch.

Tell me about it! Spent my working life as an RF engineer. --doug

Regards, Lew

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 06/09/2020 23.24, Doug McGarrett wrote:

...

On 9/6/20 4:11 PM, Lew Wolfgang wrote:

...

On 9/6/20 12:35 PM, Doug McGarrett wrote:

...

Does anyone have a suspicion as to what else might cause a sudden suspension of function?

...

...

Did you check the logs for errors? /var/log/messages would be one place to look.  Sometimes errors will be written right before a crash. There does not appear to be a file called /var/log/messages There is a slew of files in /var/log, going as far back as June (I bought the machine in June) and just a few in September. There is a very long  file called /var/log> In it I found the following line, which I thought peculiar, but not threatening /var/log is a directory, and in it there has to be a file named "messages". If not, your system is borked again. There is a directory called /var/log with 32 entriescd /, but "messages" is not one of them. [  2702.896] (EE) event15 - Kensington      Kensington USB/PS2 Orbit: client bug: event processing lagging behind by 28ms, your system is too slow"

Irrelevant. Yes, I know. It just surprized me.

...

Kensington is my trackball. Earlier in the file, I found this, which has nothing to do with failure, I guess, but I don't understand it:

8.669] (II) event16 - HP USB Webcam: HP USB Webcam: is tagged by udev as: Keyboard

Irrelavant.

Look for lines with "panic" in them. Could not find any. Isn't there a way to use grep to check every file in

On 9/6/20 5:54 PM, Carlos E. R. wrote: the system for the word? --doug

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

El 2020-09-07 a las 12:53 +0100, Daniel Morris escribió:

On Sun, Sep 06, 2020 at 01:11:25PM -0700, Lew Wolfgang wrote:

...

Let me throw some mud on the wall and see what sticks:

Did you check the logs for errors?  /var/log/messages would be one place to look.  Sometimes errors will be written right before a crash.

I think Tumbleweed defaults to flushing/not storing journals between runs, which I've thought was a folly under Leap when hunting for what's changed/once worked/no-longer works on several machines.

Gosh :-( No permanent journal and no syslog. Just wonderful :-(

The file:

/etc/systemd/journald.conf

needs to have this set/not commented out (as root)

Storage=persistent

then restart the journal service (without the leading hash)

#systemctl restart systemd-journald

I think you only need to create the persistent directory. Just creating "/var/log/journal/" should do it - I don't know if restarting is needed. I know that this does work on Leap. Doug, please do: ls /var/log/journal/ If you get: ls: cannot access '/var/log/journal/': No such file or directory then do: mkdir /var/log/journal/ as root, obviously. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))

On 9/7/20 8:25 AM, Patrick Shanahan wrote:

* Carlos E. R. [09-07-20 08:18]:

...

El 2020-09-07 a las 12:53 +0100, Daniel Morris escribió:

...

On Sun, Sep 06, 2020 at 01:11:25PM -0700, Lew Wolfgang wrote:

...

Let me throw some mud on the wall and see what sticks:

Did you check the logs for errors?  /var/log/messages would be one place to look.  Sometimes errors will be written right before a crash. I think Tumbleweed defaults to flushing/not storing journals between runs, which I've thought was a folly under Leap when hunting for what's changed/once worked/no-longer works on several machines. Gosh :-(

No permanent journal and no syslog. Just wonderful :-(

...

The file:

/etc/systemd/journald.conf

needs to have this set/not commented out (as root)

Storage=persistent

then restart the journal service (without the leading hash)

#systemctl restart systemd-journald I think you only need to create the persistent directory. Just creating "/var/log/journal/" should do it - I don't know if restarting is needed.

I know that this does work on Leap.

Doug, please do:

ls /var/log/journal/

If you get:

ls: cannot access '/var/log/journal/': No such file or directory

then do:

mkdir /var/log/journal/

as root, obviously. maybe first read man journald.conf

Gobbledigook. --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/7/20 9:12 AM, Daniel Morris wrote:

Hi Carlos,

On Mon, Sep 07, 2020 at 02:16:23PM +0200, Carlos E. R. wrote:

...

...

The file:

/etc/systemd/journald.conf

needs to have this set/not commented out (as root)

Storage=persistent

then restart the journal service (without the leading hash)

#systemctl restart systemd-journald I think you only need to create the persistent directory. Just creating "/var/log/journal/" should do it - I don't know if restarting is needed.

I know that this does work on Leap.

Doug, please do:

ls /var/log/journal/

If you get:

ls: cannot access '/var/log/journal/': No such file or directory

then do:

mkdir /var/log/journal/

as root, obviously. I think you also need the right ownership and permissions in /var/log and doing the above is going to depend on the umask of root, too. You're aiming for:

drwxr-sr-x 1 root systemd-journal 64 Jan 18 2019 journal

so that becomes:

#mkdir /var/log/journal #chgrp systemd-journal /var/log/journal #chmod 755 /var/log/journal; chmod g+s /var/log/journal

drwxr-sr-x  3 root systemd-journal 4096 Aug 28 05:05 . drwxr-xr-x 16 root root            4096 Sep  7 14:04 .. drwxr-sr-x  2 root systemd-journal 4096 Sep  5 19:12 f5b8154985b1452e9f0ec7020a049032 linux1:/var/log/journal # Here's the sequence of events, including my typos, etc: linux1:/home/doug # mkdir /var/log/journal mkdir: cannot create directory ‘/var/log/journal’: File exists linux1:/home/doug # chgrp systemd-journal /var/log/journal linux1:/home/doug # chmod 755 /var/log/journal; chmod g+s /var/log/journal linux1:/home/doug # cd /var/log linux1:/var/log # ls -la total 24316 drwxr-xr-x 16 root     root                4096 Sep  7 14:04 . drwxr-xr-x 11 root     root                4096 Jun 13  2014 .. -rw-r--r--  1 root     root               14012 Sep  3 16:53 alternatives.log drwxr-xr-x  2 root     root                4096 Aug 25 14:06 apparmor drwx------  2 root     root                4096 Aug 25 10:47 audit -rw-------  1 root     root               67360 Sep  7 14:04 boot.log -rw-rw----  1 root     utmp                1152 Sep  2 22:14 btmp drwxr-x---  2 chrony   chrony              4096 Aug 25 14:43 chrony drwxr-xr-x  2 lp       lp                  4096 Sep  2 23:54 cups drwxr-x---  2 firebird firebird            4096 Aug 25 08:32 firebird -rw-r-----  1 root     root                   0 Aug 28 20:55 firewalld drwxr-sr-x  3 root     systemd-journal     4096 Aug 28 05:05 journal drwx------  2 root     root                4096 Aug 25 09:28 krb5 -rw-rw-r--  1 root     utmp              137532 Sep  2 01:01 lastlog lrwxrwxrwx  1 root     root                  18 Aug 28 20:40 log -> /run/initramfs/log drwx------  2 mysql    mysql               4096 Aug 25 14:18 mysql -rw-------  1 root     root               10325 Aug 29 20:27 pbl.log -rw-r-----  1 root     root             9431078 Sep  7 14:05 pk_backend_zypp -rw-r-----  1 root     root            12822592 Sep  4 18:32 pk_backend_zypp-1 drwx------  2 root     root                4096 Aug 28 20:37 private -rw-r--r--  1 root     root                1040 Aug 20 06:24 README drwxr-x---  2 root     root                4096 Aug 25 17:37 samba -rw-r-----  1 root     root              156302 Sep  7 14:25 snapper.log drwxr-x---  2 root     root                4096 Aug 25 11:39 tuned drwxr-xr-x  2 root     root                4096 Aug 29 00:18 updateTestcase-2020-08-29-00-18-17 -rw-r-----  1 root     root                3068 Sep  7 14:04 wpa_supplicant.log -rw-rw-r--  1 root     utmp              103680 Sep  7 14:06 wtmp -rw-r--r--  1 root     root               33094 Sep  7 14:04 Xorg.0.log -rw-r--r--  1 root     root               28358 Sep  6 22:37 Xorg.0.log.old drwx------  9 root     root                4096 Sep  4 19:42 YaST2 drwxr-x---  2 root     root                4096 Aug 25 16:01 zypp -rw-r-----  1 root     root             1734800 Sep  7 14:24 zypper.log -rw-r-----  1 root     root              356692 Sep  4 18:36 zypper.log-20200905.xz linux1:/var/log # ./journal bash: ./journal: Is a directory linux1:/var/log # cd ./journal linux1:/var/log/journal # ls -la total 12 drwxr-sr-x  3 root systemd-journal 4096 Aug 28 05:05 . drwxr-xr-x 16 root root            4096 Sep  7 14:04 .. drwxr-sr-x  2 root systemd-journal 4096 Sep  5 19:12 f5b8154985b1452e9f0ec7020a049032 linux1:/var/log/journal # --doug

Whilst the 'persistence if there once was' rule was a nice courtesy for legacy systems, I still think setting an option in a config file is far cleaner, and much easier to audit/check later. I don't like things being a side-effect of something else, it's not a good policy - proven by staring at the clean install on my Dad's "new" machine in bemusement at where the logs weren't (and hadn't been for the few months things had been leaping along nicely).

For all the hoopla about moving from text files to database, I've grown to really like it, and journalctl for viewing. Grossly long lines that are scrollable with the arrow keys on badly setup terminals is just one of the niceties.

Daniel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Mon, 2020-09-07 at 14:16 +0200, Carlos E. R. wrote:

El 2020-09-07 a las 12:53 +0100, Daniel Morris escribió:

...

On Sun, Sep 06, 2020 at 01:11:25PM -0700, Lew Wolfgang wrote:

...

Let me throw some mud on the wall and see what sticks:

Did you check the logs for errors? /var/log/messages would be one place to look. Sometimes errors will be written right before a crash.

I think Tumbleweed defaults to flushing/not storing journals between runs, which I've thought was a folly under Leap when hunting for what's changed/once worked/no-longer works on several machines.

Gosh :-(

No permanent journal and no syslog. Just wonderful :-(

'Default' installs have systemd-logger installed (which essentially is just a README and the /var/log/journal directory) This package is recommended by patterns-base-enhanced_base - users without recommended packages better not be surprised if recommended functionality is not present :) Cheers, Dominique

El 2020-09-07 a las 14:45 -0400, Doug McGarrett escribió:

On 9/7/20 8:16 AM, Carlos E. R. wrote:

...

El 2020-09-07 a las 12:53 +0100, Daniel Morris escribió:

...

On Sun, Sep 06, 2020 at 01:11:25PM -0700, Lew Wolfgang wrote:

...

...

I think you only need to create the persistent directory. Just creating "/var/log/journal/" should do it - I don't know if restarting is needed.

I know that this does work on Leap.

Doug, please do:

ls /var/log/journal/

linux1:/home/doug # ls /var/log/journal/ f5b8154985b1452e9f0ec7020a049032 linux1:/home/doug

Ok, then you do have a permanent journal, and there is no "panic" recorded there. Bad luck. No idea of what caused your problem till it happens again. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))

El 2020-09-07 a las 14:42 -0400, Doug McGarrett escribió:

On 9/7/20 7:53 AM, Daniel Morris wrote:

...

On Sun, Sep 06, 2020 at 01:11:25PM -0700, Lew Wolfgang wrote:

...

Storage=persistent

then restart the journal service (without the leading hash)

#systemctl restart systemd-journald

Did that. Reran. Still no "panic"

linux1:/home/doug # systemctl restart systemd-journald linux1:/home/doug # journalctl | grep -i panic linux1:/home/doug #

You are still using "su". We told you to use instead "su -". That is Sierra Uniform 'dash'". It will not change the no panic situation, but your insistence in keeping using "su" instead of "su -" will cause you trouble. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))