When upgrading to 1.2.11, installer can appear to stop at 42%

[misterjmw]

On two different CentOS 7 systems the installer hangs at 42%.
The upgrade page keeps refreshing, but no progress is made.

The seems to be caused by importing template packages (which I can find no other way to import).

From the Forums: https://forums.cacti.net/viewtopic.php?f=2&t=60847

[2020-04-06 20:58:15] [ always  ] Converting Table #191 'version'
[2020-04-06 20:58:15] [ always  ] Converting Table #192 'weathermap_auth'
[2020-04-06 20:58:16] [ always  ] Converting Table #193 'weathermap_data'
[2020-04-06 20:58:16] [ always  ] Converting Table #194 'weathermap_groups'
[2020-04-06 20:58:16] [ always  ] Converting Table #195 'weathermap_maps'
[2020-04-06 20:58:16] [ always  ] Converting Table #196 'weathermap_settings'
[2020-04-06 20:58:16] [ always  ] Switched from  to /tmp/cduF1KTV7
[2020-04-06 20:58:16] [ always  ] NOTE: Using temporary file for db cache: /tmp/cduF1KTV7
[2020-04-06 20:58:16] [ always  ] Upgrading from v1.2.10 (DB 1.2.11 (DB: 1.2.10)) to v1.2.11
[2020-04-06 20:58:16] [ always  ] Found 6 templates to install
[2020-04-06 20:58:16] [ always  ] About to import Package #1 'Cacti_Stats.xml.gz'.
[2020-04-06 20:58:18] [ always  ] Import of Package #1 'Cacti_Stats.xml.gz' under Profile '1' succeeded
[2020-04-06 20:58:18] [ always  ] About to import Package #2 'Cisco_Router.xml.gz'.

Eventually, I reboot the server. The Install runs through converting the tables again;

[2020-04-06 20:58:16] [ always  ] Switched from  to /tmp/cduF1KTV7
[2020-04-06 20:58:16] [ always  ] NOTE: Using temporary file for db cache: /tmp/cduF1KTV7
[2020-04-06 20:58:16] [ always  ] Upgrading from v1.2.10 (DB 1.2.11 (DB: 1.2.10)) to v1.2.11
[2020-04-06 20:58:16] [ always  ] Found 6 templates to install
[2020-04-06 20:58:16] [ always  ] About to import Package #1 'Cacti_Stats.xml.gz'.
[2020-04-06 20:58:18] [ always  ] Import of Package #1 'Cacti_Stats.xml.gz' under Profile '1' succeeded
[2020-04-06 20:58:18] [ always  ] About to import Package #2 'Cisco_Router.xml.gz'.
-- Reboot here --
[2020-04-06 21:23:21] [ always  ] Spawning background process: /bin/php '/usr/share/cacti/install/background.php' 1586229801.2444
[2020-04-06 21:23:21] [ always  ] Setting PHP Option max_execution_time = 0
[2020-04-06 21:23:21] [ always  ] Setting PHP Option memory_limit = -1
[2020-04-06 21:23:22] [ always  ] Starting INSTALL Process for v1.2.11
[2020-04-06 21:23:22] [ always  ] Found 196 tables to convert
[2020-04-06 21:23:22] [ always  ] Converting Table #1 'aggregate_graphs'
[2020-04-06 21:23:22] [ always  ] Converting Table #2 'aggregate_graphs_graph_item'
[2020-04-06 21:23:22] [ always  ] Converting Table #3 'aggregate_graphs_items'
[2020-04-06 21:23:22] [ always  ] Converting Table #4 'aggregate_graph_templates'

This time it succeeds as the import is not performed at the end of the process.

Also; It should also be noted that the timestamps are in local time and the installation times (started/completed) are seemingly in UTC.

