[opensuse] I can't start a java process.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cer@Telcontar:~> gigacontrol log4j:WARN No appenders could be found for logger (net.sourceforge.cridmanager.Settings). log4j:WARN Please initialize the log4j system properly. Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread <============= at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:717) at sun.java2d.Disposer.lambda$static$0(Disposer.java:94) at java.security.AccessController.doPrivileged(Native Method) at sun.java2d.Disposer.<clinit>(Disposer.java:83) at sun.awt.X11GraphicsConfig.<init>(X11GraphicsConfig.java:132) at sun.java2d.xr.XRGraphicsConfig.<init>(XRGraphicsConfig.java:41) at sun.java2d.xr.XRGraphicsConfig.getConfig(XRGraphicsConfig.java:54) at sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:262) at sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227) at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:128) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at java.awt.Toolkit$2.run(Toolkit.java:860) at java.awt.Toolkit$2.run(Toolkit.java:855) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854) at sun.swing.SwingUtilities2.getSystemMnemonicKeyMask(SwingUtilities2.java:2020) at javax.swing.plaf.basic.BasicLookAndFeel.initComponentDefaults(BasicLookAndFeel.java:1158) at javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(MetalLookAndFeel.java:431) at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(BasicLookAndFeel.java:148) at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLookAndFeel.java:1577) at javax.swing.UIManager.setLookAndFeel(UIManager.java:539) at javax.swing.UIManager.setLookAndFeel(UIManager.java:579) at javax.swing.UIManager.initializeDefaultLAF(UIManager.java:1349) at javax.swing.UIManager.initialize(UIManager.java:1459) at javax.swing.UIManager.maybeInitialize(UIManager.java:1426) at javax.swing.UIManager.getInstalledLookAndFeels(UIManager.java:419) at net.sourceforge.cridmanager.Settings.initLookAndFeel(Settings.java:125) at net.sourceforge.cridmanager.Settings.init(Settings.java:104) at net.sourceforge.cridremote.RemoteControlView.main(RemoteControlView.java:795) cer@Telcontar:~> The gigacontrol script is: #!/bin/bash #cd ~/Moria/cridmanager cd ~/Moria/Gigaset/cridmanager exec java -Xmx1G -cp cridmanager-1.4.3.jar net.sourceforge.cridremote.RemoteControlView ... This is absurd, I have 23 gigs free. cer@Telcontar:~> free -h total used free shared buff/cache available Mem: 31Gi 6,9Gi 11Gi 308Mi 13Gi 23Gi Swap: 99Gi 881Mi 99Gi cer@Telcontar:~> - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXoe4SBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVhXMAnik0R5/ztnOPGm2UJFWX +QTxMZ7gAJ9kxhhSRVv6xYjBQXAZvXTYfRZFzw== =kigk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
04.04.2020 01:27, Carlos E. R. пишет:
cer@Telcontar:~> gigacontrol log4j:WARN No appenders could be found for logger (net.sourceforge.cridmanager.Settings). log4j:WARN Please initialize the log4j system properly. Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread <=============
...
The gigacontrol script is:
#!/bin/bash #cd ~/Moria/cridmanager cd ~/Moria/Gigaset/cridmanager exec java -Xmx1G -cp cridmanager-1.4.3.jar net.sourceforge.cridremote.RemoteControlView
May be it needs more memory than you allowed it to have. Read what -Xmx option does.
...
This is absurd,
Not everything you do not know or understand is absurd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 08.53, Andrei Borzenkov wrote:
04.04.2020 01:27, Carlos E. R. пишет:
cer@Telcontar:~> gigacontrol log4j:WARN No appenders could be found for logger (net.sourceforge.cridmanager.Settings). log4j:WARN Please initialize the log4j system properly. Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread <=============
...
The gigacontrol script is:
#!/bin/bash #cd ~/Moria/cridmanager cd ~/Moria/Gigaset/cridmanager exec java -Xmx1G -cp cridmanager-1.4.3.jar net.sourceforge.cridremote.RemoteControlView
May be it needs more memory than you allowed it to have. Read what -Xmx option does.
I rebooted and it worked fine, as it has worked for years. Possibly after some hours it will fail to start - or many not, I rebooted to a previous kernel.
...
This is absurd,
Not everything you do not know or understand is absurd.
Then explain it to me, why after the last update I suddenly have those problems. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
May be it needs more memory than you allowed it to have. Read what -Xmx option does.
I rebooted and it worked fine, as it has worked for years. Possibly after some hours it will fail to start - or many not, I rebooted to a previous kernel.
...
This is absurd,
Not everything you do not know or understand is absurd.
Then explain it to me, why after the last update I suddenly have those problems.
Insufficient data. It seems your "gigacontrol" needs for heapspace than it was given, that's all anyone can explain. -- Per Jessen, Zürich (12.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 13.37, Per Jessen wrote:
Carlos E. R. wrote:
May be it needs more memory than you allowed it to have. Read what -Xmx option does.
I rebooted and it worked fine, as it has worked for years. Possibly after some hours it will fail to start - or many not, I rebooted to a previous kernel.
...
This is absurd,
Not everything you do not know or understand is absurd.
Then explain it to me, why after the last update I suddenly have those problems.
Insufficient data. It seems your "gigacontrol" needs for heapspace than it was given, that's all anyone can explain.
Nononono. It has been working for years. Now it fails. Firefox fails to open tabs, tabs crash. gkrelm crashes. Then I get messages about not being able to open threads, temporarily no resources. Sometimes in the shell, or with java. java simply is more sensitive to the problem. I get coredumps of everything. Finally, I have to reboot (with crashes) and everything works. I hibernate for the night, and next morning after restore and a while, problems start again. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 04/04/2020 13.37, Per Jessen wrote:
Carlos E. R. wrote:
May be it needs more memory than you allowed it to have. Read what -Xmx option does.
I rebooted and it worked fine, as it has worked for years. Possibly after some hours it will fail to start - or many not, I rebooted to a previous kernel.
...
This is absurd,
Not everything you do not know or understand is absurd.
Then explain it to me, why after the last update I suddenly have those problems.
Insufficient data. It seems your "gigacontrol" needs more heapspace than it was given, that's all anyone can explain.
Nononono. It has been working for years. Now it fails.
That is still all the explanation available based on the data you have provided.
Firefox fails to open tabs, tabs crash. gkrelm crashes. Then I get messages about not being able to open threads, temporarily no resources. Sometimes in the shell, or with java. java simply is more sensitive to the problem. I get coredumps of everything. Finally, I have to reboot (with crashes) and everything works. I hibernate for the night, and next morning after restore and a while, problems start again.
I have a 15.1 desktop in the office next door, maybe I'll go patch that and see if it misbehaves the same way. -- Per Jessen, Zürich (12.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 13.54, Per Jessen wrote:
Carlos E. R. wrote:
On 04/04/2020 13.37, Per Jessen wrote:
Carlos E. R. wrote:
May be it needs more memory than you allowed it to have. Read what -Xmx option does.
I rebooted and it worked fine, as it has worked for years. Possibly after some hours it will fail to start - or many not, I rebooted to a previous kernel.
...
This is absurd,
Not everything you do not know or understand is absurd.
Then explain it to me, why after the last update I suddenly have those problems.
Insufficient data. It seems your "gigacontrol" needs more heapspace than it was given, that's all anyone can explain.
Nononono. It has been working for years. Now it fails.
That is still all the explanation available based on the data you have provided.
And I'm expanding the info. It is something different, the java process is running now just fine after a reboot. For some reason Linux is out of resources, not for java, but for everything. Many processes fail to start, only that java prints the error and others do not. For example, the other day I got: cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
Firefox fails to open tabs, tabs crash. gkrelm crashes. Then I get messages about not being able to open threads, temporarily no resources. Sometimes in the shell, or with java. java simply is more sensitive to the problem. I get coredumps of everything. Finally, I have to reboot (with crashes) and everything works. I hibernate for the night, and next morning after restore and a while, problems start again.
I have a 15.1 desktop in the office next door, maybe I'll go patch that and see if it misbehaves the same way.
Please see the thread "Everything is coredumping". You can see there debug output with this error: #1 0x00007efbf61b6bec in g_log_default_handler (log_domain=log_domain@entry=0x7efbf61f8b8e "GLib", log_level=log_level@entry=6, message=message@entry=0x565557843a60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=unused_data@entry=0x0) at gmessages.c:305 -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup. Have you got any custom settings that might affect that? -- Per Jessen, Zürich (14.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 14.22, Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
No. The only processes for which I used cgroups are clamav and maybe spamd. As I said, it was working ok till the update on April 1st. This machine is new, installed about a month ago. Ryzen 5 and AMD graphics. 32 gigabytes of ram. System disk is nvme m2. The system was cloned from the old machine, and was working fine till that update. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sat, Apr 04, 2020 at 02:37:37PM +0200, Carlos E. R. wrote:
On 04/04/2020 14.22, Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
No.
The only processes for which I used cgroups are clamav and maybe spamd.
As I said, it was working ok till the update on April 1st.
This machine is new, installed about a month ago. Ryzen 5 and AMD graphics. 32 gigabytes of ram. System disk is nvme m2. The system was cloned from the old machine, and was working fine till that update.
systemd might have a default user task limit of around 512. Are you using that many threads/tasks? Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
05.04.2020 09:33, Marcus Meissner пишет:
On Sat, Apr 04, 2020 at 02:37:37PM +0200, Carlos E. R. wrote:
On 04/04/2020 14.22, Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
No.
The only processes for which I used cgroups are clamav and maybe spamd.
As I said, it was working ok till the update on April 1st.
This machine is new, installed about a month ago. Ryzen 5 and AMD graphics. 32 gigabytes of ram. System disk is nvme m2. The system was cloned from the old machine, and was working fine till that update.
systemd might have a default user task limit of around 512.
As was mentioned in another post in this thread it is limits.conf. I do not see systemd interfering with NPROC on Leap 15.
Are you using that many threads/tasks?
bor@bor-Latitude-E5450:~/src/linux$ ps -eL -u bor | wc -l 794 bor@bor-Latitude-E5450:~/src/linux$ That is with three terminals, one Chromium, one Firefox, one running QEMU, one Thunderbird and deluge. Browsers have couple of tabs open each. Nothing spectacular. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
05.04.2020 09:50, Andrei Borzenkov пишет:
05.04.2020 09:33, Marcus Meissner пишет:
On Sat, Apr 04, 2020 at 02:37:37PM +0200, Carlos E. R. wrote:
On 04/04/2020 14.22, Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
No.
The only processes for which I used cgroups are clamav and maybe spamd.
As I said, it was working ok till the update on April 1st.
This machine is new, installed about a month ago. Ryzen 5 and AMD graphics. 32 gigabytes of ram. System disk is nvme m2. The system was cloned from the old machine, and was working fine till that update.
systemd might have a default user task limit of around 512.
As was mentioned in another post in this thread it is limits.conf. I do not see systemd interfering with NPROC on Leap 15.
Are you using that many threads/tasks?
bor@bor-Latitude-E5450:~/src/linux$ ps -eL -u bor | wc -l 794 bor@bor-Latitude-E5450:~/src/linux$
Sorry, it should have been bor@bor-Latitude-E5450:~/src/linux$ ps -L -u bor | wc -l 554 bor@bor-Latitude-E5450:~/src/linux$ Still over 512 :) And for comparison bor@bor-Latitude-E5450:~/src/linux$ ps -u bor | wc -l 93 bor@bor-Latitude-E5450:~/src/linux$ Browsers appear to use a lot of threads. GNOME daemons started as part of DE are using several threads each and there are a lot of them. So the above limit is trivially exceeded on any vanilla user system.
That is with three terminals, one Chromium, one Firefox, one running QEMU, one Thunderbird and deluge. Browsers have couple of tabs open each. Nothing spectacular.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2020 09.08, Andrei Borzenkov wrote:
05.04.2020 09:50, Andrei Borzenkov пишет:
05.04.2020 09:33, Marcus Meissner пишет:
On Sat, Apr 04, 2020 at 02:37:37PM +0200, Carlos E. R. wrote:
On 04/04/2020 14.22, Per Jessen wrote:
Carlos E. R. wrote:
...
systemd might have a default user task limit of around 512.
As was mentioned in another post in this thread it is limits.conf. I do not see systemd interfering with NPROC on Leap 15.
Are you using that many threads/tasks?
Yes... way more. And I did not know.
bor@bor-Latitude-E5450:~/src/linux$ ps -eL -u bor | wc -l 794 bor@bor-Latitude-E5450:~/src/linux$
Sorry, it should have been
bor@bor-Latitude-E5450:~/src/linux$ ps -L -u bor | wc -l 554 bor@bor-Latitude-E5450:~/src/linux$
Still over 512 :)
cer@Telcontar:~> ps -u cer -f -L --no-header | wc -l 1278 cer@Telcontar:~> ps -eL -u cer | wc -l 1756 cer@Telcontar:~> ps -L -u cer | wc -l 1279 cer@Telcontar:~>
And for comparison
bor@bor-Latitude-E5450:~/src/linux$ ps -u bor | wc -l 93 bor@bor-Latitude-E5450:~/src/linux$
cer@Telcontar:~> ps -u cer | wc -l 199 cer@Telcontar:~>
Browsers appear to use a lot of threads. GNOME daemons started as part of DE are using several threads each and there are a lot of them. So the above limit is trivially exceeded on any vanilla user system.
That was the case. Months ago, while I was using my previous, more limited machine, I changed the default in firefox to use 4 processes (the default is 8), to conserve memory. So this week in some conversation here I was reminded to reset to the default (8 processes) as this new machine has ample memory. And that day or the next (using to Firefox applications) the problems started but I did not relate it, till googling and finding a redhat bugzilla that mentioned the thread issue. <https://bugzilla.redhat.com/show_bug.cgi?id=995177#c43> Still, that applications coredump without a nice message about the problem is not nice. I had to do a "gdb bt full" to know that the problem was about threads failing to open. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
FWIW, I have just patched and rebooted a Leap 15.1 desktop machine with KDE, it shows no problems. -- Per Jessen, Zürich (13.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 14.50, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
FWIW, I have just patched and rebooted a Leap 15.1 desktop machine with KDE, it shows no problems.
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E.R. wrote:
On 04/04/2020 14.50, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
FWIW, I have just patched and rebooted a Leap 15.1 desktop machine with KDE, it shows no problems.
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up. -- Per Jessen, Zürich (13.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 14.58, Per Jessen wrote:
Carlos E.R. wrote:
On 04/04/2020 14.50, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
FWIW, I have just patched and rebooted a Leap 15.1 desktop machine with KDE, it shows no problems.
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Yes, but what? Telcontar:~ # ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127968 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1850 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Telcontar:~ # cer@Telcontar:~> ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127968 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1200 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited cer@Telcontar:~> I have not changed any of that. Telcontar:~ # sysctl kernel.pid_max kernel.pid_max = 32768 Telcontar:~ # cat /proc/sys/kernel/threads-max 255937 Telcontar:~ # cat /proc/sys/fs/file-nr 19040 0 3276345 Telcontar:~ # Googling, I read "/etc/systemd/logind.conf UserTasksMax needs to be set higher than ~12000". I don't have that variable. The other day I found an external bugzilla, but then I had to reboot and lost it. Maybe it was googling for "creating thread 'gmain': Error creating thread: Resource temporarily unavailable" <https://bugs.archlinux32.org/index.php?do=details&task_id=60> or "glib-error ** creating thread 'main' error creating thread resource temporarily unavailable" <https://bugzilla.redhat.com/show_bug.cgi?id=995177> Last comment says: Just FYI, I hit the same traceback after hitting the user limit on number of processes (ulimit -u), which is 1024 by default. I had firefox with ~700 threads. Raising it to 4096 fixes the issue for me. I have: Telcontar:~ # ulimit -u 1850 cer@Telcontar:~> ulimit -u 1200 cer@Telcontar:~> How do I rise it? -u the maximum number of user processes # - nproc - max number of processes Ah. Here: /etc/security/limits.conf * hard nproc 1700 * soft nproc 1200 root hard nproc 3000 root soft nproc 1850 Changing and rebooting: * hard nproc 5000 * soft nproc 4096 root hard nproc 6000 root soft nproc 2000 -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 04/04/2020 15.28, Carlos E.R. wrote:
On 04/04/2020 14.58, Per Jessen wrote:
Carlos E.R. wrote:
"glib-error ** creating thread 'main' error creating thread resource temporarily unavailable"
<https://bugzilla.redhat.com/show_bug.cgi?id=995177>
Last comment says:
Just FYI, I hit the same traceback after hitting the user limit on number of processes (ulimit -u), which is 1024 by default. I had firefox with ~700 threads. Raising it to 4096 fixes the issue for me.
I remember now that I changed firefox performance settings, first to "auto", then to "8" processes. It was set to 4. Just rebooted: cer@Telcontar:~> ps -eLf | grep firefox | wc -l 456 cer@Telcontar:~>
I have:
Telcontar:~ # ulimit -u 1850 cer@Telcontar:~> ulimit -u 1200 cer@Telcontar:~>
Now: cer@Telcontar:~> ulimit -u 4096 Telcontar:~ # ulimit -u 2000 We'll see what happens. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 04/04/2020 15.39, Carlos E. R. wrote:
On 04/04/2020 15.28, Carlos E.R. wrote:
On 04/04/2020 14.58, Per Jessen wrote:
Carlos E.R. wrote:
"glib-error ** creating thread 'main' error creating thread resource temporarily unavailable"
<https://bugzilla.redhat.com/show_bug.cgi?id=995177>
Last comment says:
Just FYI, I hit the same traceback after hitting the user limit on number of processes (ulimit -u), which is 1024 by default. I had firefox with ~700 threads. Raising it to 4096 fixes the issue for me.
I remember now that I changed firefox performance settings, first to "auto", then to "8" processes. It was set to 4.
Just rebooted:
cer@Telcontar:~> ps -eLf | grep firefox | wc -l 456 cer@Telcontar:~>
I have:
Telcontar:~ # ulimit -u 1850 cer@Telcontar:~> ulimit -u 1200 cer@Telcontar:~>
Now:
cer@Telcontar:~> ulimit -u 4096
Telcontar:~ # ulimit -u 2000
We'll see what happens.
I hibernated for siesta, restored, and it is working. I just opened a dozen youtube tabs, no issues. So the hypothesis now is that firefox with performance setting, process limit set to 8, opens so many threads that the system was starving. cer@Telcontar:~> ps -eLf | grep firefox | wc -l 460 cer@Telcontar:~> And I had two firefox openened (different profiles). With both running, I get: cer@Telcontar:~> ps -eLf | grep firefox | wc -l 866 cer@Telcontar:~> And the limit was 1200. What I don't know is how to find out how many are used, say now. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 04/04/2020 21.48, Carlos E. R. wrote:
On 04/04/2020 15.39, Carlos E. R. wrote:
On 04/04/2020 15.28, Carlos E.R. wrote:
On 04/04/2020 14.58, Per Jessen wrote:
Carlos E.R. wrote:
"glib-error ** creating thread 'main' error creating thread resource temporarily unavailable"
<https://bugzilla.redhat.com/show_bug.cgi?id=995177>
Last comment says:
Just FYI, I hit the same traceback after hitting the user limit on number of processes (ulimit -u), which is 1024 by default. I had firefox with ~700 threads. Raising it to 4096 fixes the issue for me.
I remember now that I changed firefox performance settings, first to "auto", then to "8" processes. It was set to 4.
Just rebooted:
cer@Telcontar:~> ps -eLf | grep firefox | wc -l 456 cer@Telcontar:~>
I have:
Telcontar:~ # ulimit -u 1850 cer@Telcontar:~> ulimit -u 1200 cer@Telcontar:~>
Now:
cer@Telcontar:~> ulimit -u 4096
Telcontar:~ # ulimit -u 2000
We'll see what happens.
I hibernated for siesta, restored, and it is working. I just opened a dozen youtube tabs, no issues.
So the hypothesis now is that firefox with performance setting, process limit set to 8, opens so many threads that the system was starving.
cer@Telcontar:~> ps -eLf | grep firefox | wc -l 460 cer@Telcontar:~>
And I had two firefox openened (different profiles). With both running, I get:
cer@Telcontar:~> ps -eLf | grep firefox | wc -l 866 cer@Telcontar:~>
And the limit was 1200. What I don't know is how to find out how many are used, say now.
Apparently: Telcontar:~ # ps -u cer -f -L --no-header | wc -l 1275 Telcontar:~ # ps -u root -f -L --no-header | wc -l 366 Telcontar:~ # and that number is above the 1200 limit. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
04.04.2020 16:28, Carlos E.R. пишет:
Ah. Here: /etc/security/limits.conf
* hard nproc 1700 * soft nproc 1200 root hard nproc 3000 root soft nproc 1850
This is certainly not default. Default is empty file (comments only); kernel sets NRPOC based on total amount of memory (on couple of systems here it is approximately 3800 processes per 1GiB). So either you or something else modified this file. This must have happened recently, immediately before your problems started. If you use btrfs you may check snapshots when exactly.
Changing and rebooting:
* hard nproc 5000 * soft nproc 4096 root hard nproc 6000 root soft nproc 2000
On 05/04/2020 08.45, Andrei Borzenkov wrote:
04.04.2020 16:28, Carlos E.R. пишет:
Ah. Here: /etc/security/limits.conf
* hard nproc 1700 * soft nproc 1200 root hard nproc 3000 root soft nproc 1850
This is certainly not default. Default is empty file (comments only); kernel sets NRPOC based on total amount of memory (on couple of systems here it is approximately 3800 processes per 1GiB).
So either you or something else modified this file. This must have happened recently, immediately before your problems started. If you use btrfs you may check snapshots when exactly.
No, long ago. Looking at the backup, the last time was Feb 2018: Isengard:/mnt/BookTelcontar # l 003/etc/security/limits.conf -rw------- 3 root root 2335 Feb 5 2018 003/etc/security/limits.conf Isengard:/mnt/BookTelcontar # l 002/etc/security/limits.conf -rw------- 3 root root 2335 Feb 5 2018 002/etc/security/limits.conf Isengard:/mnt/BookTelcontar # l 001/etc/security/limits.conf -rw------- 3 root root 2335 Feb 5 2018 001/etc/security/limits.conf Isengard:/mnt/BookTelcontar # but I think it was several years ago. My comments written in the file (not dated) say: # harden against fork-bombs # rpm proposes: #* hard nproc 16384 #* soft nproc 4096 So at some time there was an issue with fork bombs and I reduced the number. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E.R. wrote:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Yes, but what?
Telcontar:~ # ulimit -a [snip] stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1850 ^^^^ That's very low.
Ah. Here: /etc/security/limits.conf
FWIW, that file is empty on my Leap 15.1 system. As Andrei already suggested, something or someone changed that file. limits.conf comes with pam - maybe check if you have any /etc/security/limits.conf.* ? -- Per Jessen, Zürich (7.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2020 09.42, Per Jessen wrote:
Carlos E.R. wrote:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Yes, but what?
Telcontar:~ # ulimit -a [snip] stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1850 ^^^^ That's very low.
Well, it wasn't till firefox opened 400 threads :-D The computer maximum seems to be 32k something, not a longint.
Ah. Here: /etc/security/limits.conf
FWIW, that file is empty on my Leap 15.1 system. As Andrei already suggested, something or someone changed that file.
That file here is old. Maybe is empty now, but it was not in some past. At some time there was a problem or scare about fork bombs and I reduced the number.
limits.conf comes with pam - maybe check if you have any /etc/security/limits.conf.* ?
Nope. I have older copies of the file, dated back to 2009, everything commented out. Had this paragraph: #<domain> <type> <item> <value> #* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student - maxlogins 4 It was the same on year 2005, version 10.1, and later till 13.1 (2016?) - so I don't see when was the "fork bomb". Later. Maybe Feb 5, 2018. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <per@computer.org> wrote:
Carlos E.R. wrote:
On 04/04/2020 14.50, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
For example, the other day I got:
cer@Telcontar:~> less /var/log/warn /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable /usr/bin/lessopen.sh: fork: retry: Resource temporarily unavailable cer@Telcontar:~>
That is essentially the same in the coredumps you are seeing - unable to fork(), i.e. create a new process. I guess this could be memory or no more room for new processes, system wide on in a cgroup.
Have you got any custom settings that might affect that?
FWIW, I have just patched and rebooted a Leap 15.1 desktop machine with KDE, it shows no problems.
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back -- (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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 11:14]:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Re-read this post instead of presupposing actions. The answer to your question "How?" is pertinent and correct. -- (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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say. You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-? Anyway, I hibernated this afternoon and I'm watching to see what happens - but I did so *after* applying some change. I increased "ulimit -u". -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 14:29]:
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote: > Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say.
You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-?
Anyway, I hibernated this afternoon and I'm watching to see what happens - but I did so *after* applying some change. I increased "ulimit -u".
first rule of troubleshooting only change one thing at a time then move forward based on the results. but you still have not resolved the suggestion about hibernating. so you will not know what helped which problem. -- (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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 20.35, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [04-04-20 14:29]:
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote: > On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote: >> Carlos E.R. wrote:
> It could be that the 24hrs is irrelevant and the only thing that > matters is the hibernation cycle (plus maybe hardware dependency). > Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say.
You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-?
Anyway, I hibernated this afternoon and I'm watching to see what happens - but I did so *after* applying some change. I increased "ulimit -u".
first rule of troubleshooting only change one thing at a time then move forward based on the results.
but you still have not resolved the suggestion about hibernating.
You say: *only change one thing at a time* Which is your proposed change? I'll do that, then reboot, run some hours, then hibernate, then run some hours more. Which is what I'm doing, by the way. I changed one thing, and I'm doing the sequence: change applied, reboot, work, hibernate after some hours, restore, work some hours more; crash? Well, it is not crashing yet. I'll have to see if it holds longer. You have not told me what change to apply, you only told me to hibernate. I have hibernated many times. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sat, 4 Apr 2020 20:26:10 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote:
On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote: > Carlos E.R. wrote:
It could be that the 24hrs is irrelevant and the only thing that matters is the hibernation cycle (plus maybe hardware dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say.
You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-?
No, I'm not proposing anything, now. I was indeed proposing that you hibernate your machine, to save Per some time, but that was before you told us that you already knew that as a result of my proposal. Now I'm just annoyed that you still haven't realized what on earth you had failed to do, and haven't apologized as a consequence. But I can't force you to realize and thus don't expect an apology.
Anyway, I hibernated this afternoon and I'm watching to see what happens - but I did so *after* applying some change. I increased "ulimit -u".
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 21.22, Dave Howorth wrote:
On Sat, 4 Apr 2020 20:26:10 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <> [04-04-20 09:54]:
On 04/04/2020 15.32, Dave Howorth wrote: > On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote: >> Carlos E.R. wrote:
> It could be that the 24hrs is irrelevant and the only thing that > matters is the hibernation cycle (plus maybe hardware > dependency). Carlos could test that quickly.
How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say.
You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-?
No, I'm not proposing anything, now. I was indeed proposing that you hibernate your machine, to save Per some time, but that was before you told us that you already knew that as a result of my proposal.
Now I'm just annoyed that you still haven't realized what on earth you had failed to do, and haven't apologized as a consequence. But I can't force you to realize and thus don't expect an apology.
I'm sorry, but I don't understand at all what you asked me to do. I can apologize, but I don't know for what! So, could you please explain what exactly did you people wanted me to do? Just hibernate? I have hibernated many times. :-? I have known for long, and I have said so several times, that the machine shows the problem after restoring from hibernation. Here, for example: Thread: "Everything is coredumping :-/"
The sequence of events is:
I reboot. Everything seems ok
I hibernate for the night.
On restore next morning (I see the kernel complaining about something), then after an hour I have problems. First thing I notice is either gkrellm crashed, or firefox fails to open links clicked on email. Sometimes the tab crashes; restore tab sometimes works, sometimes not. Things like starting a java process fail with some message about not being able to start a thread, resource temporarily unavailable. Which is absurd, this machine has 32 GB of ram and is barely loaded, just desktop stuff. 22 gigs free. Finally, I'm forced to reboot.
All this started after the updates in April 1, some of which I have reverted (glibc, kernel).
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sat, 4 Apr 2020 21:35:39 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 21.22, Dave Howorth wrote:
On Sat, 4 Apr 2020 20:26:10 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote:
* Carlos E. R. <> [04-04-20 09:54]: > On 04/04/2020 15.32, Dave Howorth wrote: >> On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote: >>> Carlos E.R. wrote: > > >> It could be that the 24hrs is irrelevant and the only thing >> that matters is the hibernation cycle (plus maybe hardware >> dependency). Carlos could test that quickly. > > How?
:) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say.
You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-?
No, I'm not proposing anything, now. I was indeed proposing that you hibernate your machine, to save Per some time, but that was before you told us that you already knew that as a result of my proposal.
Now I'm just annoyed that you still haven't realized what on earth you had failed to do, and haven't apologized as a consequence. But I can't force you to realize and thus don't expect an apology.
I'm sorry, but I don't understand at all what you asked me to do. I can apologize, but I don't know for what!
So, could you please explain what exactly did you people wanted me to do?
Just hibernate? I have hibernated many times. :-?
I have known for long, and I have said so several times, that the machine shows the problem after restoring from hibernation.
Here, for example: Thread: "Everything is coredumping :-/"
Sorry, but whatever you said in some other thread is somewhere else. You hadn't said it here, and in fact you'd said/implied the opposite, immediatedly preceding as I quoted. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2020 22.48, Dave Howorth wrote:
On Sat, 4 Apr 2020 21:35:39 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 21.22, Dave Howorth wrote:
On Sat, 4 Apr 2020 20:26:10 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 04/04/2020 18.25, Dave Howorth wrote:
On Sat, 4 Apr 2020 17:11:59 +0200 "Carlos E. R." <> wrote:
On 04/04/2020 16.29, Patrick Shanahan wrote: > * Carlos E. R. <> [04-04-20 09:54]: >> On 04/04/2020 15.32, Dave Howorth wrote: >>> On Sat, 04 Apr 2020 14:58:01 +0200 Per Jessen <> wrote: >>>> Carlos E.R. wrote: >> >> >>> It could be that the 24hrs is irrelevant and the only thing >>> that matters is the hibernation cycle (plus maybe hardware >>> dependency). Carlos could test that quickly. >> >> How? > > :) hybernate and bring it back
That is known, in my system, to cause the problem. But without applying some change it proves nothing.
Then why did you previously say:
Here it takes a day, and after one hibernation/restore cycle. And may be related to the specific hardware.
To which Per replied:
Sure, like I said, "for what it's worth". I'll wait 24hours and report back. That it takes a day before the problem manifests itself does seem indicative of something not being cleaned up.
Which given what you've now said does mean Per was wasting his time and that my comment was useful, as Patrick saw.
I'm sorry, but I don't understand what you are trying to say.
You are proposing me to hibernate to cause the fault, but I already know that hibernating causes the fault. What do I gain by hibernating? What new knowledge? :-?
No, I'm not proposing anything, now. I was indeed proposing that you hibernate your machine, to save Per some time, but that was before you told us that you already knew that as a result of my proposal.
Now I'm just annoyed that you still haven't realized what on earth you had failed to do, and haven't apologized as a consequence. But I can't force you to realize and thus don't expect an apology.
I'm sorry, but I don't understand at all what you asked me to do. I can apologize, but I don't know for what!
So, could you please explain what exactly did you people wanted me to do?
Just hibernate? I have hibernated many times. :-?
I have known for long, and I have said so several times, that the machine shows the problem after restoring from hibernation.
Here, for example: Thread: "Everything is coredumping :-/"
Sorry, but whatever you said in some other thread is somewhere else.
You hadn't said it here, and in fact you'd said/implied the opposite, immediatedly preceding as I quoted.
I'm sorry, but I was having a big problem here, I was strained and tense, and I lost track of what I said where. I thought you had all read all my threads on my problem. I did say in this thread to please read the other thread, because I had just posted there important (and long) information on this problem. I could not duplicate it also here. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
Marcus Meissner -
Patrick Shanahan -
Per Jessen