Internal database error while uploading content

dhavalsoni88 · August 27, 2016, 12:47pm

I’ve migrated Kaltura sever using rsync from old server to newer server. it was due to hardware upgradation.

Now, everything works fine KMC Login - Ok, admin_console login -OK, existing Data content -OK. But,when I am /user uploading content to his/her account, we are getting error “Internal database error”.

When I run “kaltlog” command and again reuploaded from my PC I get detailed error as below:

2016-08-27 13:18:08 [0.002008] [XXX.XXX.XXX.XXX] [754817273] [API] [KalturaStatement->execute] DEBUG: /* video.tikklr.com[754817273][propel] */ INSERT INTO track_entry (`ID`,`TRACK_EVENT_TYPE_ID`,`PS_VERSION`,`CONTEXT`,`PARTNER_ID`,`ENTRY_ID`,`HOST_NAME`,`UID`,`CHANGED_PROPERTIES`,`KS`,`DESCRIPTION`,`CREATED_AT`,`UPDATED_AT`,`USER_IP`,`CUSTOM_DATA`) VALUES (NULL,‘5’,‘ps3’,’|kmc:5.38.10|media|add’,‘107’,‘0_wv7lwr9g’,‘video.tikklr.com’,’’,‘status [4]->[7]’,‘ZDVmZWZhODU5MGMzOTQ3ODI4OTBmMjM3YzhhYTRmYTQ2MGMzNWY0NnwxMDc7MTA3OzE0NzIzODYxNDg7MjsxNDcyMjk5NzQ4LjkyMzk7aW5mb0BkaGF2YWxzb25pLm5ldDsqLGRpc2FibGVlbnRpdGxlbWVudDs7’,‘entry::postUpdate[2757]’,‘2016-08-27 13:18:08’,‘2016-08-27 13:18:08’,‘XXX.XXX.XXX.XXX’,‘a:1:{s:9:“sessionId”;s:9:“754817273”;}’)
2016-08-27 13:18:08 [0.051816] [XXX.XXX.XXX.XXX] [754817273] [API] [BasePeer::doInsert] ERR: exception ‘Exception’ with message ‘SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query’ in /opt/kaltura/app/infra/log/KalturaLog.php:82
Stack trace:
#0 /opt/kaltura/app/vendor/propel/Propel.php(408): KalturaLog::err(‘SQLSTATE[HY000]…’)

2016-08-27 13:18:08 [0.000701] [XXX.XXX.XXX.XXX] [754817273] [API] [KalturaFrontController->getExceptionObject] ALERT: exception ‘PropelException’ with message ‘Unable to execute INSERT statement. [wrapped: SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query]’ in /opt/kaltura/app/vendor/propel/util/BasePeer.php:299
Stack trace:
#0 /opt/kaltura/app/alpha/lib/model/om/BaseTrackEntryPeer.php(853): BasePeer::doInsert(Object(Criteria), Object(KalturaPDO))

Here, XXX.XXX.XXX.XXX is my system’s IP address.

Can anyone help me in this please?

jess · August 28, 2016, 8:45pm

Hello,

Seems each time the code needs to insert data into MySQL, it fails.
When you did the rsync, did this include the MySQL data? if so, did you preserve permissions on the files you synced? I am guessing you didn’t and that’s the problem.

The MySQL files need to be owned by ‘mysql’ user, unless you made manual changes to the distro’s MySQL configuration, that is.
I am guessing this is the problem since you say reading from the DB, which is needed for logging in to the UI, does work.
Also, if that’s the case and you did not copy the files with proper permissions, I expect you’ll have many additional errors due to that.
Setting the correct permissions for most relevant Kaltura dirs and files can be done by re-running the configure scripts, but this will not correct the MySQL DB files.

vrajeshvora · November 25, 2016, 4:42pm

Is there any way we can restore the permission by reinstalling Kaltura on same server or script to run on the server to recover the permission?

vrajeshvora · November 27, 2016, 5:04pm

Anyway, I have fixed the issue by updating the Kaltura,but i do not see past publisher and user account created in Kaltura. Is there anyway we can retrieve them from old backup?

After doing testing I have removed test publisher and sysadmin accounts, but I am still seeing them in Kalura database table kuser.

jess · November 28, 2016, 2:42pm

Hello,

We never delete records from the DB, instead, we change the status column.
The status for an active kuser will be 1, as defined here:

github.com

kaltura/server/blob/Lynx-12.6.0/alpha/lib/enums/KuserStatus.php#L9


