AT and CRON/CRONTAB, uncertainties

English Applications
#1

I can make them both work, but in each case, it takes several, frustrating workarounds.

AT is a strange duck. I can “at -f someScript now + 2 minutes”, as the documentation allows,
and a proper display is returned. BUT, 5 minutes later, if I do an atq, the jobs in the queue are listed,
and invariably the job submitted is still there, and will remain there. To force it out, I submit
“at -f dummyAt now” which causes the previously submitted job to run.

I do this from the command line in Konsole, as a “regular user”.

CRONTAB will give you heartburn. While AT gives you access to all exported variables, Crontab does not.
For example, **$SHLVL **and the other system, exported variables are accessible in a script that is run by Cron.
But, other variables that I set and export in .bashrc, are not accessible; e.g., $binDir which is my personal bin.
No way! You want it, set it in the script, and a complete path, not a relative one.

Any suggestions will be greatly appreciated and duly researched.

Regards,
Frank G.
:\

#2

It seems that you failed to read the man page of crontab

man 5 crontab

It tells you a lot about environment variables and also that it used sh and not bash.

#3

On 2015-05-26 07:36, frankeG wrote:
>
> I can make them both work, but in each case, it takes several,
> frustrating workarounds.
>
> AT is a strange duck. I can “at -f someScript now + 2 minutes”, as
> the documentation allows,
> and a proper display is returned. BUT, 5 minutes later, if I do an
> atq, the jobs in the queue are listed,
> and invariably the job submitted is still there, and will remain there.

Are you sure the atd daemon is running? I think it is not enabled by
default nowdays.


systemctl status atd.service

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#4

Hi,

Yes, like what Henk said you need to define your own PATH and either in the crontab file itself (if you want to just add a single line of code in the crontab file) or put it in the script you want to call from crontab.

echo "$PATH" 2>&1 >> /tmp/path

inside the crontab file and see what/which PATH is in available. :slight_smile:
of course you need to define the *** * * * * *** entry in crontab.

#5

Many thanks for the responses which I have read, and will do some further experimenting, after which I shall return with findings.
And, I shall read more manpages.

Regards,
Frank G.:wink:

#6

Robin_Listas ( of the fuzzy bird Avatar) points out:
Are you sure the atd daemon is running? I think it is not enabled by default nowdays.

And, he is quite correct; I inserted a start statement into my .bashrc so it is started automatically every time.
Previously I was issuing a simple

atd

at the command line. Now, the need for a second at no longer exists, and the commands are run at the correct time; much nicer to work with.

Now, the issue of crontab: Suggestions of Jetchisel and Carlos were most helpful:

It tells you a lot about environment variables and also that it used sh and not bash.

Yes, like what Henk said you need to define your own PATH and either in the crontab file itself (if you want to just add a single line of code in the crontab file) or put it in the script you want to call from crontab.

echo "$PATH" 2>&1 >> /tmp/path

inside the crontab file and see what/which PATH is in available.
of course you need to define the *** * * * * *** entry in crontab.

Both suggestions led to a lot of testing, learning, and relief. I ran the simplest of tests, and as Henk points out, what you get, from SH, is a very basic set of environmental variables. Then following the next suggestion, I am still playing with this, but I think the major problem is solved, lack of learning, and I can move forward.

I have some other problems to work on, but when I finish with them, I shall continue with crontab and post some general facts of use
that may be helpful to others.

Many thanks to all who responded and those who took the time to read and reason with my problem;

Regards
Frank G.:cool: (summer smile in Dallas)

#7

On 2015-06-10 02:56, frankeG wrote:
>
>> Robin_Listas ( of the fuzzy bird Avatar) points out:
>> Are you sure the atd daemon is running? I think it is not enabled by
>> default nowdays.
> And, he is quite correct; I inserted a start statement into my .bashrc
> so it is started automatically every time.

Huh, no, that’s not the way.

Do, in a terminal:


su -
systemctl status atd.service
systemctl start atd.service
systemctl enable atd.service
systemctl status atd.service

It the last command above says loaded and enabled, it should start
automatically on next boot.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#8

???

I am not sure what this does do, but in any case I am realy amazed that it does run owned by an end-user and still functions.

And one can only guess (I am not willing to test this) what happens on log-out, and/or second log-in.

It is a system daemon. should be started by root and Carlos gives you the correct way to do this.