Как перенести место хранения логов journalctl из /var/log

Игнорируй это. Все оставшиеся разделы размонтируются systemd-shutdown'ом после убийства всех процессов.

Игнорируй это.

вся суть systemd - игнорируй ошибки и некорректное поведение, представляй себе что все работает. норм.

Тебе посраться захотелось? Здесь нет ошибок и некорректного поведения. Это штатная ситуация — все ФС, которые не получилось отмонтировать в ходе основного шатдауна (после завершения основной части процессов), отмонтируются после убийства всех оставшихся процессов. Легаси-инитскрипты имеют точно такое же поведение.

что корректного в том чтобы пытаться размонтировать фс, которая используется? или использовать фс, которую нужно размонтировать? старые инит скрипты были недостаточно умными чтобы с этим разобраться, а новые системы слишком умные для этого.

О, рабы systemd...

т. к. его до последнего насилует journalctl.

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

Кстати этот «журналист» хренов может и загрузке мешать, роняя машину в бесконечный цикл, из которого ни загрузиться, ни в консоль прныгнуть, ни заказать отключение.

А лучше переходи например на слаку. Здесь этого гемороя и близко нет. И не будет. А этот гребаный systemd всю оставшуюся дорогу будет источником гемороя, и чем дальше тем больше. Еще пару лет, полностью заростет все автоматикой, и будете как винде — все вопросы решать ПЕРЕУСТАНОВКОЙ.

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

Они были недостаточно умные чтобы создавать проблемы, которые пользователю можно было бы героически решить, на радость маме и на гордость папе.

а новые системы слишком умные для этого.

Кстати да. unit'ы systemd по сути представляют из себя скрипты. Только очень мелко нарезанные и раскиданные по всей системе. Это называется, как я недавно узнал «обфускация». Тоесть запутывание с целью усложения анализа. Делается все для того чтобы пользователь был беспомощен в системе, чтобы системой могла управлять ТОЛЬКО автоматика systemd. Тоесть делается все чтобы systemd стал НЕЗАМЕНИМЫМ. Это узурпация системы. Это техногенно-маркетинговое рейдерство на проект GNU/Linux

скрипты. Только очень мелко нарезанные и раскиданные по всей системе

Ты как будто не ковырялся в init скриптах RedHat или SUSE до перехода на systemd. Вот там была «обфускация». Но ты, вижу, любитель slackware, а там да, всё централизовано и без лишней автоматизации вперёд настройки.

Ты как будто не ковырялся в init скриптах RedHat или SUSE до перехода на systemd

Так ведь именно эти корпорации продвигают systemd. Не удивительно что они изуродовали systmV, чтобы убедить в необходимости systemd. А хомячье и повелось, стало жрать то чем кормят, вместо того чтобы просто выбрать необфусцированные дистрибутивы. Да действительно в слаквари все централизовано и просто. Вот смотри /etc/rc.d

init.d
rc.0
rc.4
rc.6
rc.K
rc.M
rc.S
rc.acpid
rc.alsa
rc.alsa-oss
rc.atalk
rc.autofs
rc.avahidaemon
rc.avahidnsconfd
rc.bind
rc.bluetooth
rc.cgconfig
rc.cgred
rc.consolekit
rc.cups
rc.dictd
rc.dnsmasq
rc.font
rc.fuse
rc.gpm
rc.httpd
rc.inet1
rc.inet1.conf
rc.inet2
rc.inetd
rc.ip_forward
rc.keymap
rc.local
rc.loop
rc.mcelog
rc.messagebus
rc.modules
rc.modules-3.10.104
rc.modules-3.10.104-smp
rc.modules-3.10.17
rc.modules-3.10.17-smp
rc.mysqld
rc.networkmanager
rc.nfsd
rc.ntpd
rc.pcmcia
rc.php-fpm
rc.php-fpm.orig
rc.rpc
rc.samba
rc.samba.orig
rc.saslauthd
rc.sendmail
rc.serial
rc.snmpd
rc.sshd
rc.syslog
rc.sysstat
rc.sysvinit
rc.udev
rc.ulogd
rc.wireless
rc.wireless.conf
rc.yp
rc0.d
rc1.d
rc2.d
rc3.d
rc4.d
rc5.d
rc6.d

вперёд настройки.

А что страшного? Еще для примера покажу как настраивается интернет. Ровно ЧЕТЫРЕ строки в файле настройки. rc.inet1.conf:

# /etc/rc.d/rc.inet1.conf
#
# This file contains the configuration settings for network interfaces.
# If USE_DHCP[interface] is set to "yes", this overrides any other settings.
# If you don't have an interface, leave the settings null ("").

# You can configure network interfaces other than eth0,eth1... by setting
# IFNAME[interface] to the interface's name. If IFNAME[interface] is unset
# or empty, it is assumed you're configuring eth<interface>.

# Several other parameters are available, the end of this file contains a
# comprehensive set of examples.

