Document FreeBSD installation instructions

[zi0r]

I've created a port/package of proxysql for FreeBSD users. You can view details here:
proxysql port

This will enable them to easily install proxysql via ports or the FreeBSD package management system.

If interested, there are various tweaks to the source that might make future maintenance a little easier:

• Convert gnugrep regexes: grep -Po '\d\d\d\d\d\dL' -> egrep '[0-9]{5}L': gnugrep is not installed by default.
• Consider adding support for log file close/reopen via a signal (or config file knob to allow printing log lines without the timestamp so that they may be easily forwarded to syslog or native syslog support). FreeBSD's newsyslog doesn't support the 'copytruncate' option that logrotate does.
• Update syntax when using ln: ln -fsT -> ln -fs: FreeBSD lacks the -T arg.
• Make PROXYSQLCLICKHOUSE configurable via an environment variable: Most users probably don't need clickhouse support and their library didn't trivially compile for me.
• Make paths (/etc, /var/lib/proxysql, etc.) more easily configurable at build time.

[mirostauder]

Automated message: PR pending admin approval for build testing

[zi0r]

I've also discovered an additional (non-impactful) issue in lib/ProxySQL_Admin.cpp:get_open_fds(), which attempts to open /proc/self/fd. However, even with procfs mounted on FreeBSD, there is no /proc/self.

The closest is /proc/curproc, which contains:
% ls /proc/curproc/

cmdline dbregs  etype   file    fpregs  map     mem     note    notepg  osrel   regs    rlimit  status

It looks like this only impacts statistics; however, it does produce an error every so often:

ProxySQL_Admin.cpp:9512:get_open_fds(): [ERROR] 'opendir()' failed with error: '2'

A quick fix for this could simply be to wrap the call (int32_t cur_fds = get_open_fds();) and subsequent if in lib/ProxySQL_Admin.cpp in something like:

#ifndef __FreeBSD__
...

[zi0r]

There also appears to be an issue with the code to enable the RESTapi server in lib/ProxySQL_RESTAPI_Server.cpp.

ProxySQL_Admin.cpp:2009:admin_handler_command_set(): [INFO] Received command SET admin-restapi_enabled='true'
Query OK, 1 row affected (0.00 sec)

mysql> 
mysql> LOAD ADMIN VARIABLES TO RUNTIME;
 ProxySQL_Admin.cpp:1069:is_admin_command_or_alias(): [INFO] Received LOAD ADMIN VARIABLES TO RUNTIME command
 ProxySQL_Admin.cpp:7351:flush_admin_variables___database_to_runtime(): [INFO] Computed checksum for 'LOAD ADMIN VARIABLES TO RUNTIME' was '0xF5493CB4BE1DDC86', with epoch '1711986969'
in.cpp:1355:my_terminate(): [ERROR] ProxySQL crashed due to exception
Query OK, 0 rows affected (0.01 sec)

mysql> BACKTRACE ------------
0x689530 <_Z12my_terminatev+0x46> at /usr/local/sbin/proxysql
0x8280a7b16 <_ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE+0x76> at /usr/local/lib/gcc12/libstdc+.so.6
0x8280a7b71 <_ZSt9terminatev+0x11> at /usr/local/lib/gcc12/libstdc++.so.6
0x8280a7dec <__cxa_throw+0x4c> at /usr/local/lib/gcc12/libstdc++.so.6
0x675f53 <_ZN10httpserver9webserver5startEb.cold+0x81> at /usr/local/sbin/proxysql
0x832aae <_Z21restapi_server_threadPv+0xe> at /usr/local/sbin/proxysql
0x823a97a75 <pthread_create+0x8d5> at /lib/libthr.so.3
----------------------
^DBye
[1]   Abort trap (core dumped) /usr/local/sbin/proxysql -f -c /usr/local/etc/proxysql/proxysql.cfg

I was able to track this down to the following line:

ws = std::unique_ptr<httpserver::webserver>(new webserver(create_webserver(p)));

I was able to resolve this issue, and get the RESTapi to successfully launch by replacing it with:

ws = std::unique_ptr<httpserver::webserver>(new webserver(create_webserver(p).start_method(http::http_utils::start_method_T::THREAD_PER_CONNECTION)));

