From: "Massimo S." <ecs-isp@2rosenthals.com>
Reply-To: ml@ecomstation.it
Subject: Re: [eCS-ISP] apache+php and VA limit
To: eCS ISP Mailing List <ecs-isp@2rosenthals.com>
References: <list-8797881@2rosenthals.com>
Organization: eComStation dot it
Message-ID: <e3f0aa11-38f2-50ce-8763-1a6e7b160bdb@ecomstation.it>
Date: Mon, 1 Jan 2024 19:42:51 +0100
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; it-IT; rv:1.7.13) Gecko/20060424
 Thunderbird/1.0.8 Mnenhy/0.7.4.0
MIME-Version: 1.0
In-Reply-To: <list-8797881@2rosenthals.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: it-IT
Content-Transfer-Encoding: 7bit



Il 01/01/2024 17:54, Steven Levine ha scritto:
> In <list-8792046@2rosenthals.com>, on 12/26/23
>     at 02:01 PM, "Massimo S." <ecs-isp@2rosenthals.com> said:
> 
> 
> Hi,
> 
> Happy New Year.

hi and

happy new year to you too and to everyone on the ML

> 
>> after more than 3 weeks i've to say that raising the value of VAL has
>> improved overall system stability
> 
> This is true for most systems.
> 
>> of course in that condition the server is not accessible, with mouse,
>> keybord or remote
> 
> Does the mouse still move or is it stuck in place?

no, it's all completely freezed
no ping, no mouse movement, no keyboard tc.


>> it also save the previous DUMP and do the new one, so i've 2 dumps the
>> situation good and the situation bad
>> this could be of any help?
> 
> Hang on to them for now.  I'll let you know when I am ready to look at
> them.  We won't know if they contain any useful clues until we look.
> 
> Based on the GETRAM output, you need to try to kill a few more processes
> before attemping the setboot.

i kill some more process now, i've updated the script

> I would start with:
> 
>> 0008    0.133M    0.027M       34        7  ACPIDAEM
>> 0019    0.414M    0.168M      106       43  PMSPOOL
>> 0020    0.066M    0.039M       17       10  CMD
>> 0022    0.188M    0.066M       48       17  CMD
>> 0059    3.684M    2.340M      943      599  GATEWAY
>> 0065   10.605M   10.047M     2715     2572  HTTPX
>> 0066    0.070M    0.039M       18       10  CMD
>> 0092    1.660M    3.699M      425      947  HTTPX
>> 0093    6.996M    3.691M     1791      945  HTTPX
>> 0094   12.320M    5.496M     3154     1407  HTTPX
>> 0095   12.293M    5.535M     3147     1417  HTTPX
>> 0096   12.297M    5.500M     3148     1408  HTTPX
>> 0097    0.293M    0.066M       75       17  CMD
> 
> Of course you will not be able to kill te stuck httpx and you need to
> avoid killing your cmd.exe session.
> 
> The kernel is going to try to kill these process off on it's own.  You are
> getting helping it out.
> 
>> 0105    0.105M    0.012M       27        3  PROCDUMP
> 
> PROCDUMP should not be running.

procdump was run by the script that close process and then reboot
now i've removed all the diagnostic part in the hope it help


>> but if it's apache with his unkillable child all these improvements will
>> not help for sure, since afaik in  some way it lock something in the file
>> system that prevent the normal reboot with setboot /b
> 
> My experience is that unkillable processes do not prevent reboots.  The
> kernel will attempt to kill all the existing processes, but it is fully
> aware that the kill might fail and this will not prevent the reboot.
> 
> My gut feel is that this is more of a hardware issue.  A

this is not possible, i run apache+php since more than 15 years on /2
and i changed a number of bare metal servers, now it runs in a VM (vbox)
and i'v seen this issue with all the hardware configurations possible
and now also with the virtual machine
>> i also don't know if there something more powerful to the setboot /b that
>> is able to reboot the system also in those situations
> 
> Don't you think that after all the years you have used OS/2, if such a
> thing existed, you would already know about it?
> 
> BTW, which version of setboot are you using?  There's the AiRBoot version,
> the IBM version and the dfsee version.  They all invoke the same IOCTL to
> do the reboot.
> 
> Steven

this one (i guess the IBM default one):

Directory of C:\OS2
16/10/01 13:24         24.148      0 a---  SETBOOT.EXE


massimo