$ ldd /usr/local/bin/binup
        linux-vdso.so.1 (0x00007ffc269ce000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x0000778f07092000)
        libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x0000778f06762000)
        libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x0000778f06400000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000778f06732000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000778f0672a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000778f06312000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000778f06722000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000778f06000000)
        /lib64/ld-linux-x86-64.so.2 (0x0000778f070da000)

У меня были мысли делать статическую сборку, но пока решил обойтись без этого:

liblzma вроде должен быть на любой системе. К примеру, та же Ubuntu мне не даёт его удалить, т. к. на него завязано слишком много всего.
libssl – да, вы правы – та версия, с которой слинкован мой бинарник, довольно старая (релиз специально собирался на старом LTS, чтобы не было проблем с glibc на новых дистрибутивах), и на моём сервере эта версия установлена как зависимость пакетов, которые не установлены из коробки: The following packages will be REMOVED: libdns1104 libisc1100 libpython3.7 libpython3.7-minimal libpython3.7-stdlib libssl1.1 mongo-tools mongodb mongodb-clients mongodb-server mongodb-server-core. Тут я не прав.
Все остальные зависимости довольно стандартные – с ними проблем вроде бы быть не должно (или я ошибаюсь?) – релиз специально собирается на относительно древней 20.04, а у glibc, насколько я знаю, в этом месте с совместимостью всё хорошо.

В общем, решил, что в первом релизе можно пока с этим не мудрить. Но спасибо, замечание валидное – посмотрю, как тут лучше сделать. То, что оно у вас из коробки не запустилось – действительно нехорошо, это надо исправлять.

KonishchevDmitry Aug 8 at 21:57

Поправил. Теперь вот так:

$ ldd /usr/local/bin/binup
        linux-vdso.so.1 (0x00007ffc0ea76000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x000077e82861a000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000077e8285ea000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000077e8285e2000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000077e827712000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000077e8285da000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000077e827400000)
        /lib64/ld-linux-x86-64.so.2 (0x000077e828662000)

На выходных напишу тесты на это дело и попробую разобраться с liblzma + подумаю – может всё-таки перейду на musl и буду линковаться с ним – тогда будет вообще 100% статика. Но я к нему отношусь несколько настороженно – поэтому изначально и не стал идти в сторону статической линковки.

OleSv Aug 8 at 09:49

Посмотрите на eget https://github.com/zyedidia/eget

KonishchevDmitry Aug 8 at 09:57

Спасибо, но, судя по README, он, как минимум, не поддерживает post-install-скрипты. Для меня это прямо важно – начиная с того, чтобы рестартануть обновлённый сервис и заканчивая чем-то более сложным вроде:

set -eu

prometheus-node-exporter --help > /etc/prometheus/help.dump
systemctl restart prometheus-node-exporter

curl -s http://localhost:9100/metrics | \
  sed -r '/^#/ d; s/^([a-z_]+)(.*)/\1/' | \
  sort -u > /etc/prometheus/metrics.dump

cd /etc/prometheus && git diff help.dump metrics.dump >&2

– к примеру, вот такой post-install скрипт у меня настроен для Prometheus Node Exporter, чтобы отслеживать, какие новые интересные метрики появились в новом релизе.

Ну и ещё всякие мелочи – к примеру, binup при обновлении выводит ссылку на changelog – мелочь, но очень удобно. :)

Revertis Aug 8 at 11:42

В код пока не смотрел, но как вы подменяете бинарник без остановки сервиса?

selivanov_pavel Aug 8 at 12:56

В Linux имя файла - это просто название для конкретного inode в каталоге. Можно его менять или удалять, даже если из файла запущен процесс.

Revertis Aug 8 at 12:58

У меня как будто не всегда это получается, поэтому и спрашиваю :-/

selivanov_pavel Aug 8 at 13:11

cp `which htop` .

./htop

rm ./htop # другая консоль

всё работает

KonishchevDmitry Aug 8 at 13:12

Вы видимо пытались открыть именно этот файл и поправить – так да, нельзя. Но так никто никогда и не делает – вдруг вы по какой-то причине не допишете его до конца и тогда только всё запорете. Поэтому всегда в этой же директории создаётся новый файл с другим именем, туда пишутся данные + делается fsync(), чтобы они гарантированно записались на диск, а затем уже делается rename() – и новый файл атомарно заменяет старый.

Если погуглите, то даже сможете найти интересный хак, как можно восстановить удалённый файл через /proc, если есть хотя бы один процесс, у которого он ещё открыт. ;)

13werwolf13 Aug 8 at 14:20

простите но установку софта (а так же различного рантайма/библиотек/зависимостей/etc) в систему в обход штатного пакетного менеджера иначе как замусориванием и вредными советами я назвать не могу.

гораздо правильнее и полезнее потратить 5 секунд времени и помочь мейнтейнерам своего дистрибутива опакетить недостающее ПО, тем более что в случае go и rust это делается проще простого (пример spec для rpm проекта на rust) и даже не потребует тащить себе в систему ничего что требуется для сборки, это можно сделать вообще с телефона в браузере.

zorn-v100500 Aug 9 at 00:46

гораздо правильнее и полезнее потратить 5 секунд времени и помочь мейнтейнерам своего дистрибутива опакетить недостающее ПО

Удачи с дебианом за 5 секунд сделать )

А установку пакетов в обход стандартных репозиториев я считаю еще большим злом (как минимум нужен рут, а в пакет можно запихать скриптов на что фантазии хватит). И тем более добавление каких то левых реп в систему.

eyeDM Aug 9 at 12:50

Удачи с дебианом

Для таких случаев есть Docker и аналоги

zorn-v100500 Aug 11 at 05:56

Зачем мне докер например для этого https://github.com/symfony-cli/symfony-cli ?

Закинул в ~/.local/bin и не паришься.

composer там же у меня живет (он сам может обновляться через self-upgrade), хоть и есть в стандартных репах.

В /usr/local/bin - да, замусоривание системы. А в хоме - это другое )

PS. docker у меня кстати тоже rootless и какает в ~/.local/share/docker