# =============================================================================
#ВОТ ЗДЕСЬ РЕЛЬНО ВСЕ НАСТРАИВАЕТСЯ
# Config information for eth0:
IPADDR[0]="192.168.1.2"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""
#ВОТ И ВСЯ НАСТРОЙКА. ОСТАЛЬНОЕ -- ПРИМЕРЫ И ИНСТРУКЦИИ ЧТОБЫ НЕ ЛАЗИТЬ В ГУГЛ

# Config information for eth1:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""

# Config information for eth2:
IPADDR[2]=""
NETMASK[2]=""
USE_DHCP[2]=""
DHCP_HOSTNAME[2]=""

# Config information for eth3:
IPADDR[3]=""
NETMASK[3]=""
USE_DHCP[3]=""
DHCP_HOSTNAME[3]=""

# Default gateway IP address:
GATEWAY="192.168.1.1"

# Change this to "yes" for debugging output to stdout.  Unfortunately,
# /sbin/hotplug seems to disable stdout so you'll only see debugging output
# when rc.inet1 is called directly.
DEBUG_ETH_UP="no"

# Example of how to configure a bridge:
# Note the added "BRNICS" variable which contains a space-separated list
# of the physical network interfaces you want to add to the bridge.
#IFNAME[0]="br0"
#BRNICS[0]="eth0"
#IPADDR[0]="192.168.0.1"
#NETMASK[0]="255.255.255.0"
#USE_DHCP[0]=""
#DHCP_HOSTNAME[0]=""

## Example config information for wlan0.  Uncomment the lines you need and fill
## in your info.  (You may not need all of these for your wireless network)
#IFNAME[4]="wlan0"
#IPADDR[4]=""
#NETMASK[4]=""
#USE_DHCP[4]="yes"
#DHCP_HOSTNAME[4]="icculus-wireless"
#DHCP_KEEPRESOLV[4]="yes"
#DHCP_KEEPNTP[4]="yes"
#DHCP_KEEPGW[4]="yes"
#DHCP_IPADDR[4]=""
#WLAN_ESSID[4]=BARRIER05
#WLAN_MODE[4]=Managed
##WLAN_RATE[4]="54M auto"
##WLAN_CHANNEL[4]="auto"
##WLAN_KEY[4]="D5AD1F04ACF048EC2D0B1C80C7"
##WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=96389dc66eaf7e6efd5b5523ae43c7925ff4df2f8b7099495192d44a774fda16"
#WLAN_WPA[4]="wpa_supplicant"
#WLAN_WPADRIVER[4]="ndiswrapper"

## Some examples of additional network parameters that you can use.
## Config information for wlan0:
#IFNAME[4]="wlan0"              # Use a different interface name instead of
                                # the default 'eth4'
#HWADDR[4]="00:01:23:45:67:89"  # Overrule the card's hardware MAC address
#MTU[4]=""                      # The default MTU is 1500, but you might need
                                # 1360 when you use NAT'ed IPSec traffic.
#DHCP_KEEPRESOLV[4]="yes"       # If you don't want /etc/resolv.conf overwritten
#DHCP_KEEPNTP[4]="yes"          # If you don't want ntp.conf overwritten
#DHCP_KEEPGW[4]="yes"           # If you don't want the DHCP server to change
                                # your default gateway
#DHCP_IPADDR[4]=""              # Request a specific IP address from the DHCP
                                # server
#WLAN_ESSID[4]=DARKSTAR         # Here, you can override _any_ parameter
                                # defined in rc.wireless.conf, by prepending
                                # 'WLAN_' to the parameter's name. Useful for
                                # those with multiple wireless interfaces.
#WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=thekey"
                                # Some drivers require a private ioctl to be
                                # set through the iwpriv command. If more than
                                # one is required, you can place them in the
                                # IWPRIV parameter (separated with the pipe (|)
                                # character, see the example).

Ну разве не приятно? Разве не просто?

У слаки bsd init

В вашем примере:
1. Не четыре, а три
2. Комментарии неверно расставили, gateway забыли

Там sysvinit, кукаретик. Просто скрипты изуродованы как относительно sysv, так и относительно BSD.

Ты уверен, что в /var/log пишёт именно journald? Обычно логи journald бинарные, а уже потом он форвардит их в обычный rsyslog, который перенестраивай как хочешь

Ну и всё правильно сказали, игнорируй эти предупреждения, штатное поведение. Переносить логи из /var/log куда-либо гораздо больший костыль

Ровно ЧЕТЫРЕ строки в файле настройки. rc.inet1.conf

И чего тут особенного?

# cat /etc/systemd/network/00-default.network
[Network]
Address=192.168.1.1/24
Gateway=192.168.1.254
DNS=192.168.1.254

Можно я тоже в сраче поучаствую? :)

$ cat /etc/systemd/network/eth.network
[Match]
Name=eth*
[Network]
DHCP=yes

Если в /etc/systemd/journald.conf прописано Storage=persistent, то пишет сразу в /var/log/journal

По карйней мере в мане так:

