вторник, 15 февраля 2022 г.

Удаление записей из списка "Приложения" в настройке оповещений Linux Mint xfce

После удаления из системы двух ранее использовавшихся программ было обнаружено, что несмотря на удаление относящихся к данному ПО каталогов из ~/.cache ~/.config ~/.local/share, записи об этих программах остались в списке "Приложения":


Увы, интенсивный поиск в Интернет к желаемому ответу на поставленный вопрос не привёл. Получилось, что "спасение утопающих – дело рук самих утопающих".

Было выяснено, что за оповещения отвечает компонент notifyd. Поиск в файловой системе привёл к его файлу настроек xfce4-notifyd.xml (в файловом менеджере включить отображение скрытых файлов), расположенный в: ~/.config/xfce4/xconf/xfce-perchannel-xml


Открыть этот файл в текстовом редакторе и аккуратно удалить лишние записи от <value type= до (включая) >  Для образца можно посмотреть на предыдущие записи, например, Dropbox и FileZilla, FileZilla и Firefox ...  :


При следующем сеансе работы в системе (у меня это было после перезагрузки) "лишних" записей быть не должно:


Делюсь, может быть кому-либо пригодится  😊

понедельник, 14 февраля 2022 г.

Определить запущен ли Transmission через bash

При написании сценария возникла проблема определения: работает ли клиент торрент Transmission. Быстрая команда pidof Transmission результата не выдает, несмотря на то, что в списке процессов данный процесс присутствует:

Как показало следствие, правильно процесс называется transmission-gtk. И тогда при такой инструкции:

[ "$(pidof transmission-gtk)" ] && echo "1" > /tmp/transmission.txt || echo "0" > /tmp/transmission.txt

при запущенном Transmission в файл transmission.txt будет записано значение 1, а при не запущенном – 0.

Магия, однако ...  😎 

четверг, 3 февраля 2022 г.

Интерпретация некоторых результатов вывода iwconfig

Про Wi-Fi написано много, но зачастую найти ответ на конкретный вопрос бывает затруднительно. 

Описываемая ниже ситуация является личным опытом, а изложенные выводы являются личным мнением, которое не претендует на то, чтобы быть "непреложной истиной". Употребление написания Wi-Fi обусловлено следованию английской аббревиатуре Wireless Fidelity. Подробности читайте здесь.

По завершении мероприятий по тонкой настройке своей точки Wi-Fi был дан запрос iwcоnfig.

Мероприятия по тонкой настройку Wi-Fi включали в себя выборы:
✔  взаимного расположения токи wifi и принимающего устройства, за которым чаще всего работаешь (также учитывалось наличие между ними различных предметов); 
✔  частоты вещания точки Wi-Fi; 
✔  ширины канала: 20/40 или только 20; 
✔  стандарта работы: B/G/N, G/N, только N; 
✔  мощности передатчика: по умолчанию 17 dBm (~ 50 мВт) или ниже. 

При этом также стояла задача обеспечения приемлемой величины Overal Tx CCQ (для себя – не ниже 60%). 

⤷  Пояснение. В качестве точки Wi-Fi был использован маршрутизатор MikroTik, на котором можно и увидеть данное значение. Не думаю, что на маршрутизаторах для домашнего Интернет, выдаваемых провайдером, его можно посмотреть. Overal Tx CCQ  интерпретируется как усреднённый CCQ (качество канала на передачу/приём) только на передачу Tx. На базовой станции он показывает усреднённые значения по качеству передачи на всех подключившихся Wi-Fi клиентах.

Сразу возникли вопросы типа "это хорошо или плохо?" и "можно ли считать это приемлемым?".

Первое – это значок с всплывающим при подведении к нему указателя мыши "... 68%"

Например, 3 полоски это ещё приемлемо или, всё-таки, необходимо выкручивать мощность передатчика в состояние default, чтобы попробовать добиться заполнения всех 4 полосок.

Второй блок вопросов касается результата вывода команды iwconfig

Например, Signal level=-51 dBm это приемлемо или нет?

К большому сожалению, в русскоязычных источниках быстрого ответа найти не удалось. Хотя и встречалось пояснение, касающихся степени заполнения 5 полосок индикатора Wi-Fi. Из него следует, что 3 полоски – это ещё нормально, 4 – хорошо, 5 – очень хорошо. 

Например, так выглядит беспроводное подключение на Windows:

Данное подключение установлено с точкой Wi-Fi, расположенной через стенку в соседнем помещении. Расстояние между точкой W-Fi и подключенным к ней компьютером по прямой составляет примерно 3,6-3,8 метра.

