Loading...
 
Skip to main content

Features / Usability


503 Service Unavailable message on a single, upper level page

Suddenly, with no apparent change or edit on my part, I have one of my main pages giving a "Service Unavailable" message (otherwise, blank page). This is the offending page: https://h600.org/wiki/Family+BranchesQuestion

It is the top page in a structure. And one of 5 main structure / top level pages for the site. All other pages seem fine still. Even ones lower in the same structure. I can even edit the page (from the structure page). History shows it has not been edited since March 2024. Viewing previous versions via the history page gives the same "Service Unavailable" message.

Being a main page, it is viewed often. Using TikiWiki version 26.2 27.4 and PHP 8.2 at the moment. PHP Mem limit is at 512M, exec time at 120. Afraid to upgrade Tiki versions with it in this state. Was planning on upgrading in a few months when the v30 LTS comes out; bypassing v27 all together.

Ideas on how to debug or resolve this?

UPDATE: Isolated it to an image reference. Image looks fine in the gallery. But any reference to it in the page causes the 503 Service Unavailable blank page to occur. DItto for second page that started acting up.

Marc Laporte wrote:

Nothing of significance with running tiki-check.php, that I could see.

States composer could not be found and a few PHP errors are generated trying to stat composer files that do not exist (composer.json, composer.lock)
States cannot write to folder "files/forums" but the "files" folder does not even exist.
Complains tesseract package is not installed (for OCR)
Complains Realtime Tiki is not enabled / installed.


A second, top-level structure page is now exhibiting the same issue: https://h600.org/wiki/Genetic+GenealogyQuestion . Is this the right place in the forum to inquire about strange, un-characterized bugs like this?

I see nothing in the "Tiki Logs" other than login messages. I cleared the Tiki Cache which resulted in no change.

These are not overly complex pages. No different than the still working https://h600.org/wiki/yDNA+GroupingsQuestion stop level structure page.

I am also starting to see, at various times, "429 Too many requests" error pages from any page visit or attempt to follow an action like a save during an edit session. Could it be we are being hit with a DoS attack? Server logs from the hosting provider do not really indicate this; that I can see. No unusual or heavy load. It is an older "shared physical host" service. Beginning to get very frustrating. I have not reached out to the hosting provider as it takes hours to walk up the chain to find someone who really knows what they are doing.

UPDATE: This may have started after turning on cPanel Site Quality Management. It appears they pound the server too heavily. I turned it back off and have not been seeing Too Many Requests any more. But still seeing the Service Unavailable message consistent on those two pages. Without fail.


FYI, have cleared browser cache as well as tikiwiki caches. Have tried with different browsers and different client machines (desktop, tablet). It is consistent. Always with the two pages mentioned (503 Service Unavailable) and never with any other page. These are not complex pages although they are the top pages of 2 of the 6 structures on the site. I should add I have a second tikiwiki installation with all the same parameters and on the same shared server / account. And it has no problems. These are not the largest structures either.

Do I dare try to upgrade the TikiWiki versions and PHP level? Will it make it worse? A frustrating problem with no leads to investigate as to how / why.



Upgraded to 27.4 LTS but it makes no difference.

Is it possible I have a loop in aliases that is causing a hiccup? Or more than one file with the same alias name? Renaming the file does not help (whether I let it add an alias in a tiki comment or not). I have SEO turned on. So maybe route.php is having a hiccup somewhere. How can I debug this theory?

Let us know the steps you will take to fix this issue. This will help other users.

Thank


A temporary solution you can try. Create a new page with the content of the page that is causing your problem.

I encountered this problem last year on a test site. Not on one or two pages, but on the entire tiki site. After several days of searching here and there, even reverting to the previous version, the 503 error remained. I solved my problem by changing hosting providers. I always make a backup of the database and all the website files.

What I noticed was that the MySQL version was obsolete on the old hosting provider. Once the domain name, database, and all the files were migrated, the problem was solved. But I don't think that's a solution in your case.

