1 |
> > Thanks Michael. I'd like to have more control over when the commands |
2 |
> > are run. Maybe the system crontab (cronbase) should be used when that |
3 |
> > control isn't necessary or to allow programs to add stuff to a crontab, |
4 |
> > and a user crontab should be used when more control is necessary? |
5 |
> > |
6 |
> |
7 |
> I personally like the idea of the cron.{daily,weekly,...}, but the |
8 |
> implementation is a little goofy. On our mail server, I've added an |
9 |
> additional directory called cron.bihourly to update virus/spam |
10 |
> signatures every two hours. The simplest way to accomplish this is to add, |
11 |
> |
12 |
> # Run every two hours |
13 |
> 0 */2 * * * root find -L /etc/cron.bihourly -type f -executable \ |
14 |
> -execdir '{}' \; |
15 |
> |
16 |
> in the global /etc/crontab. I'm sure this is horribly deficient |
17 |
> according to whoever implemented the run-crons stuff, but for me the |
18 |
> additional clarity is worth it. |
19 |
> |
20 |
> You can of course add anything else you like in the global/user |
21 |
> crontabs, and they'll work normally. |
22 |
|
23 |
OK, I've moved all of my user crontabs (including root) to /etc/crontab. |
24 |
|
25 |
> But be careful: do you really want `emerge -puDN` to run 15 minutes |
26 |
> after you start an `eix-sync`? Or do you just want it to run when |
27 |
> `eix-sync` is done? If it's the latter, you don't want to schedule it 15 |
28 |
> minutes later -- you could hit a slow mirror and still be updating when |
29 |
> the `emerge` kicks off. In that case it's better to put all of the |
30 |
> commands in one script, and schedule that when you want. That way the |
31 |
> commands occur in sequence, and you can bail out if something fails. |
32 |
|
33 |
Done. |
34 |
|
35 |
> > I think it's better for me to pipe the commands to mailx. I get mail if |
36 |
> > I run this on the command line |
37 |
> > |
38 |
> > emerge -pvDuN world | /usr/bin/mail -s "subject" -a "From: from" |
39 |
> > my@×××××.com <mailto:my@×××××.com> |
40 |
> > |
41 |
> > But I don't get any mail when it runs in the crontab. Do you know why |
42 |
> > that's happening? I do get mail from 'emerge -pvDuN world' run in the |
43 |
> > crontab without piping it to mail. |
44 |
|
45 |
I got it working in /etc/crontab. Should I file a bug for |
46 |
http://www.gentoo.org/doc/en/cron-guide.xml to mention that vixie-cron must |
47 |
be restarted when making changes to /etc/crontab? It says: |
48 |
|
49 |
"Note that only Vixie-cron schedules jobs in /etc/crontab automatically." |
50 |
|
51 |
> I'm not sure. I do the same thing, though, albeit with a temporary file |
52 |
> (and it works). Maybe try `echo`ing the output to a file? This script |
53 |
> emails me the current iptables to make sure fail2ban hasn't gone berserk: |
54 |
> |
55 |
> #!/bin/bash |
56 |
> |
57 |
> # Send the current iptables -L -n output to the postmaster. |
58 |
> |
59 |
> TMPFILE=/tmp/iptables-state.log |
60 |
> MAILADDR="postmaster@×××××××.com" |
61 |
> |
62 |
> echo "To: $MAILADDR" > $TMPFILE |
63 |
> echo "From: root@×××××××××××.com" >> $TMPFILE |
64 |
> echo "Subject: mx1 iptables state" >> $TMPFILE |
65 |
> |
66 |
> iptables -L -n >> $TMPFILE |
67 |
> |
68 |
> sendmail -f root@×××××××××××.com \ |
69 |
> $MAILADDR \ |
70 |
> < $TMPFILE |
71 |
> |
72 |
> rm $TMPFILE |
73 |
> |
74 |
> It's not very fancy but it does work. If a temp file works for you, it |
75 |
> might help you narrow down the problem. |
76 |
|
77 |
Wouldn't you rather use a one-liner like this? |
78 |
|
79 |
iptables -L -n | mail -s "mx1 iptables state" -a "From: root@×××××××××××.com" |
80 |
postmaster@×××××××.com |
81 |
|
82 |
- Grant |