Disabling auto self upgrades

I’m auto installing invoiceninja on heroku and I’m noticing that invoiceninja appears to try to “self update” itself after installation which leads to a timeout error each time. Is there a way to disable the auto self update

If you create a file called version.txt in the storage folder with the version number (ie, 3.4.2) it may prevent this.

I still get this error despite having the text file in the storage folder.

By’self update’ do you mean the app redirects to /update ?

I’d suggest trying to load /update to see if it times out, it should be pretty quick.

Here’s the code if you want to try disabling it:

https://github.com/invoiceninja/invoiceninja/blob/master/app/Http/Middleware/StartupCheck.php#L54

In fiddling around with the application I managed to disable the update by using the NINJA_PROD RESELLER_TYPE env

However now I get this image

https://imagebin.ca/v/3nUN7SwnCgSD

Trying to disable sign up now

How do I remove the “SIGN UP NOW” options as setting RESELLER_TYPE to false does not work.

You need to remove NINJA_PROD and RESELLER_TYPE

But in removing the NINJA_PROD and RESELLER TYPE it would give me the original subject error.

This isn’t the right way to fix it.

I’m hosting on HEROKU and my log files indicate the following:-


removed

This is my Heroku Buildpack

https://github.com/karneaud/invoiceninja-buildpack

I’m trying to keep it automated so it can infact be auto updated using Heroku

How long does /update take if you call it in your browser?

In the next version you can add UPDATE_SECRET to the .env file to prevent /update from loading without the secret.

http://docs.invoiceninja.com/en/latest/configure.html#security

How long does /update take if you call it in your browser?

Apparently more than 30secs as Heroku has a time limit and the process is eventually interrupted. Will try the .env variable

Have you tried calling /update in your browser?

In the next version you can add UPDATE_SECRET to the .env file to prevent /update from loading without the secret.

Tried your suggestion but still to no avail when you access https://invoices.example.com for the first time it redirects to /update and now gives me an error

with respect to my last comment with the “time outs” what can you say might be the cause of it?

Maybe the installation isn’t completing/creating the database, if that happens loading /update would take a long time as it would run the database migrations to setup the database.

I’d suggest checking the table exist after installation/before loading /update.

Well as far as I see all databases seem to have been created as when attempting to reload the application after the first time it seems to work ok. I have a hobby account and the dynos would shut down for a while and then restart if accessed. This is when it occurs then works fine form then on.

What database tables should I check?

There will either be no tables or all of the tables

Can you help me understand the process:

  • Are you using the Invoice Ninja setup screen after running the install buildpack?
  • Does the app timeout after submitting the setup screen?

All tables are accounted for.

When accessing the application for the first time after a 24/ 48hr period using the url https://invoices.kendallarneaud.me ( or any url for that matter). the application redirects to https://invoices.kendallarneaud.me/update which would give me the timeout response.

If I then tried to refresh the page I get the expected results. Again this error only happens on first access of the application within a 24hr period.

  • I am not accessing the setup screen after running install build pack. I’m accessing any url
  • No the app does not timeout after submitting the setup screen. Setup screen works fine.

You initially wrote “I’m noticing that invoiceninja appears to try to “self update” itself after installation”, is this related to installing the app or does the problem occur later?

Hillel,

Ah sorry about that mix up. At first this was my initial theory but I was apparently wrong. The problem is occurring later. It was first brought to my attention when a client tried to access the application. Now it started happening to me as well.