3:16 p.m.
I have my computers registered with the Linux Counter, and my main
desktop machine is supposed to update its status once a week, using a
cron job:
# added by lico-update.sh version 0.3.14
58 11 * * 4 /home/joe/bin/lico-update.sh -m
The permissions on the script are right, and if run manually, it works.
This worked fine under Fedora 16, but doesn't now that I'm running F
17. Does anybody know what's happened, or how to find out?
12:39 p.m.
On 03/23/2013 02:48 AM, Michael Schwendt wrote:
Well, as I've asked: Do other cron jobs work for you if you
install them
in the same way? And it would be normal (default) behaviour for them to
be logged in /var/log/cron - grep joe /var/log/cron would tell.
I don't have any other, so I can't tell.
4:57 p.m.
On 23 Mar 2013 at 14:43, Joe Zeff wrote:
Date sent: Sat, 23 Mar 2013 14:43:44 -0700
From: Joe Zeff <joe(a)zeff.us>
To: Community support for Fedora users
<users(a)lists.fedoraproject.org>
Subject: Re: Problem with cron
On 03/23/2013 11:56 AM, Steven Stern wrote:
> One of those things that can bite you in the butt is that the
> environment for /bin/sh might be different than than in /bin/bash,
> especially as invoked by cron.
Somebody suggested adding something new to crontab and seeing if it
works. I tried it. Alas, even though I have both EDITOR and VISUAL
set in both .bashrc and .bash_profile, crontab -e insists on invoking
vi, an editor that I despise, and refuse to learn. (I prefer nano,
and have that set as my default editor for EVERYTHING in a terminal.)
Does anybody know how to force crontab to do what I want, not what
it's author wants? -- users mailing list users(a)lists.fedoraproject.org
What is showing in the /var/log/cron file?
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users Guidelines:
http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question?
Ask away: http://ask.fedoraproject.org
+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes@kuentos.guam.net
mailto:msetzerii@gmail.com
http://www.guam.net/home/mikes
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+
http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC@HOME CREDITS
SETI 14241123.577007 | EINSTEIN 10516707.209852
ROSETTA 6622686.028717 | ABC 15903416.868091
3:46 p.m.
On 04/19/2013 01:10 PM, Michael Schwendt wrote:
I've been very busy recently and only had a brief look at some
procmail
filtered folders, where the question you had asked was still unanswered.
So, I replied.
Oh. OK, asked and answered. And, I'd like to mention that I didn't
mean to imply that your comment was a twitticism, just that the other
one I was mentioning was. Glad that I didn't accidentally insult you.
3:10 p.m.
On Wed, 17 Apr 2013 10:49:45 -0700, Joe Zeff wrote:
What I don't understand is why you're bothering with this
three weeks
later. It's just like over at fedoraforum.org where somebody made a
foolish suggestion today about an issue I'd marked as [SOLVED] six days
ago, with a complete explanation of what caused it that had nothing to
do with today's twiticism.
I've been very busy recently and only had a brief look at some procmail
filtered folders, where the question you had asked was still unanswered.
So, I replied.
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc6.git2.3.fc19.x86_64
loadavg: 0.65 0.63 0.51
12:49 p.m.
On 04/17/2013 02:57 AM, Michael Schwendt wrote:
I'm not sure I understand the question, because above example
already
shows how the $EDITOR environment variable is set to nano for crontab
to pick it up.
What I don't understand is why you're bothering with this three weeks
later. It's just like over at fedoraforum.org where somebody made a
foolish suggestion today about an issue I'd marked as [SOLVED] six days
ago, with a complete explanation of what caused it that had nothing to
do with today's twiticism.
4:57 a.m.
On Sun, 24 Mar 2013 10:02:31 -0700, Joe Zeff wrote:
On 03/24/2013 03:12 AM, Michael Schwendt wrote:
> Verify that $EDITOR is set actually. $EDITOR is evaluated here just fine.
> And
>
> $ echo $EDITOR
> emacs
> $ EDITOR=nano crontab -e
> <Ctrl-X>
> crontab: no changes made to crontab
As I'm sure I've written before, I've checked this with echo, and
they're set. However, do they need to be Exported to be picked up by
crontab?
I'm not sure I understand the question, because above example already
shows how the $EDITOR environment variable is set to nano for crontab
to pick it up.
The example could be rewritten to be more clear:
$ echo $EDITOR
emacs
$ EDITOR=nano
$ echo $EDITOR
nano
$ crontab -e
<Ctrl-X>
crontab: no changes made to crontab
The "Ctrl-X" refers to exiting "nano". One can see that $EDITOR is
set
correctly in the environment and that "crontab" picks it up.
Exporting refers to whether parts of the environment (here a variable)
would be automatically made available to subsequent commands (which
can be especially important for running shell-scripts).
$ TEST=hello
$ echo $TEST
hello
$ bash
$ echo $TEST
$ exit
$ export TEST
$ bash
$ echo $TEST
hello
$ exit
$
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc6.git2.1.fc19.x86_64
loadavg: 0.14 0.13 0.14
2:15 p.m.
On 03/23/2013 11:56 AM, Steven Stern wrote:
One of those things that can bite you in the butt is that the
environment for /bin/sh might be different than than in /bin/bash,
especially as invoked by cron.
It worked fine in F 16, and it works from a command line. I'm not
saying you're wrong, but if you're right, what might have changed?
Also, shouldn't the line starting with "scriptversion"
be a comment?
No. It's setting a variable that's used later in several places. Do a
search on scriptversion, and you'll see.
12:18 p.m.
On Sat, 23 Mar 2013 23:12:44 -0700, Joe Zeff wrote:
On 03/23/2013 10:47 PM, Garry T. Williams wrote:
> On 3-23-13 15:21:37 Joe Zeff wrote:
>> [joe@khorlia ~]$ echo $EDITOR nano
>
> This is your problem. You're missing a full path and crontab(1)
> requires it.
>
>
If so, why does this work:
EDITOR=nano crontab -e
On Fedora 18:
[mdeggers@trident ~]$ export EDITOR=nano
[mdeggers@trident ~]$ printenv EDITOR
nano
[mdeggers@trident ~]$ crontab -e
invokes nano
[mdeggers@trident ~]$ which nano
/usr/bin/nano
(Don't know how I got /bin/nano earlier - maybe I was on the wrong machine)
So, I have no idea why it doesn't work on your machine. It works here.
. . . . just my two cents.
/mde/
12:07 p.m.
Am 24.03.2013 18:03, schrieb Joe Zeff:
On 03/24/2013 03:19 AM, Michael Schwendt wrote:
> I'm also not surprised, but I've asked about /var/log/cron early.
Yes, and I've reported before that all it showed was my examining (and editing)
crontab
if someone aks for a log file he asks for it's content and
NOT for the interpretation of the guy with the problem
there is no "but" and no "if"
if you need help show informations
show them fully and do not strip them as you believe it is good
YOU MAY not understand details of the output which could lead
the expert to teh solution of your problem - it does not matter
if it would have helped in exactly this case
as example: if i request a specific information and get a stripped
or mangled one i often lose any interest to follow the problem
12:02 p.m.
On 03/24/2013 03:12 AM, Michael Schwendt wrote:
Verify that $EDITOR is set actually. $EDITOR is evaluated here just
fine.
And
$ echo $EDITOR
emacs
$ EDITOR=nano crontab -e
<Ctrl-X>
crontab: no changes made to crontab
As I'm sure I've written before, I've checked this with echo, and
they're set. However, do they need to be Exported to be picked up by
crontab?
5:19 a.m.
On Sat, 23 Mar 2013 18:00:22 -0700, Joe Zeff wrote:
On 03/23/2013 04:36 PM, Reindl Harald wrote:
> and what says "ps aux | grep cron"?
Neither cron nor anacron is listed. Somehow, I'm not surprised.
I'm also not surprised, but I've asked about /var/log/cron early.
It tells much about whether crond is running and processing cron jobs,
including system tasks. So many posts in this thread, and so many
words in each of them, and the solution could have been found much
faster with a little bit of trouble-shooting.
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git1.3.fc19.x86_64
loadavg: 0.15 0.22 0.30
5:12 a.m.
On Sat, 23 Mar 2013 14:43:44 -0700, Joe Zeff wrote:
Somebody suggested adding something new to crontab and seeing if it
works. I tried it. Alas, even though I have both EDITOR and VISUAL set
in both .bashrc and .bash_profile, crontab -e insists on invoking vi, an
editor that I despise, and refuse to learn. (I prefer nano, and have
that set as my default editor for EVERYTHING in a terminal.) Does
anybody know how to force crontab to do what I want, not what it's
author wants?
Verify that $EDITOR is set actually. $EDITOR is evaluated here just fine.
And
$ echo $EDITOR
emacs
$ EDITOR=nano crontab -e
<Ctrl-X>
crontab: no changes made to crontab
works for me as a test for using "nano". I use a custom $EDITOR for a very
long time, and crontab -e has accepted it happily for a very long time,
too.
Only somebody, who can reproduce your problems or who has seen the
problems before, may be able to help you.
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git1.3.fc19.x86_64
loadavg: 0.37 0.48 0.39
8:54 p.m.
Am 24.03.2013 02:37, schrieb Joe Zeff:
On 03/23/2013 06:25 PM, Reindl Harald wrote:
> pfff - and why do you not start crond?
>
> systemctl enable crond.service
> systemctl start crond.service
> systemctl status crond.service
As it happens, I was just running around the Fedora documentation and found those lines.
It's now active. Thanx
anyway, because I might not have thought of the right place to look. The only question
left is, why isn't this on
by default?
i can not remember a linux without crond enabled
but however, "systemctl list-units | grep service" should
be a default maintain-action for everybody to enable
used services and much more important disable unused ones
it's strange that you have so many years experience as
you say but such basic things are always a long thread
by not check basics
9:03 p.m.
On 03/23/2013 06:54 PM, Reindl Harald wrote:
it's strange that you have so many years experience as
you say but such basic things are always a long thread
by not check basics
I have many years of experience with computers in general, and over a
decade with Linux, but I've never used it professionally, or
administered anything but my own computer. Thus, I have considerable
knowledge of certain parts of Linux, but there are, I know, great big
gaping holes. And, each time something like this happens, I try to
learn from it and not make the same mistake again.
8:37 p.m.
On 03/23/2013 06:25 PM, Reindl Harald wrote:
pfff - and why do you not start crond?
systemctl enable crond.service
systemctl start crond.service
systemctl status crond.service
As it happens, I was just running around the Fedora documentation and
found those lines. It's now active. Thanx anyway, because I might not
have thought of the right place to look. The only question left is, why
isn't this on by default?
8:25 p.m.
Am 24.03.2013 02:00, schrieb Joe Zeff:
On 03/23/2013 04:36 PM, Reindl Harald wrote:
> and what says "ps aux | grep cron"?
Neither cron nor anacron is listed. Somehow, I'm not surprised
pfff - and why do you not start crond?
systemctl enable crond.service
systemctl start crond.service
systemctl status crond.service
6:36 p.m.
Am 24.03.2013 00:34, schrieb Joe Zeff:
Sorry, but I don't use sudo. Ever. In fact, when I did a clean
install on my laptop, I made sure it wasn't
included. If I need to be root, I know and understand how su works
so just do it
> Start the cron process
Better yet:
EDITOR=nano crontab -e
worked just fine. Why? Who knows; It Just Worked.
However, the new item didn't run when expected. (I'd set it to run about ten
minutes after the edit.) I'm not
sure, at this point, if cron is actually active or not
and what says "ps aux | grep cron"?
6:34 p.m.
On 03/23/2013 04:20 PM, Steven Stern wrote:
Sometimes we just have to bite the bullet. You're trying to add
ONE
LINE to crontab. Just do it. Or....
Stop the cron process
edit /var/spool/yourid (with your favorite editor as root via sudo)
Sorry, but I don't use sudo. Ever. In fact, when I did a clean install
on my laptop, I made sure it wasn't included. If I need to be root, I
know and understand how su works.
Start the cron process
Better yet:
EDITOR=nano crontab -e
worked just fine. Why? Who knows; It Just Worked.
However, the new item didn't run when expected. (I'd set it to run
about ten minutes after the edit.) I'm not sure, at this point, if cron
is actually active or not.
6:06 p.m.
On 03/23/2013 04:43 PM, Joe Zeff wrote:
On 03/23/2013 11:56 AM, Steven Stern wrote:
> One of those things that can bite you in the butt is that the
> environment for /bin/sh might be different than than in /bin/bash,
> especially as invoked by cron.
Somebody suggested adding something new to crontab and seeing if it
works. I tried it. Alas, even though I have both EDITOR and VISUAL set
in both .bashrc and .bash_profile, crontab -e insists on invoking vi, an
editor that I despise, and refuse to learn. (I prefer nano, and have
that set as my default editor for EVERYTHING in a terminal.) Does
anybody know how to force crontab to do what I want, not what it's
author wants?
Suck it up!
Arrow to the last line of the file. Press SHIFT-A. Press Enter. Type
in your new line. Press ESC when done. Press :. Type q. Press Enter.
--
-- Steve
6:20 p.m.
On 03/23/2013 06:13 PM, Joe Zeff wrote:
On 03/23/2013 04:06 PM, Steven Stern wrote:
> Suck it up!
>
FOAD
Just because you like using an obsolete, antique editor that was
designed before CRTs were in use doesn't mean that everybody else has to
use it. Yes, I started out with punched cards, but I've also moved on.
Maybe it's time for you to do the same?
Sometimes we just have to bite the bullet. You're trying to add ONE
LINE to crontab. Just do it. Or....
Stop the cron process
edit /var/spool/yourid (with your favorite editor as root via sudo)
Start the cron process
--
-- Steve
6:14 p.m.
Am 24.03.2013 00:04, schrieb Mark Eggers:
On Sat, 23 Mar 2013 15:21:37 -0700, Joe Zeff wrote:
> On 03/23/2013 02:59 PM, Ed Greshko wrote:
>> egreshko@meimei ~]$ export EDITOR=/usr/bin/nano [egreshko@meimei ~]$
>> crontab -e
>
> [joe@khorlia ~]$ echo $EDITOR nano
>
> And, if I just run nano from the command line, it works, because
> /usr/bin is on my PATH.
On Fedora 18, nano is in /bin. I don't know if that's where it is on
Fedora 17
and since F17 /bin as /usr/bin is the same
https://fedoraproject.org/wiki/Features/UsrMove
6:13 p.m.
On 03/23/2013 04:06 PM, Steven Stern wrote:
Suck it up!
FOAD
Just because you like using an obsolete, antique editor that was
designed before CRTs were in use doesn't mean that everybody else has to
use it. Yes, I started out with punched cards, but I've also moved on.
Maybe it's time for you to do the same?
6:04 p.m.
On Sat, 23 Mar 2013 15:21:37 -0700, Joe Zeff wrote:
On 03/23/2013 02:59 PM, Ed Greshko wrote:
> egreshko@meimei ~]$ export EDITOR=/usr/bin/nano [egreshko@meimei ~]$
> crontab -e
[joe@khorlia ~]$ echo $EDITOR nano
And, if I just run nano from the command line, it works, because
/usr/bin is on my PATH.
On Fedora 18, nano is in /bin. I don't know if that's where it is on
Fedora 17.
[mdeggers@trident ~]$ which nano
/bin/nano
So:
export EDITOR=/bin/nano
crontab -e
brings up crontab (empty for me) in the nano editor. Since I prefer vi, I
immediately Ctrl-X out of the editor and unset the environment variable
with:
unset EDITOR
And now I'm back to vi.
To find out where nano is on Fedora 17, type:
which nano
from the command line. Then adjust your export command accordingly.
. . . . just my two cents
/mde/
4:59 p.m.
On 03/24/13 05:43, Joe Zeff wrote:
On 03/23/2013 11:56 AM, Steven Stern wrote:
> One of those things that can bite you in the butt is that the
> environment for /bin/sh might be different than than in /bin/bash,
> especially as invoked by cron.
Somebody suggested adding something new to crontab and seeing if it works. I tried it.
Alas, even though I have both EDITOR and VISUAL set in both .bashrc and .bash_profile,
crontab -e insists on invoking vi, an editor that I despise, and refuse to learn. (I
prefer nano, and have that set as my default editor for EVERYTHING in a terminal.) Does
anybody know how to force crontab to do what I want, not what it's author wants?
egreshko@meimei ~]$ export EDITOR=/usr/bin/nano
[egreshko@meimei ~]$ crontab -e
--
From now on, at least during winter time, Im going to blame all
spelling an grammar erros on the cat sitting on my chest every time I sit down at the
computer....
5:25 p.m.
Am 23.03.2013 23:19, schrieb Joe Zeff:
On 03/23/2013 02:57 PM, Michael D. Setzer II wrote:
> What is showing in the /var/log/cron file?
>
Just that I began editing it. I don't know vi, I don't want to, and I've no
idea how to exit except for killing
the terminal, which I did. I say, "Fi on vi!"
besides the fact that /var/log/cron has nothing to do with vi
so do not use it - what is your problem?
see blow - it's even not installed on production servers
qith around 50 cronjobs, so please stop whining about it
[root@arrakis:~]$ which vi
/usr/bin/which: no vi in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/scripts)
5:09 p.m.
Am 23.03.2013 23:00, schrieb Joe Zeff:
On 03/23/2013 02:47 PM, Reindl Harald wrote:
> why do you not simply place your cronjobs in/etc/cron.d/?
>
> i maintain a lot of servers with tons of cronjobs running as
> different users and never in my life called the contab-command
Because crontab is specifically written for this, and I saw no reason not to use it
who cares - cronobs are one-liners
*/10 * * * * apache nice -n 19 ionice -c 3 bash /scripts/cleanup-uploadtemp.cron
_______________________
also take a look at anacrontab
normally you have there a line for daily jobs
touch /etc/cron.daily/mycronjob.sh
chmod 700 /etc/cron.daily/mycronjob.sh
and in this file place a shebang and
su -c 'whatever' user
there are millions of ways for cronjobs and all of them
can be done by any ordinary text-editor
_______________________
[root@srv-rhsoft:~]$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=5
# the jobs will be started during the following hours only
START_HOURS_RANGE=0-12
#period in days delay in minutes job-identifier command
1 5 cron.daily nice -n 19 run-parts
/etc/cron.daily
7 25 cron.weekly nice -n 19 run-parts
/etc/cron.weekly
@monthly 45 cron.monthly nice -n 19 run-parts
/etc/cron.monthly
5 p.m.
On 03/23/2013 02:47 PM, Reindl Harald wrote:
why do you not simply place your cronjobs in/etc/cron.d/?
i maintain a lot of servers with tons of cronjobs running as
different users and never in my life called the contab-command
Because crontab is specifically written for this, and I saw no reason
not to use it.
5 p.m.
would you please strip your quotes
especially footers and signatures
a 7 KB message for a one-liner is ridiculus
Am 23.03.2013 22:57, schrieb Michael D. Setzer II:
[stripped fullquote]
What is showing in the /var/log/cron file?
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users Guidelines:
> http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question?
> Ask away: http://ask.fedoraproject.org
+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes@kuentos.guam.net
mailto:msetzerii@gmail.com
http://www.guam.net/home/mikes
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+
http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC@HOME CREDITS
SETI 14241123.577007 | EINSTEIN 10516707.209852
ROSETTA 6622686.028717 | ABC 15903416.868091
2:08 p.m.
On 03/23/2013 11:36 AM, Michael Schwendt wrote:
On Sat, 23 Mar 2013 10:39:00 -0700, Joe Zeff wrote:
> On 03/23/2013 02:48 AM, Michael Schwendt wrote:
>> Well, as I've asked: Do other cron jobs work for you if you install them
>> in the same way? And it would be normal (default) behaviour for them to
>> be logged in /var/log/cron - grep joe /var/log/cron would tell.
>
> I don't have any other, so I can't tell.
That's a surprising answer. In other words, you haven't done any
trouble-shooting at all.
Actually, I haven't done any trouble-shooting *yet,* because this is the
first time I've ever had this type of problem show up. I will, however,
be trying your suggestion and getting back to you next Thursday.
4:47 p.m.
Am 23.03.2013 22:43, schrieb Joe Zeff:
On 03/23/2013 11:56 AM, Steven Stern wrote:
> One of those things that can bite you in the butt is that the
> environment for /bin/sh might be different than than in /bin/bash,
> especially as invoked by cron.
Somebody suggested adding something new to crontab and seeing if it works. I tried it.
Alas, even though I have
both EDITOR and VISUAL set in both .bashrc and .bash_profile, crontab -e insists on
invoking vi, an editor that I
despise, and refuse to learn. (I prefer nano, and have that set as my default editor for
EVERYTHING in a
terminal.) Does anybody know how to force crontab to do what I want, not what it's
author wants?
why do you not simply place your cronjobs in /etc/cron.d/?
i maintain a lot of servers with tons of cronjobs running as
different users and never in my life called the contab-command
4:43 p.m.
On 03/23/2013 11:56 AM, Steven Stern wrote:
One of those things that can bite you in the butt is that the
environment for /bin/sh might be different than than in /bin/bash,
especially as invoked by cron.
Somebody suggested adding something new to crontab and seeing if it
works. I tried it. Alas, even though I have both EDITOR and VISUAL set
in both .bashrc and .bash_profile, crontab -e insists on invoking vi, an
editor that I despise, and refuse to learn. (I prefer nano, and have
that set as my default editor for EVERYTHING in a terminal.) Does
anybody know how to force crontab to do what I want, not what it's
author wants?
1:56 p.m.
On 03/23/2013 12:47 PM, Joe Zeff wrote:
On 03/23/2013 08:58 AM, Steven Stern wrote:
> On 03/22/2013 03:16 PM, Joe Zeff wrote:
>> I have my computers registered with the Linux Counter, and my main
>> desktop machine is supposed to update its status once a week, using a
>> cron job:
>>
>> # added by lico-update.sh version 0.3.14
>> 58 11 * * 4 /home/joe/bin/lico-update.sh -m
>>
>> The permissions on the script are right, and if run manually, it works.
>> This worked fine under Fedora 16, but doesn't now that I'm running F
>> 17. Does anybody know what's happened, or how to find out?
>
> A couple of thoughts:
> 1. Does the script have executable permissions?
Already answered in what you quote.
> 2. Is cron working at all? Add "58 11 * * 4 touch /tmp/cron.test" as
> another cron job. Does the test file date change?
An interesting possibility.
> 3. Just for laughs, check the SELinux logs to see if there's an AVC. It
> may be that the script that created and installed the file didn't set
> the selinux permissions correctly.
>
I'm not getting any alerts, and if that were the issue, I would. And,
if you'd like to examine the script, you can find it here:
http://linuxcounter.net/script/lico-update.sh
One of those things that can bite you in the butt is that the
environment for /bin/sh might be different than than in /bin/bash,
especially as invoked by cron.
Also, shouldn't the line starting with "scriptversion" be a comment?
--
-- Steve
1:36 p.m.
On Sat, 23 Mar 2013 10:39:00 -0700, Joe Zeff wrote:
On 03/23/2013 02:48 AM, Michael Schwendt wrote:
> Well, as I've asked: Do other cron jobs work for you if you install them
> in the same way? And it would be normal (default) behaviour for them to
> be logged in /var/log/cron - grep joe /var/log/cron would tell.
I don't have any other, so I can't tell.
That's a surprising answer. In other words, you haven't done any
trouble-shooting at all.
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git0.4.fc19.x86_64
loadavg: 0.15 0.22 0.22
1 p.m.
Am 23.03.2013 18:43, schrieb Richard Vickery:
On Fri, Mar 22, 2013 at 10:03 PM, David G. Miller wrote:
Perchance you're not in crontab.allow?
where is crontab.allow? I just went to locate the file and couldn't
it simply does not exist
updatedb and locate are your friend
[root@srv-rhsoft:~]$ locate cron | grep allow
/etc/cron.allow
but it does NOT matter for /etc/crontab or /etc/cron.d
it conrols which users are allowed to create cron-entries
12:47 p.m.
On 03/23/2013 08:58 AM, Steven Stern wrote:
On 03/22/2013 03:16 PM, Joe Zeff wrote:
> I have my computers registered with the Linux Counter, and my main
> desktop machine is supposed to update its status once a week, using a
> cron job:
>
> # added by lico-update.sh version 0.3.14
> 58 11 * * 4 /home/joe/bin/lico-update.sh -m
>
> The permissions on the script are right, and if run manually, it works.
> This worked fine under Fedora 16, but doesn't now that I'm running F
> 17. Does anybody know what's happened, or how to find out?
A couple of thoughts:
1. Does the script have executable permissions?
Already answered in what you quote.
2. Is cron working at all? Add "58 11 * * 4 touch
/tmp/cron.test" as
another cron job. Does the test file date change?
An interesting possibility.
3. Just for laughs, check the SELinux logs to see if there's an
AVC. It
may be that the script that created and installed the file didn't set
the selinux permissions correctly.
I'm not getting any alerts, and if that were the issue, I would. And,
if you'd like to examine the script, you can find it here:
http://linuxcounter.net/script/lico-update.sh
12:43 p.m.
On Fri, Mar 22, 2013 at 10:03 PM, David G. Miller <dave(a)davenjudy.org>wrote:
Joe Zeff <joe <at> zeff.us> writes:
>
> I have my computers registered with the Linux Counter, and my main
> desktop machine is supposed to update its status once a week, using a
> cron job:
>
> # added by lico-update.sh version 0.3.14
> 58 11 * * 4 /home/joe/bin/lico-update.sh -m
>
> The permissions on the script are right, and if run manually, it works.
> This worked fine under Fedora 16, but doesn't now that I'm running F
> 17. Does anybody know what's happened, or how to find out?
From the crontab man page:
The cron jobs could be allow or disallow for different users. For
classical
crontab there exists cron.allow and cron.deny files. If cron.allow file
exists, then you must be listed therein in order to be allowed to use this
command.
Perchance you're not in crontab.allow?
Cheers,
Dave
--
where is crontab.allow? I just went to locate the file and couldn't.
10:58 a.m.
On 03/22/2013 03:16 PM, Joe Zeff wrote:
I have my computers registered with the Linux Counter, and my main
desktop machine is supposed to update its status once a week, using a
cron job:
# added by lico-update.sh version 0.3.14
58 11 * * 4 /home/joe/bin/lico-update.sh -m
The permissions on the script are right, and if run manually, it works.
This worked fine under Fedora 16, but doesn't now that I'm running F
17. Does anybody know what's happened, or how to find out?
A couple of thoughts:
1. Does the script have executable permissions?
2. Is cron working at all? Add "58 11 * * 4 touch /tmp/cron.test" as
another cron job. Does the test file date change?
3. Just for laughs, check the SELinux logs to see if there's an AVC. It
may be that the script that created and installed the file didn't set
the selinux permissions correctly.
--
-- Steve
4:48 a.m.
On Fri, 22 Mar 2013 14:12:02 -0700, Joe Zeff wrote:
As the included comment says,
I'm not familiar with any lico-update.sh script (and have never used it
for the LiCo project), so I could not guess what it does, especially not
since it added an absolute path for the command to execute. Hence my
question.
it was added to my crontab by the script
when I ran the installation routine, and I checked it with crontab -l to
make sure exactly what it said.
Okay.
I came to the conclusion that it's not
getting run because of two things: the page at the Linux Counter doesn't
update when it should and there's no mention of the script being run in
/var/log/cron. However, if I run the script from the command line, the
counter updates.
Well, as I've asked: Do other cron jobs work for you if you install them
in the same way? And it would be normal (default) behaviour for them to
be logged in /var/log/cron - grep joe /var/log/cron would tell.
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git0.4.fc19.x86_64
loadavg: 0.19 0.14 0.23
12:03 a.m.
Joe Zeff <joe <at> zeff.us> writes:
I have my computers registered with the Linux Counter, and my main
desktop machine is supposed to update its status once a week, using a
cron job:
# added by lico-update.sh version 0.3.14
58 11 * * 4 /home/joe/bin/lico-update.sh -m
The permissions on the script are right, and if run manually, it works.
This worked fine under Fedora 16, but doesn't now that I'm running F
17. Does anybody know what's happened, or how to find out?
From the crontab man page:
The cron jobs could be allow or disallow for different users. For classical
crontab there exists cron.allow and cron.deny files. If cron.allow file
exists, then you must be listed therein in order to be allowed to use this
command.
Perchance you're not in crontab.allow?
Cheers,
Dave
4:12 p.m.
On 03/22/2013 01:49 PM, Michael Schwendt wrote:
On Fri, 22 Mar 2013 13:16:16 -0700, Joe Zeff wrote:
> I have my computers registered with the Linux Counter, and my main
> desktop machine is supposed to update its status once a week, using a
> cron job:
>
> # added by lico-update.sh version 0.3.14
> 58 11 * * 4 /home/joe/bin/lico-update.sh -m
>
> The permissions on the script are right, and if run manually, it works.
> This worked fine under Fedora 16, but doesn't now that I'm running F
> 17. Does anybody know what's happened, or how to find out?
How/where did you install this cron job? In "joe"'s crontab via
"crontab -e"?
Or in the system-wide crontab (e.g. one of/etc/cron*)?
How did you reach the conclusion that the job isn't executed at all?
Does /var/log/cron mention it? Do other cron jobs work for you if you
install them in the same way?
As the included comment says, it was added to my crontab by the script
when I ran the installation routine, and I checked it with crontab -l to
make sure exactly what it said. I came to the conclusion that it's not
getting run because of two things: the page at the Linux Counter doesn't
update when it should and there's no mention of the script being run in
/var/log/cron. However, if I run the script from the command line, the
counter updates.
3:49 p.m.
On 03/22/2013 01:40 PM, suvayu ali wrote:
On Fri, Mar 22, 2013 at 9:16 PM, Joe Zeff <joe(a)zeff.us> wrote:
> Does anybody know what's happened, or how to find out?
Maybe save the output to a log file.
/home/joe/bin/lico-update.sh -m &> /tmp/mycron.log
There isn't any output. However, I've been thinking of adding this line
to the script:
date >> update.log
to see if and when it runs.
3:49 p.m.
On Fri, 22 Mar 2013 13:16:16 -0700, Joe Zeff wrote:
I have my computers registered with the Linux Counter, and my main
desktop machine is supposed to update its status once a week, using a
cron job:
# added by lico-update.sh version 0.3.14
58 11 * * 4 /home/joe/bin/lico-update.sh -m
The permissions on the script are right, and if run manually, it works.
This worked fine under Fedora 16, but doesn't now that I'm running F
17. Does anybody know what's happened, or how to find out?
How/where did you install this cron job? In "joe"'s crontab via
"crontab -e"?
Or in the system-wide crontab (e.g. one of/etc/cron*)?
How did you reach the conclusion that the job isn't executed at all?
Does /var/log/cron mention it? Do other cron jobs work for you if you
install them in the same way?
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git0.4.fc19.x86_64
loadavg: 0.51 0.68 0.74
4023
days inactive
4051
days old
51 comments
11 participants
participants (11)
-
David G. Miller (aka DaveAtFraud) -
Ed Greshko -
Garry Williams -
Joe Zeff -
Mark Eggers -
Michael D. Setzer II -
Michael Schwendt -
Reindl Harald -
Richard Vickery -
SternData -
Suvayu Ali