Storage=
           Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored
           only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on
           disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if
           needed), during early boot and if the disk is not writable.  "auto" is similar to "persistent" but the directory /var/log/journal is not
           created if needed, so that its existence controls where log data goes.  "none" turns off all storage, all log data received will be dropped.
           Forwarding to other targets, such as the console, the kernel log buffer or a syslog daemon will still work however. Defaults to "auto".

Вы слишком добрые, используете типичные конфиги, которые везде одинаково просто делаются. Попросили бы его изобразить туннель какой.

Попросили бы его изобразить туннель какой.

Сферический и в вакууме? Так он не так уж часто и востребован. А если про vpn-ы так и тут конфиги одинаковые у всех.
Вообще спорить на эту тему можно долго, что проще: поправить скрипты которые все в одном месте или конфиги которые разбросаны.
В тему разбросанных конфигов, если требуемое в них не предусмотрено, как писали выше, ошизееш искать нужный скрипт. Где-то с год назад в копейкооси мне потребовался нестандарт, я офигель во что превратили эту кучу скриптов (давно я достаточно плотно сидел на шапке, там такого бардака еще не было)

Особенное то, что люди уже забыли зачем нужен NetworkManager. И кастают на лупбек /interfaces, где NM настроен ВРУЧНУЮ, хотя именно его назначение — автоматизция настройки сети, причем как раз для случаев когда конфик часто меняется, когда интерфейсов много и тд и тп. Тоесть когда действительно влом один раз вручную настроить. А здесь, цени, ВРУЧНУЮ предлагается настраивать мастер автоматизации. Понимаешь о чем я? Походу бытует представление, что NetworkManager действительно нужен для обеспечения сети.

У слаки bsd init

Если быть точнее bsd-style. Я слышал об этом, но в принципе не заостряю внимание. Главное что не бацилаД. Да и речь выше шла о сюзе с красной шляпой (Бог мой, на русском это название звучит... Ох как выразительно, как подходяще)

NetworkManager рулит на десктопе/лэптопе, где требуется динамика, интерактивность и интеграция с рабочей средой и приложениями.
systemd-networkd удобен для серверов и контейнеров, когда вышеперечисленного не требуется и оптимально иметь минимум зависимостей.
Каждый используется по назначению на своём месте.

Судя по топику не рулит он ни разу. Для динамики кстати существует mapping в /interfaces. Мне он не нужен, поэтому не разбирался особо. Но суть в том что там по различным признакам определяется контекст ситуации и выбирается соответствующий комплекс настроек. Например может прочекаться сеть и по наличию определенного узла определиться, что ноут на работе а не дома.

Но это же все надо читать, верно? Нужно же овладеть напильником, да? Это же тяжело? Легче доверить напильник ручной обезьянке и надеяться что она всегда справится, правильно я говорю?

Это неправильно. Ворнинги и ошибки свидетельствуют, что что-то пошло не так. Это нужно фиксить или добавить обработку поведения в таких ситуациях, но не игнорировать.

Судя по топику

Не нужно равняться на лузеров и неосиляторов.

Но это же все надо читать, верно? Нужно же овладеть напильником, да?

Правильно, причём это касается и NetworkManager и systemd-networkd.

Это неправильно. Ворнинги и ошибки свидетельствуют

Как ты посмел кинуть тень на божественное системд? Да ты просто хейтер!

Правильно, причём это касается и NetworkManager и systemd-networkd.

А вот здесь ты не прав. Если средства автоматизации не справляются с автоматизацией то нахер они нужны? Очевидно все-таки легче час потерять но за пять минут долететь самому, разобравшись с ручными настройками.

не справляются с автоматизацией

УМВР, ЧЯДНТ?

ЧЯДНТ?

Не пробуешь вникунть в абсурд ситуации.

Не нужно равняться на лузеров и неосиляторов.

Как это не нужно если именно для «неосиляторов» и созданы средства автоматизации? Именно на них и нужно равняться. Если им «неосиляторам» костыли не помогают, а осиляторы и без костылей справляются, то кому нужны костыли?

Я понял откуда между нами недоразумение. Я отвечал в эту тему по ссылке из списка уведомлений, по контексту холивора решив что это уведомления по другой теме — «поломалась сеть после обновления». Сейчас только заметил что тема не та ^_^

Суть в том что там у человека гавкнул NetworkManager, и кто-то ему посоветовал «настроить его вручную». В общем тоже о сети речь пошла и это здесь меня ввело в заблуждение.

Нет, я пользусь systemd. И даже отправляю баг-репорты.

Верно. Это легко исправляется вручную (дописыванием недостающей зависимости), но она нужна условно (в зависимости от того, куда journald пишет логи), а механизма условного изменения юнитов в systemd нет и не будет, т. к. это излишнее усложнение слишком важного механизма. Если кому-то зудит, тот может дописать соответствующую зависимость вручную.

Гипотетически, можно дописать логику в journald, чтобы он при своём запуске создавал соответствующий drop-in в /run в зависимости от того, куда пишет логи.