Это должно работать на основе деталей Вашего вопроса. Можно сохранить следующее в файле, изменить mydirectory на название целевой папки и затем работать bash name_of_script
:
#!/bin/bash
# * matches any string | [08] matches 0 and 8
for image in /usr/share/wallpapers/*/contents/images/16[08]0x*.jpg; do
# create variables by cutting $image in pieces separated by /
name=$(awk -F/ '{print $5}' <<<$image)
file=$(awk -F/ '{print $8}' <<<$image)
# copy to "mydirectory"
cp "$image" mydirectory/"$name""$file"
done
То же может быть упрощено как это:
for image in /usr/share/wallpapers/*/contents/images/16[08]0x*.jpg; do
cp "$image" mydirectory/"$(awk -F/ '{print $5 $8}' <<<$image)"
done
Кажется, что так и должно быть:
Из журнала изменений selinux-policy-3.12.1-139:
- Разрешить ввод systemd_cronjob_t через, bin_t
Do у вас есть какие-либо ошибки в /var/log/audit/audit.log
, относящиеся к mariadb
? Быстрая и простая проверка состоит в том, чтобы setenforce = 0
и запустить задания cron
. Если им лучше, то это был SELinux, вызвавший проблему.
Если в системе имеется systemd, для этого можно использовать события таймеров. Просто определите новую службу , которая должна содержать команду/задачу, которую необходимо выполнить, а затем создайте событие таймера с параметром OnUnitActiveSec
:
[Unit]
Description=daily + 1 hour task
[Timer]
OnUnitActiveSec=25h # run 25 hours after service was last started
AccuracySec=10min
[Install]
WantedBy=timers.target
Используйте то же имя для файлов, за исключением того, что вместо .service
используется .timer
.
Синтез:
job.service
в каталоге /etc/systemd/system/
. systemctl status job.service
. job.timer
в /etc/systemd/system/
. Заполните его необходимой информацией:
[Единица измерения]
Описание = ежедневная + 1 часовая задача
[Таймер]
OnUnitActiveSec = 25h # запуск через 25 часов после последнего запуска службы
Рс = 10мин
[Установить]
PaydBy = timers.target
systemctl list-timers
Я мало играл с системами multiarch, поэтому вполне может быть лучший способ, чем то, что я предлагаю здесь. Я не проверял свое предложение, я не уверен, что оно не противоречит какой-то особенности мультиарха.
Можно использовать equivs для создания фиктивных пакетов только для зависимостей.
equivs-control make.control
Пакет: make
, Архитектура: armhf
, Зависит: make: amd64
и Multi-Arch: foreign
. Можно также установить значение Version
в соответствии с версией amd64 make. equivs-build make.control
Если это не удовлетворяет dpkg, другой подход, который будет работать, но менее удобен, заключается в том, чтобы не устанавливать amd64 make внутри chroot, а вместо этого сделать корень хоста доступным внутри chroot (Для примера см. Обеспечение/bin и/lib внутри chroot-тюрьмы ), или, по крайней мере, сделать
двоичным и его зависимостями (которые для сделать
просто libc). Добавьте каталог, в котором двоичный файл подключен к PATH. Создайте фиктивный пакет, как описано выше, но просто объявите make
установленным, не помещайте заголовок Depends
или Multi-Arch
.