Установлена свежая Альт Рабочая станция К. Установлен cockpit и компьютер введен в домен. Вход в систему происходит под доменным пользователем. Операционная система: ALT Linux Рабочая станция 11.2 Версия KDE Plasma: 6.4.6 Версия ядра: 6.12.65-6.12-alt1 (64-бита) id: https://paste.manjaro.ru/view/dfedd7da rpm -qa | grep cron: https://paste.manjaro.ru/view/1248acff При создании заданий в cron из-под обычного пользователя они не работают. cron при этом работает: https://paste.manjaro.ru/view/8d213613 crontrol crontab: public: https://paste.manjaro.ru/view/0b7e48ca crontab -l: https://paste.manjaro.ru/view/b3cb88c7 Файл дебага в /tmp не создается. Прав на каталоги хватает: если я ту же самую команду выполняю от моего пользователя - она работает. Пробовал дополнительно указывать в crontab пользователя PATH - не помогает. Если создам в /etc/cron.d/rsync_test задачу с тем же кодом но для root - все работает. Не работает исключительно для моего пользователя.
в конце последней строки файла должен быть перевод строки, иначе эту последнюю строку не использует. в т.ч. если единственная
В crontab несколько правил, я просто привел первое из них. Для проверки положил несколько правил в /etc/cron.d Разумеется указал от какого пользователя их надо исполнить (моего, доменного из id) - запустилось, работает.
Было предположение, что cron-задания не работают из-за того, что отсутствует файл /etc/cron.allow Добавил его, вписал моего пользователя - результат тот же, не работает.
Была теория, что не выполняются задания пользователи из-за специфического значения uid (1298421113). Создал 7 пользователей с uid от 10000 до 1500000000 (каждый следующий пользователь имел uid на 1 разряд больше предыдущего), но нет, от локальных пользователей задачи через crontab исполняются. Для доменного их будто бы не существует, хотя в /var/spool/cron файл для доменного пользователя присутсвует. Права и разрешения на него такие же как на локальных пользователей: uid)user:crontab 600 Так же не указывал в описании: создание задачи в /etc/cron.d/echo_test с указанием пользователя работает: $ cat /etc/cron.d/echo_test * * * * * user@domain.local /usr/bin/echo "test" > /tmp/echo_test.test Все пользователи, так же как доменный состоят в группе crontab.
(Ответ для Алексей на комментарий #3) > Было предположение, что cron-задания не работают из-за того, что отсутствует > файл /etc/cron.allow > Добавил его, вписал моего пользователя - результат тот же, не работает. м.б. тут еще посмотреть?: grep ad_gpo /etc/sssd/sssd.conf grep -vE "^#|^ " /etc/security/access.conf
(Ответ для zvn на комментарий #5) > (Ответ для Алексей на комментарий #3) > > Было предположение, что cron-задания не работают из-за того, что отсутствует > > файл /etc/cron.allow > > Добавил его, вписал моего пользователя - результат тот же, не работает. > > м.б. тут еще посмотреть?: > grep ad_gpo /etc/sssd/sssd.conf https://paste.manjaro.ru/view/e23d4a6a Последняя строка добавлена в ходе экспериментов с нейросеткой. Результатов не дало > grep -vE "^#|^ " /etc/security/access.conf Тут пустой выхлоп.
а если зайти в шелл этого аккаунта и выполнить: $ export EDITOR=/usr/bin/чтототампоудобнееvi $ crontab -e и добавить в конец что-то вроде: * * * * * /bin/date>~/DATE в конце строки нажать Enter сохранить и выйти (... чем-то напоминает древнее https://www.linux.org.ru/forum/general/890283#comment-890469) потом увидеть, что перевод есть (хотя, если нет перевода строки, то в случае crontab -e предупреждает, вообще-то crontab: installing new crontab .... premature EOF errors in crontab file, can't install. Do you want to retry the same edit? y ) $ crontab -l * * * * * /bin/date>~/DATE $ файл ~/DATE создается? или даже такое простейшее не срабатывает?
(Ответ для zvn на комментарий #7) > а если зайти в шелл этого аккаунта и выполнить: > $ export EDITOR=/usr/bin/чтототампоудобнееvi > $ crontab -e По умолчанию вызывается mcedit. Да и у тестовых юзеров я делал через него. > и добавить в конец что-то вроде: > * * * * * /bin/date>~/DATE > в конце строки нажать Enter > сохранить и выйти (... чем-то напоминает древнее > https://www.linux.org.ru/forum/general/890283#comment-890469) Ах если бы :) Изначально у меня в кронтабе было 4 задания. Если бы отсутствовал Enter в последней строке, то предыдущие три должны были бы выполниться. Ну и да, это были первые советы из поиска, так что это я проверил. В конце файла стоит несколько переносов строк. > $ crontab -l > * * * * * /bin/date>~/DATE > $ $ crontab -l #minute (0-59), #| hour (0-23), #| | day of the month (1-31), #| | | month of the year (1-12), #| | | | day of the week (0-6 with 0=Sunday). #| | | | | commands * * * * * /usr/bin/touch /tmp/test0.test * * * * * /bin/date> /tmp/DATE * * * * * /usr/bin/echo -e "test" > /tmp/echo_test.test Сделал три теста. > файл ~/DATE создается? > или даже такое простейшее не срабатывает? Ни один из тестов не сработал. На всякий случай: $ ls -ln / drwxrwxrwt 20 0 0 4096 фев 2 12:45 tmp Потом дополнительо проверил с попыткой записи в домашний каталог: $ crontab -l #minute (0-59), #| hour (0-23), #| | day of the month (1-31), #| | | month of the year (1-12), #| | | | day of the week (0-6 with 0=Sunday). #| | | | | commands * * * * * /usr/bin/touch ~/test0.test * * * * * /bin/date> ~/DATE * * * * * /usr/bin/echo -e "test" > ~/echo_test.test Результат тоже нулевой.
загрузил виртуалку выполнил для аккаунта crontab -e добавил строку * * * * * /bin/date> /tmp/DATE сохранил просмотрел -l дал пару раз выполниться, файл /tmp/DATE образовался, содержимое как надо. отключил строку лог получаете примерно такой же?: # journalctl --boot |grep cron|less -S фев 02 13:50:07 myhost systemd[1]: Started crond.service - Vixie Cron Daemon. фев 02 14:00:01 myhost crond[2464]: pam_tcb(crond:session): Session opened for root by (uid=0) фев 02 14:00:02 myhost crond[2485]: (root) CMD ( test -d /run/systemd/system || /usr/lib64/sa/sa1 1 1) фев 02 14:00:02 myhost crond[2464]: pam_tcb(crond:session): Session closed for root фев 02 14:01:01 myhost crond[2609]: pam_tcb(crond:session): Session opened for root by (uid=0) фев 02 14:01:01 myhost crond[2625]: (root) CMD (run-parts /etc/cron.hourly) фев 02 14:01:02 myhost crond[2609]: pam_tcb(crond:session): Session closed for root фев 02 14:07:06 myhost crontab[3380]: (myuser) BEGIN EDIT (myuser) фев 02 14:07:45 myhost crontab[3380]: (myuser) REPLACE (myuser) фев 02 14:07:45 myhost crontab[3380]: (myuser) END EDIT (myuser) фев 02 14:07:47 myhost crontab[3466]: (myuser) LIST (myuser) фев 02 14:08:01 myhost crond[3499]: pam_tcb(crond:session): Session opened for myuser by (uid=0) фев 02 14:08:11 myhost crond[3524]: (myuser) CMD (/bin/date> /tmp/DATE) фев 02 14:08:11 myhost crond[3499]: pam_tcb(crond:session): Session closed for myuser фев 02 14:09:01 myhost crond[3633]: pam_tcb(crond:session): Session opened for myuser by (uid=0) фев 02 14:09:11 myhost crond[3655]: (myuser) CMD (/bin/date> /tmp/DATE) фев 02 14:09:12 myhost crond[3633]: pam_tcb(crond:session): Session closed for myuser фев 02 14:10:01 myhost crond[3757]: pam_tcb(crond:session): Session opened for root by (uid=0) фев 02 14:10:01 myhost crond[3756]: pam_tcb(crond:session): Session opened for myuser by (uid=0) фев 02 14:10:02 myhost crond[3779]: (root) CMD ( test -d /run/systemd/system || /usr/lib64/sa/sa1 1 1) фев 02 14:10:02 myhost crond[3757]: pam_tcb(crond:session): Session closed for root фев 02 14:10:12 myhost crond[3803]: (myuser) CMD (/bin/date> /tmp/DATE) фев 02 14:10:12 myhost crond[3756]: pam_tcb(crond:session): Session closed for myuser фев 02 14:10:12 myhost crontab[3810]: (myuser) BEGIN EDIT (myuser) фев 02 14:10:16 myhost crontab[3810]: (myuser) REPLACE (myuser) фев 02 14:10:16 myhost crontab[3810]: (myuser) END EDIT (myuser) фев 02 14:10:16 myhost crond[948]: (myuser) RELOAD (cron/myuser)
Не. Лог пустой: фев 02 13:52:34 work.domain.local systemd[1]: crond.service: Consumed 2h 37min 50.725s CPU time, 5.1G memory peak, 136K memory swap peak. фев 02 13:52:34 work.domain.local systemd[1]: Started crond.service - Vixie Cron Daemon. фев 02 13:57:32 work.domain.local crontab[1421227]: (usr@domain.local) LIST (usr@domain.local) фев 02 14:01:01 work.domain.local crond[1422663]: pam_tcb(crond:session): Session opened for root by root(uid=0) фев 02 14:01:01 work.domain.local crond[1422670]: (root) CMD (run-parts /etc/cron.hourly) фев 02 14:01:01 work.domain.local crond[1422663]: pam_tcb(crond:session): Session closed for root # date Пн 02 фев 2026 14:03:49 MSK При этом список заданий старый: $ crontab -l #minute (0-59), #| hour (0-23), #| | day of the month (1-31), #| | | month of the year (1-12), #| | | | day of the week (0-6 with 0=Sunday). #| | | | | commands * * * * * /usr/bin/touch ~/test0.test * * * * * /bin/date> ~/DATE * * * * * /usr/bin/echo -e "test" > ~/echo_test.test То есть journalctl нет никаких даже попыток запустить задачи от этого пользователя. # getent passwd usr@domain.local usr@domain.local:*:1298421113:1298400513:Пользователь П. Фамилия:/home/usr@domain.local:/bin/bash
# which crond # cat /proc/$(pgrep crond)/{cmdline,environ}
м.б. дело в том, что к имени пользователя прикручено @domain.local?
еще есть идея, что дело в привилегиях в домене для этого аккаунта, и привилегии обрабатываются неправильно на стороне ALT Linux Рабочая станция 11.2 поэтому и задавал вопрос grep ad_gpo /etc/sssd/sssd.conf
(Ответ для zvn на комментарий #11) > # which crond > # cat /proc/$(pgrep crond)/{cmdline,environ} > # which crond > # cat /proc/$(pgrep crond)/{cmdline,environ} [root@work ~]# which crond /usr/sbin/crond [root@work ~]# cat /proc/$(pgrep crond)/{cmdline,environ} /usr/sbin/crond-nLANG=ru_RU.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binXDG_DATA_DIRS=/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/USER=rootINVOCATION_ID=2e9896029aa440e2a1807d404fe712a1JOURNAL_STREAM=9:53175883SYSTEMD_EXEC_PID=1419399MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/system.slice/crond.service/memory.pressureMEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA= Может быть, конечно. Это можно как-то проверить? Хотя почему тогда, когда запускается задание из /etc/cron.d от этого пользователя все исполняется корректно? > * * * * * usr@domain.local /usr/bin/touch /tmp/test0.test Выполняется корректно от моего доменного пользователя. Может быть в pam.d надо что-то прописать?
(Ответ для zvn на комментарий #13) > еще есть идея, что дело в привилегиях в домене для этого аккаунта, и > привилегии обрабатываются неправильно на стороне ALT Linux Рабочая станция > 11.2 > поэтому и задавал вопрос grep ad_gpo /etc/sssd/sssd.conf Мой текущий пользователь админ в домене. Зашел под простым доменным юзером - та же самая картина: crontab не отрабатывает.
(Ответ для Алексей на комментарий #15) > Может быть, конечно. Это можно как-то проверить? > Хотя почему тогда, когда запускается задание из /etc/cron.d от этого > пользователя все исполняется корректно? > > * * * * * usr@domain.local /usr/bin/touch /tmp/test0.test > Выполняется корректно от моего доменного пользователя. м.б. механизм немного разный, в случае файла в /etc/cron.d имя пользователя, от которого запускать, явно прописано. в случае crontab -e участвует имя файла в /var/spool/cron ls -l /var/spool/cron|grep usr оно там совпадает с usr@domain.local ? Vixie и компания написали crond давным давно, м.б. не все части в отношении имени пользователя отрабатывает правильно?
(Ответ для Алексей на комментарий #14) > Может быть в pam.d надо что-то прописать? pamtester -v crond usr@domain.local open_session
> (Ответ для Алексей на комментарий #15) > > Может быть, конечно. Это можно как-то проверить? > > Хотя почему тогда, когда запускается задание из /etc/cron.d от этого > > пользователя все исполняется корректно? > > > * * * * * usr@domain.local /usr/bin/touch /tmp/test0.test > > Выполняется корректно от моего доменного пользователя. > > м.б. механизм немного разный, в случае файла в /etc/cron.d имя пользователя, > от которого запускать, явно прописано. > > в случае crontab -e участвует имя файла в /var/spool/cron > ls -l /var/spool/cron|grep usr > оно там совпадает с usr@domain.local > ? Да, совпадает: # ls -l /var/spool/cron|grep usr -rw------- 1 usr@domain.local crontab 483 фев 2 13:00 usr@domain.local (Ответ для zvn на комментарий #17) > (Ответ для Алексей на комментарий #14) > > > Может быть в pam.d надо что-то прописать? > pamtester -v crond usr@domain.local open_session # pamtester -v crond usr@domain.local open_session pamtester: invoking pam_start(crond, usr@domain.local, ...) pamtester: performing operation - open_session pamtester: sucessfully opened a session (Ответ для zvn на комментарий #16)
(Ответ для Алексей на комментарий #18) > > в случае crontab -e участвует имя файла в /var/spool/cron > > ls -l /var/spool/cron|grep usr > > оно там совпадает с usr@domain.local > > ? > > Да, совпадает: > # ls -l /var/spool/cron|grep usr > -rw------- 1 usr@domain.local crontab 483 фев 2 13:00 usr@domain.local м.б. немного схимичить? # cd /var/spool/cron # ln usr@domain.local usr и проверить. заодно уж: домен к имени пользователя теперь прикручивается после ввода в домен? а то раньше было по умолчанию просто имя пользователя.
(Ответ для zvn на комментарий #19) > м.б. немного схимичить? > # cd /var/spool/cron > # ln usr@domain.local usr > и проверить. Ноль реакции. > заодно уж: домен к имени пользователя теперь прикручивается после ввода в > домен? а то раньше было по умолчанию просто имя пользователя. Это зависит от настроек sssd. Если в use_fully_qualified_names значение True, то будет имя+домен Если вводить в домент через alterator, то каталоги доменных пользователей создаются в /home/domain.local/usr, пользователь, соответственно тоже будет usr, вероятно в этом случае в sssd.conf значение стоит False Я вводил через cockpit (по привычке), а он настраивает так, что каталог создается в /home/usr@domain.local, ну и пользователь, соответственно usr@domain.local, потому что в sssd use_fully_qualified_names=True
Судя по всему проблема в том, что пользователь имеет имя usr@silar.local Я в виртуальной машине поставил чистую систему. Ввел машину в домен через cockpit (таким образом, что пользователь именуется как usr@domain.local), создал тестовое правило - не работает. Вывел машину из домена. Поставил task-auth-as-sssd и ввел машину в домен через Alterator. домашний каталог пользователя теперь в /home/DOMAIN.LOCAL/usr. Зашел под этим пользователем, создал тестовое правило - работает. Не очень понятно в чем разница. Только в том что пользователь имеет суффикс @domain.local? Сделал для тест пользователь test@test.local. Зашел под ним, сделал тестовое задание в crontab. И тестовые задания не срабатывают. Видимо действительно vixie-cron не может воспринимать пользователя с @
ну вот. багу зарегистрировали, самопомощь (частичную) осуществили. по-моему, в багу никто из мейнтейнеров и не приходил. а еще год назад было иначе.
(Ответ для Алексей на комментарий #21) > Поставил task-auth-as-sssd и ввел машину в домен через Alterator. домашний > каталог пользователя теперь в /home/DOMAIN.LOCAL/usr. Зашел под этим > пользователем, создал тестовое правило - работает. я думаю, что сейчас для alt это единственный беспроблемный путь, т.к. из-за мпртзмщн все силы по этой части брошены на связку альт домена с гномом + alt мобильная ось тоже на гноме. на все остальные направления банально не хватает сил (без использования openclawd, наверное...)
(Ответ для zvn на комментарий #22) > по-моему, в багу никто из мейнтейнеров и не приходил. А из мантейнеров про неё пока никто не знает.
(Ответ для Алексей на комментарий #21) > не может воспринимать пользователя с @ Это абсолютно правильно, т.к. это разделитель имени пользователя и домена.
(Ответ для Sergey V Turchin на комментарий #25) > (Ответ для Алексей на комментарий #21) > > не может воспринимать пользователя с @ > Это абсолютно правильно, т.к. это разделитель имени пользователя и домена. Но такой пользователь, как мы видим может существовать. В этом случае cron будет работать неправильно. Точнее он неправильно будет работать, если создавать задания от самого пользователя через crontab. Если его делать от root в /etc/cron.d то все будет работать. В конце-концов у меня может быть пользователь L@ik@ и в этом случае задания через пользовательский crontab также не будут работать.
(Ответ для zvn на комментарий #23) > (Ответ для Алексей на комментарий #21) > > Поставил task-auth-as-sssd и ввел машину в домен через Alterator. домашний > > каталог пользователя теперь в /home/DOMAIN.LOCAL/usr. Зашел под этим > > пользователем, создал тестовое правило - работает. > > я думаю, что сейчас для alt это единственный беспроблемный путь, т.к. из-за > мпртзмщн все силы по этой части брошены на связку альт домена с гномом + alt > мобильная ось тоже на гноме. > на все остальные направления банально не хватает сил (без использования > openclawd, наверное...) Даже в случае альтдомена может появиться такой пользователь и задания через crontab работать не будут.
Не удивлюсь, если мантейнер отклонит этот баг по причине бага в имени пользователя. P.S. systemd.timer
на самом деле действительно @ не должен входить в имя пользователя. по сути, источником проблемы является метод ввода в домен через cockpit. но cockpit не входит ни в какие образы https://packages.altlinux.org/ru/p11/srpms/cockpit/images/?task_repo=p11, т.е. не является частью дистрибутива ALT Linux Рабочая станция 11.2 он просто находится в репозитории, как говорится, спасибо, что он есть там (может и исчезнуть из репозитория, это чтобы без иллюзий...)
(Ответ для zvn на комментарий #29) > на самом деле действительно @ не должен входить в имя пользователя. > > по сути, источником проблемы является метод ввода в домен через cockpit. > > но cockpit не входит ни в какие образы > https://packages.altlinux.org/ru/p11/srpms/cockpit/images/?task_repo=p11, > т.е. не является частью дистрибутива ALT Linux Рабочая станция 11.2 > > он просто находится в репозитории, как говорится, спасибо, что он есть там > (может и исчезнуть из репозитория, это чтобы без иллюзий...) Не совсем так. Источником проблемы являются символы, которые не обрабатываются vixie-cron. Я могу ввести машину в домен без использования cockpit и alterator, просто через командную строку, но настройки будут такие, что пользователь в имени будет иметь свой домен. Более того в вики альта: https://www.altlinux.org/ActiveDirectory/Trusts#SSSD указаны ситуации, при которых необходимо использовать полное имя пользователя с доменом. Это во-первых. А, во-вторых, имя пользователя может и без домена содержать символ, из-за которого крон не будет его обрабатывать.
ну вот вогоны из IEEE, которые занимаются темой, пишут что-то вроде такого: POSIX ("Portable Operating System Interface for Unix") standard (IEEE Standard 1003.1 2008) states: 3.437 User Name A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name. 3.282 Portable Filename Character Set The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - поскольку других вогонов во вселенной нет, то приходится жить по этим указивкам и слушать их поэзию, а не то накажут, построив межгалактическое шоссе через место существования...
Само собой, было бы странно, например, пытаться слать почту на user@gomain.org@host.local , т.к. такого быть не должно.
(Ответ для Sergey V Turchin на комментарий #32) > Само собой, было бы странно, например, пытаться слать почту на > user@gomain.org@host.local , т.к. такого быть не должно. Если кто-то сделать себе логин @lex или s@ndra то опять же работать ничего не будет :) Это нюанс, кажется, именно vixie-cron, в cronie на другой оси подобных вещей не было. Хотя сравнивать, конечно, не корректно.
(Ответ для Алексей на комментарий #33) > Если кто-то сделать себе логин @lex или s@ndra то опять же работать ничего > не будет :) > Это нюанс, кажется, именно vixie-cron, в cronie на другой оси подобных вещей > не было. Хотя сравнивать, конечно, не корректно. сейчас в своей gentoo проверил # useradd --create-home --home /home/s@ndra s@ndra useradd: invalid user name 's@ndra': use --badname to ignore в alpine # adduser s@ndra adduser: illegal character with code 64 at position 1 в alt # useradd --create-home --home /home/s@ndra s@ndra useradd: invalid user name 's@ndra': use REGEXP_NAME in /etc/login.defs to set allowed names в остальных вариантах (oracle linux, debian и др.) не стал проверять можно, конечно, и без этих утилит сгенерить аккаунт, или создать его в каком-то варианте ldap и потом понакрутить к его имени дополнений, если sssd, nslcd или др. позволяет. кстати, в sssd чаще встречал пример дополнения аккаунта доменом с помощью знака +
с другой стороны, посмотрел: https://packages.gentoo.org/packages/virtual/cron/dependencies не зря они убрали vixie-cron в alt он уже из другой эпохи, судя по man crond (внизу 2002 год) и версии пакета 4.1.20060426-alt10.3 собственно в багу эту залез только потому что меня в один прекрасный момент в alt crond шокировало то, что я поменял настройки задания, а оно не запустилось, т.к. я не сделал перезапуск crond, чего уже давно во многих других дистрибутивах не требуется (хотя у этого есть и оборотная сторона, когда изменения что-то запустят тогда, когда еще не надо)
(Ответ для zvn на комментарий #34) > (Ответ для Алексей на комментарий #33) > > Если кто-то сделать себе логин @lex или s@ndra то опять же работать ничего > > не будет :) > > Это нюанс, кажется, именно vixie-cron, в cronie на другой оси подобных вещей > > не было. Хотя сравнивать, конечно, не корректно. > > сейчас в своей gentoo проверил > # useradd --create-home --home /home/s@ndra s@ndra > useradd: invalid user name 's@ndra': use --badname to ignore > > в alpine > # adduser s@ndra > adduser: illegal character with code 64 at position 1 > > в alt > # useradd --create-home --home /home/s@ndra s@ndra > useradd: invalid user name 's@ndra': use REGEXP_NAME in /etc/login.defs to > set allowed names > > в остальных вариантах (oracle linux, debian и др.) не стал проверять > можно, конечно, и без этих утилит сгенерить аккаунт, или создать его в > каком-то варианте ldap и потом понакрутить к его имени дополнений, если > sssd, nslcd или др. позволяет. > кстати, в sssd чаще встречал пример дополнения аккаунта доменом с помощью > знака + Да, действительно для создания пользователя с @ надо отдельно regexp разрешать. Может быть имеет смысл тогда пересоздать баг или перенаправить его на сопровождающего cockpit? Чтобы скрипты, формирующие конфиги, формировали их правильными для исключения таких ситуаций?
(Ответ для Алексей на комментарий #36) > Может быть имеет смысл тогда пересоздать баг или перенаправить его на > сопровождающего cockpit? Чтобы скрипты, формирующие конфиги, формировали их > правильными для исключения таких ситуаций? лучше этот баг не трогать, если что не так, его просто отметят (но, скорее всего, никак не). что касается оформления на cockpit, то он не входит в дистрибутив (см. https://bugzilla.altlinux.org/show_bug.cgi?id=57700#c29) Вам вот тут https://bugzilla.altlinux.org/show_bug.cgi?id=57700#c28, как я понял, альтернативу предложили в виде systemd.timer
Проверялось в Sisyphus, ошибка воспроизводится. Стенд: Alt Linux KWorkstation 11.2 (обновленный до Сизифа) Версия пакета: vixie-cron-4.1.20060426-alt10.3.x86_64 При создании заданий в cron из-под пользователя с символом "@" в имени - задания не работают.
Просто для информации. Я уже года три хочу перевести альты на использование https://github.com/systemd-cron/systemd-cron Все нехватает времени.
