Пересобрал пакеты PHP 7.1.20 и 7.2.9 для Debian Stretch

По-умолчанию в Debian Stretch поставляется PHP версии 7.0.30, но свежие версии Laravel требуют как минимум PHP версии 7.1.3. Чтобы решить эту проблему я пересобрал пакеты PHP 7.1.20 и 7.2.9 для Debian Stretch (только amd64). Никаких модицикаций делать не пришлось, только добавил суффикс "~stretch1" к версии пакета.

Найти их можно в секции backports моего репозитария или скачать напрямую (7.1.20 и 7.2.9). Все три версии можно установить одновременно, но для mod_php нужно включать нужную версию явно.

Решил проблему с медленным запуском jenkins slave на Raspberry PI 3

Продолжение истории с jenkins, предыдущие посты тут и тут.

После отката версии jenkins slave с 3.25 до 3.15 решил запостить баг. Нашел уже существующий JENKINS-53810, который похож по описанию на мою проблему. Попробовал предложенное решение, но мне оно не помогло.

Попутно гуглил об использовании jenkins slave на Raspberry PI и наткнулся на эту статью. В ней использовалась java от Oracle, а не OpenJDK, которая доступна в репозитариях Raspbian.

Пробую установить jdk для arm с сайта Oracle. Скачиваю файл jdk-8u181-linux-arm32-vfp-hflt.tar.gz (Linux ARM 32 Hard Float ABI) и заливаю его на raspberry

Теперь распаковываю архив в домашнюю директорию пользователя jenkins

$ cd /home/jenkins
$ tar -xzf /tmp/jdk-8u181-linux-arm32-vfp-hflt.tar.gz
$ ln -s jdk1.8.0_181 jdk
$ /home/jenkins/jdk/bin/java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) Client VM (build 25.181-b13, mixed mode)

Пробую для начала запустить slave из консоли

$ cat | /home/jenkins/jdk/bin/java -jar remoting.jar -workDir /home/jenkins

Прошло не больше 25 секунд, но slave уже отрапортовал о готовности! Стал разбираться в чем же разница между java от Oracle и OpenJDK. Заметил в выводе упоминание mixed или interpreted mode и различные названия java машин (OpenJDK Zero / HotSpot). Дальнейшее изучение вопроса привело к находке еще одного варианта jvm - JamVM, которая активируется ключем "-jamvm".

Пробую запустить jenkins slave через эту машину

$ cat | java -jamvm -jar remoting.jar -workDir /home/jenkins

Запуск занял примерно 2 минуты 30 секунд. Не так быстро как у HotSpot от Oracle, но и намного быстрее чем OpenJDK Zero.

Сравнение вывода версий OpenJDK Zero, JamVM и HotSpot

OpenJDK Zero
 

$ java -version
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b04)
OpenJDK Zero VM (build 25.40-b08, interpreted mode)

JamVM
 

$ java -jamvm -version
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b04)
JamVM (build 2.0.0, inline-threaded interpreter with stack-caching)

HotSpot
 

$ /home/jenkins/jdk/bin/java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) Client VM (build 25.181-b13, mixed mode)

Почитать о mixed, compiled, interpreted режимах компилятора jvm и флагах -Xint, -Xcomp, -Xmixed можно тут.

Откатил версию jenkins agent с 3.25 до 3.15 на Raspberry PI

Это продолжение истории с медленным запуском Jenkins агента на Raspberry PI.

Похоже я нашел версию Jenkins агента, которая успевает запуститься на Raspberry PI 3 за три минуты. Все версии агента после 3.15 стартуют дольше 5 минут. Я не мерял сколько стартует каждая из них отдельно, но 3.25 запускается примерно 15 минут.

Я не нашел правильного способа указать версию агента для каждой ноды и просто вставил костыль в виде "wget --no-verbose -O /home/jenkins/remoting.jar https://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15/remoting-3.15.jar && " (без кавычек) в параметр Prefix Start Agent Command в настройках ноды.

Теперь старт занимает меньше 3 минут

[09/30/18 12:12:27] [SSH] Checking java version of java
[09/30/18 12:12:28] [SSH] java -version returned 1.8.0_40-internal.
[09/30/18 12:12:28] [SSH] Starting sftp client.
[09/30/18 12:12:28] [SSH] Copying latest remoting.jar...
[09/30/18 12:12:28] [SSH] Copied 776,265 bytes.
Expanded the channel window size to 4MB
[09/30/18 12:12:28] [SSH] Starting agent process: wget -qO /home/jenkins/remoting.jar https://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15/remoting-3.15.jar && cd "/home/jenkins" && java  -jar remoting.jar -workDir /home/jenkins
Sep 30, 2018 12:12:45 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /home/jenkins/remoting
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.15
This is a Unix agent
Evacuated stdout
Agent successfully connected and online

В описании к версии 3.16 на первый взгляд ничего такого, что может тормозить запуск на 10 минут, нету.

Professional Cloud Architect

Я не считаю что наличие пачки сертификатов обязательно означает профессионализм их владельца. И на собеседованиях на сертификаты как правило обращаю внимание в последнюю очередь. Но есть случаи, когда сертификаты нужны работодателю чтобы получить доступ к новым проектам и клиентам. В этом случае сертификат компенсирует работодатель и не вижу причин его не получить.

Так и получилось с Google Cloud Certified - Professional Cloud Architect.

 

Подготовка заняла около месяца по 3-4 часа вечером, но стоит упомянуть что у меня уже есть два года с Amazon Web Services (AWS) и многие вещи оказались знакомыми. Закончил специализацию Architecting with Google Cloud Platform от Coursera и проштудировал материалы, которые порекомендовали коллеги.