[2020-04-06 21:23:51] [ always  ] Converting Table #194 'weathermap_groups'
[2020-04-06 21:23:51] [ always  ] Converting Table #195 'weathermap_maps'
[2020-04-06 21:23:52] [ always  ] Converting Table #196 'weathermap_settings'
[2020-04-06 21:23:52] [ always  ] Finished INSTALL Process for v1.2.11
[2020-04-06 21:23:52] [ always  ] Installation was started at 2020-04-07 03:23:21, completed at 2020-04-07 03:23:52

[gbonny1982]

Same here, ubuntu 18.04, i tried twice with templates. Deselected them and installed ok.

[TheWitness]

I've tested again and again latest CentOS 7 on 1.2.11 both Apache and NGINX and can not reproduce this.

[netniV]

The timestamps come from PHP so are the timezone applied by the appropriate PHP.INI

[misterjmw]

The timestamps come from PHP so are the timezone applied by the appropriate PHP.INI

Obviously not terribly concerned by the times, just a bit odd that the timestamp and the referenced time didn't use the same TZ.

Both of the logs I've got seem to indicate that it hung installing template packages. I've tried the CLI and "Import" in the GUI; Is there a way to import them by hand?

[netniV]

There is the CLI program that the installer used to run, https://github.com/Cacti/cacti/blob/develop/cli/import_template.php

[F-i-f]

I ran into the same problem.
After interrupting the stuck upgrade, I was able to login, but the failed template import completely messed up my graphs. I had modified the stock templates a long time ago, and the update ended up having some graphs referencing the old template (pre-import) which I couldn't edit anymore as "Edit Graph Template" was leading me to the new imported template.
I restored from a DB backup, didn't import the templates and it worked fine.

[vperezescorcia]

I ran into the same problem.
stuck y 42% after upgrade 1.2.10 to 1.2.11 I have installed cacti over Windows server 2016 datacenter.

I rollback to 1.2.10

[ISekan]

Have the same problem on Centos7

[2020-04-14 13:36:39] [ always ] Spawning background process: /bin/php '/var/www/html/cacti/install/background.php' 1586860599.2826
[2020-04-14 13:36:39] [ always ] Setting PHP Option max_execution_time = 0
[2020-04-14 13:36:39] [ always ] Setting PHP Option memory_limit = -1
[2020-04-14 13:36:40] [ always ] Starting UPGRADE Process for v1.2.11
[2020-04-14 13:36:40] [ always ] No tables where found or selected for conversion
[2020-04-14 13:36:40] [ always ] Switched from to /tmp/cdurXZ9oZ
[2020-04-14 13:36:40] [ always ] NOTE: Using temporary file for db cache: /tmp/cdurXZ9oZ
[2020-04-14 13:36:40] [ always ] Upgrading from v1.2.8 (DB 1.2.11 (DB: 1.2.8)) to v1.2.11
[2020-04-14 13:36:40] [ always ] Found 5 templates to install
[2020-04-14 13:36:40] [ always ] About to import Package #1 'Cacti_Stats.xml.gz'.
[2020-04-14 13:36:44] [ always ] Import of Package #1 'Cacti_Stats.xml.gz' under Profile '1' succeeded
[2020-04-14 13:36:44] [ always ] About to import Package #2 'Cisco_Router.xml.gz'.

[waclaw66]

How to recover from it?
I stucked at...

2020/04/16 12:57:47 - INSTALL: always: About to import Package #4 'Local_Linux_Machine.xml.gz'.
2020/04/16 12:57:47 - INSTALL: info: Progress: 44
2020/04/16 12:57:47 - INSTALL: always: Import of Package #3 'Generic_SNMP_Device.xml.gz' under Profile '1' succeeded
2020/04/16 12:57:45 - INSTALL: always: About to import Package #3 'Generic_SNMP_Device.xml.gz'.
2020/04/16 12:57:45 - INSTALL: info: Progress: 43

the log says repeatedly...

