[opensuse-support] cpu temperature
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? --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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:
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? Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
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 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/5/20 9:04 PM, Doug McGarrett 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 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 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:
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
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:~ #
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.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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:~ #
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.
I will do that if (when) it happens again. --doug
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 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 Sun, 06 Sep 2020, 10:37:25 +0200, 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:~ #
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 Cheers. l8er manfred
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 9/6/20 7:43 AM, Carlos E. R. wrote:
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.
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. Does anyone have a suspicion as to what else might cause a sudden suspension of function? --doug --doug
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
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 9/6/20 3:41 PM, Carlos E. R. wrote:
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.
What log should I look in? Can you give me a name, or names? Don't know what you mean by "console 10"--this is a new world for me, delousing a hardware (?) or perhaps software op killer, altho it seems logical to me that it would be hardware--I'm not doing anything differently in software when the failure happens. --doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
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 There is no log called by that name in my computer.
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. OK, I have that written down, for the next time the problem occurs. Did not understand "console."
--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 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
* Doug McGarrett <dmcgarrett@optonline.net> [09-06-20 19:02]:
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
so maybe no syslog invocation, ie: all systemd-journal tell him how to find "panic" in the journal. -- (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/6/20 4:06 PM, Patrick Shanahan wrote:
- Doug McGarrett <dmcgarrett@optonline.net> [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 07/09/2020 02.02, 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".
Tumbleweed. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 9/6/20 8:02 PM, Lew Wolfgang wrote:
On 9/6/20 4:06 PM, Patrick Shanahan wrote:
- Doug McGarrett <dmcgarrett@optonline.net> [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 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 <dmcgarrett@optonline.net> [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 -- 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))
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 <dmcgarrett@optonline.net> [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 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Doug McGarrett <dmcgarrett@optonline.net> [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 <dmcgarrett@optonline.net> [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
- Doug McGarrett <dmcgarrett@optonline.net> [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 <dmcgarrett@optonline.net> [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. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out
On 9/7/20 3:27 PM, Patrick Shanahan wrote: there actually is an lgrep in the system, and I installed it and ran it with the same result--nada. 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. --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 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 <dmcgarrett@optonline.net> [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))
* Doug McGarrett <dmcgarrett@optonline.net> [09-07-20 15:55]:
- Doug McGarrett <dmcgarrett@optonline.net> [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 <dmcgarrett@optonline.net> [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. Then I ran grep -i etc. having looked up grep in "Linux in a Nutshell" my Linux reference book. But it turns out
On 9/7/20 3:27 PM, Patrick Shanahan wrote: there actually is an lgrep in the system, and I installed it and ran it with the same result--nada.
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.
guess you need to LOOK more closely. Lew did make a mistake but the character is not a small case L, he included a second pipe char, "|". ie: | |grep not | lgrep note the difference -- (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/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 Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang <wolfgang@sweet-haven.com> 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
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 <wolfgang@sweet-haven.com> 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
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... -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
On Mon, 7 Sep 2020 23:46:53 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> 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...
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
On Mon, 7 Sep 2020 23:46:53 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> 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... 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 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Doug McGarrett <dmcgarrett@optonline.net> [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." <robin.listas@telefonica.net> 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... 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 9/8/20 2:50 PM, Patrick Shanahan wrote:
- Doug McGarrett <dmcgarrett@optonline.net> [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
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 <dmcgarrett@optonline.net> wrote:
On 9/8/20 2:50 PM, Patrick Shanahan wrote:
- Doug McGarrett <dmcgarrett@optonline.net> [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
* Dave Howorth <dave@howorth.org.uk> [09-09-20 05:42]:
On Tue, 8 Sep 2020 18:20:04 -0400 Doug McGarrett <dmcgarrett@optonline.net> wrote:
On 9/8/20 2:50 PM, Patrick Shanahan wrote:
- Doug McGarrett <dmcgarrett@optonline.net> [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 ... 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. -- (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 Wed, 9 Sep 2020 07:49:37 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
- Dave Howorth <dave@howorth.org.uk> [09-09-20 05:42]:
On Tue, 8 Sep 2020 18:20:04 -0400 Doug McGarrett <dmcgarrett@optonline.net> wrote:
On 9/8/20 2:50 PM, Patrick Shanahan wrote:
- Doug McGarrett <dmcgarrett@optonline.net> [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
El 2020-09-08 a las 14:05 -0400, Doug McGarrett escribió:
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:
...
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!
Man, you installed 'lv', it is in your own email. Date: Mon, 7 Sep 2020 14:29:23 -0400 From: Doug McGarrett <dmcgarrett@...> To: wolfgang@...., opensuse-support@opensuse.org Subject: Re: [opensuse-support] cpu temperature ... 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 # -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
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
El 2020-09-08 a las 18:26 -0400, Doug McGarrett escribió:
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.
Well, you can do it the same way you installed it, with zypper: zypper remove lv But that will probably not remove the rest of the cruft it installed with it. Or, you can try yast software management module, and in "option" mark "clean up when deleting packages". Then search for "lv" and remove it. Next time, please don't be so fast installing things we did not tell you to install. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
On Tue, 8 Sep 2020 14:05:27 -0400 Doug McGarrett <dmcgarrett@optonline.net> wrote:
On Mon, 7 Sep 2020 23:46:53 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> 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... 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
El 2020-09-07 a las 14:30 -0700, Lew Wolfgang escribió:
On 9/7/20 2:13 PM, Dave Howorth wrote:
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."
I knew an specialized version of 'grep', called 'cgrep' made perhaps by Bell Labs people or by Lucent, that did a similar thing with log reports of the Lucent 5ESSS. Now a version of it is available as free source. http://awgn.github.io/cgrep/ and others. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang <wolfgang@sweet-haven.com> 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
El 2020-09-07 a las 18:16 -0400, Doug McGarrett escribió:
On 9/7/20 5:13 PM, Dave Howorth wrote:
On Mon, 7 Sep 2020 13:53:18 -0700 Lew Wolfgang <> wrote:
...
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 the bios screen EVERY TIME to set it to boot from cd,
This is intentional for security. Ancient times were naive. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
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 9/7/20 3:08 PM, Doug McGarrett wrote:
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.
You already showed that your journal is persistent by seeing multiple boots when running "journalctl --list-boots", so there's no need to worry about syslog. If a "journalctl | grep -i panic" didn't find anything then kernel panics aren't the problem. You might also try "journalctl | grep -i error" to see what pops up. If there are too many routine errors to sift through, you might also try "journalctl | grep -i error |grep /dev/sd" to see if there are any disk specific errors. You could even just type "journalctl" and page through the output looking at the entries preceding the time of the last crash. Who knows what might pop up? "locate" is a valuable tool, but it's not what you would use to see if a package is installed AND enabled. There's plenty of documentation around if you want to become more conversant with Linux administration. Maybe start looking at yast2 (GUI), zypper, systemctl, journalctl, and others. Just remember the openSUSE motto: "Have a lot of fun..." Regards, Lew
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)
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:~>
To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Doug McGarrett <dmcgarrett@optonline.net> [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
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. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
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
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. -- Atri Bhattacharya Tue 8 Sep 23:11:29 CEST 2020 Sent from openSUSE Tumbleweed on my laptop. -- 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 08/09/2020 23:39, Carlos E. R. wrote:
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.
Could start a new list opensuse-doug -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
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
El 2020-09-07 a las 14:29 -0400, Doug McGarrett escribió:
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.
On 9/6/20 10:34 PM, Lew Wolfgang wrote: linux1:/home/doug # journalctl | lgrep -i panic If 'lgrep' is not a typo you can use command-not-found to lookup the package
It is not lgrep, it is plain grep. Golf Romeo Echo Papa.
that contains it, like this: cnf lgrep linux1:/home/doug # journalctl | grep -i panic (return to linux1) Had to install lgrep:
Please remove it.
linux1:/home/doug # journalctl | lgrep -i panic linux1:/home/doug #
No panic anywhere.
Perhaps your journal is volatile. Please read the other email where I tell you how to do it permanent.
Ran memtest overnite. All clean.
Good. -- Cheers Carlos E. R. (from openSUSE Leap 15.1 x86_64 (Minas Tirith))
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 07/09/2020 01.06, Patrick Shanahan wrote:
- Doug McGarrett <> [09-06-20 19:02]:
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.
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
Does tumbleweed now default to no syslog daemon?
tell him how to find "panic" in the journal.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 07/09/2020 04.18, Doug McGarrett wrote:
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 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:
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.
Gosh. You were told to type a command, not to start searching for the journal.
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.
Just paste this line in a terminal: journalctl | grep -i panic -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.1 x86_64 (Minas Tirith))
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2020-09-06 at 13:11 -0700, 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?
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,
I do. It is how the kernel signals a kernel panic. I saw it in the sources once.
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.
The BIOS uses beeps, and yes, they are coded and there should be a list, but it depends on each brand. It is also possible to connect a PCI card that will display a POST error number, but modern boards may instead use a combination of internal leds, which is far easier than output something on the USB bus to some peripheral. ...
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.
Yes, this is the first thing to check.
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.
Indeed :-( - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCX1VEbhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV1rQAn2CqsGru9oks84um6RoG mIMhnd8TAJ0TCaGuWz1nLrOlFo6REEvYimhe0A== =r8NF -----END PGP SIGNATURE-----
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.
"[ 2702.896] (EE) event15 - Kensington Kensington USB/PS2 Orbit: client bug: event processing lagging behind by 28ms, your system is too slow"
Irrelevant.
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. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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
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. 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 (On machines that have been upgraded from way-back-when, journald spots the old /var/log/messages and carries on being persistent). Daniel -- 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))
* Carlos E. R. <robin.listas@telefonica.net> [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 -- (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/7/20 8:25 AM, Patrick Shanahan wrote:
- Carlos E. R. <robin.listas@telefonica.net> [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
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 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 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
Ken Schneider
On Sep 7, 2020, at 3:08 PM, Doug McGarrett <dmcgarrett@optonline.net> wrote:
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 chmod 2755 /var/log/journal
Will also work. Ken
-- 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
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:
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/
linux1:/home/doug # ls /var/log/journal/ f5b8154985b1452e9f0ec7020a049032 linux1:/home/doug
If you get:
ls: cannot access '/var/log/journal/': No such file or directory
then do:
mkdir /var/log/journal/
as root, obviously.
-- 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 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))
On 9/7/20 7:53 AM, Daniel Morris wrote:
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.
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 Did that. Reran. Still no "panic"
linux1:/home/doug # systemctl restart systemd-journald linux1:/home/doug # journalctl | grep -i panic linux1:/home/doug # --doug
(On machines that have been upgraded from way-back-when, journald spots the old /var/log/messages and carries on being persistent).
Daniel
-- 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 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=persistentthen 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))
participants (12)
-
Atri Bhattacharya -
Carlos E. R. -
Daniel Morris -
Dave Howorth -
Dominique Leuenberger / DimStar -
Doug McGarrett -
gumb -
jdd＠dodin.org -
Kenneth Schneider -
Lew Wolfgang -
Manfred Hollstein -
Patrick Shanahan