Особенно рекомендую пройти Google Certified Professional Cloud Architect - Part 3 от LinuxAcademy. Первые две части я пропустил, т.к. они пересекаются с Coursera а времени у меня было немного. Практическая часть специализации Coursera реализована через Qwiklabs - на каждую "лабу" дают в раза два-три раза больше времени, чем нужно для ее выполнения и в оставшееся время можно поиграться с GCP (есть ограничение по ресурсам).

Однозначно нужно прочесть Site Reliability Engineering - How Google Runs Production Systems и полистать официальную документацию. Стоит посмотреть сайт gcp.solutions и особенно разделы пересекающиеся с case studies.

Обновление BIOS до версии A22 на Dell Latitude E6430

Ноутбук жены изредка чудит. Включается, затем несколько секунд показывает логотип Dell и выключается. После повторного включения все проходит нормально. Если поторопиться, то успеваю зайти в настройки BIOS перед выключением. При таком поведении в логе BIOS появляется запись "Power Off - AFS2 force off". В процессе работы проблем не бывает.

Вчера снова наткнулся на выключение ноутбука и полез на сайт Dell проверить появилась ли новая версия BIOS. Оказывается ее выложили еще в конце апреля:

• Updated Intel ME Firmware to address security advisories INTEL-SA-00086 (CVE-2017-5711 & CVE-2017-5712) & INTEL-SA-00101(CVE-2017-13077, CVE-2017-13078 & CVE-2017-13080)
• Updated to the latest CPU microcode to address CVE-2017-5715 and associated Intel Reboot issue.

Добавил эту версию в образ диска с FreeDOS и залил в ноутбук (сейчас в образе есть версии A16, A17, A18, A20, A21 и A22). Заодно сбросил настройки на дефолтные.

Посмотрю как оно дальше будет.

Jenkins slave стал запускаться дольше 5 минут на Raspberry PI 3

После обновления плагинов в Jenkins перестал запускаться агент на Raspberry PI 3. Попробовал увеличить таймаут до 5 минут, но это не помогло

[09/22/18 19:23:36] [SSH] Checking java version of java
[09/22/18 19:23:37] [SSH] java -version returned 1.8.0_40-internal.
[09/22/18 19:23:37] [SSH] Starting sftp client.
[09/22/18 19:23:37] [SSH] Copying latest remoting.jar...
[09/22/18 19:23:37] [SSH] Copied 776,265 bytes.
Expanded the channel window size to 4MB
[09/22/18 19:23:37] [SSH] Starting agent process: cd "/home/jenkins" && java  -jar remoting.jar -workDir /home/jenkins
Sep 22, 2018 7:23:53 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /home/jenkins/remoting
ERROR: null
java.util.concurrent.CancellationException
 at java.util.concurrent.FutureTask.report(FutureTask.java:121)
 at java.util.concurrent.FutureTask.get(FutureTask.java:192)
 at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:904)
 at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:294)
 at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
 at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
[09/22/18 19:28:36] Launch failed - cleaning up connection
Slave JVM has not reported exit code. Is it still running?
[09/22/18 19:28:36] [SSH] Connection closed.

Зашел по SSH и прицепился к процессу java через strace

$ sudo strace -fF -p 10245
...
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 501190012}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 501776999}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 502077571}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 502381685}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 502568039}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 552568039}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553154922}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553459713}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553807785}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553995337}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 603995337}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 604585865}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 604886125}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 605186854}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 605490238}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 655490238}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656076704}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656386131}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656688214}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656992067}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 706992067}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 707577075}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 707885199}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 708183740}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 708487542}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 758487542}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759065257}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759258903}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759556402}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759863277}) = 0

Похоже идет ожидание какого-то события, но чего именно мне не понятно. При этом полностью нагружено одно из ядер.

Попробовал запустить агент из консоли, чтобы посмотреть сколько на самом деле занимает его запуск

$ cat | java -jar agent.jar -workDir /tmp/jenkins 
Sep 22, 2018 7:55:55 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /tmp/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /tmp/jenkins/remoting
<===[JENKINS REMOTING CAPACITY]===>

Примерно через 15 минут появился маркер готовности от агента. Это слишком много, т.к. раньше агент запускался за минуту-две максимум. Пока выставил таймаут на 30 минут и агент подключился

[09/22/18 20:31:45] [SSH] Checking java version of java
[09/22/18 20:31:45] [SSH] java -version returned 1.8.0_40-internal.
[09/22/18 20:31:45] [SSH] Starting sftp client.
[09/22/18 20:31:45] [SSH] Copying latest remoting.jar...
[09/22/18 20:31:45] [SSH] Copied 776,265 bytes.
Expanded the channel window size to 4MB
[09/22/18 20:31:45] [SSH] Starting agent process: cd "/home/jenkins" && java  -jar remoting.jar -workDir /home/jenkins
Sep 22, 2018 8:32:01 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /home/jenkins/remoting
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout
Agent successfully connected and online

Сделать файл выполняемым в Git

По-умолчанию Git не сохраняет права доступа на файлы, но есть возможность сделать отдельный файл исполняемым

$ git add script.sh

$ git ls-files --stage script.sh
100644 9f3f770bfcccad3d62d2e2d08b077469ef3722fa 0       script.sh

$ git update-index --chmod=+x script.sh

$ git ls-files --stage script.sh
100755 9f3f770bfcccad3d62d2e2d08b077469ef3722fa 0       script.sh

$ git commit -m 'Executable script'
[master (root-commit) 1cf26b3] Executable script
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100755 script.sh