View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000734 | Other Unix Port | Bug | public | 2021-05-21 16:08 | 2022-02-19 21:23 |
| Reporter | emax | Assigned To | Steven Levine | ||
| Priority | normal | Severity | block | Reproducibility | random |
| Status | closed | Resolution | no change required | ||
| Platform | Vbox guest VM | OS | eCS | OS Version | 2.2b |
| Summary | 0000734: Stunnel 5.58 debug becomes unkillable | ||||
| Description | Sometimes, rarely, stunnel when becomes slow to answer popS requests (with high cpu load) become unkillable e.g. go -ka stunnel, killem stunnel etc.. and the server must be rebooted with setboot /b Env: eCS2.2b VM under Vbox, VM with 1core and 3GB of ram assigned Stunnel build: https://smedley.id.au/tmp/stunnel-5.58-os2-20210414-debug.zip Process dump (in the state of unresponsive and unkillable) in attachment (result of: pdumpctl stunnel r f d o ) thanks massimo | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
today i had the same issue (14 jun 2021) dump in attachment |
|
|
same also today, this is becoming a serious issue, maybe more dangerous than the cpu overload |
|
|
dump in attachment |
|
|
I just want to confirm that I am seeing the same thing on my system. I'm using 5.58 to tunnel http traffic. At a random time, stunnel gets stuck in a way that it's thread will consume 100% of the CPU and the only way to kill it is to restart ArcaOS. |
|
|
thanks a lot i use "pdumpctl" to capture a dump of the "zombified" process with the command: pdumpctl STUNNEL r f d o and i upload it to mantis the tool PDumpCtl v0.16 2020-01-31 SHL is here: http://www.warpcave.com/betas/ http://www.warpcave.com/betas/PDumpCtl-0.16-20200315.zip |
|
|
Tom, please open a separate ticket for your issue. While the symptoms may appear be the same, your issue may or may not have the same root cause. If it turns out both you and Massimo are seeing the same issue, the tickets will be marked related in the fullness of time. Another reason to open your own ticket is that sometimes tickets need to marked private and if this happens you will lose access. Finally, I am not smart enough to keep track of the details for multiple configurations in a single ticket. |
|
|
The process dump indicates the hang is here. # %kx 00a5fe58: Frame 00a5fe78 Ret _pthread_rwlock_trywrlock + 117 00a5fe78: Frame 00a5feb8 Ret CRYPTO_clear_free + af 00a5feb8: Frame 00a5fef8 Ret main_cleanup + 59 00a5fef8: Frame 00a5ff20 Ret main + a0 00a5ff20: Frame 00a5ff44 Ret text + 27 00a5ff44: Frame 00a5ffe0 Ret 1eeeed61 00a5ffe0: Frame 00000000 Ret 1efb449b Can not access 0 - giving up It also implies you may not be running an current version of the pthreads library. What version are you running? If it not the current version, please update and see if this is sufficient to resolve the hang. |
|
|
trying to update (as always yum fail): ================================================================================Aggiornamento: pthread i686 2:0.2.4-1.oc00 netlabs-rel 16 k Aggiornamenti per dipendenze: libc i686 1:0.1.7-1.oc00 netlabs-rel 1.0 M Riepilogo della transazione ================================================================================Upgrade 2 Packages Dimensione totale: 1.0 M Dimensione totale del download: 16 k Procedere [s/N]: s Download dei pacchetti: pthread-0.2.4-1.oc00 | 16 kB 00:00 Running Transaction Check Test di transazione in corso Errore nel controllo transazione: il file /@unixroot/usr/bin/pwd_mkdb.exe dell'installazione di libc-1:0.1.7-1.oc00.i686 entra in conflitto con il file del pacchetto klusrmgr-1.1.4-1.oc00.i686 Riepilogo errori ---------------- |
|
|
please delete note 3771 since i give the command on another server (the AOS 503 one) instead on the right server if i give yum update yum update pthr01.dll it say that will install 17 packages and update 27 packages should i go? is this safe? thanks |
|
|
Did you really type: yum update yum update pthr01.dll Is certainly not what I would type and it certainly not going to do what you expect. Did you even check if the list of packages to be updated made any sense? If you are going to continue to refuse to use ANPM, you are going to have to put in the time to understand what yum actually does. As you have been told before, yum is a package installer. It is not a file installer. To update the pthread package, the command is yum update pthread Depending on what packages you currently have installed, this may need to update some dependent packages. Libc and libcx come to mind a possibilities. Regarding your question about safety. If you actually knew how to use yum properly, my answer would probably be yes. In your case I recommend backing up in case you make a mistake. We know that yum packages rarely make changes outside of \usr \var and \etc, so you can probably safely get away with backing up just these directory trees, although a full backup might be better in your case. |
|
|
ok, done i updated pthread and yum also updated 27 packages and installed 17 :) maybe a number of Dependencies :) now pthreads dll is this: Signature: @#bww bitwise works GmbH:0.2.4#@##1## 2021-03-09 15:10:52 Vendor: bww bitwise works GmbH Revision: 0.02.4 Date/Time: 2021-03-09 15:10:52 Build Machine: novator File Version: 0.2 Description: pthread implementation for OS/2 let's see if the issue happens again thanks |
|
|
hi all, we can close this ticket issue didn't happen again after the update of pthreads dll thanks a lot massimo |
|
|
Updating stale DLLs to current versions avoided traps and hangs. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-05-21 16:08 | emax | New Issue | |
| 2021-05-21 16:08 | emax | File Added: stunnel_dump.zip | |
| 2021-06-14 08:56 | emax | File Added: stunnel_zombi_14_6_2021.zip | |
| 2021-06-14 09:06 | emax | File Added: stunnel_zombi_14_6_2021-2.zip | |
| 2021-06-14 09:06 | emax | Note Added: 0003739 | |
| 2021-06-16 11:49 | emax | Note Added: 0003740 | |
| 2021-06-16 11:50 | emax | Note Added: 0003741 | |
| 2021-06-18 14:00 | Tom L | Note Added: 0003744 | |
| 2021-06-18 14:12 | emax | Note Added: 0003745 | |
| 2021-06-18 15:04 | Steven Levine | Note Added: 0003746 | |
| 2021-07-01 05:30 | Steven Levine | Assigned To | => Steven Levine |
| 2021-07-01 05:30 | Steven Levine | Status | new => assigned |
| 2021-07-01 06:03 | Steven Levine | Status | assigned => feedback |
| 2021-07-01 06:03 | Steven Levine | Note Added: 0003770 | |
| 2021-07-01 16:30 | emax | Note Added: 0003771 | |
| 2021-07-01 16:30 | emax | Status | feedback => assigned |
| 2021-07-01 16:44 | emax | Note Added: 0003772 | |
| 2021-07-01 20:47 | Steven Levine | Status | assigned => feedback |
| 2021-07-01 20:47 | Steven Levine | Note Added: 0003773 | |
| 2021-07-09 15:24 | emax | Note Added: 0003788 | |
| 2021-07-09 15:24 | emax | Status | feedback => assigned |
| 2021-07-21 15:35 | emax | Note Added: 0003827 | |
| 2021-07-21 15:53 | Steven Levine | Status | assigned => resolved |
| 2021-07-21 15:53 | Steven Levine | Resolution | open => no change required |
| 2021-07-21 15:53 | Steven Levine | Note Added: 0003828 | |
| 2022-02-19 21:23 | Steven Levine | Status | resolved => closed |