Как видно из рисунка, условия приёма не являются идеальными, поскольку в действительности сигнал проходит через 2 стенки да ещё на него налагаются и переотражения от угла. Несмотря на это, как видно из наличия 4-х заполненных столбиков, условия для работы вполне приемлемые. В эксперименте мощность передатчика была установлена в 10 dBm, а с учётом усиления антенны с коэффициентом 1,5 результирующая мощность составила 13 dBm.

Таким образом, будем считать, что в пересчёте 5 полосок в Windows на 4 в Linux, мои 3 полоски из 4 – это между "ещё нормально" и "хорошо" (но ближе к "хорошо").

Что касается Signal level=-51 dBm, то привожу информацию из этого источника (англ.).

Приемлемое значение, в зависимости от дальности расположения приёмника от точки Wi-Fi, колеблется в диапазоне от -55 dBm до -70 dBm. При этом приводятся следующие пояснения:

-30 dBm = Великолепно – максимально достижимая сила сигнала  – 4 полоски из 4. В большинстве случаев точка Wi-Fi расположена в нескольких футах (1 фут = 30,48 см.) от приёмника сигнала. Не является типичной ситуацией.

-67 dBm = Очень хорошо – минимальное значение силы сигнала для большинства бизнес-приложений (например, голосовая связь и потоковое видео) – 3 полоски из 4.

-70 dBm = OK – минимально допустимая сила сигнала, требуемая для приемлемой степени доставки пакетов (веб-серфинг, электронная почта) – 2 полоски из 4. Значение термина OK для себя определите сами.  📚

-80 dBm = Плохо – минимально допустимая сила сигнала для соединения с точкой Wi-Fi, но при этом доставка пакетов может оказаться под большим вопросом – 1 полоска из 4. Другими словами – вы не сможете нормально работать.

-90 dBm = Неприемлемо – чрезмерное количество пакетов, которые не могут быть доставлены получателю, большие шумы, интерференция между сигналами и т.п. Любая функциональность Wi-Fi невозможна.

Исходя из указанного выше, моё значение -51 dBm является "вполне так себе прилично", несмотря на то, что мощность передатчика составляет 5 dBm (3,16 мВт). 

Можно было бы предположить, что будь мощность побольше, то заполнились бы все 4 полоски индикатора Wi-Fi. Однако не всё так однозначно. 

Проверялось ещё одно устройство, расположенное чуточку дальше, чем упоминающееся. При подключении к точке число заполненных активных полосок индикатора Wi-Fi было 2, но в течение одной минуты все 4 полоски оказались заполненными, а при подведении указателя мыши к значку индикатора отобразилась надпись " ... 82%". Разница между устройствами, а точнее антеннами взаимодействующих устройств Wi-Fi заключается в их пространственной ориентации. 

Во-первых, на MikroTik и первом устройстве антенны являются внутренними и выполнены путём травления дорожек. Их взаимное расположение в пространстве отличается на 90 градусов. На втором устройстве антенна Wi-Fi также является встроенной (внешнее устройство, подключаемое через USB). Разъем USB имеет вертикальное расположение и по отношению к MikroTik антенна подключаемого устройства расположена практически в одной плоскости с ним. Ситуация навевает сюжет из детского киножурнала "Ералаш", в котором заключительная фраза главной героини звучит как "Ты, я и геомЭтрия".  😂

Во-вторых, – в сети можно найти материалы, в которых говорится, что повышение мощности передатчика Wi-Fi не всегда есть благо, так как мощное излучение от него в ряде случаев может "пересилить" ответ от подключаемого устройства, в результате чего связь будет никакая. Настройка мощности излучения под наименованием default каждым производителем выбирается из собственных соображений, но в большинстве случаев значение default равно максимально допустимой мощности излучения передатчика Wi-Fi в соответствии с требованиями regulatory-domain (для каждой страны это значение своё). 

Любопытно, что попытка установки на предоставленном провайдером маршрутизаторе Huawei HG8245Hv5 значения мощности Wi-Fi менее 100% вызывает у него "монаршее неудовольствие"  😡  

Установленная мной мощность передатчика MikroTik в 5 dBm обусловлена тем, что он установлен не где-то там в прихожей, а в жилой комнате и лишние мВт в ней ни к чему. К слову, тестирование данной точки с упоминавшимся выше устройством на Windows показало, что из 5 полосок закрашено 3, что, исходя из представленных выше сведений, описывается как "это ещё нормально". 

