Access denied for user debian-sys-maint

More info, via Alex: Codership deb packages use a different init script, which doesn't use the debian.cnf file in any way. You should probably copy that from upstream and the problem goes away.

Yes, using a different init script should do or running post-install configure after installation as mentioned in lp:1099429

I checked the init script in galera repo and it is still

MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"

Now, since this is a cluster environment, it doesn't make sense
to have different passwords for different boxes.

However, not providing the config file imples that, like
RHEL/CentOS, the root password is empty or provided in the cnf
file, otherwise the init will fail again.

Another possibility is to ignore the replication of mysql.users
table and run dpkg reconfigure after every SST. But this can get
complicated.

"Another possibility is to ignore the replication of mysql.users
table and run dpkg reconfigure after every SST. But this can get
complicated."

Whatever you do, don't do that. I'd rather see Debian's init script get neutered.

The CentOS script uses kill signals than use mysqladmin, which should be
fine.

Also, as discussed, this requires changes in PS's debian init script
too, for consistency.

Note, in PS's case, since there is no SST or any such automated
self-deployment, it is not that severe, but in cases where a
backup of say, master, is restored on slave, it can fail similarly.

For PS we should either document steps to fix this or, even better, probably just replace/patch/fix init scripts when PS is installed.

It seems to be not that critical in a non-cluster environment, I'm not familiar with how Debian manages MySQL, but would leaving the current behavior be least surprising there? Maybe let's just document it for PS for now?

If we want PS to be a drop-in replacement for Debian's provided MySQL, then probably we should not change the way init scripts work. Maybe we should just add some notes to the manual that after restoring mysql database from backup created on other server one has to deal with the problem outlined here somehow.

IMHO for PS not changing Debian's init scripts can make sense, but XtraDB Cluster is a much different product.
So after a new node joins the cluster for the first time, it's /etc/mysql/debian.cnf is no longer valid.

Also the upgrade_system_tables_if_necessary and check_for_crashed_tables parts of debian-start makes little to no sense on PXC.
The upgrade_system_tables_if_necessary will execute mysql_upgrade each time it won't see the mysql_upgrade_info file in place. So if an existing node is re-created with full SST, it won't get the mysql_upgrade_info file copied over with xtrabackup. The effect is that this node will work fine until you restart it. On restart, debian-start will notice there is no mysql_upgrade_info present, so it will fire mysql_upgrade, which does all the ALTERs for tables in mysql database whether those need an upgrade or not. And even though such ALTER fails on the node it's run on, still will be replicated via wsrep to other nodes making GRA files and errors on them. Just try doing "ALTER TABLE test.foo engine=innodb" on any node.

I wonder how this issue has been fixed? I did a clean install on two wheezy machines today and ran into this very same issue after the SST when adding the node (Access denied for user 'debian-sys-maint'@'localhost')? What should the debian startup script look like? Thanks!

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1276

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1962