Спустя год после выпуска 11.2 и 7 месяцев с момента релиза 12.0 доступен (https://www.freebsd.org/releases/11.3R/announce.html) релиз FreeBSD 11.3, который подготовлен (ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.3/) для архитектур amd64, i386, powerpc, powerpc64, sparc64, aarch64 и armv6 (BEAGLEBONE, CUBIEBOARD, CUBIEBOARD2, CUBOX-HUMMINGBOARD, Raspberry Pi B, Raspberry Pi 2, PANDABOARD, WANDBOARD). Дополнительно подготовлены образы для систем виртуализации (QCOW2, VHD, VMDK, raw) и облачных окружений Amazon EC2.
Поддержка выпуска 11.2 будет прекращена (https://www.freebsd.org/security/) через 3 месяца, а поддержка FreeBSD 11.3 будет производиться до 30 сентября 2021 года или в случае решения сформировать в следующем году релиз 11.4, три месяца с момента его выпуска. Релиз FreeBSD 12.1 ожидается (https://www.freebsd.org/releases/12.1R/schedule.html) 4 ноября.
Ключевые новшества (https://www.freebsd.org/releases/11.3R/relnotes.html):
- Компоненты Clang, libc++, compiler-rt, LLDB, LLD и LLVM обновлены до версии 8.0 (https://www.opennet.dev/opennews/art.shtml?num=50360);
- В ZFS добавлена (https://svnweb.freebsd.org/base?view=revision&revision=346690) поддержка параллельного монтирования сразу нескольких разделов ФС;
- В загрузчике реализована (https://svnweb.freebsd.org/base?view=revision&revision=344399) возможность шифрования разделов при помощи geli на всех поддерживаемых архитектурах.
- В loader добавлена функциональность загрузчика zfsloader, который для загрузки с ZFS теперь не требуется;
- В загрузчике для UEFI улучшено определение типа системной консоли и устройства консоли, если они не определены в loader.conf;
- В базовую поставку добавлен вариант загрузчика, написанный на языке Lua;- В ядре обеспечен вывод в лог идентификатора jail-окружения при отслеживании завершения процессов;
- Включён вывод предупреждений о возможностях, поддержка которых будет прекращена в будущих выпусках. Также добавлено предупреждение при использовании небезопасных алгоритмов geli и алгоритмов IPSec, которые объявлены устаревшими в RFC 8221;- В пакетном фильтре ipfw добавлены новые параметры: record-state (как "keep-state", но без генерации O_PROBE_STATE), set-limit (как "limit", но без генерации O_PROBE_STATE) и defer-action (вместо запуска правила, создаётся динамическое состояние, которое можно проверить при помощи выражения "check-state");
- Добавлена поддержка NAT64 CLAT (https://svnweb.freebsd.org/base?view=revision&revision=346212) с реализацией работающего на стороне потребителя транслятора, преобразующего 1 к 1 внутренние IPv4 адреса в глобальные адреса IPv6 и наоборот;
- В библиотеке pthread(3) проведена работа по улучшению совместимости с POSIX;
- В /etc/rc.initdiskless добавлена поддержка дополнительной памяти NVRAM. В утилиту rcorder добавлена поддержка /etc/rc.resume. Определение переменной jail_conf (по умолчанию содержит /etc/jail.conf) перенесено в /etc/defaults/rc.conf. В rc.subr добавлена переменная rc_service, определяющая путь к сервису, который будет запущен в случае если сервису необходимо повторно вызвать себя;- В jail.conf для утилиты jail добавлен новый параметр allow.read_msgbuf, при помощи которого можно ограничить доступ к dmesg для изолированных процессов и пользователей;
- В утилиту jail добавлена опция "-e", позволяющая указать в качестве аргумента любой параметр jail.conf и отобразить список окружений, в которых он используется;
- Добавлена утилита trim, позволяющая инициировать удаление содержимого блоков на Flash, использующих алгоритмов нормализации износа;
- В gzip добавлен флаг "-l" для поддержки формата xz;
- В newfs и tunefs разрешено использование символов подчёркивания и тире в именах меток;- В утилите fdisk добавлена поддержка секторов, превышающих 2048 байт;
- В оболочку sh добавлена поддержка опции pipefail, упрощающей проверку кода возврата для всех команд, объединённых неименованными каналами;
- Добавлена утилита spi, позволяющая взаимодействовать с устройствами через шину SPI из пространства пользователя;
- В kenv добавлена переменная init_exec, при помощи которой можно определить исполняемый файл, который будет запущен процессом init после открытия консоли в качестве обработчика PID 1;
- В утилиты e cpuset(1), sockstat(1), ipfw(8) и ugidfw(8) добавлена поддержка символьных имён для идентификации окружений jail;
- В утилиту dd добавлены опции status и progress для вывода информации о состоянии каждую секунду;
- В утилитах last и lastlogin добавлена поддержка libxo;
- Обновлены прошивки и версии сетевых драйверов;
- Пакетный менеджер pkg обновлён до выпуска 1.10.5, OpenSSL до выпуска 1.0.2s, а инструментарий для исполняемых файлов ELF до выпуска r3614;
- В портах предложены окружения рабочего стола KDE 5.15.3 и GNOME 3.28;URL: https://www.freebsd.org/releases/11.3R/announce.html
Новость: https://www.opennet.dev/opennews/art.shtml?num=51064
У вас ошибка в новости:"armv6 (BEAGLEBONE, CUBIEBOARD, CUBIEBOARD2, CUBOX-HUMMINGBOARD,
Raspberry Pi B, Raspberry Pi 2, PANDABOARD, WANDBOARD)"Большинство этих SBC на архитектуре armv7
Но сборки для них на основе ARMv6:armv6 BANANAPI:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-BANANAPI.img.xz) =armv6 BEAGLEBONE:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-BEAGLEBONE.img.xz) =
armv6 CUBIEBOARD:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-CUBIEBOARD.img.xz) =
armv6 CUBIEBOARD2:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-CUBIEBOARD2.img.xz) =
armv6 CUBOX-HUMMINGBOARD:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) =
armv6 RPI-B:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-RPI-B.img.xz) =
armv6 RPI2:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-RPI2.img.xz) =
armv6 PANDABOARD:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-PANDABOARD.img.xz) =
armv6 WANDBOARD:
SHA512 (FreeBSD-11.3-RELEASE-arm-armv6-WANDBOARD.img.xz) =
armv7 как отдельная архитектура во FreeBSD появилась только с 12.0.
Единственный UNIX во всем рынке OpenSource-операционок. Напоминаю что Linux не UNIX а еще напоминаю что в Linux systemd в то время как в UNIX-FreeBSD никакого systemd нет
А опенбсд и нетбсд?:) Но Вы это... держите в курсе.
dragonflybsd - самые легкие процессы и виртуальные ядра и Hammer итд
ага, всё до того лёгкое, что системе нужно минимум 8 гб для более менее сносной и отзывчивой работы. та жа фряшка спокойно отрабатывает как надо на системах даже с 1 гб озу.
...и даже на системах с 512M:
$ uname -srm
FreeBSD 11.2-RELEASE-p11 amd64
$ sysctl hw.physmem
hw.physmem: 523866112
$ fetch -qo- http://169.254.169.254/latest/meta-data/instance-type
t2.nano
Откуда дровишки? Ставил на ноут с 2Гб оперативки. При старте с i3wm кушало не более 150МБ ОЗУ. При работе в качестве десктопа также не ощутил никаких тормозов.
Не звезди. Я ее на древний Asus EEE PC ставил, с атомом вместо проца и 2ГБ памяти. Все работает.
Удобная вещь, эта системд. И проследит за пидом процесса, и перезапустит при падении. И конфиги простые как двери, не надо велосипедить баш-портянки. Эх! Дай мне ещё этого НЕюникса....Кстати, а почему InspurOS для китайских суперкомпьютеров от Inspur, таки является юниксом, ибо они прошли SUS-сертификацию, и таки на линуксе, ибо пересборка шляпы/чентоси?
>И конфиги простые как двери----------------------------
#!/bin/sh
#
# $FreeBSD: head/mail/exim/files/exim.in 340872 2014-01-24 00:14:07Z mat $
## PROVIDE: mail
# REQUIRE: LOGIN
# KEYWORD: shutdown
# we make mail start late, so that things like .forward's are not
# processed until the system is fully operational#
# Add the following lines to /etc/rc.conf to enable exim:
#
#exim_enable="YES"
#
# See exim(8) for flags
#. /etc/rc.subr
name=exim
rcvar=exim_enablecommand=/usr/local/sbin/exim
pidfile=/var/run/exim.pid
required_dirs=/var/log/exim
required_files=/usr/local/etc/exim/exim.conf#start_precmd=start_precmd
stop_postcmd=stop_postcmdextra_commands="reload"
stop_postcmd()
{
rm -f $pidfile
}# read settings, set default values
load_rc_config $name
: ${exim_enable="NO"}
: ${exim_flags="-bd -q30m"}run_rc_command "$1"
---------
Что сложного?Но проблема в том, что тебя лишили выбора, поэтому остается лишь петь песню как все хорошо.
А ваше навязывание баш-портянок и init, как единственной системы инициализации, не подпадает под ограничение свободы выбора?
>init, как единственной системы инициализации$ man init
DESCRIPTION
The init utility is the last stage of the boot process.init вообще ни разу не "система инициализации" чего-то.
в BSD это простой процесс-демон, запускающий /etc/rc и getty
вы вообще чего "инициализировать" собрались?
> А ваше навязывание баш-портянок
> #!/bin/shЭто не симлинк на баш, как привыкли линухоиды. Я знаю, в это сложно поверить, но баш там вообще нет в базовой установке!
/bin/sh - это действительно минимальный интерпретатор sh, без тонн интерактивных свистелок и перделок:
cloc /usr/src/bin/sh/ --exclude-dir=tests
68 text files.
68 unique files.
9 files ignored.
Language files blank comment codeC 26 1576 2233 11803
C/C++ Header 24 139 916 563
make 1 17 7 48SUM: 60 1774 3442 12755
А теперь смотрим баш:
https://www.openhub.net/p/bash/analyses/latest/languages_sum...
> Total Lines : 292,087 Code Lines : 224,357системд:
https://www.openhub.net/p/systemd/analyses/latest/languages_...
> Total Lines : 634,513 Code Lines : 469,586Вот да, если выбирать только между bash и системд в качестве интерпретатора конфигов, то специализированный системд смотрится очень даже ничего. Но все же это какой-то странный выбор, в лучших традициях
> Опустим эту газету в серную кислоту, а ТВ-парк в дистиллированую воду(c)
В нормальных системах используют http://gondor.apana.org.au/~herbert/dash/
Но таки да, Systemd и тут впилили.
> В нормальных системах используют http://gondor.apana.org.au/~herbert/dash/
> Но таки да, Systemd и тут впилили.Где впилили? В dash или в девуан? Не вижу его ни там, ни там.
В Debian, откуда он и перекочевал в Devuan.
Но это было до systemd, впрочем dash в Debian никуда и после того не делся. И даже вполне себе используется.
Никого не лишили, обратную совместимость с портянками не выпилили, если хочется вот так, по старинке.Хотя с юнитом все тоже наглядно, более чем:
[Unit]
Description=Exim Mail Transport Agent
After=network.target
Conflicts=sendmail.service postfix.service[Service]
PrivateTmp=true
Environment=QUEUE=1h
EnvironmentFile=-/etc/sysconfig/exim
ExecStartPre=-/usr/libexec/exim-gen-cert
ExecStart=/usr/sbin/exim -bd -q${QUEUE}[Install]
WantedBy=multi-user.target
>Хотя с юнитом все тоже наглядно, более чемУгу. До тех пор пока отлаживать не надо. И вся хрень systemd в корку не падает, не пойми где.
Ну ты хоть пробовал, серьезно?Отладка юнита с подробным логированием в journalctl, как stderr вызываемых комманд, так и самого механизма systemctl, который тоже подскажет что сделано не так.
Ну вот прям наоборот же все.
> Ну ты хоть пробовал, серьезно?Чувак, не поверишь, пишу всякие программы. Портируемые.
>Отладка юнита с подробным логированием в journalctl, как stderr вызываемых комманд...
Пусть оно идет в ту дырку, куда не светит солнце.
Вся эта развесистая байда systemd с линками и опциями.
Так тебя ж не заставляют ей пользоваться, раз не по душе.Штуки разные, подходы тоже.
Обе имеют право на жизнь.
Я вот программы не пишу, только сопровождаю их работу на серверах. Скрипты автоматизации - да, в том числе разумеется и на баше, много лет люблю баш.Ну а живётся гораздо спокойней и веселей когда постепенно перевел все сервера на rhel7 и системд.
В моем конкретном случае все так, в твоём может быть по другому.
Но я в свою очередь не заявлял, что альтернативы системд все поголовно гуано, да и знать мне их тоже по роду службы необходимо)
>Скрипты автоматизации - да, в том числе разумеется и на баше"Скрипты автоматизации на баше"
Закопать. Вместе со "скриптами автоматизации" и "башем".
За что ты так скрипты на баше?То что в C:/Windows/system32 лазать не умеют и какой-нибудь regsrv не вызовут?
>За что ты так скрипты на баше?Я так ласково "автоматизаторов на баше".
> Никого не лишили, обратную совместимость с портянками не выпилили, если хочется вот так, по старинке.так оно так и сделано практически во всех дистрах, кроме арча.
юниты, фигуниты - а легаси баш-портянки стартуемы системдой!
супер.
Ну это на фрюхе всё просто, я когда в первый раз увидел, как регулируется порядок запуска и остановки служб в линуксе, слегка ошалел от пиршества идиотизма человека, который это придумал.
> pidfile=/var/run/exim.pidКапец, пид файлы... А если с ним что-то не так? Как процесс останавливать будешь, чудо ты из семидесятых годов :)
С тобой что-то не так, к сожалению.
Смузи головного мозга и барбершоп подбородка мешает пользоваться тектовыми файлами, сочувствую.
Т.е. ответить "как остановить процесс" ты не модешь? ОК :-)
вот и выросло поколение "девопсов" которые ничего про ps(1) не слыхивали... ;(
> вот и выросло поколение "девопсов" которые ничего про ps(1) не слыхивали... ;(Слепцы!
> вот и выросло поколение "девопсов" которые ничего про ps(1) не слыхивали... ;(Дэбил, тебе ps вернёт не только твой процесс, но ещё с десяток процессов с таким же именем из контейнеров.
начнем с того, что дэбил это, прежде всего, тот, кто вовремя не достал, породив девопсика (тупого, кстати) под ником Dapredator.
продолжим тем, что смысла примерно 0 продолжать, ибо идиот даже manpage не открывал, видимо, не обучают этому в ютубе/хабрахабаре/стековерфлоу. или где там нонешние девопсики обучаются.
> что смысла примерно 0 продолжатьКаждый раз, когда кто-то сливается так и не осилив ответить, так как же он однозначно может вычислить pid конкретного процесса, не убив при этом десяток точно таких же процессов в контейнерах, я удивляюсь. Зачем вы пишите столько много слов?
Можно же просто написать: "да, оказывается я не знаю как однозначно вычислить pid одного конкретного процесса, сливаюсь" :-) Тут ничего страшного нет.
Подумаешь, ну бывает, за неимением опыта обгадился и оказалось, что всю жизнь не знал, что не так-то это и просто, вычислить правильный pid. Надо достойно уметь признаться в этом, что тут такого? :-)
ладно, для тебя сделаю исключение и [немного] задам направление мышления, если есть чем, конечно. Нет уверенности в том, что делаю это не зря, но все же.
у тебя тот же "демон" (ты ngx там где-то выше/ниже упоминал) имеет "родителя".
Смузехлеб способен из нескольких найти нужный, если "pid файл удалили или испортили"?
Ну же, верни мне веру в миллениалов.
> пособен из нескольких найти нужный, если "pid файл удалили или испортили"?Ага, ага. И сразу, чтобы подтвердить, что ты не п***абол, пример того, как это реализовано в любом существующем пакете любого Linux дистрибутива из top50 с distrowatch? Или так никто не делает и ты чисто покукаретизировать вышел?
P.S. :-)
>> пособен из нескольких найти нужный, если "pid файл удалили или испортили"?
> Ага, ага. И сразу, чтобы подтвердить, что ты не п***абол, пример того,
> как это реализовано в любом существующем пакете любого Linux дистрибутива из
> top50 с distrowatch? Или так никто не делает и ты чисто
> покукаретизировать вышел?какой пакет, какой топ50, какой линакс?
у тебя был глупейший, с т.з. человека разумного вопрос - как найти (убить шоб?) процесс, если пид кто-то попортил, тебе ответили, что есть цельная утилита - ps называется.что за наркоманию ты сейчас пропагандировать начал? у меня тут рядом сидит адепт системг, дык он как-то поадекватнее многократно.
ниже ты там не себя часом имел ввиду рассказывая за "десятки тысяч контейнеров" и величая кого-то админом локалхоста ?
а то как-бы тебе это сказать... проблемы _СИЛЬНО_ серьезнее чем ты тут пытаешься "решить" возникают у людей, которые и правда работают уже при подходе к первому десятку.> P.S. :-)
да, спасибо, ты сделал мой день
> цельная утилита - ps называется.Да да, только вот никто пока так и не рассказал, как же определить pid нужного nginx, а не того, который в одном из пяти контейнеров на том же хосте :-)
>> цельная утилита - ps называется.
> Да да, только вот никто пока так и не рассказал, как же
> определить pid нужного nginx, а не того, который в одном из
> пяти контейнеров на том же хосте :-)У взрослых спросить. Мариванна-восптательница или бородатый одмин подотрут твои сопли, как обычно. Громче кричи "уа!"
Давай чтобы голословным не быть, вот тебе реальный ps с реального сервера.root@XXX:~# ps ax | grep sssd_pam
15620 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
16829 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
28421 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
28499 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
28947 ? S 0:03 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
Дано: Есть hypervisor с 4 контенерами. И на гипервизоре и в контейнерах крутиться sssd демон, который авторизует юзеров из LDAP. Какой из вышеперечисленных процессов работает на гипервизоре, а какой в контейнерах? :-)Задача: написать init скрипт, который рестартанёт нужный sssd_pam
>И на гипервизоре и в контейнерах крутиться sssd демонЧувак, это тема про FreeBSD. В ней нет контейнеров.
А для отличить процессы в jails есть JID
# ps -ax -J1 | grep /sshd
27061 - IsJ 0:00.01 /usr/sbin/sshd# ps -ax -J0 | grep /sshd
80237 - Is 0:05.58 /usr/sbin/sshd
Да, контейнеры для Linux местами через одно место. С чем и поздравляю.
> Есть hypervisor с 4 контенерами. И на гипервизоре и в контейнерах крутиться sssd демон, который авторизует юзеров из LDAP. Какой из вышеперечисленных процессов работает на гипервизоре, а какой в контейнерах? :-)Ты не очень умный, поэтому я тебе ещё раз расскажу.
1) В цикле перебираешь пиды
в теле цикла:
2.а) делаешь grep -q $needed_cgroup /proc/$PID/cgroup && kill $PID
2.б) делаешь ps -h -o pidns -p $PID | grep -q $needed_ns && kill $PID(в зависимости от, вместо pidns могут быть другие неймспейсы)
Знания о том, в какой cgroup'е или неймспейсе ты запускаешь должно сохранять то, что запускает контейнеры.
Это так просто! Но ты продолжай утверждать, что без systemd жизни нет, ага.
Уровень своих знаний ты уже показал, когда предъявил юнит "для запуска openvpn", который на самом деле запускает /bin/true.
> 1) В цикле перебираешь пиды
> в теле цикла:
> 2.а) делаешь grep -q $needed_cgroup /proc/$PID/cgroup && kill $PID
> 2.б) делаешь ps -h -o pidns -p $PID | grep -q $needed_ns
> && kill $PID
> (в зависимости от, вместо pidns могут быть другие неймспейсы)ты сейчас вот рассказал ему о наличию у ps ключей отличных от 'ax'. зачем? веришь в него или считаешь, что эта информация будет полезной для более адекватных девопсиков?
> ты сейчас вот рассказал ему о наличию у ps ключей отличных от 'ax'. зачем? веришь в него или считаешь, что эта информация будет полезной для более адекватных девопсиков?Второе.
Тебе - вернет, а мне не вернет, т.к. я под нормальной ОС сижу.
Это потому, что ты школьник-админ локалхоста. А люди иногда работают, иногда поддерживают железо, на котором крутятся десятки тысяч контейнеров на ОС, на которой работает 99% интернета.Такое бывает, прикинь :-)
На нетфликс где-то процентов 30 всего трафика США приходится. Подозреваю, что обеспечить всех своих клиентов такими объемами информации, да чтоб еще не тормозило - это задача на порядок или на два более сложная, чем те, что решаешь ты в том месте, где тебя еще по недоразумению держат.Ключевой вопрос здесь - как они, бедняги, в netflix демонов-то своих останавливают без systemd ?
Сравни зарплаты девопсов и аникеев, и тогда поймёшь почему "поколение вырасло". И посмотри какую работу они выполняют, тогда поймёшь за что им платят эту зарплату.
> Сравни зарплаты девопсов и аникеев, и тогда поймёшь почему "поколение вырасло". И
> посмотри какую работу они выполняют, тогда поймёшь за что им платят
> эту зарплату.у нас, видимо, разные понятия о "эникей" и "девопс".
девопсы, которые вокруг меня, по умениям близки к олдскульным админам (тем, которые и СУБД подтюнить могли (щас это громким именем dba называется), тем, которые обслуживали пачки машин без ансибла/шефа/паппета/тд еще до появления оных - "портянками" на шелл либо вообще на мейкфайлах, тем, которые запускали top и уже понимали в какую сторону нужно смотреть пристальнее при "сервер тормозит"). получают они, соответственно, хорошо
а типичный "девопс" из интернета (вон даже выше по треду яркий представитель имеется) способен:
* (с ошибками и за полдня) написать юнит-файл из 10 строк
* спросить/прочесть ответ на стековерфлоу или подобных (и это еще на самый плохой вариант)
* поставить-запустить htop и с умным видом фтыкать в терминал пока проблема сама не решится
* при помощи ютубчика настроить ELK и пищать на форумах какой он клевыйвместо нормальных инструментов эти индивидуумы, зачастую, предпочитают мониторить графаной, как отличительная особенность их
а весь "траблшутинг" заключается в:
1 "перезапустить контейнер" (если PID какой-нибудь поганец не затер то даже без ребута ноды :trollface: ).
2. если п.1 не помог - дать больше ресурсов
3. а) если и п.2 не помог - обучаются пользоваться ресурсами типа translate.google.com и идут на стековерфлоу.
б) идут к более сообразительному коллеге со своей печалью.эникеи же просто мальчики, которые компы-ноуты таскают по этажам, картриджи меняют, проводочки протягивают и прочее.
как по мне, так они делают сильно более полезную работу, нежели Dapredator-о подобные. И навредить своей работой способны не так сильно.
>> pidfile=/var/run/exim.pid
> Капец, пид файлы...Дышите глубоко, приготовьте огнетушитель
https://www.freedesktop.org/software/systemd/man/systemd.ser...
> PIDFile=
> Takes a path referring to the PID file of the service.
> Usage of this option is recommended for services where Type= is set to forking.
> The service manager will read the PID of the main process of the service from this file after start-up of the service.и
> If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up
> If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can reliably identify the main process of the service.
> А если с ним что-то не так? Как процесс
> останавливать будешь, чудо ты из семидесятых годов :)Что именно там "не так"? Вы же в курсе, что pid file обычно пишет сам демон?
Запись и чтение pid файла при старте вызывает состояние гонки. Например, при перезапуске демона, когда новый демон уже запущен а старый ещё не завершился.
В приведенных тобой строках описывается как использовать системду со "старыми" сервисами и отнюдь не является рекомендованным способом.
>Запись и чтение pid файла при старте вызывает состояние гонки.щас заплачу....
у разработчика с мозгами стартующий процесс пишет НОВЫЙ файл, с НОВЫМ значением process ID
Не плачь. Вот тут, например, написано о соглашении наименования pid файла. http://www.pathname.com/fhs/2.2/fhs-5.13.html>>у разработчика с мозгами стартующий процесс пишет НОВЫЙ файл, с НОВЫМ значением process ID
Видно, что наглости у тебя хоть отбавляй, а мозгов немного:) Как же ты найдешь PIDфайл и проверишь что процесс еще не запущен или уже завершен? :)
Тебе бы книжки почитать для начала.
> Видно, что наглости у тебя хоть отбавляй, а мозгов немного:) Как же
> ты найдешь PIDфайл и проверишь что процесс еще не запущен или уже завершен? :)например, чтением мана?
man pidfile
The pidfile_open() function opens (or creates) a file specified by the
path argument and locks it. If pidptr argument is not NULL and file can
not be locked, the function will use it to store a PID of an already
running daemon or -1 in case daemon did not write its PID yet
так же можно почитать man flock.
>Как же ты найдешь PIDфайл и проверишь что процесс еще не запущен или уже завершенПонимаешь, дружище, есть такие штуки как системные вызовы....
> новый демон уже запущен а старый ещё не завершилсяЕсли у тебя так перезапускаются демоны, то мусор в PID-файле - далеко не самая острая проблема. Неотвязанные порты и незакрытые файлы подарят тебе намного больше веселья. Но если ты так перезапускаешь демоны, то так тебе и надо.
systemd схлопывпет все процессы в cgroup'е. Каждый процесс при старте получает свою cgroup.А как ты будешь останавливать процесс когда криворукий init-script-писатель случайно грохнул твой pid файл или, ещё хуже, записал туда pid другого процесса? :-).
killall processname, lol? И привет всем процессам в контейнерах типа docker или LXC? :-)
Я тебя внимательно слушаю.
> Я тебя внимательно слушаю.слушай и запоминай, дитя 201x: точно так же я его буду останавливать, как если бы твой криворукий на-единственно-верной-сишечке-писатель "не схлопнул все процессы в cgroup'е", а вывел какой-то мусор в бинарный лог и повис. Как-нибудь, не поверишь, справлюсь.
Причем вот подобные вещи - в его продухте происходят регулярно, и исправить это - невозможно, если тебя не зовут Лёня (а Лёня исправит методом notabug). А скриптов зачем-то грохающих pid-файлы я лично не видел никогда. При том что юниксы (а не этот ваш помоечный "новый шит-стандарт") я админю явно больше лет, чем тебе исполнилось. А если и увижу (продукт таких как ты, которых менеджер заставил таки сделать не линукс-онли сетап) - исправлю без всяких проблем (скорее с нуля напишу).
> Как-нибудь, не поверишь, справлюсь.Не верю. Поверю только когда расскажешь или покажешь кусок кода, как ты будешь останавливать процесс, когда pid файла нет или там мусор.
> вывел какой-то мусор в бинарный логЛет 6 как не интересует, что там на локальной машине в логах, все логи пишутся на удалённый сервер. Раньше был форвардинг в удалённый syslog, сейчас это ELK. Но я слышал, что systemd (специально для дегенератов) оставил совместимость не только с init скриптами, но и с возможностью писать текст.
> А скриптов зачем-то грохающих pid-файлы я лично не видел никогдаЭто говрит о том и только о том, что ничего кроме локалхоста или виртуалки на хетцнере ты в жизни не видел. Я не стал бы на твоём месте этим сильно хвастаться.
А вот в моей практике сплошь и рядом случались ситуации, когда
if [ -f /path/to/file ] ; then
###### <--- вот тут был промежуток в минуты и "file" успевал либо многократно поменяться,
###### либо вообще исчезнуть
do somethingfi
Так что мамкин скриптописатель, как ты будешь останавливать процесс, когда у тебя либо исчез pid файл, либо там мусор? У тебя с темы спрыгнуть не получится, я за этим чётко слежу.
> Не верю. Поверю только когда расскажешь или покажешь кусок кода, как ты будешь останавливать
> процесс, когда pid файла нет или там мусор.как только я услышу от тебя внятное объяснение, как ты будешь останавливать процесс, когда в прекрасном коде на прекрасной сишечке в потрохах системды - мусор вместо его pid.
И не пытайся спрыгнуть с темы - ты выдал совершенно бредовую идею, что пид из файла волшебным образом исчез. Вот и объясняй - почему это он не может точно так же исчезнуть (вместе с волшебными группами и миллионом других волшебных ненужно) из памяти кривого непроверябельного bloatware на волшебнейшей сишечке.
И чем эта ситуация отличается в лучшую сторону, кроме той, что тот код ты, по всей вероятности даже прочитать не сможешь.
> А вот в моей практике сплошь и рядом случались ситуации, когда
>
> if [ -f /path/to/file ] ; then
>
> ###### <--- вот тут был промежуток в минуты и "file" успевал либо многократно поменяться,ну твоя практика неумения писать скрипты всем понятна (man mkstemp, man mv, man lockf)
но причем тут практика некоего потного Лёни в писании на сях - которую ты выдаешь за волшебное спасение от твоего неумения программировать в юниксе?Я говорю - твоего, потому что ни в frebsd'шных, ни в большинстве других уцелевших юникс-систем стартовых скриптах подобного бреда не встречается, и внутри именно такого if будет только прекращение работы скрипта по причине неверного вызова.
Впрочем, тут еще и технически неверно, потому что нет проверки того, что на самом деле надо проверять - существования процесса с таким pid. Он может просто сдох и файл стереть не смог.
> И привет всем процессам в контейнерах типа docker или LXC? :-)
Чувак, во FreeBSD нет контейнеров.
>Как процесс останавливать будешь, чудо ты из семидесятых годов :)NAME
kill – send signal to a processLIBRARY
Standard C Library (libc, -lc)SYNOPSIS
#include <sys/types.h>
#include <signal.h>int
kill(pid_t pid, int sig);DESCRIPTION
The kill() system call sends the signal given by sig to pid, a process or
a group of processes.STANDARDS
The kill() system call is expected to conform to IEEE Std 1003.1-1990
(“POSIX.1”).HISTORY
A version of the kill() function appeared in Version 3 AT&T UNIX. The
signal number was added to the kill() function in Version 4 AT&T UNIX.
У тебя есть иные способы остановить процесс, чудо только родившееся прямо в смузи?Расскажи мне о pipes, sockets, командах остановки, и прочем.
И насколько это стандартно.
> И насколько это стандартно.Линукс ваш новый стандарт!
> И насколько это стандартно.Очевидно, что-то слышал, что можно.
И таки да.
Вот решили проблему в ядре 5.2.
В системный вызов clone() добавлен флаг CLONE_PIDFD, при указании которого родительскому процессу возвращается файловых дескриптор "pidfd", отождествлённый с созданным дочерним процессом. Данный файловый дескриптор, например, можно использовать для отправки сигналов без опасения столкнуться с состоянием гонки (сразу после отправки сигнала целевой PID может быть освобождён из-за завершения работы процесса и занят другим процессом);
И pidfd_send_signal
Дают возможность слать сигналы без гонок.
> Вот решили проблему в ядре 5.2.
> В системный вызов clone() добавлен флаг CLONE_PIDFD, при указании которого родительскому
> процессу возвращается файловых дескриптор "pidfd", отождествлённый с созданным дочерним
> процессом. Данный файловый дескриптор, например, можно использовать для отправки сигналов
> без опасения столкнуться с состоянием гонки
> И pidfd_send_signal
> Дают возможность слать сигналы без гонок.Молодцы! Всего на 8 лет отстали ;)
man pdfork
> Process descriptors are special file descriptors that represent
> processes, and are created using pdfork(),
> pdgetpid() queries the process ID (PID) in the process descriptor fd.
> pdkill() is functionally identical to kill(2), except that it accepts a process descriptor, fd, rather than a PID.man procdesc
NAME
procdesc – process descriptor facilityDESCRIPTION
procdesc is a file-descriptor-oriented interface to process signalling
and control, which supplements historic UNIX fork(2), kill(2), and
wait4(2) primitives with new system calls such as pdfork(2), pdkill(2),
and pdwait4(2). procdesc is designed for use with capsicum(4), replacing
process identifiers with capability-oriented references. However, it can
also be used independently of capsicum(4), displacing PIDs, which may
otherwise suffer from race conditions. Given a process descriptor, it is
possible to query its conventional PID using pdgetpid(2).SEE ALSO
fork(2), kill(2), pdfork(2), pdgetpid(2), pdkill(2), pdwait4(2),
kqueue(2), wait4(2), capsicum(4)HISTORY
procdesc first appeared in FreeBSD 9.0, and was developed at the
University of Cambridge.
Речь-то шла именно о файле.И да. Из скриптов будут гонки. Из программы на Си - нет.
Об этом же была речь?
>ибо они прошли SUS-сертификацию, и таки на линуксеFreeBSD/NetBSD сохранили концептуально архитектуру начиная с времен примерно 2BSD, это где-то 1979 год (если не путаю), чуть раньше разработки TCP/IP стека по заказу DARPA.
Linux это более позднее изделие, самосбор из всего что было.
загнул ты родословную)) :
"Разработка FreeBSD началась в 1993 году с быстрорастущего набора патчей пользователей системы 386BSD." взято с https://ru.wikipedia.org/wiki/FreeBSD.
и вообще это версия идет от университета беркли. со своими rc скриптами и тому подобным и уже во время своего появления она хоть и считалась юникс системой, но как бы не чистым юникс. чистым юникс была версия от AT&T.
>загнул ты родословную)) :Нет.
См архив.
2BSD это производная от AT&T Unix
4BSD от 2BSD
386BSD от 4.4BSDFree/Net/Open от 386BSD
это примерно и грубо, можно поднять даты
https://www.tuhs.org/Archive/Distributions/UCB/
Большинство местных писателей настолько тупо и лениво, что не в состоянии скачать и посмотреть код в архиве
PS
"Чистый Unix" это такой сферический конь в вакууме.
а я о чем. нет более юникс сегодня. есть его производные в лучшем случае. и bsd системы к ним мало отношения имеют. это как у дворняги есть 10% родословной благородной гончей))) я о том ,что люди ищут свою гордость в том ,что используют якобы благородный юникс. тогда когда то ,что они используют имеет весьма посредственное отношение к юникс. это глупое ребячество.
Истинная Unix - это Unix v7 для PDP11/70.RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
WED DEC 31 19:03:27 EST 1969login: root
Password:
You have mail.Все остальное переписанное и отношения к Unix не имеет.
Ничего удобного в комбайнере нет. Перезапуск вместо исправления ошибки? С чего вы взяли, что это нужно всем и везде? С чего вы взяли, что решение перезапуска идеально и конечно? Конфиги простые? Это слова того, кто эти конфиги не писал. И проблема не в описании параметров, а в том, что вообще не написано как именно тот или иной параметр работает. То, что описано можно как минимум трактовать по двум сценариям. В общем, без литра и чтения кода системд не разобраться.Единственный архитектурный плюс системд это зависимости запуска. Больше в нем ничего того, что можно сделать по юниксвей нет.
За перезапуском следить должен отдельный процесс, который до кучи еще и должен уметь снимать дамп с упавшего процесса и отсылать куда нужно. А, вы об этом и не думали, вам это не надо и все равно вы скажите, что вы правы. В некоторых случаях ваш бестолковый перезапуск может нанести в сотни раз больше ущерба, но вы об этом не слышали.
> Единственный архитектурный плюс системд это зависимости запуска.расскажите, пожалуйста, как в дистре с системды получить порядок старта сервисов? - т.е. интересует аналог rcorder...
> расскажите, пожалуйста, как в дистре с системды получить порядок старта сервисов? -поискать в /dev/random - весь смысл системды в том чтобы сделать этот порядок абсолютно непредсказуемым.
> т.е. интересует аналог rcorder...
эти ваши башпортянки...
С указанием wantedby/after - можешь хоть весь порядок выстроить. Один за одним.А так они стартуют параллельно после того как поднят юнит или таргет от которого зависят.
Что значит "можешь" ?
Хочется увидеть, вылить в файл [для анализа] и т.п.
Руками - не вариант: одна правка и анализ заново?
Стартуют параллельно? - Ok, вывести в одну строку стартующие параллельно.
Кури systemd-analyze.
> Удобная вещь, эта системд. И проследит за пидом процесса, и перезапустит при падении.N.B. типично для адептов системды.
это каким местом нужно писать демоны, чтобы за ними надо было присматривать?!
нормальный софт не нуждается в присмотре. пользователи кривого - должны страдать.
> это каким местом нужно писать демоны, чтобы за ними надо было присматривать?!ровно тем местом, которым они и пишут - или вы думаете, это только админы у них такие? Нет, разработчики тоже подтягиваются.
И, кстати, не называйте эту поделку "демон" - это слово может кому-то показаться оскорбительным, используйте термин "альтернативно-мертвый"(c)Id softw. - тем более что он гораздо точнее характеризует поделку, не умеющую detach control tty (каковые сцустемдрянь старательно поощряет, ведь перегружать слабенькие мозги современных разработчиков под новые стандарты этим вашим юниксом не следует).
> нормальный софт не нуждается в присмотре
выкидывайте это ваше мамонтово г-но - сегодня модно "быстроподнятое упавшим не считать".
В этом некоторое преимущество линукса, есть дистрибутивы с системдой, а есть без нее.Свобода - это и возможножность выбора тоже.
Это пока ты варишься на своем десктопе или даже сервере. А если тебе надо делать ПО, которое работает на разных дистрибутивах? У тебя уже нет выбора, ты должен лезть в это и пачкаться. А оно еще вдруг падает. И вот journald например падает и ты без логов. И ты такой сидишь и думаешь, как такое вообще могли пропустить?
Опять "делатель ПО" у которого все падает, кроме его собственного кода.У админов не падает, живём и радуемся.
https://ru.wikipedia.org/wiki/Unix-%D0%BF%D0&...
"Деннис Ритчи, один из создателей Unix, выразил своё мнение, что Unix-подобные системы, такие, как Linux, являются де-факто Unix-системами."
>Деннис Ритчи, один из создателей Unix, выразил своё мнение, что Unix-подобные системы, такие, как LinuxНу прилепили к теме офтопик. И что?
От этого файлопомойка из кучи тарболов стала менее файлопомойка?
> "Деннис Ритчи, один из создателей Unix, выразил своё мнение, что Unix-подобные системы,
> такие, как Linux, являются де-факто Unix-системами."это он очень давно выразил. Когда оно по сути так и было.
А сегодня этот ваш "новый стандарт" от unix уже очень и очень далеко. Причем как от того что было принято считать юниксом во времена Ритчи, так и от того, что принято ими считать сейчас.
Ну ок, много вы этого юникса сейчас видите?
> Единственный UNIX во всем рынке OpenSource-операционокНеужели у кого-то слово "Unix" ассоциируется с чем-то иным кроме как с "40 лет как устаревшими технологиями из 1970-тых годов, которые в своём развитии остановились в конце 80-тых"?
> Напоминаю что Linux не UNIXИ слава богу, не хватало ещё следовать заветам старых пердунов, которых уже в живых-то нет.
> напоминаю что в Linux systemd в то время как в UNIX-FreeBSD никакого systemd нет
Это примерно как "напоминаю, что в этом отеле кондиционер, микроволновка и стиральная машина, в то время как в нашем шалаше настоящий true-огонь и в луже можно простирнуться кто как умеет"
Вот как раз наоборот. Громче всех баш-портянками потрясают не фрюшники, а братья наши меньшие, которые и не в курсе, что кроме примитивного Sysvinit есть невероятно удобный и продвинутый BSD Init, а весь выбор систем инициализации в линуксе - выбор между лезгинкой и гей-парадом.
Стандартный вопрос любителю инит файлов. Как остановить запущеный процесс?Пид файлы и подобные костыли не предлагать.
> Стандартный вопрос любителю инит файлов. Как остановить запущеный процесс?
> Пид файлы и подобные костыли не предлагать.Отвязка от традиционного PID файла?
Запускаем:
jail -c -u someuser path=/ name='somename' command=mycommand
останавливаем:
jail -r somenameПишем "портянку":
#!/bin/sh
# PROVIDE: strange_daemon
# REQUIRE: LOGIN. /etc/rc.subr
name="strange_daemon"
rcvar=strange_daemon_enableload_rc_config $name
start_cmd="jail -c -u someuser path=/ name='my_strange_daemon_jail' command=mydaemon"
stop_cmd="jail -r 'my_strange_daemon_jail'"
run_rc_command "$1"Теперь можем делать:
service strange_daemon start
service strange_daemon stopНо вы там держитесь ))
> Запускаем:
> jail -c -u someuser path=/ name='somename' command=mycommand$ jail -c -u someuser path=/ name='somename' command=mycommand
bash: jail: command not found
$ uname -o
GNU/Linux
Что дальше?
Ну вот ты зашел не в ту тему. Посмотри название топика.
> Ну вот ты зашел не в ту тему.А, т.е. красота Юнекса в том, что "отвали со своей разновидностью, тут это работает иначе"? Всё-таки как же здорово, что Линус и ребята из Red Hat вменяемые и вертят на логротейте все эти религиозные сектантские суеверия...
> А, т.е. красота Юнекса в том, что "отвали со своей разновидностью, тут
> это работает иначе"? Всё-таки как же здорово, что Линус и ребята
> из Red Hat вменяемые и вертят на логротейте все эти религиозные сектантские суеверия...А, т.е. реализовать свое, изначально не портируемое решение в виде системды - это не "отвали со своей разновидностью, тут это работает иначе", а "вменяемость".
Не знал, не знал!
А у меня работает. И прибивать софт если и приходится, то только тот, что писался в расчете на то, что кроме GNU/Linux на свете ничего уже нет.Что дальше?
>> Запускаем:
>> jail -c -u someuser path=/ name='somename' command=mycommand
> $ jail -c -u someuser path=/ name='somename' command=mycommand
> bash: jail: command not foundОчевидно, если ты в новости о "Релиз FreeBSD 11.3",
сначала нахваливаешь наличие системд в Линуксе, а потом задаешь вопрос, как остановить запущеный процесс в BSDInit, то получишь в ответ как раз способ на фре, а не "новом стандарте"?> $ uname -o
> GNU/Linux
> Что дальше?Не сдаваться!
https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.3/
> Как остановить запущеный процесс?А как запущеный процесс? И в какой ОС? Иначе вопрос не имеет смысла.
Можно ли запустить в linux'е процесс в сигруппе и потом прибить все пиды из неё из скрипта, а не с помощью systemd? Риторический вопрос.
Если вопрос про rc-скрипты какой-то конкретной ОС, почему бы не открыть код, да не посмотреть? Опенсорс же.> Пид файлы и подобные костыли не предлагать.
В зависимости от ответов не первые вопросы и от того, какая именно задача решается, ответ может быть разный. Начиная от "найти нужный процесс в списке процессов, по имени+cmdline и убить" и "дать возможность в скрипте определить свою функцию rc_stop() если мы хотим странного", заканчивая использованием средств контейнеризации ("убить" cgroup/jail/etc) или отправкой команды процессу-супервизору демона остановить сервис (привет, daemontools и друзья).
Вообще, разговор "скрипты vs конфиги" в контексте кастомизации процесса запуска сервисов - он не про надёжную (и/или гарантированную) остановку сервиса, а про способ описания логики запуска/остановки сервиса (ВНЕЗАПНО). Запускать процессы в тех же сигруппах заскриптованная на шелле логика никак не мешает - файловое api сигруп это позволяет. Хотя написать обвязку практичнее (и я не про systemd - он сильно больше, чем cli для cgroup, очевидно).
И да, это, systemd с его использованием линуксовых сигрупп тоже не даёт гарантий - cgroup'а процесса может измениться (например, другим запущенным менеджером сигрупп или третьим лицом).
> А как запущеный процесс? И в какой ОС? Иначе вопрос не имеет смысла.Linux/FreeBSD + на чём там systemd-луддиты пытаются костылять? bash? shell? Perl?
Как запущенный? Да всё равно как.
Я уже лет 5 сижу на systemd, обожаю его за то, что теперь, когда я пишу программы оторванные от терминала, мне не нужно думать, как в ралзичных ста тысячах дистрибутивов Linux (В том числе сборки от Васяна) мне запустить, остановить или перезагрузить мой демон.
Я просто использую конфиг от systemd, который 4 строчки и работает одинаково на всех дистрибутивах, за исключением существующих только в теории маргинальных извращений типа devian :-)
Процесс будет остановлен командой kill с нужным сигналом. Какие в этом сложности?> когда я пишу программы оторванные от терминала, мне не нужно думать, как в ралзичных ста тысячах > дистрибутивов Linux (В том числе сборки от Васяна) мне запустить, остановить или перезагрузить
> мой демон.Вообще есть lsb, которого стоит придерживаться. Если Вы не знаете как остановить написать стартовый скрипт для linux'а, быть может не стоит писать свои программы? И, наконец, в дистрах есть мейнтенеры с которыми можно обсудить этот вопрос, либо они напишут стартовый скрипт сами, раз уж Вы не в состоянии это сделать.
> Процесс будет остановлен командой killКакой процесс? Как ты его найдёшь?
> Если Вы не знаете как остановить написать стартовый скрипт для linux'аЯ чувствую, сейчас вскроется, кто на самом деле не умеет писать.
Как определить процесс, которому послать kill?
P.S. Например процесс называется "nginx". Задача остановить "nginx" на хост системе. Из дополнительных условий, на хост системе крутится ещё 5 LXC контейнеров, в трёх из которых тоже есть процесс "nginx".Как будем останавливать nginx? :-)
> P.S. Например процесс называется "nginx". Задача остановить "nginx" на хост системе. Из дополнительных условий, на хост системе крутится ещё 5 LXC контейнеров, в трёх из которых тоже есть процесс "nginx".
> Как будем останавливать nginx? :-)Как запущен nginx?
Может, он под daemontools? Тогда svc -d servicename.А так, открой для себя ключ "--ns" у pkill (хотя бы). Узнаешь, что остановить процесс в нужном контейнере можно и без systemd.
>> P.S. Например процесс называется "nginx". Задача остановить "nginx" на хост системе. Из дополнительных условий, на хост системе крутится ещё 5 LXC контейнеров, в трёх из которых тоже есть процесс "nginx".
>> Как будем останавливать nginx? :-)
> Как запущен nginx?
> Может, он под daemontools? Тогда svc -d servicename.Начинается стандартная краснoглазая свистопляска с "как запущен". Вот для того, чтобы больше никогда таких вопросов не задавали, и придуман systemd. Воистину, systemd - это лучшее, что было сделано для Linux за последние лет 15 наверное.
> А так, открой для себя ключ "--ns" у pkill (хотя бы). Узнаешь,
> что остановить процесс в нужном контейнере можно и без systemd.И как тебе это поможет? У тебя pid неизвестен. Перед тем как лужу газифицировать, почитай, на что отвечать пытаешься.
>>> P.S. Например процесс называется "nginx". Задача остановить "nginx" на хост системе. Из дополнительных условий, на хост системе крутится ещё 5 LXC контейнеров, в трёх из которых тоже есть процесс "nginx".
>>> Как будем останавливать nginx? :-)
>> Как запущен nginx?
>> Может, он под daemontools? Тогда svc -d servicename.
> Начинается стандартная краснoглазая свистопляска с "как запущен".Красноглазая? Глаза у меня стали красными, когда я всю ночь пытался подружить systemd и кастомное средство контейнеризации. Знакомые, совокупляющие докер и systemd тоже много расказывали злых историй.
> Вот для того, чтобы больше никогда таких вопросов не задавали, и придуман systemd.
Ага, и ещё, например, для того, чтобы свалившись systemd утаскивал за собой всю систему.
Чё сказать-то хотел? Вот напишу я в systemd-юните запуск контейнера сбоку от systemd, а в стоп-скрипт забуду прописать правильную команду или ошибусь где-то. Получаем всё тот же гемморой, что и раньше, даже хуже.> Воистину, systemd - это лучшее, что было сделано для Linux за последние лет 15 наверное.
И снова мантры вместо аргументов. Почему у поклонников systemd всегда так? Ну хотя как ещё, если аргументов нет?
>> А так, открой для себя ключ "--ns" у pkill (хотя бы). Узнаешь, что остановить процесс в нужном контейнере можно и без systemd.
> И как тебе это поможет? У тебя pid неизвестен. Перед тем как лужу газифицировать, почитай, на что отвечать пытаешься."pgrep, pkill - look up or signal processes based on name and other attributes" (man pkill)
Даже не знаю, что можно добавить к этому))
А ключ "--ns" мне поможет прибить nginx в нужном контейнере, очевидно.
> Глаза у меня стали красными, когда я всю ночь пытался подружить systemd и кастомное средство контейнеризации. Знакомые, совокупляющие докер и systemd тоже много расказывали злых историй.О, смузи-докероадмины подтягиваются :-)
> Ага, и ещё, например, для того, чтобы свалившись systemd утаскивал за собой всю систему.О, знатные байки от кукаретиков про неуловимого джо, которого никто никогда не видел :-)
>> Глаза у меня стали красными, когда я всю ночь пытался подружить systemd и кастомное средство контейнеризации. Знакомые, совокупляющие докер и systemd тоже много расказывали злых историй.
> О, смузи-докероадмины подтягиваются :-)По существу есть что сказать? Нет? Тогда молчи.
>> Ага, и ещё, например, для того, чтобы свалившись systemd утаскивал за собой всю систему.
> О, знатные байки от кукаретиков про неуловимого джо, которого никто никогда не видел :-)Ты конструктивен до невозможности. Начал умничать про остановку процесса, обогадился и перешёл к унылым типа-смешниым подколам.
Да, смерть pid1 в unix-системах приводит к kernel panic. Но если ты этого никогда не видел, то разумеется, так не бывает.
> По существу есть что сказать? Нет? Тогда молчи.По существу я жду, когда ты расскажешь, как найти среди десятка процессов с одинаковым именем тот, который нужно убить/рестартануть. Я всё ещё жду, с темы соскочить не получится :-)
>> По существу есть что сказать? Нет? Тогда молчи.
> По существу я жду, когда ты расскажешь, как найти среди десятка процессов с одинаковым именем тот, который нужно убить/рестартануть. Я всё ещё жду, с темы соскочить не получится :-)Пока ты не скажешь, как именно запущен процесс, твой вопрос не имеет никакого смысла. И в какой ОС.
Если брать твой пример про nginx и LXC контейнеры, то вариантов масса:
- Найти процесс с нужным именем (в том числе с нужной строкой аргументов) в нужном namespace, под нужным пользователем и послать ему сигнал. Например, через pkill.
- Найти список процессов в нужной нам сигруппе, далее по имени найти нужный nginx и послать ему сигнал.
Как узнать правильный namespace/cgroup? Зависит от того, как мы запускаем. Очевидно, эти знания нужно где-то хранить, вопрос исключительно в способе. Без этих знаний найти нужный процесс нельзя.
> Пока ты не скажешь, как именно запущен процесс, твой вопрос не имеет никакого смысла. И в какой ОС.Я запускаю все процессы под Linux и через systemd. Но мне чертовски интересно, как это делаете вы, в мире, где systemd не существует. По-этому я не знаю, как вы запускаете процессы. Предположим обычным sysv-init или rc.subr - на выбор.
> Найти процесс с нужным именем (в том числе с нужной строкой аргументов) в нужном namespace, под
> нужным пользователем и послать ему сигнал. Например, через pkill.Я уже писал выше, повторюсь. Вот тебе реальный пример из жизни:
root@XXX:~# ps ax | grep sssd_pam
15620 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
16829 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
28421 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
28499 ? S 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
28947 ? S 0:03 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
Дано: Есть hypervisor с 4 контенерами. И на гипервизоре и в контейнерах крутиться sssd демон, который авторизует юзеров из LDAP. Какой из вышеперечисленных процессов работает на гипервизоре, а какой в контейнерах?Задача: написать init скрипт, который рестартанёт нужный sssd_pam
>> Пока ты не скажешь, как именно запущен процесс, твой вопрос не имеет никакого смысла. И в какой ОС.
> Я запускаю все процессы под Linux и через systemd. Но мне чертовски интересно, как это делаете вы, в мире, где systemd не существует. По-этому я не знаю, как вы запускаете процессы. Предположим обычным sysv-init или rc.subr - на выбор.Если ты запускаешь процесс systemd'ой, лучше всего ей же и останавливать, очевидно.
sysvinit, ЕМНИП, штатных средств для запуска в контейнере не имеет. Можно написать своё, да. Потому и вопрос - "КАК ИМЕННО ЗАПУЩЕН".
В случае FreeBSD - там контейнеры - jail. Когда я ей пользовался, запускать сервис в джейле надо было тоже какой-то самописной логикой.В любом случае, проблемы решаемы. Во FreeBSD всегда можно посмотреть на jail id у процесса и выбрать правильный. В Linux можно сделать cat /proc/$PID/cgroup и/или ls /proc/$PID/ns/* и понять, в какой сигруппе/нэймспейсе контейнер, ну и далее по вкусу..
>[оверквотинг удален]
> 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
> 16829 ? S
> 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
> 28421 ? S
> 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
> 28499 ? S
> 0:02 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
> 28947 ? S
> 0:03 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
> Дано: Есть hypervisor с 4 контенерами. И на гипервизоре и в контейнерах крутиться sssd демон, который авторизует юзеров из LDAP. Какой из вышеперечисленных процессов работает на гипервизоре, а какой в контейнерах?См. выше про магию с /proc. Плюс есть ещё команда lsns, чтобы понять, какие вообще нэймспейсы есть.
> Задача: написать init скрипт, который рестартанёт нужный sssd_pam
Сорян, но нет. Скрипт я писать не буду. Всё, что нужно для его написания я перечислил в этом ответе. Поиграйся с примерами команд, что я тебе писал, если ты правда хочешь разобраться, а не потроллить, станет понятно, как отличать контейнеры без systemd.
Собственно, мой изначальный поинт был в том, что cgroups/namespaces - это свойство ОС, а не systemd и всем этим можно пользоваться и из скриптов, было бы только желание.Ну и кстати вопрос, а точно ли это хорошая практика - убивать контейнеризованый демон с гипервизора?
> Ну и кстати вопрос, а точно ли это хорошая практика - убивать контейнеризованый демон с
> гипервизора?ой жесткач... Я хочу на гипервизоре убить sssd гипервизора при этом не задеть контейнеры.
>> Ну и кстати вопрос, а точно ли это хорошая практика - убивать контейнеризованый демон с гипервизора?
> ой жесткач... Я хочу на гипервизоре убить sssd гипервизора при этом не задеть контейнеры.Цитирую тебя же:
>> Какой из вышеперечисленных процессов работает на гипервизоре, а какой в контейнерах?
>> Задача: написать init скрипт, который рестартанёт нужный sssd_pamНи слова про то, что убивать ты собрался процесс с "dom0". Ок. Всего прочего, что я написал это не отменяет. Смотришь, какие есть сигруппы/нэймспейсы, ищешь в нужной процесс и вперёд. Сколько раз мне это нужно повторить?)
Вопрос к архитекторам докера почему pid1 внутри контейнера железобетонно монополизирован
> Вопрос к архитекторам докера почему pid1 внутри контейнера железобетонно монополизированЯ именно докером почти не пользовался, но вообще же, линуксовые неймспейсы вполне позволяют запустить в качестве внутриконтейнерного pid1 произвольный процесс.
Да, но вот не в докере)
> Какой процесс?Процесс для которого написан стартовый скрипт.
> Как ты его найдёшь?
Каждый процесс присваивается идентификатор в posix, найду я его командой pidof, к примеру.
> Как определить процесс, которому послать kill?
Из pid файла взять.
>> Какой процесс?
> Процесс для которого написан стартовый скрипт.
>> Как ты его найдёшь?
> Каждый процесс присваивается идентификатор в posix, найду я его командой pidof, к
> примеру.
>> Как определить процесс, которому послать kill?
> Из pid файла взять.Перечитай этот тред ещё раз целиком. По четвёртому разу лень объяснять, почему всё, что ты написал выше, не работает.
>> А как запущеный процесс? И в какой ОС? Иначе вопрос не имеет смысла.
> Linux/FreeBSDИ там и там можно запускать как обычные процессы, так и контейнеризованные. Используя как shell-скрипты, так и демона-уродца (во freebsd его ещё надо написать сначала, надеюсь не напишут).
> на чём там systemd-луддиты пытаются костылять? bash? shell? Perl?
Ты хоть сам-то понял, что сейчас написал?
И чем гадать, выставляя себя очевидным неучем без кругозора, лучше бы взял да посмотрел, как там сделано.> Как запущенный? Да всё равно как.
Нет, не всё равно. Например, запущеный в сигруппе процесс - это одна история, а запущенный руками из под моего пользователя - другая. Та же история с джейлами, например. А если вспомнить ещё про daemontools-подобные запускаторы/супервизоры...
> Я уже лет 5 сижу на systemd, обожаю его за то, что теперь, когда я пишу программы оторванные от терминала, мне не нужно думать, как в ралзичных ста тысячах дистрибутивов Linux (В том числе сборки от Васяна) мне запустить, остановить или перезагрузить мой демон.
Если скрипты/юниты поставляются вместе с сервисом его мэйнтейнером, то думать тебе не надо в любом случае. Ну, кроме ситуаций, когда там что-то сломано. Сюрприз, написать некорректный юнит тоже можно. Если хочется чего-то странного, то придётся писать своё в любом случае.
И systemd тут совсем никаких преимуществ не имеет. В лучшем случае, ты напишешь скрипт, который будет запускаться systemd-юнитом. В худшем случае, если у тебя, например, свой менеджер сигрупп/неймспейсов, да говорят даже тривиального докера достаточно, ты обречён жрать говно и лепить уродливые костыли.
В такие моменты становится понятно, что простота - это счастье. Запускатор, который не умеет в сигруппы/неймспейсы/аналог позволяет тебе накрутить свою логику произвольной сложности вокруг сервисов и самому рулить сигруппами/неймспейсами так как нужно и удобно тебе, а не поттерингу.
Да, это надо не всем и в простейших случаях systemd ок для многих. Systemd только для протейших случаев и годен, если хочется сложной логики, "инновации" systemd начинают только мешать, в то время как в скрипте ты можешь написать примерно всё, что захочешь.> Я просто использую конфиг от systemd, который 4 строчки и работает одинаково на всех дистрибутивах, за исключением существующих только в теории маргинальных извращений типа devian :-)
С учётом потенциально разных путей до демонов в разных дистрибутивах и с учётом разных предпочтений мейнтенеров - не верю. Ничто не мешает также унифицировать скрипты во всех дистрибутивах. Просто, бардак и зоопарк - это вообще свойство линуксовых дистрибутивов. А systemd - это лишь ещё одна неудачная попытка починить это.
> Ты хоть сам-то понял, что сейчас написал?Я эти бзяшные сабрутины на шелле наизусть помню ещё с FreeBSD 4.4 начала нулевых.
Все они завязаны на одной единственной истине - pid файл существует и в pid файле указан правильный pid процесса. Как только эта шаткая конструкция рушится, по п***е идут все эти rc.subr и все их ветвления.
> Нет, не всё равно.Нет, всё равно. Мне абсолютно пофигу как и чем ты будешь что-то запускать, мне, как администратору и как автору программ нужна надёжная конструкция для менеджмента процессов. Ни sysv ни rc.subr надёжными не являются.
Я не хочу ни лапшу-обвязку на шелле для этого писать, ни тем более полагаться на Васяна из ГобоЛинукса, который мейнтейнит мой софт и пишет для него скрипты.
Слава Леннарту теперь я могу взять шаблон от systemd из четырёх строк и поправить там одну строку с путём до моего сервиса.
> Systemd только для протейших случаев и годен
Для начала тебе стоит прочитать если не документацию, то хотябы feature list от systemd чтобы понять, насколько ты беспробудно глуп.
> Ничто не мешает также унифицировать скрипты во всех дистрибутивах.Что ж за 20 лет этого никто не сделал? Слава Богу есть Леннарт. Прямо пойду сейчас задоначу ему. :-)
>> Ты хоть сам-то понял, что сейчас написал?
> Я эти бзяшные сабрутины на шелле наизусть помню ещё с FreeBSD 4.4 начала нулевых.Понятно, не понял. Трагично.
> Все они завязаны на одной единственной истине - pid файл существует и в pid файле указан правильный pid процесса. Как только эта шаткая конструкция рушится, по п***е идут все эти rc.subr и все их ветвления.
Во-первых, freebsd - не единственная BSD. Во-вторых, конструкция с pid-файлами может работать надёжно. В третьих, в в той же OpenBSD pid-файлы не используются (не системный сервис может использовать - смотря что автор написал в rc_stop()). В четвёртых, я считаю, что запускать продакшен-сервисы системным rc - неправильно. Его задача - загружать базовые системные демоны, надёжно и тривиально. Всё. Продакшен-сервисы должны запускаться тем, что наиболее отвечает потребностям продакшена.
Что касается pid-файлов и systemd. Вот в systemd всё завязано на то, что сигруппа процесса не может измениться. А это не так - может. И когда это случается - "эта шаткая конструкция рушится".
То есть принципиальной разницы никакой. Мы не решили проблему, а перенесли её из одного места в другое. Надёжный способ - как в daemontools, например. Когда у каждого процесса свой родитель-супервизор, который ВСЕГДА знает PID дочернего процесса. Но откуда systemd-фанатик мог про такое слышать?>> Нет, не всё равно.
> Нет, всё равно. Мне абсолютно пофигу как и чем ты будешь что-то запускать, мне, как администратору и как автору программ нужна надёжная конструкция для менеджмента процессов. Ни sysv ни rc.subr надёжными не являются.Нет, не всё равно. Я привёл примеры почему - ты прочитал в ответ мантры. Продолжай читать дальше. Рекомендую ещё маршрут менять, когда чёрная кошка дорогу переходит.
> Я не хочу ни лапшу-обвязку на шелле для этого писать, ни тем более полагаться на Васяна из ГобоЛинукса, который мейнтейнит мой софт и пишет для него скрипты.
Не пиши лапшу-обвязку. Открой любой rc-файл да скопипасть. Если сам без лапши писать не умеешь.
А если в скрипте вдруг описана какая-то сложная логика - почитай её, может быть автор не просто так делает что-то отличное от "позвать kill для пида такого-то"?> Слава Леннарту теперь я могу взять шаблон от systemd из четырёх строк и поправить там одну строку с путём до моего сервиса.
Мы уже поняли, что ты пишешь/эксплуатируешь тривиальные программы в простейшем из возможных случаев и только этим твой кругозор и ограничивается. Можешь не повторять это снова.
>> Systemd только для протейших случаев и годен
> Для начала тебе стоит прочитать если не документацию, то хотябы feature list от systemd чтобы понять, насколько ты беспробудно глуп.Ты мог написать что-то по делу, но ты перешёл на личности. Молодец.
Я не только читал доки к s-d, но и имею опыт его использования в продакшене. И точно тебе говорю, что в моих условиях он не решает проблем, а только создаёт их. Потому что средство контейнеризации у нас написано было сильно раньше, чем s-d пришёл в убунту и потому что оно решает несколько другие задачи, нежели systemd. Нет, s-d, конечно, лучше чем upstart - последнее просто беспробудный мрак и уродство. Но это единственное, что я могу сказать хорошего про поделие поццеринга.>> Ничто не мешает также унифицировать скрипты во всех дистрибутивах.
> Что ж за 20 лет этого никто не сделал? Слава Богу есть Леннарт. Прямо пойду сейчас задоначу ему. :-)Так и поттеринг этого не сделал. Раньше были разные скрипты - теперь разные юниты. Для каких-то базовых демонов это может быть и унифицировано, а в целом...
А почему за 20 лет никто не сделал? Я не знаю, бардак и разнообразие - это вообще свойство линуксов, и с наступлением systemd ничего принципиально не изменилось.
Так что донать на здоровье, как говорится, если слышен бабок шелест, значит лох идёт на нерест.
> Надёжный способ - как в daemontools, например.Если опустить всю политоту, возникает один простой вопрос, который является производной вопроса "если вы такие умные, почему такие бедные?". Если daemontools/openrc/whatever такие хорошие, почему systemd везде? Абсолютно на всех linux и unix подобных серверах?
За исключением серверов, которые находятся в районе статистической погрешности, и на фоне количества серверов с systemd их просто не существует.
>> Надёжный способ - как в daemontools, например.
> Если опустить всю политоту, возникает один простой вопрос, который является производной вопроса "если вы такие умные, почему такие бедные?". Если daemontools/openrc/whatever такие хорошие, почему systemd везде? Абсолютно на всех linux и unix подобных серверах?Именно daemontools - не знаю. То, что успользуется там, где я работаю - самопальный велосипед, вдохновлённый подходом daemontools. Слышал по меньшей мере про 2 не самых мелких продакшена в РФ, которые используют runit (примерно то же самое, что daemontools).
Почему везде systemd? Потому что это зафорсил redhat, главным образом игнорируя чужое мнение и попытки конструктивной критики.
Ну и потому что в отличе от upstart systemd всё-таки работает.> За исключением серверов, которые находятся в районе статистической погрешности, и на фоне количества серверов с systemd их просто не существует.
Это потому что systemd не только супервизор (как daemontools svc), но и pid1 и замена rc-скриптам и всему на свете. Там где я работаю, сейчас всё постепенно обновляется до версии убунты с системдой, однако, весь продакшен всё равно запускается самопалом (и так и будет далее). Systemd же используется примено для того, для чего /etc/rc в OpenBSD - чтобы запустить ОС и некоторые системные сервисы. И на её месте могло быть что угодно, просто желания поддерживать свой дистрибутив линукса нет никакого желания и ресурсов.
Как трактовать подобную статистику - решай сам.PS: миллионы мух не могут ошибаться!
> Как трактовать подобную статистику - решай сам.Нежелание читать документацию, NIH синдром и боязнь всего нового. Три в одном :-)
>> Как трактовать подобную статистику - решай сам.
> Нежелание читать документацию, NIH синдром и боязнь всего нового. Три в одном :-)Понятно, ты - мистер божья роса.
>Если daemontools/openrc/whatever
> такие хорошие, почему systemd везде? Абсолютно на всех linux и unix
> подобных серверах?Птамуша кругом все такие талантливые троли, как ты.
>За исключением серверов, которые находятся в районе статистической погрешности
За исключением погрешности. Разумеется !
Не стоит обобщать там, где Вы не в курсе дела. Если Вы видите только системы с s-d, это не значит, что другие не существуют в мире и уж тем более, не используются в промышленности. Особенно, если учитывать, что s-d нет на системах с сертификатом UNIX™. А я много видел именно такие машины, а ляликсов - не так уж и много.
> Надёжный способ - как в daemontools, например. Когда у каждого процесса свой родитель-супервизор,
> который ВСЕГДА знает PID дочернего процесса.Ровно так работает systemd. Только в отличие от daemontools, у всех процессов есть один общий родитель - systemd. Он знает про все процессы, даже если ты им меняешь cgroup :-)
>> Надёжный способ - как в daemontools, например. Когда у каждого процесса свой родитель-супервизор,
>> который ВСЕГДА знает PID дочернего процесса.
> Ровно так работает systemd. Только в отличие от daemontools, у всех процессов есть один общий родитель - systemd.Ага, поэтому если свалится один супервизор daemontools, он утянет за собой только один сервис. А если свалится systemd - то все сервисы за собой.
(на самом деле, будет kernel panic, ибо systemd - pid1)> Он знает про все процессы, даже если ты им меняешь cgroup :-)
1) Сигруппу поменял дочерний процесс сервиса. Упс?
2) Я сделал oneshot-сервис, который говорит bicyclectl start servicename, что приводит к запуску процесса в другой системе контейнеризации, процесс может быть запущен в другом namespace/cgroup. Упс?
> Ага, поэтому если свалится один супервизор daemontools, он утянет за собой только один сервис.Это очень ценное свойство, например на сервере баз данных, когда падает всего лишь один mysql :-)
> А если свалится systemd - то все сервисы за собой. (на самом деле, будет kernel panic, ибо systemd - pid1)Ага, именно поэтому случаев падения systemd pid1 если и есть, то их можно посчитать по пальцам одной руки, попавшей под циркулярку :-)
> Сигруппу поменял дочерний процесс сервиса. Упс?Не-а, исключено. Права root вынь да положь :-)
> Я сделал oneshot-сервис, который говорит bicyclectl start servicename, что приводит к запуску
> процесса в другой системе контейнеризации,А родительский процесс всё равно будет общий и systemd про это знает. Упс? :-)
>> Ага, поэтому если свалится один супервизор daemontools, он утянет за собой только один сервис.
> Это очень ценное свойство, например на сервере баз данных, когда падает всего лишь один mysql :-)Тебе, видимо, кажется, что это смешно, но это глупо. Очевидно, что если на сервере только один сервис, разницы нет. И что?
>> А если свалится systemd - то все сервисы за собой. (на самом деле, будет kernel panic, ибо systemd - pid1)
> Ага, именно поэтому случаев падения systemd pid1 если и есть, то их можно посчитать по пальцам одной руки, попавшей под циркулярку :-)А и не требуется, чтобы это было часто. И речь в первую очередь про подход. Класть все яйца в одну корзину - изначально ненадёжный подход.
>> Сигруппу поменял дочерний процесс сервиса. Упс?
> Не-а, исключено. Права root вынь да положь :-)Или CAP_SYS_ADMIN, ЕМНИП. И что? PID-файл, например, тоже имеет злые рутовые права и просто так не побьётся. А отдельный cgroup-manager, очевидно, работает под рутом.
И, внезапно, сам процесс может быть рутовым. Так бывает, да-да.>> Я сделал oneshot-сервис, который говорит bicyclectl start servicename, что приводит к запуску процесса в другой системе контейнеризации,
> А родительский процесс всё равно будет общий и systemd про это знает.
> Упс? :-)Какой родительский процесс? Oneshot же. Ты точно настоящий systemd-фан? Не знаешь, как работает обожествляемое тобой же поделие.
> Класть все яйца в одну корзину - изначально ненадёжный подход.Ну тут же понимаешь, что при такой формулировке ты сразу напрашиваешься на "если ты такой умный, почему на опеннете, а не в redhat?" :-)
> например, тоже имеет злые рутовые права и просто так не побьётсяКак нехрен делать, оно лежит в {/var}/run (tmpfs) который может быть вычищен кем угодно по ошибке (например таким грешили ранние версии sssd)
> Какой родительский процесс? Oneshot же. Ты точно настоящий systemd-фан? Не знаешь, как работает
> обожествляемое тобой же поделие.Ламер, ты перед тем, чтобы что-то ляпнуть, проверил бы, как оно работает. Возьми любой готовый пакет с oneshot, например openvpn, запусти его а потом посмотри "systemd-cgls".
Школота необразованная. Говорю же, иди читай документацию :-)
>> Класть все яйца в одну корзину - изначально ненадёжный подход.
> Ну тут же понимаешь, что при такой формулировке ты сразу напрашиваешься на "если ты такой умный, почему на опеннете, а не в redhat?"Нет, не понимаю. Почему я должен быть в redhat? Почему ты считаешь, что я должен быть "военом за единообразие"? Все решения уже написаны, задолго до systemd, зачем мне ещё раз велосипедить?
>> например, тоже имеет злые рутовые права и просто так не побьётся
> Как нехрен делать, оно лежит в {/var}/run (tmpfs) который может быть вычищен кем угодно по ошибке (например таким грешили ранние версии sssd)Во-первых, предположение про tmpfs неверно, это ваш больной линукс-мир и только. Во-вторых, это полностью аналогично по смыслу ситуации с альтернативным менеджером сигрупп, подравшимся с systemd. Что и следовало доказать. В обоих случаях rc-скрипты/systemd не могут сами выйти из проблемной ситуации.
>> Какой родительский процесс? Oneshot же. Ты точно настоящий systemd-фан? Не знаешь, как работает обожествляемое тобой же поделие.
> Ламер, ты перед тем, чтобы что-то ляпнуть, проверил бы, как оно работает. Возьми любой готовый пакет с oneshot, например openvpn, запусти его а потом посмотри "systemd-cgls".1)
$ grep "Type=" /usr/lib/systemd/system/openvpn-*
/usr/lib/systemd/system/openvpn-client@.service:Type=notify
/usr/lib/systemd/system/openvpn-server@.service:Type=notify
2)
$ tail -11 /usr/lib/systemd/system/alsa-restore.service
[Unit]
Description=Save/Restore Sound Card State
ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
ConditionPathExists=/var/lib/alsa/asound.state[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/usr/bin/alsactl restore
ExecStop=-/usr/bin/alsactl store
# systemctl start alsa-restore.service
# systemd-cgls | grep -i alsa
#Ну как?
> Школота необразованная. Говорю же, иди читай документацию :-)
См. выше, умник.
> Ну как?Всё ещё хуже окахзалось, т.е. ты решил останавливать процесс, которого нет? :-) :-)
>> Ну как?
> Всё ещё хуже окахзалось, т.е. ты решил останавливать процесс, которого нет? :-) :-)Ты там, видимо, хорошо время проводишь. Или память у тебя короткая очень. Но мы не бросим тебя и научим любить родину.
1) Ты там кукарекал про openvpn? Получите и распишитесь - не oneshot -> ты лжёшь.
2) Я тебе показал, как работают oneshot сервисы. Ты мне обещал, что я что-то увижу в cgls. Не увидел -> ты лжёшь.
3) Я запускал вполне честный юнит, который на моём ср*ном рабочем ноуте с рачем запускается при каждой загрузке. Просто ты не знаешь, что такое oneshot, хотя так яро надрачиваешь на systemd.
$ systemctl | grep alsa
alsa-restore.service loaded active exited Save/Restore Sound Card State
$
т.е. ничего не сфейлилось и отработало корректно.
Короче, ты или снова лжёшь или дурачка включаешь. Скорее второе.
> Но мы не бросим тебя и научим любить родину.Слушай, завязывай уже бухать!
> Получите и распишитесь - не oneshot -> ты лжёшь.Перестань лгать. :-)
$ dpkg -S /lib/systemd/system/openvpn.service
openvpn: /lib/systemd/system/openvpn.service
$ cat /lib/systemd/system/openvpn.service
[Unit]
Description=OpenVPN service
After=network.target[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/openvpn[Install]
WantedBy=multi-user.target
> 2) Я тебе показал, как работают oneshot сервисы. Ты мне обещал, что я что-то увижу в cgls. Не увидел -> ты лжёшь.Ты липо паталогический лжец, который не умеет проигрывать, либо по незнанию своему довёл систему до нерабочего состояния. Скорее всего второе. Сочувствую твоему работодателю :-)
$ systemd-cgls | grep vpn
│ │ │ └─25761 grep --color=auto vpn
│ ├─15704 /usr/lib/NetworkManager/nm-openvpn-service --bus-name org.freedes...
│ ├─15707 /usr/sbin/openvpn --remote vpn.CENSORED.com 1194 udp --comp-lzo a...
> который на моём ср*ном рабочем ноуте с рачемТвою жеж маму... Что ж ты раньше про Arch linux не сказал...... Этого разговора не было бы. Столько времени потеряно (за счёт работодателя :-) ). Пля, арчлинукс. Я чувствовал, что что-то с тобой не так...
Всё, ты мне больше не интересен. Кто там следующий? :)
>[оверквотинг удален]
> Description=OpenVPN service
> After=network.target
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
> ExecReload=/bin/true
> WorkingDirectory=/etc/openvpn
> [Install]
> WantedBy=multi-user.targetМне как-то даже неудобно тебе говорить это, но юнит который ты мне сам скопипастил запускает не openvpn, а /bin/true.
Ну и да, в раче такого нет. Поттерингоунификация такая поттерингоунификация, доо.>> 2) Я тебе показал, как работают oneshot сервисы. Ты мне обещал, что я что-то увижу в cgls. Не увидел -> ты лжёшь.
> Ты липо паталогический лжец, который не умеет проигрывать, либо по незнанию своему довёл систему до нерабочего состояния. Скорее всего второе. Сочувствую твоему работодателю :-)
> $ systemd-cgls | grep vpn
> │ │ │ └─25761 grep --color=auto vpn
> │ ├─15704 /usr/lib/NetworkManager/nm-openvpn-service --bus-name org.freedes...
> │ ├─15707 /usr/sbin/openvpn --remote vpn.CENSORED.com 1194 udp --comp-lzo a...И что? Ты мне показал юнит, запускающий /bin/true и тот факт, что у тебя запущен openvpn.
А что покажет systemd-cgls -u openvpn.service ? ;)>> который на моём ср*ном рабочем ноуте с рачем
> Твою жеж маму... Что ж ты раньше про Arch linux не сказал...... Этого разговора не было бы. Столько времени потеряно (за счёт работодателя :-) ). Пля, арчлинукс. Я чувствовал, что что-то с тобой не так...Слабо чувствовал ещё. Дома я вообще OpenBSD использую, и как только мне не нужно будет по доп. работе тестировать линуксонли проприетарные бинарники, рач, вероятно, покинет мой ноут. Но это лирика. Так-то среди линуксов он один из самых адекватных.
А причём тут работодатель я не понял. На работе, очевидно, не рач. Хотя за деньги я что угодно админить буду, я не гордый.> Всё, ты мне больше не интересен. Кто там следующий? :)
Ну да, показал мне юнит, запускающий /bin/true и какой-то openvpn в списке процессов - уделал так уделал)
На самом деле, ты прекрасно расчехлился, и я мог бы вообще ничего тебе не отвечать - любой, умеющий читать поймёт, какой ад ты пишешь.
> Всё, ты мне больше не интересен. Кто там следующий? :)Я всё думал, почему мне кажется знакомым твой стиль общения, наполненый высокомерием, твердолобым упрямством и невежеством.
А оказывается мы общались по работе.> Что ж ты раньше про Arch linux не сказал...... Этого разговора не было бы.
В лицо ты мне такого не говорил, хотя про рач на лаптопе точно знал.
В интернете так легко быть смелым, правда? ;)
Не могу сдержаться и не высказаться немного по поводу твоей писанины. Я поступаю плохо и неправильно, но тем не менее:> https://www.opennet.dev/openforum/vsluhforumID3/117224.html#279
Жмур, не выноси сор из избы, а?
Мне есть что сказать про твоё "культурное наследие" да и просто по теме, но я не буду опускаться до такого; уж точно не на публику.
Единственное, что я не могу не прокомментировать: те БСДшные админы были профессионалами, в отличие от. Уволил того админа лично ты пользуясть своими связями и адмресурсом.
Правда его сразу же забрали программировать в соседний отдел на более выгодную позицию.
Те ребята могли отдебажить или написать программу, патчили ядро, били по рукам тех, кто делал фигню.
Ты же все проблемы решал сам знаешь как.
Не надо больше врать и хвастаться, ладно? И выносить на публику то, что выносить не нужно?> https://www.opennet.dev/openforum/vsluhforumID3/116147.html
(речь идёт о твоих хвастливых каментах не только к этой теме; делать подборку комментариев я не буду)
В России ты всегда ныл про "поганую рашку" и "поравалить". Свалил. Ура.
Что не так с твоей самооценкой, если ты ходишь хвастаться на опеннет и самоутверждаешься количеством серверов под btrfs в продакшене?
Радуешься, что работаешь в пейсбуке, рядом с такими людьми, как mason и кламм?
Знаешь, почему ты хвастаешься и самоутверждаешься на опеннете, а кламм (например) нет? Потому что он специалист, а ты - посредственность. Ему не надо ничего себе доказывать подобным образом.
Веди себя достойно, что ли.
Взрослый же человек, а такой х****й занимаешься. Как школьник.PS: когда ты пишешь, что ты разбираешься во FreeBSD, ты, мягко говоря, СИЛЬНО преувеличиваешь.
PS2: про oneshot всё-таки прочитай.
> Единственное, что я не могу не прокомментировать: те БСДшные админы были профессионалами,
> в отличие от. Уволил того админа лично ты пользуясть своими связями
> и адмресурсом.
> Правда его сразу же забрали программировать в соседний отдел на более выгодную
> позицию.a это не про Андрея З. речь часом?
но вообще, в целом, картина понятна :) у меня было ощущение что я общаюсь просто с тупым девопсиком, а оказалось, что всё сильно хуже.
> PS: когда ты пишешь, что ты разбираешься во FreeBSD, ты, мягко говоря,
> СИЛЬНО преувеличиваешь.ну был еще 1 дефективный менеджер в интернете. в жж как слоник-в-домене подписывался, тот себя тоже большим специалистом по фре считал. Есть такие люди, которые 3 раза из-за спины админа видели ОС, но уже везде заявляют ее знание, да, к сожалению.
> PS2: про oneshot всё-таки прочитай.думаешь, у него в фейсбучике, должность писателя юнитфайлов? вполне себе допускаю, что его и близко к серверам/деплою не подпускают. лидит, поди, потихоньку, писяя в мозг руководителю про свою нужность и важность.
> a это не про Андрея З. речь часом?З., кажется, ушёл сам и точно сразу за кордон уехал. Это про Андрея И.
>> PS: когда ты пишешь, что ты разбираешься во FreeBSD, ты, мягко говоря, СИЛЬНО преувеличиваешь.
> ну был еще 1 дефективный менеджер в интернете. в жж как слоник-в-домене подписывался, тот себя тоже большим специалистом по фре считал. Есть такие люди, которые 3 раза из-за спины админа видели ОС, но уже везде заявляют ее знание, да, к сожалению.Я бы не хотел совсем уж перемывать тут кому-то кости. Поэтому прокомментирую скромно:
1) Слоник, судя по всему, FreeBSD таки использовал и имел какой-то опыт её эксплуатации. В отличие от. По работе он (не слоник) всегда занимался исключительно линуксом.
2) Слоник был волен сам принимать решения и сам решил делать то, что сделал. Бог ему судья. Этот же персонаж - исполнитель. Тимлид != менеджер.>> PS2: про oneshot всё-таки прочитай.
> думаешь, у него в фейсбучике, должность писателя юнитфайлов? вполне себе допускаю, что его и близко к серверам/деплою не подпускают. лидит, поди, потихоньку, писяя в мозг руководителю про свою нужность и важность.Я не знаю, чем именно он там занимается, но в его слова про тимлида могу поверить. Фейсбук - большая компания, меня совершенно не удивляет, что там могут работать специалисты разного уровня, если вы понимаете, на что я намекаю ;)
PS: Если ты тот самый тигар, то мы с тобой в одной компании (хостинг на букву А) тоже работали. Но никогда не пересекались, даже в переписке.
>> a это не про Андрея З. речь часом?
> З., кажется, ушёл сам и точно сразу за кордон уехал. Это про
> Андрея И.Значит нет, З да, улетел, но как-то с чувством того, что "Я" поступил не красиво, по его словам.
> PS: Если ты тот самый тигар, то мы с тобой в одной
> компании (хостинг на букву А) тоже работали. Но никогда не пересекались,
> даже в переписке.из тех, кто из msk, но с кем не пересекелся по работе разве что Дима Ф. вспоминается :-)
> Значит нет, З да, улетел, но как-то с чувством того, что "Я" поступил не красиво, по его словам.Я не могу тут точно что-то утверждать, это было довольно давно. Может З. тоже уволили. Для меня выглядело всё так: в один день он пришёл и сказал, что у него гринкард и работать он теперь будет в другом месте. Поэтому думаю, что таки ушёл сам.
Несмотря на то, что я отношусь к обоим Андреям с искренним уважением, близкими друзьями мы никогда не были и общались, в основном, по рабочим вопросам, кроме пары-тройки походов в бар.
PS: Про "не красивость" - думаю, это в любом случае так.> из тех, кто из msk, но с кем не пересекелся по работе разве что Дима Ф. вспоминается :-)
Я даже и не могу вспомнить уже, о ком может идти речь. Тогда я был ещё "техом" (слово из прошлого, хехе), а не админом, поэтому, думаю, наши рабочие контакты едва ли сильно пересекаются.
> PS: Если ты тот самый тигар, то мы с тобой в одной компании (хостинг на букву А) тоже работали.
> Но никогда не пересекались, даже в переписке.В агаве что ли?
>Все они завязаны на одной единственной истине - pid файл существует и в pid файле указан правильный pid процесса. Как только эта шаткая конструкция рушится, по п***е идут все эти rc.subr и все их ветвления.Как много пафоса, а на деле просто банальное незнание предмета обсуждения.
1 Для контроля демонов есть monitd. У него даже вебмордочка есть, при желании. Он даже сокеты может контролировать.
2 Для старт/стоп, если pid не считается корректным, то можно
# man rc.subr
NAME
rc.subr – functions used by system shell scriptsDESCRIPTION
....
check_process procname [interpreter]
Prints the PIDs of any processes that are running with a first
argument that matches procname. interpreter is handled as per
check_pidfile.
И этого в неособо клинических случаях вполне достаточно.
>>Единственный UNIX во всем рынке OpenSource-операционок.Утверждение не верно.
Solaris —> OpenSolaris —> Illumos—> OpenIndiana.
OpenIndiana шевелится регулярно
Есть ещё https://www.osdyson.org не шевелитяс
Ещё есть какой-то но забыл название, но и не шевелится.
Дерево юникс-подобных https://ru.wikipedia.org/wiki/Unix#/media/%D0%A4&#...
Какой дистрибутив Линукс наиболее похож на оригинальный Юникс?
AIX
Лицензия Проприетарная
Впрочем, как и сам UNIX когда-то...
Ты хотя бы читай, на что отвечаешь.
он не просто был проприетарным. он был закрытым. причем военными с 1956 и вплоть до 1982 года. поэтому впрочем и был создан линукс. чтобы иметь альтернативную юникс-подобную операционную систему, свободную заметьте. все BSD так и не могут оторваться от зависимости компаний. впрочем есть и плюсы. документация и изменения более плавные и реже ломаются апи. но прогресс малость отстает. впрочем спор о инит скриптах или о RC, никакой почвы не имеет. впрочем как и системд. каждый пользует свое. а попытка сказать линуксоиду , что у тебя не юникс... это показатель глупости и незнания, да и выпендрежа. линуксоид скажет и слава Богу.
Я пишу ответ на то, что FreeBSD не является единственным открытым UNIX, а есть ещё OpenIndiana которая произошла из Solaris.
В последнем предложении я так же спросил, какой Linux дистрибутив наиболее похож на оригинальный UNIX.
Фноним в ответ написал - AIX. Я написал то что это проприетарных Юникс и не понятно к упоминать его.
Ты пишешь краткий экскурс в историю развития Юникс.
У меня серьезные опасения по поводу вменяемости людей обитающих в комментариях.
я его и написал именно для подтверждения, что юникс всегда был проприетарным. и в этом отличие чистых юникс от юникс-лайк как линукс. впрочем спасибо AT&T за прекрасную реализацию идеи многопоточной операционной системы. теперь мы имеем нормальные оси на своих компах и серваках. в отличие от той же винды.
А в Википедии написано следующие https://en.wikipedia.org/wiki/OpenIndiana
OpenIndiana is a free and open-source Unix operating system derived from OpenSolaris and based on illumos.
> я его и написал именно для подтверждения, что юникс всегда был проприетарным.
> и в этом отличие чистых юникс от юникс-лайк как линукс. впрочем
> спасибо AT&T за прекрасную реализацию идеи многопоточной операционной системы. теперьза многопоточную - к сану иди со своей спасибой. До него была многозадачная.
из-за каких-то как раз at&t привнесенных проблем (в sunos ничем не воняло) после перехода на ее реализацию у них стал очень неэффективный fork, и пришлось скопипастить отработанное уже в винде на тот момент решение с "тредами", никому кроме солярки тогда совершенно ненужное - эпоха 1250ядерных процессоров еще даже на горизонте не маячила.> мы имеем нормальные оси на своих компах и серваках. в отличие
> от той же винды.у которой с реализацией тредов было нормально с самого начала (поскольку делались прежде всего для gui программ, которым многотредовость, а не многопроцессность, нужна по определению, а не чтоб все ядра позанимать), и которая никого не копировала.
Нормальные они у вас, ага.
> с "тредами", никому кроме солярки тогда совершенно ненужное - эпоха 1250ядерныхhttps://duckduckgo.com/?q=%E2%80%94+%D0&...
> процессоров еще даже на горизонте не маячила.
> Единственный UNIX во всем рынке OpenSource-операционок.Нет. FreeBSD не Unix. Unix это только то, что прошло сертификацию.
Настоящие Unix™: Oracle Solaris, Apple macOS/OS, AIX и ряд других.
FreeBSD не Unix и никогда им не будет, у этого сборища фриков не найдется денег на сертификациюА единственной серверной платформе играющей серьезную роль в этом мире(ОС на базе ядра Linux) эта сертификация не нужна, потому что Linux давно закопал конкурентов.
А что скажешь о OpenIndiana?
с точки зрения распространения , линукс действительно победитель и ему точно не нужна сертификация на юникс. потому как при создании упоминалось о юникс - подобной ОС, а не о самом юникс. и этим все сказано. даже если он в точности похож на юникс, он не является им. про bsd вообще молчу. их отношение к юникс тоже весьма отдаленное. да и много вещей они перетащили из линукс, как и обратно впрочем. я не понимаю смысла данного спора. юникс типа благородная? но бесполезная как оказалось. а линукс неблагородный , но везде?)))
Вопрос был адресован человеку с другим никнеймом, но ответил ты и не слова не сказал про OpenIndiana о которой был вопрос. У меня сложилось очень плохое впечатление о комментаторах. Такое впечатление, что они не читают перед тем как написать, но даже если читают, то не понимают о чем пишут. А казалось бы просто открыть статью на Википедии и не позориться.
Вообще-то minix гораздо популярнее. В каждом процессоре же.
Да ты очередной сказочник :DmacOS: XNU = X is Not Unix.
FreeBSD: открытая BSD Unix (не считая блобов в репах, типа нвидии)
Solaris: проприетарная BSD Unix => проприетарная System V Unix. (Вот радости-то от сертифицированного Юникса)
Сертификация - пыль. Это вообще не нужно для обычных людей, пусть и задирающих гузку, пытающихся гадить на систему, которая тоже принесла много интересных вещей в мир технологий, в том числе линуксов. Лишняя суета академическим юниксам, вроде фряхи, только вредит. Главное - это технология, а не бумажка.
За бабки можно купить любое звание, даже то, что система является сертифицированным unix-ом, не являясь им по настоящему. Ведь если сердце операционной системы не является юниксом, то какой же это юникс в целом. Остались только концепции и подходы.
Но макос это звание почти заслужил, ведь в нём глубоко внутри работает фриковская FreeBSD. :)
Работает она просто превосходно.
Всех с релизом! :) Долгой жизни настоящему открытому проекту!
> Но макос это звание почти заслужил, ведь в нём глубоко внутри работает
> фриковская FreeBSD. :)внутри которой работает линуксэмулятор. Браво, макось на самом деле - линукс, оказывается!
P.S. freebsd там "внутри", если ты не в курсе, примерно на тех же правах что ядерный линуксвраппер в самой freebsd, и для тех же целей - чтобы не переписывать тонны кода, не так чтоб очень важного.
Тогда макось не просто линукс, а конкретный centos. Но... линуксатор работает, но не обязателен. А попробуй запусти макос без фряхи. )
И окажется, что права совсем разные.К тому же это самый нижний уровень макоси в связке с драйверами. Представляешь, что будет, если оставить macos без bsd слоя. Вообще много чего отвалится:
- файловые системы, через фряшный слой идёт обращение к макосным фс; называется базовая поддержка файловых систем;
- поддержка сетевых устройств и стек;
- совместимость с posix потоками и сигналами;
- сетевые сокеты;
- связь драйверов с более верхним слоем ядра.Система станет абсолютно неработоспособна, поскольку фрибсд обеспечивает на маке сильно базовые вещи. Попробуй из под дома выдернуть часть фундамента.
Практически весь дарвин держится на фрибсд.
А на фряхе центос ставить не обязательно. Лично мне он был нужен только для нвидии. Сейчас, на амд с открытыми драйверами, совсем всё хорошо. Без линуксэмулятора.
нет, речь об in-kernel линуксоляторе - он не центос эмулирует, а ведро и его внутренний api примерно 4.4 (с обещаниями вот-вот запилить 4.20) - потому что некоторые драйверы (а bsd и притащена-то в макось ради драйверов) таки линуксные. В частности, и kms-драйвер амды ;-)и да, это современная амде - отдельный порт. А несовременная еще смешнее:
Copyright 2008 Red Hat Inc.
(rv770, к сожалению, сдохла она у меня, наконец)это, конечно, не весь ip stack, как, насколько я понимаю, по сей день в дарвине через фрю таскается, но тоже занятный такой момент - и вряд ли выпиленный яблом при портировании.
А, я понял про какой. Транслятор системных вызовов. Это прекрасная идея. :) Сильно упростило портирование драйверов и запуск неродного софта. Не зря Microsoft в десятке так же решили сделать. Да и не только они. Теперь бинарный слой совместимости делают все кому не лень. Только по модному, через контейнеры и виртуализацию.По мне linux начинается, когда делаешь kldload linux, всё остальное - всесильная фряха и порты.
Но и синергия - это тоже неплохо. Например, мне лично Docker пока не нужен, но возможности его использования на FreeBSD, пусть и экспериментальной, я рад. Это хорошо, если freebsd умеет делать то, что делают остальные системы, без особых напрягов. Главное, чтобы все эти навороты были опциональными и не включались, пока не попросят. :)
>Нет. FreeBSD не Unix. Unix это только то, что прошло сертификацию."Пекинская утка не Утка. Утка это только что прошло сертифкацию на Утку."
>> Единственный UNIX во всем рынке OpenSource-операционок.
> Нет. FreeBSD не Unix. Unix это только то, что прошло сертификацию.это мнение одного опеннетовского комментатора, стоящее ровно $0, как и он сам.
> Настоящие Unix™: Oracle Solaris, Apple macOS/OS, AIX и ряд других.
угу, а SystemV, SystemIII и System7 юниксами не являются, потому что никакую "сертификацию" не проходили (современый солярис, кстати, тоже).
Вот Ритчи-то удивится.
> FreeBSD не Unix и никогда им не будет, у этого сборища фриков
вот Ритчи-то с Томсоном были бы удивлены (они и были точно таким же "сборищем фриков")
> А единственной серверной платформе играющей серьезную роль в этом мире(ОС на базе
> ядра Linux) эта сертификация не нужна, потому что Linux давно закопалпотому что "новый стандарт" юниксом давно уже не является, и даже unix-like системой быть стремительно перестает - вафлянд, system-all-in-one-shit-d и case insensitive fs, ни разу, действительно, на юниксы не похожи.
> конкурентов.
его главный конкурент, вероятнее всего - винда. И нет, ему еще копать и копать.
> Напоминаю что Linux не UNIXЭто является большей проблемой для UNIX, чем для Linux. С каждым десятилетием UNIX всё больше и больше начинает вызывать ассоциации с окаменелостями.
> С каждым десятилетием
> UNIX всё больше и больше начинает вызывать ассоциации с окаменелостями.во времена всеобщего поклонения OS/2 - тоже так говорили.
Да и MS что-то подобное бухтела, правда, недолго, там еще Билл рулил, и он-то имел острый нюх.
> Единственный UNIX во всем рынке OpenSource-операционокВо-первых, нет, FreeBSD не UNIX. А во вторых, что вам с этого или того что был бы? Подтереться этим шильдиком?
> Напоминаю что Linux не UNIX а еще напоминаю что в Linux systemd в то время как в UNIX-FreeBSD никакого systemd нет
А лучше бы был вместо этих убогих rc скриптов.
У FreeBSD, впрочем, есть другие преимущества, поэтому только её и используем.
>Единственный UNIX во всем рынке OpenSource-операционок. Напоминаю что Linux не UNIX а еще напоминаю что в Linux systemd в то время как в UNIX-FreeBSD никакого systemd нетFreeBSD не имеет права назваться UNIX. BSD изначально был набором прикладного софта так же как GNU. Какие безграмотные люди.
>FreeBSD не имеет права назваться UNIX. BSD изначально был набором прикладного софта так же как GNU. Какие безграмотные люди.___ не имеет права назваться _____. ____ изначально был набором прикладного софта так же как ___.
Какие безграмотные люди.
Нужное вписать. Долго сраться о терминах.
Нет. BSD изначально была самодостаточной ОС - Ядро+окружение.
>Единственный UNIX во всем рынке OpenSource-операционокДважды по суду не юникс. Потом много кода переписывали.
> Потом много кода переписывали.Если не изменяет память, то не более 5%.
А оно надо, быть Юникс? Сами Керриган и Ритчи выпустили Plan9. Юникс - это тоже куча костылей, как и любая сложная система (почти)
Не, но это УНИХ, а УНАС?
Значительная часть ченджлога (я понимаю что это минорный релиз, но...) уже даже не пытается завуалировать тот факт, что какая-то возня еще не означает какой-то жизни...
>какая-то возня еще не означает какой-то жизни...ну просто свою жизнь описал.
Сразу видно что ты не в теме :)11.х и правда уже не жилец, туда только бэкпортируют что получается из 13, освновные силы по портированию на 12 брошены, ибо это сильно проще.
Но в 11.х всё ещё фиксят всякие страшные вещи, когда они находятся, не смотря на то, что фактически это двойная работа ибо кодовая база существенно (местами) отличается.Больше всего фишек у нас появляется при мажерной смене номера, те когда будет 13.0 - тогда будет много нового, что накопилось но не могло быть бэкпортировано в 12 и тем более в 11.
Но многие вещи бэкпортировать просто и это делают.
> В loader добавлена функциональность загрузчика zfsloader, который для загрузки с ZFS теперь не требуется;Ура! Неужели таки можно будет совсем обойтись без этой развалюхи-UFS2? Всё-таки ZoL я доверяю больше.
>Ура! Неужели таки можно будет совсем обойтись без этой развалюхи-UFS2?1 загружаться можно было и ранее с ZFS раздела
2 UFS2+snap+softupdate активно юзаем на виртуальных системах, хорошие показатели.
> UFS2+snapА как у них с производительностью?
Отличия в процентах, не принципиально.Проблемы намного больше с архитектурой прикладного софта и мудизме величия имени эффективных менеджеров.
> 2 UFS2+snap+softupdate активно юзаем на виртуальных системах, хорошие показатели."works as intended" и мертвый локап всей fs на момент выполнения снапа - отличный показатель, ага
----------
- Доктор, когда я вот так делаю, то у меня болит.
- А вы так не делайте
----------
ну вот я и не пользуюсь ufs2 - но и патчить вручную вечноломаемую zfs надоело.
И куды бечь - неясно.
>ну вот я и не пользуюсь ufs2 - но и патчить вручную вечноломаемую zfs надоело.не знаю, десятки систем, запустили и забыли. Не ломается, не патчим.
может тебе надо с кем-то поговорить?
> не знаю, десятки систем, запустили и забыли.ну может дело в том что у меня не стояло задачи "забыть" ;-)
> может тебе надо с кем-то поговорить?
спасибо, я с человеком, неимоверными усилями (не программистсткими, там десяток строк, а вот это вот "human relations") починившим _намертво_ сломанный в текущих версиях arc (то есть он совсем не работал, вообще) уже поговорил.
Велит ждать, пока у него найдется время починить другое место - а пока либо дидлок, либо вручную ограничивать размер arc (и при наличии свободной памяти, соответственно, она вместо использования под кэш просто не используется вообще). Старый патч к современным версиям не подходит, а я слишком плаваю в теме, чтобы самостоятельно распутать эту вермишель.Вероятно, в текущем проекте будет линух и ext4, тем более что на этом арме мне особенно стремно с zfs, ее ж небось вообще не тестируют с ним :-(
Да, чувак, тебе явно набо было с кем-то поговорить...
без нее можно было обойтись еще шесть лет назад.
А вот загрузку bootenv'ов этим улучшизмом сломали (не знаю, починили с тех пор или нет - неинтересно)
I ♥ FreeBSD
Когда перепишут на Rust?
> Когда перепишут на Rust?Когда вы соизволите переписать.
>В gzip добавлен флаг "-l" для поддержки формата xz;Наркоманы? Вообще то:
-l, --list list compressed file contentsКроме того нахрена xz в gzip??? Безумие. BSD.
Явно косяк составлятеля новости.
Ибо код говорит https://svnweb.freebsd.org/base/stable/11/usr.bin/gzip/gzip....1634 case FT_XZ:
1635 if (lflag) {
1636 maybe_warnx("no -l with xz files");
1637 goto lose;
1638 }
А точнее, косяк программера при описании изменений.https://svnweb.freebsd.org/base?view=revision&revision=343251
MFC r342845,342846: Port NetBSD improvements:
- Add -l support for xz files
- Add lzip support to gzip based on the example lzip decoder.
>>В gzip добавлен флаг "-l" для поддержки формата xz;
> Наркоманы? Вообще то:
> -l, --list list compressed file contentsНе торопитесь с суждениями, это издержки перевода
> Add -l support for xz filesт.е. поддежка опции -l для xz файлов.
«Добавлена поддержка NAT64 CLAT с реализацией работающего на стороне потребителя транслятора, преобразующего 1 к 1 внутренние IPv4 адреса в глобальные адреса IPv6 и наоборот;»
- типа такого есть под линукс? Без левых сервисов типа меридо
> «Добавлена поддержка NAT64 CLAT с реализацией работающего на стороне потребителя
> транслятора, преобразующего 1 к 1 внутренние IPv4 адреса в глобальные адреса
> IPv6 и наоборот;»
> - типа такого есть под линукс? Без левых сервисов типа меридоThere is a CLAT implementation for Android, Android CLAT. T-Mobile USA provides NAT64 with T-Mobile's IPv6-only service.[14][unreliable source?]
Orange Poland starts IPv6 only (CLAT/NAT64/DNS) service in September 2013.[15]
Android native CLAT implementation appeared in Jelly Bean 4.3.
Windows Phone native CLAT implementation in 2014 with WP 8.1.[16]
Windows 10 (Creators update) has a native 464XLAT implementation for desktop and mobile. It is enabled for WWAN interface when the Mobile Operator has enabled 464xlat on the network [17][18]
iOS 12.0 features a native CLAT implementation.[19] Additionally, Apple requires all apps submitted to the App Store to work on IPv6 networks.[20]
clatd is a CLAT implementation for Linux.А фря, как всегда, отстает на 10 лет от других и подбирает объедки с барского стола
Объедки - это скорее ZoL и DRM, а не родные имплементации. А так она просто внедряет фичи со скоростью сообразной их нужности, ничего плохого в этом нет.
ядерным линукс модулем пользуется не только дрм но некоторые дрова, например сетевух.
clatd. юзерспейсный. ага. прикопайте с tayga рядом.
>А _______, как всегда, отстает на 10 лет от других и подбирает объедки с барского стола-------
То что я не могу схавать: "подбирает объедки с барского стола"То на что хватило интеллекта заюзать: "наметился быстрый рост, появились новые интересные фичи"
--------
FreeBSD или Linux? Как веб сервер.
После прочтения https://vez.mrsk.me/freebsd-defaults.html желание что-то пропало.
Чувак захотел сразу что бы кто-то под него настроил.У меня типовые конфигурации лет по 10, c модификациями, кочуют от сервера к серверу.
> Чувак захотел сразу что бы кто-то под него настроил.нет, он просто захотел "как в линухе". И пусть себе туда и катится - с мнением что все что не как в линухе - "poor standard" и вообще "insecure". Особенно страшные и ужасные баги в сендмэйл двадцатилетней давности, на фоне open relay из коробки в каждом постфиксе и remote root в exim раз в неделю.
> После прочтения https://vez.mrsk.me/freebsd-defaults.html желание что-то пропало.Ух ты, та пафосная портянка в новом оформлении, с темным фоном и рамочками!
Ну, возьмем второй пункт:
> Mailer Daemon
> FreeBSD includes Sendmail in the base system and enables it by default.
> рассуждения о том, как плох sendmailТам нагнетается впечатление, что по умолчанию запускается готовый толстый мейлер, но:
% grep sendmail /etc/defaults/rc.conf
# Settings for /etc/rc.sendmail and /etc/rc.d/sendmail:
sendmail_enable="NO" # Run the sendmail inbound daemon (YES/NO).
sendmail_flags="-L sm-mta -bd -q30m" # Flags to sendmail (as a server)
sendmail_cert_create="YES" # Create a server certificate if none (YES/NO)
sendmail_submit_enable="YES" # Start a localhost-only MTA for mail submission
sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
# Flags for localhost-only MTA
sendmail_outbound_enable="YES" # Dequeue stuck mail (YES/NO).
sendmail_outbound_flags="-L sm-queue -q30m" # Flags to sendmail (outbound only)
А на самом деле запускается по умолчанию ровно то, что описано в мане:
> If the rc.conf sendmail_enable option is set to "NO", a sendmail daemon will still be started and bound only to the localhost interface in order to accept command line submitted mailДалее по списку идет
> Since I'm more familiar with PF, that's what I use. Unfortunately, the version of PF included with FreeBSD hasn't been synced with upstream since 2009. Do you want such a critical component of your OS (or network device) left largely unmaintained?То, что это форк, с другим развитием
> This implementation is derived from OpenBSD 4.5.
> It has been heavily modified to be capable of running in multithreaded FreeBSD kernel and scale its performance on multiple CPUs.и соотв. трудностями синка с апстримом автор то ли умалчивает, то ли вообще не знает.
"largely unmaintained"
hselasky Fri Jul 5 10:31:37 2019 +0000 MFC r349369: Convert all IPv4 and IPv6 multicast memberships into using a STAILQ instead of a linear array.
kp Fri Apr 26 13:00:22 2019 +0000 MFC r346349:
rgrimes Thu Apr 25 21:28:28 2019 +0000 MFC: r345888: Use IN_foo() macros from sys/netinet/in.h inplace of handcrafted code
kp Wed Apr 24 14:08:14 2019 +0000 MFC r346319:
kp Fri Mar 29 14:34:51 2019 +0000 MFC r345177:
kp Sat Mar 23 07:07:44 2019 +0000 MFC r345223:
kp Thu Mar 21 14:17:10 2019 +0000 MFC r345366:
kp Fri Mar 15 11:01:49 2019 +0000 MFC r344921:
kp Sun Mar 10 00:56:38 2019 +0000 pf: Small performance tweak
kp Sat Mar 9 10:28:36 2019 +0000 MFC r340073, r341359:
kp Fri Mar 1 18:12:05 2019 +0000 MFC r344691:
pkelsey Mon Feb 11 23:33:16 2019 +0000 MFC r343534: Don't re-evaluate ALTQ kernel configuration due to events on non-ALTQ interfaces
pkelsey Mon Feb 11 23:30:30 2019 +0000 MFC r343995: Reduce the time it takes the kernel to install a new PF config containing a large number of queues
kp Fri Feb 1 10:04:53 2019 +0000 MFC r343418:
kp Tue Jan 29 17:49:38 2019 +0000 MFC r343295:
kp Tue Jan 22 01:07:18 2019 +0000 MFC r343041
если брать год написания сего опуса:
marcel Sat Dec 10 03:31:38 2016 +0000 Improve upon r309394
glebius Fri Dec 9 18:00:45 2016 +0000 Backout accidentially leaked in r309746 not yet r
eviewed patch :(
glebius Fri Dec 9 17:59:15 2016 +0000 Use counter_ratecheck() in the ICMP rate limiting
.
kp Mon Dec 5 21:52:10 2016 +0000 pflog: Correctly initialise subrulenr
marcel Fri Dec 2 06:15:59 2016 +0000 Fix use-after-free bugs in pfsync(4)
kp Thu Oct 13 20:34:44 2016 +0000 pf: port extended DSCP support from OpenBSD
kp Tue Oct 4 19:35:14 2016 +0000 pf: remove fastroute tag
Т.е. по простонародному - вранье.Далее идет портянка о недостаточной секурности обновлений и портов и приводится возможность атаки с помощью подмены архива при скачивании и использовать уязвимости libarchiv (ничего похожего в пингвинах конечно же никогда не было, особенно не было в дебиане ))
И опять пафосное:
> These bugs and poor design choices have left FreeBSD users vulnerable to root-level compromise every time they update their system or ports tree. Think about that for a second.Как будто единственная возможность запустить portsnap из под рута.
А то, что обновлять порты можно через svn/git, что еще и удобнее - скромно умалчивается.> So how many of these actually need to be done as root? Only the last one. And how many of these are done as root by default in FreeBSD? All of them.
Тут и далее вообще непонятные претензии - билд софта, видите ли, можно запускать из под рута да еще и на хосте. Подписанные пакеты скачиваются не по секурному HTTPS.
> Swap
> I think swap should always be encrypted. FreeBSD developers disagree.
> Now here's the same thing with the swap automatically encrypted:
> # Device Mountpoint FStype Options Dump Pass#
> /dev/ada0p3.eli none swap sw 0 0
> All you need to do is add ".eli" to the device name. A one-time key will be generated and destroyed when swap is unmounted, so the swap contents should be unrecoverable. If you had unencrypted swap previously, consider using dd to write random data over it before encrypting.Придирка на ровном месте - это вот так. Свап видите ли не зашифрован по умолчанию злобными разработчиками.
А то, что шифрование включается добавлением .eli (это подразумевает подгрузку модуля, монтирование) совсем не магией, а из-за реализованой как раз разработчиками поддержки ...
Да никто же не спорит что дефолты странные.
Хочешь, юзай мои дефолты:
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/1.../
+
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/1.../
или
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/1.../рсинком это накатывается так:
rsync -caEW --inplace --ignore-errors --force --numeric-ids -hiv --stats rsync://www.netlab.linkpc.net:873/os-cfg/FBSD/12.0/base/ / (аналогично для srv и wks)
только перечитай содержимое и осознай перед использованием, а то после первой пересборки системы у тебя 100% шанс туда попасть только через консоль :)
(ибо ссш выпиливается из системы, дрова сетевух нужно прописывать на загрузку самому, rc.conf перетрётся ибо нужно сначало переименовать его в rc.conf.machine и мож ещё какие то чудеса)
FreeBSD будет работать пока жёсткий диск не развалится.
+1
У меня неделю работало с отвалившимся рутом. Запустило виртуалки (на другом пуле), а рутовый и отвалился. Трогать до выходных боялся :)
в кривых руках всё развалится
Уж тебе ли не знать...
+1
Мне и на десктопе с фрей хорошо живётся, и медиплеер у меня на фре.
Кеды патчите?)
Уже все давно пропатченно.
Нет, у меня xfce4, из него кой чего патчу.
11.2>> В утилите zfsd появилась возможность работы с любыми типами провайдеров GEOM, включая md, geli, glabel и gstripe;
11.3>> В ZFS добавлена поддержка параллельного монтирования сразу нескольких разделов ФС;
11.3>> В загрузчике реализована возможность шифрования разделов при помощи geli на всех поддерживаемых архитектурах;
12.0>> В инсталлятор bsdinstall и загрузчик zfsboot добавлена поддержка установки и загрузки с использованием связки UEFI+GELI (шифрованные разделы на системах с UEFI);Вот это всё на фоне того что они хотят пересесть на ZoL как-то странновато смотрится. В то же время нормальное нативное шифрование поддержать ну прям никак, раз продолжают своё пилить. Груздь
11.2>> В утилите zfsd появилась возможность работы с любыми типами провайдеров GEOM, включая md, geli, glabel и gstripe;zfsd нужна крайне малому числу специальных людей, а уж с geli и подавно.
11.3>> В ZFS добавлена поддержка параллельного монтирования сразу нескольких разделов ФС;
поздравляем, сломали кросс-маунты с нескольких пулов. К счастью, пока эту глупость еще можно выключить.
12.0>> В инсталлятор bsdinstall и загрузчик zfsboot добавлена поддержка установки и загрузки с использованием связки UEFI+GELI (шифрованные разделы на системах с UEFI);
но поскольку secureboot не поддерживается, пользы от этого зверя - никакой. (пошифровать все кроме критичных для загрузки частей ты и раньше мог)
> Вот это всё на фоне того что они хотят пересесть на ZoL как-то странновато смотрится.
а если посмотреть на то что на самом деле там происходит под капотом, а не на мелкие внешние улучшизмы - то совершенно не странно. Но страшно за данные, если они представляют хоть какую-то ценность. Впрочем, большая часть ZoLовского трэша и так уже вмержена - просто с промежуточной остановкой в иллюмосе.
>а если посмотреть на то что на самом деле там происходит под капотом, а не на мелкие внешние улучшизмы - то
> совершенно не странно. Но страшно за данные, если они представляют хоть какую-то ценность. Впрочем,
> большая часть ZoLовского трэша и так уже вмержена - просто с промежуточной остановкой в иллюмосе.Чо, все так плохо?
Только-только перетащили последний сервак из дальнего чулана на zfs, а тут какие-то недобрые предзнаменования...
И за что минус к посту? За то, что спросил, каковы перспективы zfs во фре?
Нет, мне абсолютно параллельно здешнее плюсодрочерство, обмазывайте вашими плюсами и минусами до полного самоудовлетворения, но иногда хочется понять логику одноклеточных организмов...
> Чо, все так плохо?поищи здесь же поиском по zfs/zol
все, как бы это сказать...нехорошо. Код бедняги переписывают-переписывают, и уже совсем что-то непохожее на исходник от sun'а написали, причем внешне (по измерениям и вообще впечатлению от использования) лучше работать оно совершенно вот не стает, а регрессов множество и лишь часть из них какими-то совершенно титаническими усилиями иногда удается откатить.
Причем куды бечь - совершенно непонятно.
То "works as intended", то уже почти но еще немного уже совсем готовое для продакшн.
При этом редхат вложила неимоверное количество денег [ibm] в xfs+lvm-thin+bcache - и оно в принципе даже и работает, а про детали реализации лучше просто ничего уже и не знать.
В тыкву превращается? Ну так кто ее эту тыкву видел-то, и не полтора десятилетия назад? А вот тыкву из zfs вполне себе видели недавно. Как и реакцию разработчиков - "as intended".
> все, как бы это сказать...нехорошо. Код бедняги переписывают-переписывают,Мда.
> Причем куды бечь - совершенно непонятно.
Да на фре-то как раз понятно, там особо и вариантов нет, так что назад, на ufs. Но уж больно привыкли к вкусностям zfs. Хоть и прожорлива, зараза. Жалко будет, если испоганят.
> Да на фре-то как раз понятно, там особо и вариантов нетчем фря-то и хороша, что "новый стандарт" не изображает, и все то же самое можно быстро перенести на что угодно. Но вот на что? illumos труп, closedSolaris стоит неадекватных денег и ты целиком зависим от их поддержки (потому что нет толком community и нет возможности починить самому), об "новый стандарт" мараться неохота. А больше, собственно, уже и нет никого живого.
ну и вот из чего хранилку-то делать? На винде - так я не умею :-(
> Хоть и прожорлива, зараза.
это urban legend.
last pid: 89963; load averages: 0.58, 0.55, 0.47 up 408+15:04:00 15:45:20
23 processes: 1 running, 22 sleeping
CPU: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle
Mem: 3236K Active, 30M Inact, 732M Wired, 215M Free
ARC: 375M Total, 80M MFU, 178M MRU, 3104K Anon, 1700K Header, 112M Other
Swap: 1024M Total, 44M Used, 980M Free, 4% Inuse
(машина одноядерная, поэтому для нее это адекватная нагрузка)ну да, она тут патченная, иначе был бы arc 850 (лимитов нет) и вставание всего колом, когда запустится какой-нибудь периодический прожорливый индексатор.
Если же использовать ее не как fs общего назначения, а для nas/san - памяти придется отсыпать, ну так альтернативы тоже небесплатные.
Я более того скажу. С дефолтными настройками.last pid: 72253; load averages: 1.05, 1.02, 0.88 up 7+00:29:38 16:05:26
59 processes: 1 running, 58 sleeping
CPU: 0.3% user, 0.0% nice, 0.3% system, 0.1% interrupt, 99.3% idle
Mem: 44M Active, 218M Inact, 48M Laundry, 536M Wired, 108M Free
ARC: 233M Total, 65M MFU, 49M MRU, 32K Anon, 2616K Header, 115M Other
27M Compressed, 98M Uncompressed, 3.67:1 Ratio
Swap: 2048M Total, 2048M Free
> Я более того скажу. С дефолтными настройками.с дефолтными у тебя тут будут неприятности, если что-то все же потребует себе память.
Включая, возможно (в зависимости от версии и особенностей железа) и мертвое повисание. При том что в свопе в этот момент могут быть (и скорее всего окажутся) пусты все 2 гигабайта.Ну и эффективность этого явления (arc почти отсутствует, а zfs хранит довольно много метаданных) тоже, скорее всего, окажется неприлично низкой, если только у тебя процессор не резко отличается в лучшую сторону от прочих параметров (у приведенной мной конфигурации - не, он виртуальный и одноядерный) - тогда при таком ratio возможно ты и выедешь за счет компрессии, у меня активные данные малосжимаемы (а /usr/src даром не сдались на таком корыте).
Если процессор тоже что-то дохлое типа древнего arm - то побочные эффекты (не сам lz4, а реализация механизма) превысят экономию.
Проблем там не наблюдал. Впрочем, как и нагрузки особенной.
Тоже VPS 1 CPU правда RAM 1 Gb.
> Проблем там не наблюдал. Впрочем, как и нагрузки особенной.
> Тоже VPS 1 CPU правда RAM 1 Gb.ну вот это корыто - справлялось с make -j2 buildworld (больше 2 не влезет, zfs не виновата)
arc в процессе пару раз отрастет под 800мег из такого же гигабайта, и будет отожран обратно при сборке libllvm, которой нужно 600. Как он и должен работать by design - есть лишняя память -
занимаем всю под кэш. Понадобилась user приложению - освобождаем.
Без патчей (один из которых чудовищно кривой) ты так не сможешь, к тому же эти 800 у тебя не влезут в гигабайт (чудо математики объясняется тем, что top не в курсе некоторых модных веяний, во всяком случае, в 11й, и меряет не все потребление. vfs.zfs.arc_max о нем, если что, тоже не в курсе - полезешь ручками ковырять, вычитай из него 200мегабайт на такой системе. В дефолтных настройках 11й уже вычтено ;)
> Код бедняги переписывают-переписывают, и уже совсем что-то непохожее на исходник от sun'а написалиПри этом Matt Ahrens, один из основателей и архитекторов той самой сановской оригинальной ZFS, поддерживает объединение усилий и консолидацию под ZoL, ну и типа не бойтесь названия, её просто еще не успели переименовать в OpenZFS. Старая OpenZFS as we wanted долго тужилась, но так и не взлетела, увы.
> При этом Matt Ahrens, один из основателей и архитекторов той самой сановской оригинальной ZFS,
> поддерживает объединение усилий и консолидацию под ZoLну так он и против abd'шной мерзости ничего не имел, и в тредике про поломанный (тоже одним из великих основателей, архитекторов и тд, переставшим резко после этого отвечать на письма) нахрен arc отметился - скромно его проигнорив - и т д.
Угадаешь, почему?
Правильно: раньше над ними с палкой стояли менеджеры сана - и если у клиентов оно начинало тормозить - этой самой палкой давали по горбу. (ну и, вероятнее всего, были и препродакшн-тесты на реальных железках и близких к реальным задачах, а не только юнит-тесты)
А сейчас им платит - дельфикс, которому чем быстрее сдохнет конкурент в виде freebsd со своей независимой и в виду архитектурных отличий - лучшей реализацией - тем лучше, и который уже всерьез посматривает на линух в качестве единственно-верной платформы.
https://reviews.freebsd.org/D19094
обратите внимание на реакцию "основателей и архитекторов".
> Правильно: раньше над ними с палкой стояли менеджеры сана - и если
> у клиентов оно начинало тормозить - этой самой палкой давали по
> горбу. (ну и, вероятнее всего, были и препродакшн-тесты на реальных железках
> и близких к реальным задачах, а не только юнит-тесты)При этом, вряд ли отец-основателсь желал бы, чтобы его детище загубили.
> https://reviews.freebsd.org/D19094
> обратите внимание на реакцию "основателей и архитекторов".Что-то не увидел реакции, ну и вообще, если Ольховченков доволен, значит Гапон и Мотин пока всё правильно делают, или родина таки вопасносте? :)
торренты: https://linuxtracker.org/index.php?page=torrents&category=190
Кстати, шотам с launchd? Скоро запилят?
Какой launchd? Они же решили nosh втащить, ибо от скриптов избавляться не хотят.
> Какой launchd? Они же решили nosh втащить, ибо от скриптов избавляться не
> хотят.Кто "они"? Анонимы опеннета?
А то автор на него подзабил, порта на фрю как не было так и нет, prebuild-binary есть для десяточки, которая еще в прошлом году достигла EOL. Отсутствующий репозиторий с кодом и очень экзотичная система сборки тоже не очень способствуют продвижению.
Хотя уже один
> view a list of the packages in the repository via GOPHER or via FTP in EPLF.намекает как бы, на некоторую эксцентричность.
> ибо от скриптов избавляться не хотят
Ох уж енти всезнающие анонимные эксперты …
https://jdebp.eu/Softwares/nosh/worked-example.html
## **************************************************************************
## For copyright and licensing terms, see the file named COPYING.
## **************************************************************************[Unit]
Description=BSD NTP daemon[Service]
systemdWorkingDirectory=false
ExecStart=ntpd -n -g -f /var/db/ntpd.drift
Restart=always
StandardError=inherit[Install]
WantedBy=workstation.target
Смотрю есть версия 11.3, 12.0 и 13.0
объясните пожалуйста в чём разница?
никогда не юзал фряху, хочу попробовать на виртуалочке
> Смотрю есть версия 11.3, 12.0 и 13.0
> объясните пожалуйста в чём разница?
> никогда не юзал фряху, хочу попробовать на виртуалочкетогда тебе пофиг, любую бери. Раз ты не сумел прочитать даже страничку "supported releases" - можешь хоть 13ю. (если вдруг не загружается, что, впрочем, весьма маловероятно, просто возьми предыдущую)
P.S. учти что виртуалки они собирают задницей, поэтому скачивай iso/memstick и ставься как на физическую машину. Кроме qemu - там, скорее всего, все из коробки работает.
Если спросил значит не пофиг, если бы хотел поискать инфу сам - поискал бы. Но я захотел просто спросить. Общение никто не отменял ещё на сколько я знаю раз тут коменты доступны.
На виртуалку я и хотел устанавливать вручную, а не качать готовый образ для виртуалки.
Вы так и не объяснили в чём разница!?
Стабильная, актуальная, бета? в таком порядке - или как?
> Если спросил значит не пофигкак тебе может быть не пофиг, если ты ничего о системе не знаешь - даже вот особенностей нумерации?
ну примерно так, да. Но из-за особенностей release management тебе этим париться не надо, можно ставить любой.
Суть проблемы в том, что на самом деле этими версиями те, кому как раз не пофигу, пользуются только чтоб было с чего поставить. Но это длинная история, а для начального знакомства совершенно и излишняя.
У разных веток - разный ABI, все время что-то оптимизируют, добавляют, выкидывают. Периодически накапливается критическая масса, требующая отказа от обратной совместимости - все эти изменения загоняют в новую ветку. Обычно к этому процессу привязывают внедрение прочих новшеств, просто потому, что на новом ABI их пилить легче. То, что можно запилить на старых ABI - портируют в поддерживаемые предыдущие ветки.С точки зрения нуба все ветки одинаковы, потому что нет необходимости апгрейдить систему и юзерленд.
С чисто практической т.зр. 11-я уже приближается к ЕОЛ, и необходимость делать мажорный апгрейд наступит раньше, чем для 12-й, где можно хоть раз в неделю делать freebsd-update fetch install. 13-я пока в девелопе, полуфабрикат, и ее ставить для нуба нерационально.В общем, брать последний продакшн-релиз (12.0) и не париться. Качать ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/12.0/F...
и ставить из сети.
> С точки зрения нуба все ветки одинаковы, потому что нет необходимости апгрейдить
> систему и юзерленд.
> С чисто практической т.зр. 11-я уже приближается к ЕОЛ, и необходимость делать
> мажорный апгрейд наступит раньше, чем для 12-й, где можно хоть разс точки зрения нуба это однохренственно. Но 12я именно сейчас в состоянии .0, поэтому никаких явных для нуба преимуществ перед любым снапом 13 не имеет. Можно подождать .1, но нет смысла.
> в неделю делать freebsd-update fetch install. 13-я пока в девелопе, полуфабрикат,
ничего не мешает то же самое делать между major releases.
Полуфабрикат они - все, нет у фри давно ни ресурсов, ни желания нормально сопровождать релизы, да и не было никогда. В 13й при этом баги быстро исправляют, это ж у самого разработчика оно падает или глючит, ему абыдна, да.> и ее ставить для нуба нерационально.
пока он перестанет быть нубом - половину этого втащат в 12ю, а о второй половине любители обмазаться свежайшим будут грустно скулить.
а для работы все равно нужно разбираться с releng, и с конкретным состоянием конкретных нужных для работы подсистем в каждой ветке.
>Полуфабрикат они - все, нет у фри давно ни ресурсов, ни желания нормально сопровождать релизы, да и не было никогда.Чувак, ты напиши в саппорт FreeBSD, тебе сразу вернут деньги за него.
> 12я именно сейчас в состоянии .0, поэтому никаких явных для нуба преимуществ перед любым снапом 13 не имеет.Угу, зато имеет явный недостаток в виде "can't find '/boot/entropy'" на некотором железе - иногда прямо на этапе загрузки с флэхи/CD
Так что или 11.3, или 13.
>> 12я именно сейчас в состоянии .0, поэтому никаких явных для нуба преимуществ перед любым снапом 13 не имеет.
> Угу, зато имеет явный недостаток в виде "can't find '/boot/entropy'" на некоторомну вот, собственно, о таких вещах и речь. А начинающему голову уже заморочили.
> Но 12я именно сейчас в состоянии .0, поэтому никаких явных для нуба преимуществ
> перед любым снапом 13 не имеет. Можно подождать .1, но нет смысла.Вообще-то, 12-я сейчас в состоянии 12.0-p10, и от грядущей 12.1 отличается максимум парой-тройкой бинарных патчей. Так что тут мимо кассы. 13-я же в состоянии каррента, а значит нубу вместо пакетов придется сходу ломиться в порты. Учитывая, сколько депенденсей потянут за собой иксы и какие-нибудь кеды, нуб ошалеет раньше, чем все это скомпилируется. А сверху толстым-толстым слоем лягут косяки девелоперской версии и отладочная бахрома, которая шустрости процессу никак не добавит.
Если нуб - значит пакеты. Если пакеты - значит только релизы с бинари патчами. Из самого свежего - 12.0, за 5 минут докатываемая до 12.0.10, затем безболезненно минорно апгрейдящаяся до 12.1. Советовать же человеку сходу насаживаться на неструганую альфу - это ну ни разу не серьезно.
> Вообще-то, 12-я сейчас в состоянии 12.0-p10,Угу, только вот незадача - в образе она по-прежнему в состоянии 12.0, а в этом состоянии она, случается, виснет намертво на самом начале загрузки...
>> Вообще-то, 12-я сейчас в состоянии 12.0-p10,
> Угу, только вот незадача - в образе она по-прежнему в состоянии 12.0,
> а в этом состоянии она, случается, виснет намертво на самом начале
> загрузки...Если у человека 12-ка зависнет при запуске, я думаю, он не облезет, если качнет еще 300 метров образа 11.3. Не знаю, как у вас, а у нас энторнет достаточно дешев и быстр, чтобы не терзаться страданиями от того, что негодящий образ был выбран. Но мне, почему-то, кажется, что у нашего собеседника все пройдет без малейших проблем. Я ставил 12-ю на бареметал, на виртуалки, на интель, амд и арм, на вмваре и квм - и ни разу ничего фатального не наблюдал.
Может быть дело в позитивном настрое?
Спасибо большое за такое развёрнутый и понятный ответ.
Буду пробовать :)
Поздравляем демонят.
Это точно опеннет?)