В завершение следует отметить, что идеального качества Wi-Fi вы вряд ли достигнете. В частности, это касается и роста значения параметра Invalid misc в результатах вывода iwconfig, которое в моём случае за три практически следующих друг за другом измерения составило 1024, 1033 и 1039. Для объяснения такого явления придётся вникать в тонкости реализации самой технологии Wi-Fi, а также обратиться к теории распространения радиоволн. Поэтому имею склонность согласиться с мнением, что если возможно, то вместо Wi-Fi всегда желательно использовать проводное соединение. 

В подтверждение последнего тезиса отмечу, что показываемая скорость в свойствах подключения (или iwconfig), например Bit Rate:150 Mb/s, показывает так называемую канальную скорость между устройством и точкой Wii-Fi (подробности). Она является скоростью подключения на физическом уровне, которая используется в текущее время в рамках выбранного стандарта (в данном примере – N). Казалось бы, что вот оно, счастье: 150 против 100 по кабелю (а нет – снова опыт). Если вы предпримете попытку передачи большого числа данных между устройствами, которые взаимодействуют только через Wi-Fi, то в плане быстроты отправки/получения большого числа файлов и папок испытаете глубокое разочарование. Потому что реальная скорость является совсем другим явлением и зависит от такого большого количества факторов, что временами пока дочитаешь до конца, то забудешь с чего начиналось.  👀   

Про реальную скорость с примерами написано на хабре. Для неподготовленного читателя публикация может быть мало- или совсем непонятной. Но, полагаю, в ней стоит обратить внимание на абзацы "Маркетологи и продажники" , а также "Математика не врёт". 

А самым простым способом узнать реальную скорость приёма/передачи данных на на конкретном устройстве является установка какого-либо сетевого монитора, который будет отображать значения измерений скорости на указанном в его настройках интерфейсе (Wi-Fi или LAN). К примеру, на xfce такой сетевой монитор можно добавить на панель (подробности). 

понедельник, 31 января 2022 г.

Очистка старых файлов из кэша foliate

Установка читалки электронных книг foliate вместо имеющейся в комплекте поставки Linux Mint fbreader обусловлено тем, что на моей системе при использовании fbreader перелистывание страниц можно осуществить только клавишей PageDown вместо предпочитаемой мной широкой Space (пробел).

Установку foliate можно выполнить из PPA:

sudo add-apt-repository -y ppa:apandada1/foliate && sudo apt update && sudo apt install -y foliate

В настройках foliate имеются варианты выбора шрифта, отображения вместо 2 столбцов (как по умолчанию) один, а также выключения автопереноса слов:



Читаемые и прочитанные книги складываются в каталог ~/.cache/com.github.johnfactotum.Foliate в виде файлов png – обложки книг и файлов json, которые содержат сведения о странице, на которой завершилось чтение в прошлый раз, с целью автоматического открытия читаемой книги на том же месте. При прошлом просмотре содержания указанного каталога в нём было найдено более 130 файлов.

Несмотря на наличие в настройках команды чистки кэша (раскройте в настройках пункт "Книга"), в силу "ленивости" возникло желание немного автоматизировать данный процесс. Ко всему прочему "жаба душит" за лишние занимаемые килобайты. 😂

Исходя из того, что читать люблю и читаю много 😀, на чтение книги порядка 400-500 страниц у меня уходит 2-3 дня. Принимая во внимание, что за месяц будет прочитано 10-15 книг, при числе > 10 файлов json к кэше (3 дня на книгу) было принято решение о запуске процедуры поиска и удаления файлов старше 30 суток (можно меньше или больше на ваше усмотрение). 

Описание выполнение условия "если число найденных файлов больше, чем" описано в этой заметке, а найти файлы старше N дней и удалить реализуется через параметры команды find.

➙  Примечание. В используемом мной сценарии (скрипте) применяется протоколирование действий. Узнать такие команды можно по наличию слов day, echo и log. Если такой необходимости нет, то строки их содержащие можно удалить.

#!/bin/bash
day=`date '+%d'`
books=/home/user/.cache/com.github.johnfactotum.Foliate  # вместо user указать своё имя пользователя в системе
log=/home/user/Reports/system/$day.txt
echo "$(date '+%H.%M.%S') – запуск задания foliate" >> $log
find $books -type f -name "*.json" | wc -l > /tmp/foliate.txt
value1=10
value2=`cat /tmp/foliate.txt`
if (( $value2 > $value1 )); then
    echo "            найдено файлов json – $value2" >> $log
    echo "            запуск очистки кэша foliate" >> $log
    find $books -name "*.png" -mtime +30 -delete
    find $books -name "*.json" -mtime +30 -delete
    echo "            старые файлы из кэша foliate удалены" >> $log
  else
    echo "            найдено файлов json – $value2" >> $log
    echo "            файлов кэша для удаления не назначено" >> $log
