У меня есть сценарий python3.2, который предполагается удалить папку после того, как все сделано:Crontab и доступа пользователей права на Xubuntu
def perforce_backup(
source,
destination,
tmp_location,
zip_tmp_loc,
):
logger.info('--------------------Perforce Backup--------------------'
)
logger.info('--- Check integrity of perforce depot (p4 verify)')
p4verify(source, 'user', 'password')
logger.info('--- Create a checkpoint (p4 admin checkpoint)')
p4checkpoint(source, 'user', 'password')
logger.info('--- Do the backup locally')
rsync(source, tmp_location)
logger.info('--- Zip perforce db and depot locally')
zipdir(tmp_location, zip_tmp_loc)
logger.info('--- Remove file from last folder on backup FTP')
shutil.rmtree(destination.path)
makedir(destination.path)
logger.info('--- Move zip to backup FTP')
cp(zip_tmp_loc.path + '/*', destination.path)
logger.info('--- Remove tmp_file locally - raw copy and archive')
shutil.rmtree(tmp_location.path)
logger.info('--- Remove tmp_file locally - raw copy and archive2')
shutil.rmtree(zip_tmp_loc.path)
logger.info('--- Remove tmp_file locally - raw copy and archive3')
Когда я запускаю скрипт вручную, используя пользователя «vbackup», он работает. Я определил задачу в моем «пользователе» кронтаб с этим синтаксисом (я уверен, выполнением кронтаба -e, как «vbackup» с помощью «су vbackup»:
00 22 * * * python3.2 /opt/valibackup/main.py
Когда я использую выше, скрипт запускается каждый день в 22:00 Проблема заключается в том, что она работает без необходимых привилегий, и shutil.rmtree() не работает, когда это происходит при запуске скрипта вручную.
Я пробовал следующий синтаксис, который я нашел здесь, чтобы быть уверенным, что он работал с правами «vbackup», но он даже не запускается.
*/30 * * * * vbackup python3.2 /opt/valibackup/main.py
Если я отредактирую с помощью «sudo crontab -e» вместо этого, rmtree работает, но не rsync отправляет ошибку с отказами Permission.
Любая идея?
Вы указать все пути к файлам абсолютно? то есть/path/to/dir не только для/dir? –
@RPhillipCastagna Да, все пути к файлу абсолютны – nivolas
Возможно, есть какие-либо сообщения об ошибках в журналах (должно быть где-то в/var/log или в журнале systemd, в зависимости от того, что это за Linux)? – 0range