Fatal error: unfortunately the database is not available at the moment.

[jberanek]

Just upgraded to MRBS 1.9.2 and it's moslty running ok excep that I get "Fatal error: unfortunately the database is not available at the moment." error when creating a new booking. Am using MYSQL back end on same server.

Also am now seeing a "Created By" box at the top of each booking. It was just using logged in user. How do i get rid of that?

Thanks in advance,

Greg.

Reported by: gwilsonau

Original Ticket: mrbs/support-requests/2270

[jberanek]

(1) What are the details of the fatal error? They will be in your PHP error log. If you can't find the error log you can get the error messages output to the browser by, temporarily, setting $debug = true; in your config file.

(2) The "Created By" box is a new feature only available to admins that allows them to create bookings on behalf of other users. It should contain a drop-down of all available users. If you want to disable it set $auth['admin_can_only_book_for_self'] = true;.

Original comment by: campbell-m

[jberanek]

I think this is the problem (from apache2 error log):

[Thu Jan 07 10:20:57.300785 2021] [:error] [pid 2560] [client 10.99.122.19:52050] \nE_USER_WARNING in /var/www4/html/web/lib/MRBS/DB_mysql.php at line 107\nGET_LOCK timed out after 20 seconds\nMRBS GET: Array\n(\n)\nMRBS POST: Array\n(\n    [csrf_token] => 0b68da104b2fd04d1ad3e8ed2d80486f9cf76147dea7b9f60c06bcab2fb4cbeb\n    [returl] => https://10.99.122.38/web/\n    [rep_id] => 0\n    [edit_type] => series\n    [name] => Test\n    [description] => Test only\n    [start_date] => 2021-01-07\n    [start_seconds] => 41400\n    [all_day] => \n    [end_date] => 2021-01-07\n    [end_seconds] => 45000\n    [area] => 3\n    [rooms] => Array\n        (\n            [0] => 36\n        )\n\n    [type] => I\n    [confirmed] => 1\n    [f_branch] => \n    [f_mobile] => \n    [allow_registration] => \n    [enable_registrant_limit] => 1\n    [registrant_limit] => 1\n    [rep_type] => 0\n    [rep_day] => Array\n        (\n            [0] => 4\n        )\n\n    [month_type] => 0\n    [month_absolute] => 7\n    [month_relative_ord] => 1\n    [month_relative_day] => TH\n    [rep_interval] => 1\n    [rep_end_date] => 2021-01-07\n    [skip] => \n)\nMRBS SESSION: Array\n(\n    [csrf_token] => 0b68da104b2fd04d1ad3e8ed2d80486f9cf76147dea7b9f60c06bcab2fb4cbeb\n    [user] => MRBS\\User Object\n        (\n            [username] => gwilson\n            [display_name] => Greg Wilson\n            [email] => ****@****.****\n            [level] => 2\n        )\n\n)\n\n, referer: https://10.99.122.38/web/edit_entry.php?view=day&year=2021&month=1&day=7&area=3&room=36&hour=11&minute=30
[Thu Jan 07 10:20:59.006674 2021] [:error] [pid 23899] [client 10.99.122.19:52054] \nE_USER_WARNING in /var/www4/html/web/lib/MRBS/DB_mysql.php at line 107\nGET_LOCK timed out after 20 seconds\nMRBS GET: Array\n(\n)\nMRBS POST: Array\n(\n    [csrf_token] => 0b68da104b2fd04d1ad3e8ed2d80486f9cf76147dea7b9f60c06bcab2fb4cbeb\n    [returl] => https://10.99.122.38/web/\n    [rep_id] => 0\n    [edit_type] => series\n    [name] => Test\n    [description] => Test only\n    [start_date] => 2021-01-07\n    [start_seconds] => 41400\n    [all_day] => \n    [end_date] => 2021-01-07\n    [end_seconds] => 42300\n    [area] => 3\n    [rooms] => Array\n        (\n            [0] => 36\n        )\n\n    [type] => I\n    [confirmed] => 1\n    [f_branch] => \n    [f_mobile] => \n    [allow_registration] => \n    [enable_registrant_limit] => 1\n    [registrant_limit] => 1\n    [rep_type] => 0\n    [rep_day] => Array\n        (\n            [0] => 4\n        )\n\n    [month_type] => 0\n    [month_absolute] => 7\n    [month_relative_ord] => 1\n    [month_relative_day] => TH\n    [rep_interval] => 1\n    [rep_end_date] => 2021-01-07\n    [skip] => \n)\nMRBS SESSION: Array\n(\n    [csrf_token] => 0b68da104b2fd04d1ad3e8ed2d80486f9cf76147dea7b9f60c06bcab2fb4cbeb\n    [user] => MRBS\\User Object\n        (\n            [username] => gwilson\n            [display_name] => Greg Wilson\n            [email] => ****@****.****\n            [level] => 2\n        )\n\n)\n\n, referer: https://10.99.122.38/web/edit_entry.php?view=day&year=2021&month=1&day=7&area=3&room=36&hour=11&minute=30
[Thu Jan 07 10:21:01.211139 2021] [:error] [pid 9251] [client 10.99.122.19:52063] Uncaught exception 'MRBS\\DBException' in /var/www4/html/web/lib/MRBS/DB.php at line 109\nSQLSTATE[23000]: Integrity constraint violation: 1048 Column 'create_by' cannot be null\nSQL: INSERT INTO mrbs_entry (`start_time`, `end_time`, `entry_type`, `repeat_id`, `room_id`, `create_by`, `modified_by`, `name`, `type`, `description`, `status`, `ical_uid`, `ical_sequence`, `ical_recur_id`, `branch`, `mobile`, `enable_registrant_limit`, `registrant_limit`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)\nParams: Array\n(\n    [0] => 1609979400\n    [1] => 1609980300\n    [2] => 0\n    [3] => \n    [4] => 36\n    [5] => \n    [6] => \n    [7] => Test\n    [8] => I\n    [9] => Test only\n    [10] => 0\n    [11] => MRBS-5ff645dd33275-1dd4abf3@10.99.122.38\n    [12] => 0\n    [13] => \n    [14] => Lismore\n    [15] => \n    [16] => 1\n    [17] => 1\n)\n\n#0 /var/www4/html/web/mrbs_sql.inc(988): MRBS\\DB->command('INSERT INTO mrb...', Array)\n#1 /var/www4/html/web/mrbs_sql.inc(1017): MRBS\\mrbsCreateEntry('mrbs_entry', Array)\n#2 /var/www4/html/web/mrbs_sql.inc(2457): MRBS\\mrbsCreateSingleEntry(Array)\n#3 /var/www4/html/web/edit_entry_handler.php(765): MRBS\\mrbsMakeBookings(Array, NULL, false, NULL, NULL, true, 'series')\n#4 {main}\n\nMRBS GET: Array\n(\n)\nMRBS POST: Array\n(\n    [csrf_token] => 0b68da104b2fd04d1ad3e8ed2d80486f9cf76147dea7b9f60c06bcab2fb4cbeb\n    [returl] => https://10.99.122.38/web/\n    [rep_id] => 0\n    [edit_type] => series\n    [name] => Test\n    [description] => Test only\n    [start_date] => 2021-01-07\n    [start_seconds] => 41400\n    [end_date] => 2021-01-07\n    [end_seconds] => 42300\n    [area] => 3\n    [rooms] => Array\n        (\n            [0] => 36\n        )\n\n    [type] => I\n    [confirmed] => 1\n    [f_branch] => Lismore\n    [f_mobile] => \n    [enable_registrant_limit] => on\n    [registrant_limit] => 1\n    [rep_type] => 0\n    [rep_day] => Array\n        (\n            [0] => 4\n        )\n\n    [month_type] => 0\n    [month_absolute] => 7\n    [month_relative_ord] => 1\n    [month_relative_day] => TH\n    [rep_interval] => 1\n    [rep_end_date] => 2021-01-07\n)\nMRBS SESSION: Array\n(\n    [csrf_token] => 0b68da104b2fd04d1ad3e8ed2d80486f9cf76147dea7b9f60c06bcab2fb4cbeb\n    [user] => MRBS\\User Object\n        (\n            [username] => gwilson\n            [display_name] => Greg Wilson\n            [email] => ****@****.****\n            [level] => 2\n        )\n\n)\n\n, referer: https://10.99.122.38/web/edit_entry.php?view=day&year=2021&month=1&day=7&area=3&room=36&hour=11&minute=30
[Thu Jan 07 10:22:13.198753 2021] [mpm_prefork:notice] [pid 4313] AH00169: caught SIGTERM, shutting down

Original comment by: gwilsonau

[jberanek]

BTW The site is running PHP 7.0 Problem occurred after updating form MRBS 1.7.1 to 1.9.2

Original comment by: gwilsonau

[jberanek]

(1) I am now sometimes able to create new bookings but it takes over a minute for the screen to refresh - hence the timeouts above. I've been doing some SQL tuning as both html and php web pages seem to be very fast. I've increased the innodb_buffer_pool_size t0 8 Gb but it hasn't helped. Webmin is also slow although all memory, PC use etc is all very low <10%. (2) I have made that entry and removed the booking for field.

Thanks,

Greg.

Original comment by: gwilsonau

[jberanek]

I don't quite understand what's going on. There seem to be two problems:

1. You are getting a timeout when MRBS is trying to get a lock. However this should result in the fatal error message "Failed to acquire exclusive database access", not "unfortunately the database is not available at the moment". Have you been getting the "failed to acquire ..." message?
2. You are getting an SQL error because the create_by field is empty.

Can you tell me what authentication scheme you are using please? Also, are you still getting errors having removed the "Created by" field?

Original comment by: campbell-m

[jberanek]

Campbell,

We’re using ldaps to Windows Active directory.

No currently getting failures but entries are taking over a minute to run after submitted.

Thanks,

Greg

Original comment by: gwilsonau

[jberanek]

I think the problem is nothing to do with the database but instead it's to do with the MRBS LDAP code. Here are some things to try:

(1) Switch to the 'config' auth scheme in order to test whether the problem is LDAP. Just set $auth['type'] = 'config'; and login with the default username/password of "administrator" and "secret". See if it's now quick to make a booking.

(2) Switch back to the LDAP scheme. If you have email notifications enabled then temporarily disable them by setting $mail_settings]['disabled'] = true;. If that speeds things up then it also points to the LDAP code.

(3) Upgrade to the latest version of the development code in the default branch. This is a sort of 1.9.2+ release and has some improvements to the LDAP code. You can download the latest code by following the "Download Snapshot" link on this page. Then just treat it like an upgrade to a new release.

Original comment by: campbell-m

[jberanek]

Campbell,

Thanks for your help with this.

1. This didn't make much difference to the time to make a booking still from 20 to 35 seconds Possbily becuse I'm retrieving user's email details via ldap. That could still be happening even when not authenticating via ldap.
2. This setting stopped the site working every time, even though I tried with true in single quotes.
3. I'll try the dve release this morning and see if it helps.

Original comment by: *anonymous

[jberanek]

1. No, the address won't be retrieved from LDAP if you have the 'config' authentication type. But it sounds as though it has made some difference, down from "over a minute" to 20-35 seconds. Is that correct?
2. Sorry, there was a typo in my config setting. It should be $mail_settings['disabled'] = true;.
3. Did you get a chance to try the new code?

Original comment by: campbell-m

[jberanek]

Campbell,

The dev code is quicker but 20 seconds to record, change or delete an entry is still long.

2. I disabled mail and response time was really fast - a second or two. Once mail enabled again I tried changing the mail server name entry in MRBS to be the name the mail server responds with via smtp, also tried using it's ip rather than a name but it didn't help.

Here's the mail setup:

// These settings are only used with the "smtp" backend
$mail_settings['admin_backend'] = 'mail';
//$mail_settings['admin_backend'] = 'smtp';
$smtp_settings['host'] = 'mail.summerland.com.au'; // SMTP server
$smtp_settings['port'] = 25; // SMTP port number
$smtp_settings['auth'] = FALSE; // Whether to use SMTP authentication
$smtp_settings['username'] = ''; // Username (if using authentication)
$smtp_settings['password'] = ''; // Password (if using authentication)

//Who to email
$mail_settings['admin_on_bookings']      = FALSE;  // the addresses defined by $mail_settings['recipients'] below
$mail_settings['area_admin_on_bookings'] = FALSE;  // the area administrator
$mail_settings['room_admin_on_bookings'] = TRUE;  // the room administrator - Email address set on the room
$mail_settings['booker']                 = FALSE;  // the person making the booking
$mail_settings['book_admin_on_approval'] = FALSE;  // the booking administrator when booking approval is enabled

//When to email
$mail_settings['on_new']    = TRUE;   // when an entry is created
$mail_settings['on_change'] = TRUE;  // when an entry is changed
$mail_settings['on_delete'] = TRUE;  // when an entry is deleted
//Restric email settings
$mail_settings['allow_no_mail']        = FALSE;
$mail_settings['allow_admins_no_mail'] = FALSE;  // Ignored if 'allow_no_mail' is TRUE
$mail_settings['no_mail_default'] = FALSE;
//What to email
$mail_settings['details']   = TRUE; // Set to TRUE if you want full booking details;
                                     // otherwise you just get a link to the entry
$mail_settings['html']      = TRUE; // Set to true if you want HTML mail
$mail_settings['icalendar'] = TRUE; // Set to TRUE to include iCalendar details

$mail_settings['admin_lang'] = 'en';   // Default is 'en'.
//Only allow Admins to make repeat bookings
$auth['only_admin_can_book_repeat'] = FALSE;
$auth['only_admin_can_select_multiroom'] = true;

3. I'm using the Dev code now. It shows as 1.9.2 in Help with Database schema version 81

Thanks,

Greg.

Original comment by: gwilsonau

[jberanek]

Just so that we can isolate the problem can you try setting

$mail_settings['icalendar'] = false; 

If that speeds things up then change it back to true and try setting

$zoneinfo_expiry = PHP_INT_MAX;

If you are still having problems then have a look in your PHP error log for errors. If you can't find your error log you can, temporarily, set

$debug = true;

and the errors will be displayed in the browser. But remember to turn that off before you go live.

Original comment by: campbell-m

[jberanek]

Icalendar false didn't help. I'm checking mail log on web server and email server, which is internal. No delays at receiving end but I can see delays at sending end. The only error is:

Authentication-Warning: SCULDAWEB3.lismore.local: www-data set sender to password_reset@summerland.com.au using -f

I've tried adding www-data to /etc/mail/trusted-users and restarted sendmail but error is still appearing and sending is still slow.

I don't know if that's what's causing the delay but 20 seconds delay appears for these messages in web server mail.log.

Original comment by: gwilsonau

[jberanek]

Campbell,

I've finally fixed the problem!

I installed Postifx with a simple config to send all mail via our internal email server. I stopped sendmail in startup and rebooted the web server. Creating and deleting bookings in MRBS is now instant again.

I don't know why sendmail was was inserting a 20 second delay into the email sending process but now, even if there is a delay sending, it happens in the background without slowing down MRBS.

Many thanks for your help troubleshooting this.

Cheers,

Greg.

Original comment by: gwilsonau

[jberanek]

Glad it's working now, but I suspect there's still underlying problem somewhere. Was it actually sending email when you were using sendmail? And were you getting any errors in your PHP error log?

Original comment by: campbell-m

[jberanek]

Campbell,

I think the problem changed with the upgrades as the database not available warning was coming up at first. Is it possible that the email sending was the problem the whole time and the code's written to update the booking into the database once the email sending's complete? Sendmail was definitely getting a 20 second delay on sending email. I haven't worked out why as dns, bandwidth and connectivity all seem fine. Installing Postfix solved the problem as it accepts mail instantly and handles the delay internally.

I didn't see much in the php log so was using Apache2 log and mail log to faultfind.

Cheers,

Greg.

Original comment by: gwilsonau

[jberanek]

I think there were two problems: the first was slow LDAP code, which was improved when you upgraded to the development code, and the second was the email problem.

The way the code works is that it writes to the database first and then sends the email. But you won't be returned to the original page until the email has been sent.

One of the things that's different between 1.7.1 and 1.9.2 is that in 1.9.2 email is not actually sent immediately but instead added to a queue which is then processed in a shutdown function. (You still won't get back to the original page until the shutdown function has finished, but it does allow you to modify the code and, for example, do the mail processing in a cron job).