fi
echo "            завершение задания foliate" >> $log
exit

➙  Пояснение. В строках echo "   ..." число пробелов равно 12-ти. 12 символов как раз и занимает отображение времени плюс тире с пробелами слева и справа от него: 
$(date '+%H.%M.%S') – 

Данный скрипт запускается мной при старте системы.

Ниже приводится пример реального протоколирования 30 января:

17.39.02 -- запуск задания foliate
                   найдено файлов json – 2
                   файлов кэша для удаления не назначено
                   завершение задания foliate

На тот момент в кэше были расположены файлы:

4E957209-CFCE-4BC2-9AF6-595CD61B5DBA.json
4E957209-CFCE-4BC2-9AF6-595CD61B5DBA.png
AB3F1A4D-5B5C-4C66-85D4-EF90A90A8796.json

📌  Дополнение. На форуме дали совет запретить использовать трекер положения файлов (позволяет находить файл книги который был перенесен в другой каталог). Настройка производится через dconf:

sudo dconf write /com/github/johnfactotum/Foliate/library/use-tracker false

Возможно, что для выполнения этого действия необходимо будет установить dconf-editor:

sudo apt install dconf-editor

После этого либо использовать верхнюю команду, либо, запустив графическую оболочку dconf-editor (sudo dconf-editor) отключить use-tracker.



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

четверг, 20 января 2022 г.

Выполнение действий по условию – если число файлов больше 10


Возникла необходимость автоматизации выполнения задачи по отправке файлов (папок с файлами) по условию их наличия в папке для отправки более 10 шт.

Реализацию данной задачи было решено возложить на скрипт bash, запускаемый через пользовательское задание cron.

Указанный ниже скрипт на bash действует по алгоритму:

1. Вычисляется число файлов в папке для отправки.

2. Полученное значение сравнивается с установленным значением 10.

3. Если в результате сравнения будет выяснено, что число файлов в папке для отправки больше 10, то запускается задание на отправку. Если выяснено, что число файлов 10 и менее, то задание на отправку не запускается. Отправка производится программой rclone.

В принципе, текст скрипта простой. Но особенность реализации заключается в том, что проверка условия вида

if [ $value2 -qt $value1 ]; then

здесь не работает, а работает

if (( $value2 > $value1 )); then

Поэтому текст скрипта будет следующим:

#!/bin/bash
log=место_файла_протокола/$(date '+%d').имя_файла.txt
sm=... # указывается путь к папке отправки
dm=... # указывается путь к папке получателя
# если файл протокола отсутствует, то он создаётся
if [ -f $log ]; then
  :
else
  > $log
fi
echo "     " >> $log
find $sm -type f | wc -l > /tmp/files.txt
value1=10
value2=`cat /tmp/files.txt`
if (( $value2 > $value1 )); then
     echo "$(date '+%H.%M.%S') -- файлов в папке – $value2" >> $log
     # запуск задания на отправку файлов и папок с файлами через команду перемещения
     echo "            запуск задания отправки" >> $log 
     rclone move --delete-empty-src-dirs $sm $dm
     echo "$(date '+%H.%M.%S') -- завершение задания отправки" >> $log
  else
     echo "$(date '+%H.%M.%S') -- отправка не произведена" >> $log
     echo "            файлов в папке – $value2" >> $log
fi
echo "     " >> $log
exit

По сравнению с реально использующимся текст скрипта упрощён (за счёт отсутствия ряда операций, предшествующих отправке), но показывает общую реализацию поставленной задачи.

🔰  Дополнительные пояснения. Число пробелов с строках записи в протокол событий составляет 12, что объясняется желанием удобства чтения протокола, то есть помещать следующую запись текста прямо под предыдущей, например:

17.30.01 -- файлов в папке – 11
                   запуск задания отправки
17.31.19 -- завершение задания отправки

Для автоматического удаления удаления устаревших файлов протоколов можно использовать команду:

find место_файлов_протоколов -name "*.txt" -mtime +N -delete

N является числом полных суток, например 3. То есть, если с момента создания файла протокола прошло 72 часа и менее, то файл не удаляется, а вот если прошло 72 часа 1 минута и более, то файл уже подлежит удалению. Подробности можно прочитать здесь в комментариях 5 и 6.

понедельник, 17 января 2022 г.

Очень долгое выключение Linux Mint

С неделю назад было обнаружено, что моя система Linux Mint 20.3 очень долго выключается. 💣

