Troubleshooting open_files_limit in MariaDB

Troubleshooting open_files_limit in MariaDB

It may happen in the MariaDB logs that you see failures to set open_files_limit:

160318 21:48:04 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295
160318 21:48:04 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295
160318 21:48:04 [Warning] Could not increase number of max_open_files to more than 1024 (request: 4907)

Meaning MariaDB was unable to raise the limit of maximum file descriptors at startup, with all the subsequent problems it can cause. Sometimes it is simply due to a bad setting in configuration files, such as:

open_files_limit=-1
Galera boot process in Open Stack HA and manual override

Galera boot process in Open Stack HA and manual override

Deployments of OpenStack that rely on MariaDB+Galera benefit from a HA database thanks to Galera's synchronous replication. In such deployments, the Galera cluster is typically managed via Pacemaker, by means of a galera resource agent.

While Galera itself has its own notion of cluster management (membership, health check, write-set replication...), a resource agent is still necessary for Pacemaker to perform the basic cluster management duties, for example:

  • Starting up the Galera servers on the available nodes in the cluster

  • Health monitoring and recovery actions on failure (e.g. fencing)

This document describes the concepts involved in booting a Galera cluster, how the galera resource agent implements the boot process of a galera cluster, and how it can be overriden for recovery scenarios.

Support for Aluminium Keyboards packaged, code-named apple-kbd

Support for Aluminium Keyboards packaged, code-named apple-kbd

After many episodes, the support for Apple Aluminium Keyboards is finally becoming user-friendly. All major distribs now ship a recent version of xkeyboard-config, so there is no need to mess with XKB patches anymore...

To complete the user experience, I'm happy to introduce you apple-kbd, the collection of helpful goodies you need for your Aluminium Keyboard under Linux. Here's what you'll get with this package:

Apple Aluminium Keyboards with udev, Xorg server 1.9

Apple Aluminium Keyboards with udev, Xorg server 1.9

It's been a year now since I published my support for Aluminium Keyboards. Since then, my XKB patches have been accepted in XKeyboardConfig 1.9, with a few modifications:

  • The multimedia keys can always be accessed by combining Fxx with the 3rd level chooser (this was option alul3media in my original XKB patches)
  • There is now a single XKB option alupckeys to emulate the behaviour of a PC keyboard, i.e. to enable PrintScreen, ScrollLock, SysReq and NumLock (options alupcfkeys and alupcnumlock in the original patches)
Aluminium Keyboard support under X11: all models, all OSes

Aluminium Keyboard support under X11: all models, all OSes

I finally found the time to update my previous support for Aluminium Keyboard under Xorg, and take it to the Next Level (tm). The overall support is now much more polished. For you this means several things:

  • I've implemented the XKB geometries of all variants of the long Aluminium Keyboard, be it ANSI (American), ISO (Internationnal) or JIS (Japanese)! And believe me, it's darned complicated to support JIS keyboard's dual layout without having access to the real hardware :D
  • I've added support for base XKB rules, which means that the keyboard will now be properly configured on other OSes than Linux. I personally used OpenSolaris during my tests, but it should work equally well on FreeBSD, OpenBSD, and all their cousins!
  • The keyboard support is now aware of the system-wide keyboard settings as found in Debian or Fedora for example. If you configured your system to default to Dvorak layout, the support will use it automatically!