One of the things about running in a shutdown function is that on some servers, eg Apache, the working directory of the script can change and I just wonder whether this was causing problems for sendmail. So it would be interesting to know whether sendmail was actually managing to send an email, even though it took 20 seconds, or whether the email was never sent and the script was just timing out after 20 seconds?

Original comment by: campbell-m

[jberanek]

I could see the emails were being sent and every indication was that the 20 second delay was on the sending side. i.e receiving email server was recording no delay.

From: Campbell Morrison cimorrison@users.sourceforge.net Sent: Friday, 15 January 2021 8:38 AM To: [mrbs:support-requests] 2270@support-requests.mrbs.p.re.sourceforge.net Subject: [mrbs:support-requests] #2270 Fatal error: unfortunately the database is not available at the moment.

I think there were two problems: the first was slow LDAP code, which was improved when you upgraded to the development code, and the second was the email problem.

The way the code works is that it writes to the database first and then sends the email. But you won't be returned to the original page until the email has been sent.

One of the things that's different between 1.7.1 and 1.9.2 is that in 1.9.2 email is not actually sent immediately but instead added to a queue which is then processed in a shutdown function. (You still won't get back to the original page until the shutdown function has finished, but it does allow you to modify the code and, for example, do the mail processing in a cron job).

One of the things about running in a shutdown function is that on some servers, eg Apache, the working directory of the script can change and I just wonder whether this was causing problems for sendmail. So it would be interesting to know whether sendmail was actually managing to send an email, even though it took 20 seconds, or whether the email was never sent and the script was just timing out after 20 seconds?

