基于 perl 的 cron 作业只有在长时间不活动后才会写入已安装的 cifs/windows 共享

Question

我不知道如何更简洁地命名它并且仍然有意义。

（请注意，在中午运行时，通过 cron 或手动运行它可以正常工作，所以我“知道”脚本本身是正确的。）

我有一个 cron 作业（ubuntu 13.04。）
它以我的用户（不是 root）身份运行。

作业本身在早上 6:00 运行。这是第一个整天运行的“业务级别”工作。

1 6 * * 1-5 /home/me/bin/run_perl_job

run_perl_job 只是：

#!/bin/bash
cd /home/me/bin
./script.pl

脚本将文件复制到“/mnt/shared_drive/outputfile.xls”

挂载点在 fstab 中定义为：

//fileserver/share /mnt/shared_drive cifs user=domain/me%password,iocharset=utf8,gid=1000,uid=1000,sec=ntlm,file_mode=0777,dir_mode=0777 0 0

现在。鉴于：

• 当我在普通 shell 中运行脚本时，它运行良好。
• 当我早上第一件事（通过普通终端）查看挂载点时，它会在没有事件的情况下显示（并且是可写的）。
• 当我复制 crontab 行并将其设置为在几分钟内运行时，为了查看症状，它可以正常工作（非常愉快地创建文件。）

唯一失败的情况是它在正常时间段 (6:01) 内运行。其余的脚本功能（文件本身必须通过 sftp 等下拉）所以我知道它不会死。

测试周期是 24 小时，这让我很生气。

我刚刚在“run_perl_job”脚本的开头添加了以下几行，希望它明天会公开一些内容：

cd /mnt/shared_drive
ls -lrt >>home/me/bin/process.log

但我很难过。 “这几乎就像”挂载点在一夜之间变得陈旧，并且在重新挂载之前正在等待某种访问尝试。如果我能合理地做到这一点，我会在“run_perl_job”脚本的顶部运行“mount -a”。但鉴于它必须被 sudo'ed，这对我来说似乎不合理。

想法？我的想法已经不多了，而且这个测试周期很糟糕。

Answer 1

放一个怎么样

   umount -f -v /mnt/shared_drive
   mount -v -a

在脚本运行之前进入根 cron 作业。这样你就不需要在你的脚本中使用 sudo 并且密码一目了然。 -v 可能会提示您正在发生什么使其过时