Technologique
663 subscribers
144 photos
3 videos
42 files
949 links
Deeply involved developers about various aspects, tendencies & conceptions of programming technologies, FLOSS, Linux, security, cloud infrastructures & DevOps practices, distributed systems, data warehousing & analysis, DL/ML, web3, etc.
Author: @andrcmdr
Download Telegram
Technologique
https://www.youtube.com/watch?v=QZ05o0RPwUQ
Конец проектов Unity, Mir, Ubuntu Phone (Ubuntu Personal) и конвергенции интерфейсов оболочек для десктопных и мобильных платформ (Unity 8, Convergence) - Canonical сфокусируется на дистрибутивах для облачных платформ (Ubuntu Cloud Core), встроенных систем и IoT (Snappy Ubuntu Core).

С версии Ubuntu 18.04 LTS дистрибутив будет переведён на использование окружения GNOME и оконного сервера Wayland.

https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/

Одна из ошибок Canonical - ограниченная доступность Unity и Mir только для дистрибутива Ubuntu. То же самое происходит с Pantheon в Elementary. Разработчики дистрибутива Mint, в свою очередь, поступили очень правильно, сделав Cinnamon доступным для многих дистрибутивов и открытым для разработки.

Печально, но закономерно - мобильный рынок проприетарен и закрыт (благодаря Google и Mobile Handset Alliance), закрытость драйверов для SoC мешала продвижению открытых дистрибутивов Linux для мобильных платформ, в свою очередь рынок Cloud платформ показывает непрерывный рост уже в течение нескольких лет, а рынок IoT очень бурно растёт последние полгода-год и Canonical с дистрибутивом Ubuntu имеет на этом рынке очень сильные позиции не только благодаря самим дистрибутивам, но и благодаря успешным продуктам - MAAS, Juju, Snappy/Snap/Snapcraft.io, LXC/LXD, BootStack.

https://t.me/technologique/711

#linux
#ubuntu
#breakingnews
#sadnews
Technologique
OOMd - user space daemon for killing processes by out of memory exception raises. И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов…
Daemonization for JVM

Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.

То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.

На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.

На нативно статически компилируемых языках такие приложения писать возможно и более того - это единственный правильный корректный способ написания и реализации таких резидентных приложений.

В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).

Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.

Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.

Благо по системам инициализации есть прекрасная документация.

http://upstart.ubuntu.com/cookbook/#stanzas-by-category

http://upstart.ubuntu.com/cookbook/#initctl-commands-summary

http://upstart.ubuntu.com/cookbook/#expect

http://upstart.ubuntu.com/cookbook/#run-a-java-application

http://upstart.ubuntu.com/cookbook/#alternative-method

https://wiki.ubuntu.com/Upstart

https://www.freedesktop.org/software/systemd/man/systemd.exec.html

И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference

#Linux
#Ubuntu
#Upstart
#systemd