Users are currently editing objects in the CCM won't clear

[TBT]

To better align our XI hosts with their associated offloaded Databases we've recently started renaming them. So far the process of dumping, renaming and importing the Database along with making the associated XI config changes has followed the same method on 6 of 8 XI servers.

All have been successful so far, except the most recent server where we encountered an issue. XI appears to be working, however when navigating to Configure > Core Config Manager > Apply Configuration it warns:

Users are currently editing objects in the CCM
John Smith is editing a service (started at 2020-10-19 18:19:07)

We're able to apply configuration changes and have verified the change is present. However, this warning remains. Applying the configuration as the user, a different user or even having users logout doesn't clear this warning.

This issue most likely isn't related to the recent DB name change as we've also re-imported the DB and the CCM warning was present with the same user currently editing three (3) objects in the CCM dating back to 2020-09-17.

Update #1: Prior to starting the next XI Server (Number 7), I thought it would be helpful to confirm there are no pending configuration changes. We're seeing this same behavior.

Users are currently editing objects in the CCM
John Smith is editing a service (started at 2020-10-19 10:15:05)

At this point the Database has not been renamed so we can rule that out as a potential cause. When we Apply Configuration on this Server, the warning remains, but in the config snapshots indicate "Config Ok" with an updated current date/time.

Update #2: As described in Update #1, we also see the exact same behavior on Server 8 which is another XI Server we've not changed over yet. Confirming my suspicion an issue was present with CCM prior.

Please advise,

[benjaminsmith]

Hi @TBT,

It's possible that there is some kind of database issue, but before checking that, please go to the Configure > CCM > CCM Admin > Settings and disable session locking and let me know if the issue persists.

session-locking.png

If so, please send us your system profile and we'll check the logs for you.

Regards,
Benjamin

To send us your system profile.
Login to the Nagios XI GUI using a web browser.
Click the "Admin" > "System Profile" Menu
Click the "Download Profile" button
Save the profile.zip file and share in a private message or upload it to the post/ticket, and then reply to this post to bring it up in the queue.

[TBT]

I've sent you the profile.zip from one of our least active servers. Additionally, here are few more notable items that may be helpful.

1. Disabling session locking had no affect on resolving the issue.

2a. All XI Servers except one are experiencing this same issue.
2b. It is the same user on all XI Servers (I've included the UID in PM).
2c. This particular user does not make changes to the one server not affected, but does on all others that are affected.
2d. The date/time stamp on the edit message all differ across XI Servers.

[tgriep]

Make sure you and other users exit all of the browsers on their systems to make sure the connection to the server is closed.

Run this to clear the lock on that record.

Code: Select all

echo 'truncate tbl_session_locks;' |mysql -t -u nagiosql -pnagiosql nagiosql -h xxx.xxx.xxx.xxx
echo 'truncate tbl_session;' |mysql -t -u nagiosql -pnagiosql nagiosql -h xxx.xxx.xxx.xxx

Change xxx.xxx.xxx.xxx to the IP address of the remote MYSQL database and adjust the username or password if needed.
Then they should be able to edit objects in the CCM without that message showing up.

[TBT]

The warning went away after we did as you suggested. We then tested by applying a configuration change and the warning came back.

At the time of the change, I was logged in and sitting on the Apply Configuration page (not making changes). Another user logged in to apply a change. The change was accept, however, also generated the warning of this user editing an object still.

Also another weird occurrence. This morning I went back to view the one XI Server not affected, and sure enough it now too has a warning but with a different user.

Please advise,

[tgriep]

Open a root shell on the Nagios server and run the following commands. Get the /tmp/info.txt file and upload it to the ticket.

Code: Select all

mysql -u root -pnagiosxi -h xxx.xxx.xxx.xxx -e "show global status like '%used_connections%'; show variables like 'max_connections';" >/tmp/info.txt
echo "SELECT table_schema as 'Database', table_name AS 'Table', round(((data_length + index_length) / 1024 / 1024), 2) 'Size in MB' FROM information_schema.TABLES ORDER BY (data_length + index_length) DESC;" |mysql -t -u root -pnagiosxi -h xxx.xxx.xxx.xxx >>/tmp/info.txt
echo 'select * from tbl_session_locks;' |mysql -t -u nagiosql -pnagiosql nagiosql -h xxx.xxx.xxx.xxx >>/tmp/info.txt
echo 'select * from  tbl_session;' |mysql -t -u nagiosql -pnagiosql nagiosql -h xxx.xxx.xxx.xxx >>/tmp/info.txt

The first 2 commands require the root MYSQL username so adjust the password.

[TBT]

Sent via PM as requested.

[tgriep]

Correct me if I am wrong but is looks like you are using the same offloaded MYSQL database server for all of your XI servers.
If so, I would guess that 2 of the XI servers are pointed to the same table and that is why the locks are coming back with other users.

Make sure all of the XI servers are pointing to different tables.

[TBT]

We've verified the permissions and database names, along with source IP addresses associated with the permissions. Everything looks correct.

Also, keep in mind that it doesn't affect just two XI Servers, but all (7 in total). When we discovered the issue, it was present on XI Server that were still using old database names.

While I have your attention can you tell me where this user_id 60 comes from in this record which is retrieved from the tbl_session table?

+----+---------+------------------------------------------------------------------+-------------+---------+--------+------------+--------------+--------+
| id | user_id | session_id | ip | type | obj_id | started | last_updated | active |
+----+---------+------------------------------------------------------------------+-------------+---------+--------+------------+--------------+--------+
| 1 | 60 | 703ec39b53ceb23502f62d86331298e11964eecdf1a85613838e613819cd5d62 | xxx.xxx.xxx.xxx | service | 169 | 1603396469 | 1603396479 | 1 |
+----+---------+------------------------------------------------------------------+-------------+---------+--------+------------+--------------+--------+

We're running XI 5.6.7 still (Yes, I know were' behind), maybe there was a bug fix along the way to 5.7.4?

Any further suggestions.... Perhaps it is time to schedule a remote support session?

[tgriep]

The user ID can be seen in the xi_users table in the nagiosxi database.

To view the tables, run this as root is the nagiosxi database is hosted on Postgres

Code: Select all

echo 'select * from xi_users;' | psql nagiosxi nagiosxi

Run this if it is hosted in MYSQL.

Code: Select all

echo 'select * from xi_users;' | mysql -t -u root -pnagiosxi nagiosxi -h xxx.xxx.xxx.xxx

Adjust the username, password and the IP address, table name.

I did not see anything in the change log specific to the issue you are having but it would still be best to update XI.

Another thing to do is is your MYSQL server is a new version, as of [MySQL 5.7.5] and [MariaDB 10.2.4] the STRICT_TRANS_TABLES mode is enabled by default.
When this is enabled it causes database changes to be rolled back if they do not meet strict requirements.
This causes problems with Nagios XI and how it saves it's data to the database.

This could cause the issue you are having and the following article are instructions for adjusting the MYSQL database settings.
https://support.nagios.com/kb/article/n ... s-780.html