<?php
/**
* @package Core
* @subpackage model.enum
*/ 
interface KuserStatus extends BaseEnum
{
	const BLOCKED = 0;
	const ACTIVE = 1;
	const DELETED = 2;	
}

So, if the status is not 1, the kuser is not active.

vrajeshvora · November 30, 2016, 4:03am

That means if I removed the user X from the KMC and recreate the same user again would I able to Login to KMC console or not? I have tested it and it is working at all. I have created the user account “Test” and removed it. After sometime, I have created the KMC user account “test” again, but it wont allow me to login. instead giving some error while trying to open KMC console.

jess · November 30, 2016, 1:13pm

Hello,

You can create multiple partners with the same email address and name, only the partner ID is unique and that’s an auto incremented column.
It’s important to note that all partners with the same email address, will have the same passwd, so if you have:
Partner ID: 101, email address: test@example.com
Partner ID: 102, email address: test@example.com

and you change the passwd for 102, it wil also change for 101.

Deleted partners [and kusers] will not be able to login.

If you have an issue logging in, from the shell, run:
# kaltlog
then try to login and look at the output in the shell, then, go to the relevant log where the errors were logged [will usually be /opt/kaltura/log/kaltura_api_v3.log, but some actions are logged to /opt/kaltura/log/kaltura_prod.log as well and PHP fatal errors will be logged to the Apache error log - /opt/kaltura/log/kaltura_apache_errors*.log] and look at the lines leading to the final error/exception. Then paste these lines here so I can help you further.

vrajeshvora · December 7, 2016, 5:46am

Hi,

Thank you for the update. I have reviewed the Kaltura and Apache and LFD log in my server and found below errors:

File does not exist: /opt/kaltura/app/start/images/passed_step.png, referer: http://IP/start/index.php
File does not exist: /opt/kaltura/app/start/images/passed.png, referer: http://IP/start/index.php
File does not exist: /opt/kaltura/app/start/images/failed.png, referer: http://IP/start/index.php
File does not exist: /opt/kaltura/app/start/images/optional.png, referer: http://IP/start/index.php

LFD.log

Suspicious Process PID:6895 PPID:11429 User:apache Uptime:39671 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6898 PPID:11429 User:apache Uptime:39671 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6902 PPID:11429 User:apache Uptime:39670 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6904 PPID:11429 User:apache Uptime:39669 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6906 PPID:11429 User:apache Uptime:39669 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6908 PPID:11429 User:apache Uptime:39668 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6909 PPID:11429 User:apache Uptime:39668 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6910 PPID:11429 User:apache Uptime:39668 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6913 PPID:11429 User:apache Uptime:39668 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6914 PPID:11429 User:apache Uptime:39668 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6916 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6917 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6920 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6921 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6923 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6924 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6925 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6928 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6929 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6931 PPID:11429 User:apache Uptime:39667 secs EXE:/usr/sbin/httpd CMD:/usr/sbin/httpd
Suspicious Process PID:6967 PPID:6967 User:kaltura Uptime:39655 secs EXE:/usr/bin/php CMD:/usr/bin/php populateFromLog.php

jess · December 7, 2016, 6:51pm

Hello,

The LFD.log is not really relevant for this.
In your output, I do not see anything relevant to the loginByLoginId request…

Again, in the shell, I suggest you run:
# source /etc/kaltura*bash.sh
# kaltlog

then try to make the login request and look at the output.
kaltlog is just an alias for tail -f /opt/kaltura/log/.log /opt/kaltura/log/batch/.log | grep -A 1 -B 1 --color “ERR:|PHP|trace|CRIT|[error]”

If there are errors in /opt/kaltura/log/kaltura_api_v3.log, which is where the login request will log to, you should be able to see them. You can also just look inside the file, looking for the email addr you’re using to login or for calls to loginByLoginId, a sample call should look like this:

(
    [format] => 2
    [ignoreNull] => 1
    [clientTag] => Kaltura-admin
    [apiVersion] => 3.3.0
    [loginId] => $`THE_EMAIL_IN_QUESTION`
    [password] => 
    [partnerId] => $PARTNER_ID
    [privileges] => disableentitlement
    [otp] =>
    [kalsig] => 58b11f9d9995b1caf3be7e365dd31b84
    [service] => user
    [action] => loginByLoginId
)
]

In the same log, you should also be able to see the SQL query made, something along the lines of:

SELECT ... FROM `user_login_data` WHERE user_login_data.LOGIN_EMAIL=$THE_EMAIL_IN_QUESTION..

Follow the whole chain of events to understand why the login request is denied…