After skimming the libhttpserver documents, I'm guessing there is an issue with the default INTERNAL_SELECT option. I didn't investigate further as the above patch (in limited testing) appears to be fine.

[zi0r]

The idea for configurable timestamp output in log lines would also be useful for systemd users, in the event they wanted to allow systemd to handle logging on behalf of the application. In that scenario, those users would also see double timestamps.

[renecannao]

Hi @zi0r .

Thank you for the PR.
@mirostauder is already working on some of the items you mentioned.

About get_open_fds() , it seems we need to use /dev/fd on FreeBSD : https://man.freebsd.org/cgi/man.cgi?query=fdescfs

About the RESTAPI , I think we should leave INTERNAL_SELECT as the default, and use THREAD_PER_CONNECTION for FreeBSD .

About "support for log file close/reopen" : you can use PROXYSQL FLUSH LOGS command as an alternative. Is that good enough?

About "allow printing log lines without the timestamp" : this is a possible feature requests. Even if, interestingly, recently we have seen case in which timestamps of proxysql and system logs were out of sync for several minutes when the system was overloaded, thus relying on proxysql timestamp is better for troubleshooting.

[zi0r]

Thank you for the PR. @mirostauder is already working on some of the items you mentioned.

Thank you all for the quick replies!

About get_open_fds() , it seems we need to use /dev/fd on FreeBSD : https://man.freebsd.org/cgi/man.cgi?query=fdescfs

fdescfs would be fine. Example output from a login shell:

% ls /dev/fd
0 1 2 3 4

About the RESTAPI , I think we should leave INTERNAL_SELECT as the default, and use THREAD_PER_CONNECTION for FreeBSD .

This sounds perfect.

About "support for log file close/reopen" : you can use PROXYSQL FLUSH LOGS command as an alternative. Is that good enough?

If you can add a signal hook to allow a SIGUSR1/SIGUSR2/SIGHUP (these are the common ones) to trigger the same functionality, that would be ideal. FreeBSD's newsyslog (their tool for rotating logs) supports sending a signal after log rotation. However, it doesn't natively support MySQL commands.

newsyslog effectively runs mv thing.log thing.log.0;bzip thing.log.0;touch thing.log;kill -USR1 $pid

Perhaps we could look at moving the logic from lib/ProxySQL_Admin.cpp's PROXYSQL FLUSH LOGS handler into a shared function that both it and a new signal hook can call.

About "allow printing log lines without the timestamp" : this is a possible feature requests. Even if, interestingly, recently we have seen case in which timestamps of proxysql and system logs were out of sync for several minutes when the system was overloaded, thus relying on proxysql timestamp is better for troubleshooting.

From a FreeBSD perspective, if we can add the signal to trigger the log files to close/re-open, then I'm no longer worried about the timestamps. :)

This was the interim hack I used in the port:

sed -i.bak -e 's|strftime(__buffer, 25, "%Y-%m-%d %H:%M:%S", __tm_info);|snprintf(__buffer, 3, "%s", "");|g' -e 's,"%s \[,"%s\[,g' -e '/__timer/d' -e '/__tm_info/d' include/proxysql_debug.h

So, just about anything will be an improvement. :)

Here's a link to the port Makefile/patches/etc. I'm happy to incorporate any changes you may be interested in.

[mirostauder]

Can one of the admins verify this patch?

[zi0r]

I haven't had a chance to dig into this just yet; however, the sqlite3 dep is failing to build under FreeBSD in v2.6.3--it previously built fine with the 2.6.2 release. Tons (> 10,000 lines) of errors like the following:

sqlite3.c:175061:35: note: (near initialization for 'zKWText')
sqlite3.c:175061:39: warning: excess elements in scalar initializer
175061 |   'R','E','I','N','D','E','X','E','D','E','S','C','A','P','E','A','C','H',
       |                                       ^~~
sqlite3.c:175061:39: note: (near initialization for 'zKWText')
sqlite3.c:175061:43: warning: excess elements in scalar initializer
175061 |   'R','E','I','N','D','E','X','E','D','E','S','C','A','P','E','A','C','H',
       |                                           ^~~
sqlite3.c:175061:43: note: (near initialization for 'zKWText')
sqlite3.c:175061:47: warning: excess elements in scalar initializer
175061 |   'R','E','I','N','D','E','X','E','D','E','S','C','A','P','E','A','C','H',
       |                                               ^~~
sqlite3.c:175061:47: note: (near initialization for 'zKWText')
sqlite3.c:175061:51: warning: excess elements in scalar initializer
175061 |   'R','E','I','N','D','E','X','E','D','E','S','C','A','P','E','A','C','H',
       |                                                   ^~~
sqlite3.c:175061:51: note: (near initialization for 'zKWText')
sqlite3.c:175061:55: warning: excess elements in scalar initializer

[zi0r]

I haven't had a chance to dig into this just yet; however, the sqlite3 dep is failing to build under FreeBSD in v2.6.3--it previously built fine with the 2.6.2 release. Tons (> 10,000 lines) of errors like the following:

These errors were introduced by the sqlite3_pass_exts.patch patch. Working on figuring out a proper fix now.

sqlite3.c:25178:30: error: expected declaration specifiers before '__THROW'
25178 | extern int toupper (int __c) __THROW;
      |                              ^~~~~~~
sqlite3.c:25191:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25191 | int check_args_types(int argc, sqlite3_value** argv) {
      |                                                      ^
sqlite3.c:25203:56: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25203 | int check_args_lengths(int argc, sqlite3_value** argv) {
      |                                                        ^
sqlite3.c:25227:97: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25227 | static void mysql_native_passwordFunc(sqlite3_context* context, int argc, sqlite3_value** argv) {
      |                                                                                                 ^
sqlite3.c:25277:97: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25277 | static void caching_sha2_passwordFunc(sqlite3_context* context, int argc, sqlite3_value** argv) {
      |                                                                                                 ^
sqlite3.c:25357:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25357 | ){
      |  ^
sqlite3.c:25371:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25371 | ){
      |  ^
sqlite3.c:25397:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25397 | ){
      |  ^
sqlite3.c:25496:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25496 | ){
      |  ^
sqlite3.c:25552:59: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25552 | SQLITE_PRIVATE void sqlite3RegisterDateTimeFunctions(void){
      |                                                           ^
sqlite3.c:25658:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25658 | SQLITE_PRIVATE void sqlite3OsClose(sqlite3_file *pId){
      |                                                      ^
sqlite3.c:25664:84: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25664 | SQLITE_PRIVATE int sqlite3OsRead(sqlite3_file *id, void *pBuf, int amt, i64 offset){
      |                                                                                    ^
sqlite3.c:25668:91: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25668 | SQLITE_PRIVATE int sqlite3OsWrite(sqlite3_file *id, const void *pBuf, int amt, i64 offset){
      |                                                                                           ^
sqlite3.c:25672:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25672 | SQLITE_PRIVATE int sqlite3OsTruncate(sqlite3_file *id, i64 size){
      |                                                                 ^
sqlite3.c:25675:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25675 | SQLITE_PRIVATE int sqlite3OsSync(sqlite3_file *id, int flags){
      |                                                              ^
sqlite3.c:25679:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
25679 | SQLITE_PRIVATE int sqlite3OsFileSize(sqlite3_file *id, i64 *pSize){
      |                                                                   ^
sqlite3.c:25683:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token

[zi0r]

This resolves the build. I'm guessing ctype.h gets included somehow under Linux, but not under FreeBSD?

Perhaps it would be more appropriate to replace the toupper() calls with calls to sqlite3Toupper() as they have builtin defines to handle this (and then remove the offending line below)?

--- a/deps/sqlite3/sqlite3_pass_exts.patch
+++ b/deps/sqlite3/sqlite3_pass_exts.patch
@@ -11,7 +11,7 @@
 +////////////////////////////////////////////////////////////////////////////////
 +
 +// ctype.h
-+extern int toupper (int __c) __THROW;
++extern int toupper (int __c);
 +
 +// SHA256_crypt
 +char * sha256_crypt_r (const char *key, const char *salt, char *buffer, int buflen);

[zi0r]

I've updated the port to 2.6.4. You can view the current Makefile/patches here