problems upgrading from 1.1.38 to 1.2.2: log file issues

[texashoser]

Running CentOS 7 and installed Cacti from yum quite some time ago. Upgraded to 1.2.2 tonight via yum and having problem with log file permissions on page five of the upgrade process. I realize that the permissions for the file/directory are now such that they are owned by the httpd user (in this case apache) where in the previous version it was owned by the user 'cacti.' However, after changing permissions on the log file to 'apache' I still get the same error:

WARNING: One or more paths appear to be incorrect, unable to proceed

If I change the path for the log file on the upgrade page and click Next, the path changes in the mysql database and the check mark turns green but the page returns to itself, page five titled 'Critical Binary Locations and Versions.' If I actually click the refresh button in the upgrade page itself, the path for the cacti log file always returns to '/var/log/cacti.log' no matter what is actually set in the mysql database. Permissions on this file are fine but I can see this in the log file:

INSTALL-ERRORS: info: addError(Paths, path_cactilog, Resource is not writable)

The file is indeed writable:

-rwxrwxrwx 1 apache apache 27718799 Mar 13 20:55 /var/log/cacti.log

SE Linux is disabled. Not sure where to go from here...

Thanks,

[netniV]

Ah, this may be because you are putting the log file directly in /var/log/. As such, the system checks that if the log file was removed or cycled (moved to a dated version), it can create a new one and it would not be able to. We have had to do that check because there had been issues were people's log files were being cycled by cacti or removed by another process, and from that point no logs were being generated so there'd be no history when a problem arose.

The simple solution would be to create a subfolder called cacti and give permissions at the folder level, then specify /var/log/cacti/cacti.log. It is a change to your location but it resolves the issue.

[texashoser]

Ah, this may be because you are putting the log file directly in /var/log/. As such, the system checks that if the log file was removed or cycled (moved to a dated version), it can create a new one and it would not be able to. We have had to do that check because there had been issues were people's log files were being cycled by cacti or removed by another process, and from that point no logs were being generated so there'd be no history when a problem arose.

The simple solution would be to create a subfolder called cacti and give permissions at the folder level, then specify /var/log/cacti/cacti.log. It is a change to your location but it resolves the issue.

Yes, I've already tried this numerous times. Same thing happens. If I hit Next on that screen, the change gets updated in the database, but the process does not progress to the next page. If I click the refresh icon on the page, the text reverts back to /var/log/cacti.log. The permissions are fine:

drwxrwxrwx 2 apache apache 45 Mar 13 21:38 cacti

-rwxrwxrwx 1 apache apache 19663 Mar 13 20:05 cacti.log
-rwxrwxrwx 1 apache apache 0 Feb 25 07:38 cacti_stderr.log

In fact, Cacti/spine is writing to that file but getting errors since the upgrade hasn't finished. This is what's in the mysql database:

+----------------+---------------------------------------+
| name | value |
+----------------+---------------------------------------+
| path_cactilog | /var/log/cacti/cacti.log |
| path_stderrlog | /usr/share/cacti/log/cacti_stderr.log |
+----------------+---------------------------------------+

[texashoser]

OK - got this working. During the upgrade of the Cacti RPM, a new log directory and files were created: /var/log/cacti/<log files>. Yet the upgrade web pages defaulted to the selected /var/log/cacti.log path and would not budge, even after the log directory path was updated in the mysql database as part of this process. Not sure if this was because cacti logs existed in the /var/log directory or if this was a browser cache issue - or both.

So, I removed the log files directly sitting in /var/log and used a browser on another machine and finally was able to resolve this issue and move forward and complete the upgrade. Definitely need, I think, some better upgrade logic around the log path function of the upgrade scripts.

[netniV]

I as understood it, that had been resolved in issue 2337

[texashoser]

I as understood it, that had been resolved in issue 2337

Perhaps not.