which odules @lkeet ? Core Dolibarr modules or thirdparty modules from the dolistore?
Also, you still have not revealed which Dolibarr version that you run and on which PHP version.
I would like to see the 2 other logs, I want to see the log from your webserver, both access and error log, and I would also like to see the Dolibarr log in debug mode. This is something you enable as a module in Dolibarr and then you raise the loglevel to DEBUG.
Once again, please post only the relevant lines from these logs. We do not want everything, just the relevant stuff. Thank you.
I disabled the following modules that were active: Input Calculator, Events/Agenda, WYSIWYG Editor, Data imports, Data Exports, Module Builder, API/Web Services (REST Server), Paypal, Stripe, Webhook.
I enabled the following modules that were inactive: Debug Logs, Debug Bar
The following modules have been enabled since the beginning: Users, Expense reports, Third Parties, proposals, sales orders, shipments, vendors, invoices, taxes, salaries, banks, margins, double entry accounting, products, services, inter-modules workflow.
The hosting company cleared the Apache logs last week after I was chatting with them about the 503 error. They could find nothing wrong on their end. I set up a login to Dolibarr and let them click on the card page for the invoice that produces the 503 error. They could not trace it back to an Apache error or a PHP error. When I looked at the Apache error logs before they were cleared, there were no errors on the week when the 503 errors started.
Interesting ; I just joined this forum because I am also experiencing a similar issue, starting around the beginning of December. I have a script that imports orders via the REST API. The get imported in the Draft state and I manually validate them. This worked for a year, but as of early December every single one now gives me a 503 error after I validate them. Older invoices still work fine.
I can still view the contents of the invoices via the REST API ; it is the website that seems to have problems with it.
The Dolibarr logs don’t show anything unusual; at the least all the database queries seem to be happening and returning results that appear consistent. I’ve added logging right at the top to catch if the PHP is error-ing out and that doesn’t appear to be the case. It seems like the 503 is truly coming from Dolibarr.
The other item of note, what caught my attention in the first place, is that my script adds a “private_note” to the invoice, and those notes were blank when this problem started happening. I modified my script to NOT put on the notes and it made no difference, so it doesn’t seem to be the cause of the problem so much as another symptom.
I went through the same process of disabling plugins, etc, to no avail. The only plugin I had recently added was my own skeleton of a plugin, which just creates an admin page and doesn’t hook to anything else ; nevertheless I did disable it to no effect.
I’m still digging to find the root cause, but PHP is one of my weaker languages, and debugging through a shared-hosting site is a painful process to say the least.
Welcome on board, sorry that it is under such circumstances @carguin
debugging through a shared-hosting site is a painful process to say the least
Luckily you do not have to do that. If you take a backup inside Dolibarr, then you can from that file easily start a mariadb container restored from the backup file.
If you then also start a dolibarr container, then you can quickly get a copy of your production Dolibarr. You can then use this setup to debug the issue.
I have created a github repository here that uses this method for my development setup. You do not need all the steps, the steps where you have a clone of the dolibarr repo is not initially relevant here
Since you already know how to use the API, the first thing I’d like to do in your new debug setup are:
find an existing invoice that works in the GUI
use the API explorer to change the status/statut
reload the existing invoice that worked in the GUI - does it still work?
I am also having problems when I regenerate the PDF on an Order. I also get the 503 when I regenerate the PDF on a Proposal. The 503 stays with only the order, invoice, or proposal that I regenerate the PDF. Other orders, invoices, or proposals where the PDF was NOT regenerated still load properly.
I’m having exactly the same issue as Ikeet with the 503 error. Seems to be related to generating or regenerating the PDF for the invoice. I can’t get to the card page of any invoice after I’ve generated or regenerated. That means I can’t edit it or delete it. I upgraded from 21.02 to 22.04 thinking an upgrade would fix it, but alas it’s still broken.
It took me a little bit to get that running (mostly my own inexperience with containers), but it’s working now, and the problem does not reproduce in that environment.
I’ll walk through trying to make the environment more representative ; right now I did not bring over the ‘documents’ directory, and the set of modules being loaded is just the default set… which is darn close to what I have normally but I need to look over it closer.
That might be the thing I changed before this problem started happening. On the “invoice” side of things, I found that I didn’t have a Invoice documents model selected, so I enabled the “Sponge” template.
I tried disabling that, then deleting and re-creating one of the problematic entries, and it didn’t seem to make a difference.
FWIW, with respect to sales orders where I am experiencing the issue, I have the “eratosthene” template selected. I don’t believe I changed that since the initial setup. My import process creates just the order first, and once I have validated the order the script then creates the shipment and invoice, so at the stage I see the problem I just have the order.
I will note that I have been using the Sponge template as standard for a couple years now with no issue prior to this. This 503 error started happening a week or so ago (maybe a bit longer) while doing normal invoice processing. No updates to Dolibarr were made until after I noticed the issue. I’ll get some logs from my hosting provider when I’m able. It’s possible there were server updates that occurred, such as to PHP or Apache, but those are mostly invisible to me.
Update: Definitely related to the PDF generation feature! I created a new test invoice and used the .odt template instead. No errors. In the invoice card, I then switched the invoice over to Sponge, hit “Generate,” and sure enough it popped up with the 503. Here are a couple of relevant errors in the SSL log, anonymized:
