Homebrew, PHP 7.1 en cURL error 56: SSLRead() return error -9806

Na het installeren van PHP 7.1 via Brew kreeg ik via de WordPress HTTP API soms de volgende foutmelding te zien:

cURL error 56: SSLRead() return error -9806

Ik was deze fout wel vaker tegen gekomen, maar het is altijd weer even zoeken naar de oplossing. Het belangrijkste is dat er gewerkt wordt Homebrew curl en openssl:

brew uninstall git
brew uninstall curl

brew install openssl
brew install libressl

brew install curl --with-openssl

brew install php71 --with-homebrew-curl --with-homebrew-libressl --build-from-source
brew install php71-xdebug
brew install php71-mcrypt

Verder zijn ook de volgende Homebrew packages handig om te installeren:

brew install svn

brew install git --with-brewed-curl --with-brewed-openssl --with-brewed-svn --without-completions
brew install git-ftp
brew install git-flow

brew install composer
brew install php-code-sniffer
brew install phpmd
brew install phpunit
brew install phpmyadmin

Bronnen

Problemen met MariaDB versie 10.1.8 op OS X El Capitan

Na het updaten van MariaDB via Brew naar versie 10.1.8 had ik problemen met het opstarten van de MySQL server.

~  mysqld
2015-10-28 10:45:19 140735257919488 [Note] mysqld (mysqld 10.1.8-MariaDB) starting as process 1069 ...
2015-10-28 10:45:19 140735257919488 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The InnoDB memory heap is disabled
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Memory barrier is not used
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Compressed tables use zlib 1.2.5
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Using CPU crc32 instructions
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Completed initialization of buffer pool
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Highest supported file format is Barracuda.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: The log sequence numbers 2407038528 and 2407038528 in ibdata files do not match the log sequence number 2407038728 in the ib_logfiles!
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Database was not shutdown normally!
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Starting crash recovery.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Restoring possible half-written data pages
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: from the doublewrite buffer...
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: 128 rollback segment(s) are active.
2015-10-28 10:45:19 140735257919488 [Note] InnoDB: Waiting for purge to start
2015-10-28 10:45:19 7000008b1000  InnoDB: Assertion failure in thread 123145311424512 in file btr0cur.cc line 5341
InnoDB: Failing assertion: rb_ctx != RB_NONE
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
151028 10:45:19 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.8-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467104 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48000
0   mysqld                              0x000000010f93bd21 my_print_stacktrace + 61
0   mysqld                              0x000000010f3dfffc handle_fatal_signal + 632
0   libsystem_platform.dylib            0x00007fff9501552a _sigtramp + 26
0   ???                                 0x0000000000000009 0x0 + 9
0   libsystem_c.dylib                   0x00007fff9f50237b abort + 129
0   mysqld                              0x000000010f782e39 _ZL28btr_check_blob_fil_page_typemmPKhm + 0
0   mysqld                              0x000000010f8cf80d _Z14row_purge_stepP9que_thr_t + 2334
0   mysqld                              0x000000010f8a2a1a _Z15que_run_threadsP9que_thr_t + 822
0   mysqld                              0x000000010f8f9862 _Z9trx_purgemmb + 2812
0   mysqld                              0x000000010f8eccb1 srv_purge_coordinator_thread + 2484
0   libsystem_pthread.dylib             0x00007fff94b169b1 _pthread_body + 131
0   libsystem_pthread.dylib             0x00007fff94b1692e _pthread_body + 0
0   libsystem_pthread.dylib             0x00007fff94b14385 thread_start + 13
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Aangezien ik geen MariaDB/MySQL expert ben heb ik niet de oorzaak van dit probleem kunnen vinden. Gelukkig kun je met Brew eenvoudig terug naar een oudere versie.

brew switch mariadb 10.0.21

Hiermee was het probleem direct opgelost.

Brew update PHP 5.6 tidy: Unable to initialize module

Na het update van Brew pakketten liep ik tegen de volgende foutmelding aan:

PHP Warning: PHP Startup: tidy: Unable to initialize module
Module compiled with build ID=API20131226,NTS
PHP compiled with build ID=API20131226,NTS,debug
These options need to match
 in Unknown on line 0

Dergelijke problemen zijn vaak eenvoudig op te lossen door pakketten even opnieuw te installeren vanuit de bron:

brew reinstall php56-tidy --build-from-source

Homebrew PHP memory limit verhogen voor Composer

Ik heb op mijn blog al regelmatig geschreven over Homebrew (brew), PHP en Composer. Soms komt het voor dat bij het uitvoeren van een Composer commando memory limit fouten optreden. Bijvoorbeeld:

$ composer update

Loading composer repositories with package information
Updating dependencies (including require-dev)

