On 04/02/24 04:24 am, Massimo S. wrote:

Il 04/12/2022 19:48, Massimo S. ha scritto:

Il 03/12/2022 01:56, Steven Levine ha scritto:

In <list-5686242@2rosenthals.com>, on 12/01/22
    at 12:02 PM, "Massimo S." <ecs-isp@2rosenthals.com> said:

Hi Massimo,

if i recall well you should have some utility to avoid this (rare)
situation?

I'm not sure what utility you are thinking of.  What a reboot request
hangs, there's not much you can do.  What I do have is scripts that shut
down as much as possible before the reboot is requested and this gives the
best chance of avoiding reboot hangs.

As always the best solution is to detect that you are running low of
resources and resolve this isssue before it can hang the system.

Steven

this only happens (luckily rarely) on the web server that use apache+PHP

massimo

hi all,

in this period unfortunately it's happening quite often

eg. at 6,50 the server did one of his scheduled reboots, all ok
some minutes later apache exited (i've nothing in popuplog.os2 or eQ dumps)
the rexx procedure tried to restart it with no success
at 7,08 the rexx procedure gave the setboot /b
and the vm stuck at the "system is rebooting"

in apache access log i've only normal requests after the reboot at around 6,50 since
7,06 (the last http request) a mix of some normal users requests or some bot scanning
web pages (eg. scroogle or semrush)
since semrush is of no interest i will try to filter the bot on the firewall
nowadays robots.txt is completely ignored by anyone


since the other web server that has no PHP and running apache with html/js websites only
is rock solid stable, i guess it's something on PHP

Why guess?

You mention the access log, but you don't mention the error log, POPUPLOG, or the exceptq logs. Check the php error log as well.

I would also not overlook something simple, like the need for a full disk check. PHP apps can be finicky about the inability to write to the filesystem.

If this were to happen to me (and it has), I would check the above logs for clues. Then, I would reboot with the Apache startup disabled to make sure that the VM could boot properly. I would boot from alternative media and run a full diskcheck on *all* volumes, looking also for adequate available space to write on each of them. Then, after another reboot, I would disable the loading of the PHP module (and anything else which I thought might add complexity to the Apache startup, and try starting Apache by itself. If that worked, I would then add back each of those modules (PHP last, if possible) and observe the Apache startup behavior, as well as shutdown behavior.

It's best not to make suppositions or guesses. As we say in the vernacular, you never know; you just never, never know.

GL HTH