---

[support-requests:#2270]https://sourceforge.net/p/mrbs/support-requests/2270/ Fatal error: unfortunately the database is not available at the moment.

Status: open Group: Created: Wed Jan 06, 2021 05:15 AM UTC by Greg Wilson Last Updated: Thu Jan 14, 2021 09:07 AM UTC Owner: nobody

Just upgraded to MRBS 1.9.2 and it's moslty running ok excep that I get "Fatal error: unfortunately the database is not available at the moment." error when creating a new booking. Am using MYSQL back end on same server.

Also am now seeing a "Created By" box at the top of each booking. It was just using logged in user. How do i get rid of that?

Thanks in advance,

Greg.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/mrbs/support-requests/2270/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

Greg Wilson

System & Network Administrator Infrastructure Summerland Credit Union

p 1300 802 222 | d 6620 7010 | m 0400 438 038 | w summerland.com.auhttps://summerland.com.au | e gwilson@summerland.com.au

[https://summerland.com.au/emailsigs/sculemailsig.jpg]

[https://summerland.com.au/images/content/annual_report/Kincentric.png]https://summerland.com.au/news/290-summerland-recognised-as-one-of-australia-s-leading-employers

making a difference by providing people with ethical banking solutions to fulfill their life dreams

This email from Summerland contains guidance only and should not be relied upon as advice. The content of this email is confidential and may be subject to the provisions of the Privacy Act. If received in error, please notify the sender and delete immediately. Please consider the environment before printing this email. Proudly the first financial institution in NSW to achieve Gold Partner Accreditation in the Sustainability Advantage Programhttps://summerland.com.au/sustainability

Original comment by: gwilsonau

Attachments: https://sourceforge.net/p/mrbs/support-requests/_discuss/thread/246cfd94e4/667c/3cd9/attachment/alternate