MySQL error on locking in recent Squeeze DAB template VM on bootup

apmuthu

Well-Known Member
Feb 26, 2009
807
8
58
Chennai - India & Singapore
github.com
Recreated a MediaWiki v1.16.5 template on Squeeze using DAB and created and ran a VM using it.
Code:
# cat /var/log/syslog
Jan 29 17:09:29 mywiki kernel: imklog 4.6.4, log source = /proc/kmsg started.
Jan 29 17:09:29 mywiki rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="266" x-info="http://www.rsyslog.com"] (re)start
Jan 29 17:09:29 mywiki /usr/sbin/cron[294]: (CRON) INFO (pidfile fd = 3)
Jan 29 17:09:29 mywiki /usr/sbin/cron[295]: (CRON) STARTUP (fork ok)
Jan 29 17:09:29 mywiki /usr/sbin/cron[295]: (CRON) INFO (Running @reboot jobs)
Jan 29 17:09:30 mywiki mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Jan 29 17:09:30 mywiki mysqld: 130129 17:09:30 [Note] Plugin 'FEDERATED' is disabled.
Jan 29 17:09:30 mywiki mysqld: 130129 17:09:30  InnoDB: Initializing buffer pool, size = 8.0M
Jan 29 17:09:30 mywiki mysqld: 130129 17:09:30  InnoDB: Completed initialization of buffer pool
Jan 29 17:09:30 mywiki mysqld: 130129 17:09:30  InnoDB: Started; log sequence number 0 44233
Jan 29 17:09:30 mywiki mysqld: 130129 17:09:30 [Note] Event Scheduler: Loaded 0 events
Jan 29 17:09:30 mywiki mysqld: 130129 17:09:30 [Note] /usr/sbin/mysqld: ready for connections.
Jan 29 17:09:30 mywiki mysqld: Version: '5.1.66-0+squeeze1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[469]: Upgrading MySQL tables if necessary.
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Looking for 'mysql' as: /usr/bin/mysql
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock'
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Running 'mysqlcheck' with connection arguments: '--port=3306' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock' '--host=localhost' '--socket=/var/run/mysqld/mysqld.sock'
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.columns_priv                                 OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.db                                           OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.event                                        OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.func                                         OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.general_log
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Error    : You can't use locks with log tables.
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: status   : OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.help_category                                OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.help_keyword                                 OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.help_relation                                OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.help_topic                                   OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.host                                         OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.ndb_binlog_index                             OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.plugin                                       OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.proc                                         OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.procs_priv                                   OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.servers                                      OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.slow_log
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Error    : You can't use locks with log tables.
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: status   : OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.tables_priv                                  OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.time_zone                                    OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.time_zone_leap_second                        OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.time_zone_name                               OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.time_zone_transition                         OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.time_zone_transition_type                    OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: mysql.user                                         OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: Running 'mysql_fix_privilege_tables'...
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[473]: OK
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[533]: Checking for insecure root accounts.
Jan 29 17:09:31 mywiki /etc/mysql/debian-start[537]: Triggering myisam-recover for all MyISAM tables
Jan 29 17:09:49 mywiki postfix/master[686]: daemon started -- version 2.7.1, configuration /etc/postfix
Jan 29 17:11:29 mywiki init: Id "1" respawning too fast: disabled for 5 minutes
Jan 29 17:11:29 mywiki init: no more processes left in this runlevel
Jan 29 17:18:10 mywiki init: Id "1" respawning too fast: disabled for 5 minutes
Jan 29 17:22:01 mywiki /USR/SBIN/CRON[761]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jan 29 17:24:51 mywiki init: Id "1" respawning too fast: disabled for 5 minutes
Jan 29 17:31:32 mywiki init: Id "1" respawning too fast: disabled for 5 minutes
Jan 29 17:38:13 mywiki init: Id "1" respawning too fast: disabled for 5 minutes
Jan 29 17:39:01 mywiki /USR/SBIN/CRON[800]: (root) CMD ([ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Jan 29 17:44:54 mywiki init: Id "1" respawning too fast: disabled for 5 minutes
There are quite a few Error : You can't use locks with log tables. in the above.

One Post says it is harmless.

Running table checks implicitly locks the table (equivalent to executing 'LOCK TABLES') to prevent concurrency issues. The log engine is a table type (just like myisam and innodb) that was introduced in 5.1 which do not need - and thus do not support - locking. The mysql slow log and general log use said engine by default.

The contents of /etc/inittab is (init is PID 1):
Code:
# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:2:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."

# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty 38400 tty1

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3
 
Last edited:
Re: MySQL error on locking in recent Squeeze DAB template VM on bootup - Fixed

All recent DAB Builds will have the following line appended to the /etc/inittab file in the template:
Code:
1:2345:respawn:/sbin/getty 38400 tty1
This must be commented out like:
Code:
# 1:2345:respawn:/sbin/getty 38400 tty1
The sed code to do it is:
Code:
sed -e 's/^\s*1:2345:respawn/# 1:2345:respawn/' -i /etc/inittab

In a running container, after doing the above, reinitialise with:
Code:
telinit q
 
Last edited:
Re: MySQL error on locking in recent Squeeze DAB template VM on bootup - Fixed

All recent DAB Builds will have the following line appended to the /etc/inittab file in the template:

The line is correct (used for new openvz console feature).
 
Re: MySQL error on locking in recent Squeeze DAB template VM on bootup - Fixed

If the line in /etc/inittab is required for PVE 2.x OpenVZ containers and causes problems for PVE 1.x OpenVZ containers if not commented out, I foresee a flood of migrations will be affected by this.

Also then we must maintain separate templates and possibly a different DAB for each PVE or atleast build in intelligent templates atleast.

Any standard way of determining what version of vzctl or PVE to look for when porting containers and building generic templates?

pveversion | cut -d/ -f2 yields 1.9 or 2.2

Does DAB accept any if constructs?

Any way to determine the PVE version of the host from within the guest?

Such a change affects all existing OpenVZ container users not to mention the incompatibility that would arise in porting across standard OpenVZ installs / Xen / VMWare, etc.

Are there any other such template design issues that need to be considered when making generic ones for use in both PVE 1.x and PVE 2.x? The last time we were thrown off gear was when initrc was changed to insserv.

If the template is made for PVE 1.x and the said line remained commented out, would it affect the running of the container in PVE 2.x other than the lack of the console feature? Can the old PVE 1.x console method be used in PVE2.x for such containers?
 
Last edited:
Re: MySQL error on locking in recent Squeeze DAB template VM on bootup - Fixed

Are there any other such template design issues that need to be considered when making generic ones for use in both PVE 1.x and PVE 2.x? The last time we were thrown off gear was when initrc was changed to insserv.
The solution is to update any 1.X installation ASAP instead. And yes, you need to manually add the line on old containers to make the new console work.

see: http://pve.proxmox.com/wiki/OpenVZ_Console

If the template is made for PVE 1.x and the said line remained commented out, would it affect the running of the container in PVE 2.x other than the lack of the console feature?

no, just the console does not work.

Can the old PVE 1.x console method be used in PVE2.x for such containers?

No. The OpenVZ team decided to do not include the 'init logger' code. So we now use the official openvz solution for the console.
 
Re: MySQL error on locking in recent Squeeze DAB template VM on bootup - Fixed

Thanks Dietmar for clarity on the issue.

Made a separate Wiki Page to address these FAQs.

Any way to determine the PVE version of the host from within the guest other than putting in a file during container creation that will become wrong on migration?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!