Your website is hosted by hostgator and you can find help here https://www.hostgator.com/help/article/503-service-unavailable-error-messageQuestion
I think a Hostgator have a good support. Maybe a solution!!

Thanks. I tried that. The newly created page with the same (copied) content creates a 503 Service Unavailable error so. So not the page name or being the root of a structure. It is something in the content. I will try to comment out sections until I can get the page to work; to maybe narrow the scope down.

  • Tiki commenting the whole page still gives the error.
  • Removing all content of the page yields a clean page and view (no error). Adding back a single sentence is similar.
  • Removing this: {img fileId="109" width="400px" thumb="box" rel="box[g]"} allows the page to work. Leaving that code in, even inside a tiki comment, causes the page to not display. The image displays fine in the file gallery. Download of the JPG file looks normal on the desktop.
  • Similar issue on second page that stopped displaying. Get rid of one of the image references and the page displays fine (albeit without the image).


How to debug this level of error when you do not have access to database nor apache server logs?

I agree that likely the hosting provider made some update that caused the change. As I have not. They are constantly editing .htaccess files at their whim which often breaks something. I restored that file back but it did not fix anything. I wonder if they made a change to the PHP installation and maybe removed support for some features or image processing macros that is not being picked up otherwise. But why only 2 of thousands of pages on two sites. Or hundreds of images. Weird. Guess I could try to save the DB and recreate it from scratch. Not sure if I can switch database programs as of yet. Maybe reload the files from the desktop; maybe the file system is partly corrupted somehow or the disk is being erratic in delivering the file for image processing. Hostgator support is fine if you can escalate it up two levels. But you cannot get it escalated anymore because they are using an AI for level one. So you never convince it that the problem needs a more experienced look. (At least I have not found a way to do that.)

Hum well big bizarre problem! Not having access to the database via phpmyadmin is a problem.
Question : Have you checked the permissions on the image folder? Perhaps after upgrading to Tiki 27.4, the permissions were changed on some files or folder?
You have a specific problem on only two pages. It’ very bizarre...
Or maybe your hostgator can return to an earlier date with a backup automatic system? Date before a problem.

Personally, I never use a hosting service that does not give me access to the server, the database and the php.ini file.
A good host with excellent, fast support in the United States is Hobohost.

francis wrote:
Hum well big bizarre problem! ...

Sorry if I implied otherwise. I have access to PHPMyAdmin and the databases I create. It is the MySQL error logs I do not seem to have access too. Along with the Apache logs. And I see no way to have a debug feature enabled to give me logs when trying to render a page via a tikiwiki URL. It is a 15 year old VPS service (shared host) which is a pseudo-VM without access to the MySQL, sendmail, etc shared resource installations. (I have my own servers as well but have kept these very public sites on a public hosting service as they monitor and patch security flaws more quickly than I can. So uptime is usually better. When my servers were inside the University computer center, they were hacked every few months.)

Hostgator will not backup if you have too many inodes. I have a separate image gallery with tens of thousands of images that creates over 100k inode entries. So I do my own backups with beyondcompare to my own servers. But I only run them once a month as the sites do not change often enough. Realize they have redundant disks and back them up multiple times a day. So restore things on a crash. Just they do not give you access to those backups they do.

Hundreds of images are working fine. Just these two on these two pages flaked out. I discovered my backup of the image files is on a server I cannot access at the moment. So will have to wait till I get that access again to restore those two image files — in case they were corrupted in some way. (As mentioned, when downloaded, they look fine. But trying to view inside a TikiWiki page gives me the 503 error.) File permissions on the folder and files are all identical and open as expected.

Am waiting to when I have access to the backup of the image folder from previous months to verify the image files did not change. Next would be to try and figure out if the PHP image processing that is setup in the new updates is somehow barking on these two particular JPG files.