Topic on Project:Support desk

Some PHP process got looped, server support managed to kill it. No logs to determine whats happened.

Hello,

I have encountered the first issue with my MadiaWiki installation. I was playing with Vector.CSS file yesterday when the site stopped loading. At all. It doesn not show any errors or misconfiguration alerts, it just keeps endlessly loading. I tried different pages, other than main page, still the same. I removed all extra extensions and rss whitelist form LocalSettings.php, still the same. Tried different devices and browsers. I placed a custom .html file in the main directory and it was accessible, it's not a domain problem. I tried Manual:How to debug but the files is not being written as nothing loads. Same with browser console, it's empty.

What my be the issue there?

---

While creating this thread I received a reply from my server helpdesk. They claim the PHP process got looped and caused the site not able to run. They attached a screenshot with the lsphp73 process endlessly running. Possible MediaWiki bug or misconfiguration in my files?

it would be interesting to know what you put in the css. Ideally it would be good to know where mediawiki is stuck.

Try running manual:runJobs.php from the commandline (does it work?). You could try seeing if the api (especially actual api not the doc page) works and remove whatever you added to the css. You could also try manual:edit.php to edit from commandline.

Thanks! I don't have access tothe commandline, it's a shared hosting.

I played with vector.css and mobile.css styles doing some minor changes to the background or font colors. I also placed my infoboxes styles in common.css. After the support broke the loop, they are accessible here:

https://wiki.starfield.pl/wiki/MediaWiki:Vector.css

https://wiki.starfield.pl/wiki/MediaWiki:Mobile.css (should be same as vector.css)

https://wiki.starfield.pl/wiki/MediaWiki:Common.css

Is there a way to avoid that issue in the future?

Without knowing what happened, it is hard to know how to avoid it. If it does happen again, please raise the issue with us and we'll try to get some more information. Logs would be good.

maybe it could be an i18n recache event that somehow got stuck, but that doesnt quite sound right (if so adjusting manual:$wgCacheDirectory to somewhere writable might help). Really impossible to know without knowing what happened.

Thank you, gentlemen! I will address my issue here next time it happens before contacting the server support desk. The last four days were alright, nothing has happened. Cheers!

I have the same problem, but managed to work around it. When running ImportTextFiles.php, after about 10-20 files, the upload would loop (not progressing) without an error and memory/cpu would climb indefinitely.

My work-around is to call the script with one file at a time and add a 4 second sleep interval between each call. It has been working reliably that way for the last couple of hours.

I think there's an issue in ImportTextFiles with async handling of page updates. If the updates occur too quickly and the machine, DB or disk IO are too slow, then some sub-function is returning success to the ImportTextFiles.php program without actually completing the task. This needs to be changed so that updates are synchronous.