2020/04/16 13:15:49 - INSTALL-JSON: debug: Using supplied data
2020/04/16 13:15:49 - INSTALL-JSON: notice: Start: {"Step":"97","Eula":"1"}
2020/04/16 13:15:49 - INSTALL-STEP: notice: Install Parameters: array ( 'Runtime' => 'Web', 'Step' => '97', 'Eula' => '1', )
2020/04/16 13:15:49 - INSTALL-STEP: notice: Initial: '97'
2020/04/16 13:15:49 - INSTALL-STEP: notice: Previously complete: NULL
2020/04/16 13:15:49 - INSTALL-STEP: debug: Does match: '1.2.11'
2020/04/16 13:15:49 - INSTALL-STEP: notice: After: '97'
2020/04/16 13:15:49 - INSTALL-STEP: debug: setStep(): '97'
2020/04/16 13:15:49 - INSTALL-STEP: notice: setStep(): stepError false < '97'
2020/04/16 13:15:49 - INSTALL-LANGUAGE: info: getLanguage(): en-US
2020/04/16 13:15:49 - INSTALL-LANGUAGE: debug: setLanguage(): en-US
2020/04/16 13:15:49 - INSTALL-THEME: info: getTheme(): modern
2020/04/16 13:15:49 - INSTALL-THEME: info: Checking theme: modern
2020/04/16 13:15:49 - INSTALL-THEME: debug: setTheme(): modern
2020/04/16 13:15:49 - INSTALL-STEP: debug: Error: false
2020/04/16 13:15:49 - INSTALL-STEP: debug: Done: '97'
2020/04/16 13:15:49 - INSTALL-BACKGROUND: debug: backgroundTime = 1587034648.4288
2020/04/16 13:15:49 - INSTALL-BACKGROUND: debug: backgroundNeeded =
2020/04/16 13:15:49 - INSTALL-BACKGROUND: debug: ---------------- Check Expire ----------------
2020/04/16 13:15:49 - INSTALL-BACKGROUND: debug: backgroundDateStarted = 2020-04-16 10:57:28
2020/04/16 13:15:49 - INSTALL-BACKGROUND: debug: backgroundLast = 1587034648.4288
2020/04/16 13:15:49 - INSTALL-BACKGROUND: debug: backgroundExpire = 1587034249
2020/04/16 13:15:49 - INSTALL-JSON: notice:   End: {"Mode":null,"Step":"97","Errors":[],"Eula":"1","Prev":{"Text":"Previous","Step":96,"Enabled":true,"Visible":false},"Next":{"Text":"Next","Step":98,"Enabled":true,"Visible":false},"Test":{"Text":"Test Connection","Step":-
4,"Enabled":true,"Visible":false},"Theme":"modern","StepData":{"Current":"44","Total":100}}

[ParkaMark]

I can confirm the same problem (hanging) on CentOS 8 under Chrome. After many re-attempts, I then switched to using Firefox and the install did actually complete (no hang), but then I was not able to login on the cacti login screen. The login failure is not the same as just a wrong username/invalid password (which it would print in red text if this was the case) - instead, the login just doesn't work, the page refreshes/resets with no red text. And clearing cookies doesn't resolve this problem.

After spending hours on this, I've reverted back to 1.2.10.

Incidentally, during my cookie resetting etc between versions, I did clock that version 1.2.11 does not appear to set the Cacti cookie, but this is present on 1.2.10. At least I think that's what I saw - I don't have the time or patience to troubleshoot this any further.

[misterjmw]

@ParkaMark I have also experienced the 'no login' issue. I have found that I can bypass it by logging in (which redirects back to the login page) then going to a cacti link in my browser (e.g. graph), from there I'm let in. Certainly not a 'real' fix.

[TheWitness]

Unfortunately, I have been unable to reproduce this on either CentOS 8 or CentOS 7 either using Apache or Nginx. Could it be that you guys have some apache configuration setup that is not the default? Are you using https and have you inspected the cookie domain or the cookie settings? You say that there is not Cacti cookie, well that means it has to be environment related.

So, I asked these questions elsewhere:

1. What version of PHP
2. What version of Apache
3. Any customization's to Apache configuration
4. http or https self signed or legit.
5. Cookie domains enabled?
6. Good dns that matches the cookie domain?