При подробном выводе процесса выключения после достижения состояния Reached target Power-off появляется:
 
systemd-shutdown[1]: Waiting for process: crond

🔸Примечание. Чтобы это увидеть на экране необходимо отредактировать файл /etc/default/grub, приведя строку GRUB_CMDLINE_LINUX_DEFAULT к виду GRUB_CMDLINE_LINUX_DEFAULT="" и обновить grub (sudo update-grub).

Специально время не засекалось, но по прикидкам ожидание может составлять 0,5-1 минуту, после чего система выключается.

Поиск в англоязычном сегменте выдал следующее: имеет место процесс crond, который запускается каждые 10 минут. Что он делает – "сия великая тайна есть", но есть мнение, что данный объект был создан приложением Free Download Manager (а я им некоторое время пользовался 😄) Если при просмотре содержания каталога /etc/cron.d вы наблюдаете объект collect, то вот он далее и нужен.


В упоминавшейся выше публикации говорится о целесообразности перемещения collect в любое другое место. 

Моё предложение следующее. Через встроенный редактор Midnight Commander (sudo mc) или стандартный текстовый редактор xed ( sudo xed /etc/cron.d/collect ) отредактируйте его содержание путём записи символа комментария:


У меня всё пришло в норму тотчас же.

Другим вариантом предлагается уменьшить время ожидания закрытия приложений, изменяя величину DefaultTimeoutStopSec=90s в /etc/systemd/system.conf

понедельник, 3 января 2022 г.

FireDM – менеджер загрузок, понимающий ссылки youtube

Долгое время для скачивания видео нужного качества (по выбору) с видеохостинга youtube мной использовалось ПО 4k videodownloader. С недавней поры при попытках скачать ряд роликов данное ПО стало требовать входа в аккаунт Google. 


Поскольку требуемая функция относится к уже платному тарифному плану 4k videodownloader, то для обхода указанного выше ограничения youtube и скачивания роликов в качестве 1080p, если такой вариант существует, мной стали предприниматься усилия по поиску разумной альтернативы.

Некоторое время мной использовался сервис loader.to, аналогичный множеству других онлайновых сервисов для скачивания с youtube, которые легко находятся через поисковый запрос.  Но вчера при поиске ссылки на скачивание deb-пакета Free Download Manager был случайно найден менеджер загрузок FireDM. Общее представление об этом ПО можно получить на сайте проекта (но требуется немного понимать английский язык 😃 ).

Если кому интересно как интерфейс выглядит на компьютере, а не так как показано на сайте, то привожу снимок со своего экрана:


Программа распространяется в виде самодостаточного приложения. 

Для скачивания перейдите по этой ссылке. Для Linux скачивайте AppImage, для Windows – архив zip. На момент публикации:

Примечание. Программу можно скачать и с videohelp.com по этой ссылке.

Перед запуском приложения AppImage убедитесь, что файл является исполняемым, например:


Как указано в описании возможностей FireDM, скачивание потокового видео не ограничивается только видеохостингом youtube. Действительно, в ходе экспериментов было выявлено, что без проблем скачиваются видео с Одноклассники, В Контакте, Rutube + ещё один специфический ресурс, о котором вслух говорить не принято (💞).  

А теперь немного "нужных" подробностей.

🔅  Не исключено, что вам необходимо будет установить пакет mpeg (sudo apt install -y ffmpeg) 

🔅  FireDM перехватывает ссылки из буфера обмена. Если при запущенной программе скопировать в адресной строке браузера ссылку на страницу с роликом, то Fire DM практически сразу же начинает её анализировать. Ссылка будет анализироваться даже в том случае, если она  будет скопирована первой, а программа FireDM будет запущена второй.

🔅  После завершения анализа FireDM выведет варианты для выбора какой из них скачать:





🔅  Как только выбор завершён необходимо нажать на кнопку DOWNLOAD:


Кроме того, можно указать папку для сохранения скачиваемого  видео:


Папка Downloads создаётся автоматически при первом скачивании.

🔅  Нажав на кнопку Settings в левом столбце программы можно выбрать цветовое оформление внешнего вида, а также указать множество других параметров. Нажимая на кнопку Apply справа от строки с наименованием цветового оформления можно видеть изменение цветового оформления "на лету". Требуется небольшое знание английского языка или умение пользоваться онлайн-переводчиком.  😀



🔅  Скрытые файлы и папки приложения

К скрытым файлам и папкам приложений, как правило, относятся данные настроек, кэши и дополнительные элементы. Настройки FireDM расположены в ~/.config/FireDM: