我不知道如何更简洁地命名它并且仍然让它有意义。
（请注意，这在中午通过 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，这对我来说似乎不合理。
想法？我的想法不多了，这个测试周期很糟糕。