PHP Fatal error:  Allowed memory size of 1073741824 bytes exhausted at Zend/zend_vm_execute.h:551 (tried to allocate 32 bytes) in phar:///usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Dergelijke fouten zijn vrij eenvoudig op te lossen door de memory limit te verhogen. Dit kan eenvoudig door in het PHP configuratie bestand de memory limit te verhogen.

Hiervoor moet je echter wel weten wat de locatie is van PHP configuratie bestand. Met Homebrew is dit gelukkig eenvoudig te achterhalen. Hiervoor moeten we eerst weten van welke PHP versie we gebruik maken:

$ php -v

PHP 5.6.3 (cli) (built: Nov 16 2014 12:01:32) (DEBUG)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

Vervolgens kunnen we met het Homebrew info commando aanvullende informatie opvragen:

$ brew info php56

Dit commando zal de nodige informatie geven over PHP en onder het kopje “Caveats” zal de locatie van het PHP configuratie bestand vermeld staan:

The php.ini file can be found in:
    /usr/local/etc/php/5.6/php.ini

Vervolgens kan dit bestand met behulp van nano eenvoudig aangepast worden.

nano /usr/local/etc/php/5.6/php.ini

De memory_limit kan vervolgens eenvoudig aangepast worden van bijvoorbeeld:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 1024M

naar:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 4096M

Met behulp van het volgende commando kan gecontroleerd worden of de wijziging goed is doorgevoerd:

$ php -i | grep memory_limit

memory_limit => 4096M => 4096M

Website kopie maken met HTTrack

Soms wil je even een statische kopie van een website maken voor offline gebruik of als backup. Met behulp van wget kan eenvoudig een kopie gemaakt worden:

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent http://example.org

De wget tool neemt echter niet altijd alle gekoppelde stylesheets, scripts, afbeeldingen, etc. mee. Om een betere kopie te krijgen kan het daarom handig zijn om gebruik te maken van HTTrack. Met behulp van brew is deze tool eenvoudig te installeren op een Mac:

brew install httrack

Vervolgens kan met het httrack commando eenvoudig een kopie van een website gemaakt worden.

Homebrew MariaDB MySQL server has gone away

Bij het importeren van een grote WordPress database in mijn lokale MariaDB database server liep ik tegen de volgende fout aan:

ERROR 2006 (HY000) at line 40786: MySQL server has gone away

Na wat zoeken op internet kom je al snel berichten tegen dat dit te maken heeft met de ‘max_allowed_packet‘ configuratie instelling.

Na wat zoeken heb ik in mijn gebruikersmap (~) een MySQL configuratie bestand (~/.my.cnf) aangemaakt volgens de MariaDB documentatie.

https://mariadb.com/kb/en/mariadb/documentation/getting-started/configuring-mariadb-with-mycnf/#location-in-linux-unix-mac

Door hier het volgende in te zetten is de ‘max_allowed_packet’ instelling eenvoudig te verhogen.

[mysqld]
max_allowed_packet=1073741824

Vervolgens kan MariaDB database server eenvoudig herstart worden met behulp van het volgende commando:

mysql.server restart

Mijn MacBook Pro installatie

In dit bericht zal ik kort samenvatten hoe mijn MacBook Pro installatie er uit ziet qua programma’s, tools, addons, etc..

Webbrowsers

  • Google Chrome [standaard]
    • LastPass
    • AdBlock Plus
  • Firefox
    • LastPass
    • AdBlock Plus
    • Firebug
  • Opera
    • LastPass
  • Safari
    • LastPass

Productiviteit

  • Evernote
  • Dropbox
  • Alfred 2

Entertainment

  • Spotify
  • VLC

Ontwikkeling

  • iTerm2
  • Sublime Text 3
  • Java SE Development Kit
  • Eclipse
    • PHP Development Tools (PDT)
    • Preferences
      • PHP » Editor » Save Actions » ✓ Remove trailing whitespace » All lines
  •  SourceTree
    • Project folder: /Users/remco/Projects
    • Terminal App: iTerm2
    • Taal: English
  • FileZilla
    • Thema: Classic
  • Poedit
  • Homebrew
  • Node.js
    • brew install node
  • Git
    • brew install git
  • PHP
    • brew tap homebrew/dupes
    • brew tap homebrew/versions
    • brew tap homebrew/homebrew-php
    • brew install php56
  • PHP CodeSniffer
    • brew install php-code-sniffer
  • WordPress Coding Standards
    • https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards
  •  Grunt
    • npm install -g grunt-cli
    • npm install -g npm-check-updates
  • Xcode
  • VirtualBox
    • https://github.com/xdissent/ievms

Communicatie

  • Adium
  • Skype
  • Twitter

Overige

  • ScanSnap
    • ABBYY FineReader for ScanSnap
  • uTorrent
  • The Unarchiver
  • QFinder
  • Kitabu
  • Aegisub

Bronnen