useful commands - yar145/mytestrepo1 GitHub Wiki
obtain a list of deleted files which are still held open by applications:
lsof | egrep "deleted|COMMAND"
https://access.redhat.com/solutions/2316
systemd
How to automatically restart Linux services with Systemd
[Unit] StartLimitIntervalSec=300 StartLimitBurst=5
[Service] Restart=on-failure RestartSec=1s
$ sudo systemctl daemon-reload
[Set up self-healing services with systemd](Set up self-healing services with systemd)
Использование таймеров systemd вместо заданий cron
Использование таймеров systemd вместо заданий cron
systemctl status *timer
Создадим unit-файл с именем myMonitor.service в папке /etc/systemd/system. Он не обязательно должен быть исполняемым.
[Unit] Description=Logs system statistics to the systemd journal Wants=myMonitor.timer
[Service] Type=oneshot ExecStart=/usr/bin/free
[Install] WantedBy=multi-user.target
Этот файл, пожалуй, можно назвать простейшим файлом конфигурации сервиса. Теперь давайте проверим его состояние и протестируем его для того чтобы убедиться в том, что он работает так, как ожидается.
[root@testvm1 system]# systemctl status myMonitor.service ● myMonitor.service - Logs system statistics to the systemd journal Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled) Active: inactive (dead) [root@testvm1 system]# systemctl start myMonitor.service [root@testvm1 system]#
А почему ничего не выводится в консоль? Дело в том, что по умолчанию стандартный вывод (stdout) от программ, запускаемых systemd с помощью unit-файлов сервисов, перенаправляется в журнал systemd. Благодаря этому, по крайней мере, до тех пор, пока соответствующие записи существуют, эти записи можно проанализировать. Заглянем в журнал и поищем записи, относящиеся к нашему сервису и к дню, когда мы проводили испытания. Соответствующая команда будет выглядеть так: journalctl -S today -u myMonitor.service. Ключ -S — это сокращённый вариант --since. Он позволяет указывать временной период, за который утилита journalctl ищет записи.
systemctl list-timers systemctl list-units
Using systemctl and journalctl To start the timer:
$ sudo systemctl start certbot-renewal.timer To enable the timer to be started on boot-up:
$ sudo systemctl enable certbot-renewal.timer To show status information for the timer:
$ systemctl status certbot-renewal.timer
To show journal entries for the timer:
$ journalctl -u certbot-renewal.service
Understanding Systemd Units and Unit Files
How rename user in Linux
usermod -l login-name old-name
create pkcs12 from certificates
openssl pkcs12 -export -in client.crt -inkey client.key -certfile ca.crt -name MyClient -out client.p12
Диагностика ALSA
Первым делом понадобятся хоть какие-то инструменты для диагностики — это пакет alsa-utils
sudo apt install alsa-utils
Теперь посмотрим, как видит наше оборудование система
aplay -l
speaker-test -Dplughw:1,0 -c4
-D — id устройства. 1,0 — это индексы устройства и подустройства, их мы видели выше в выводе aplay а вот структура текстовой части описана тут -c — количество каналов на которые будет выведен тест В моем случае первые 2 канала работают хорошо, а вот дальше интересно — 3й канал LFO не звучит, но зато звучит 4й канал. Такое ощущение, что LFO настроен как… стерео?.. Мне кажется, это часть моей проблемы.
alsamixer
Следующая полезная утилита — hdajacksensetest. Показывает какие разъемы детектируют подключение внешних устройств.
hdajackretask
HDAAnalyzer
Правка конфигов
Других утилит, способных помочь в настройке звука я не обнаружил. Остается попробовать только одно — искать и править конфиги. С помощью гугла и find, мне удалось обнаружить несколько локаций.
PulseAudio
/usr/share/pulseaudio в папке alsa-mixer тут лежат конфиги. Т.к. Pulseaudio более-менее работает тут я ничего трогать не стал. /etc/pulse/daemon.conf Как я понял, это настройки службы pulseaudio — один из немногих конфигов, изменения в котором на что-то влияют. именно тут настройками: enable-lfe-remixing = yes lfe-crossover-freq = 200 я заставил звучать свой сабвуфер из Pulseaudio так, как он должен. Для lfe-crossover-freq 200 — это очевидно частота среза в герцах. Но тут же становится очевидно, что настроить нечто более сложное(при подключении наушников прекращать отправлять бас на сабвуфер) в этом конфиге возможности нет.
ALSA
/usr/share/alsa/* Тут лежит несколько shell-скриптов, в т.ч. alsa-info.sh, который может быть полезен при подготовке дефекта в трекере и т.д. а в папке pcm какие-то конфиги, разобраться в которых мне не удалось:
Пример конфига: center_lfe.conf
Трогать их я пока не решился. /etc/modprobe.d/alsa-base.conf — второй доказанно полезный конфиг. Вот эта строчка, дописанная в низ конфига, реально заставила работать наушники под ALSA: options snd-hda-intel model=auto,auto probe_mask=1 Про настройку этого конфига написано довольно много. Одна из его целей, как я понял — сопоставить устройствам кодеки(model). Кодеки это… какой-то пресет маппингов… Есть табличка (копия есть тут). Думаю, в большинстве случаев для стандартных конфигураций этого действительно достаточно. Там описаны модели для разных контроллеров. Но если для вас они не срабатывают, то вам рекомендуют добавить свою конфигурацию. Звучит классно, но тут я должен сделать 2 ремарки:
гайда как сделать свою конфигурацию — что конфигурить, куда сохранять, коммитить и т.д. я не нашел. После изменения настроек в alsa-base.conf нужно перезагружать ОС. Без перезагрузки никакие sudo alsa force-reload и даже хардкорный echo 1 | sudo tee /sys/class/sound/hwC1D0/reconfig не заставляют ALSA перечитать кодек устройства.
Кстати, в /sys/class/sound/hwC1D0/ — лежат файлы уже непосредственно устройства, т.е. как я понял hdajackretask работает именно с этими файлами. Тут тоже, наверное, можно сделать что-то полезное, если знать куда что писать.