Discussion:
Why is atd daemon so fragile
(too old to reply)
root
2017-12-03 10:03:19 UTC
Permalink
I was experimenting with creating some one-shot events
using the at command. Sometimes I would kill a process
after it had started, other times the format of my
at command may have been faulty. Whatever the cause
I sometimes ran into the message "at daemon not running".
I shouldn't be easy, or even possible to shut down a
scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to
schedule.
Giovanni
2017-12-03 15:12:26 UTC
Permalink
Post by root
I was experimenting with creating some one-shot events
using the at command. Sometimes I would kill a process
after it had started, other times the format of my
at command may have been faulty. Whatever the cause
I sometimes ran into the message "at daemon not running".
I shouldn't be easy, or even possible to shut down a
scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to
schedule.
You shouldn't kill the daemon ('atd'). If you have to kill a scheduled
job you can use 'atrm' if the job is still in its queue or kill the
process if already started.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >
root
2017-12-03 17:42:24 UTC
Permalink
Post by Giovanni
Post by root
I was experimenting with creating some one-shot events
using the at command. Sometimes I would kill a process
after it had started, other times the format of my
at command may have been faulty. Whatever the cause
I sometimes ran into the message "at daemon not running".
I shouldn't be easy, or even possible to shut down a
scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to
schedule.
You shouldn't kill the daemon ('atd'). If you have to kill a scheduled
job you can use 'atrm' if the job is still in its queue or kill the
process if already started.
I didn't make myself clear. I an trying to implement an automatic
procedure that generates tasks to be executed at specific but
not foreseealble times. Some of these tasks seem to kill the daemon
themselves, so any subsequent automatic tasks are never executed.

I don't know why the daemon is killed, but I have to assume
that it will be killed. So, when the robot creates a new
task I could see if the daemon is running and, if so,
just execute the at command. If the daemon is not running
then I would start the daemon to execute the task.

It is simpler for the robot to just kill the daemon and
restart it before enabling the new task.

All this is supposed to run without my intervention.

I can be more specific: these tasks are scheduling recordings
of TV programs during the coming day.
Post by Giovanni
Ciao
Giovanni
Lew Pitcher
2017-12-03 18:25:43 UTC
Permalink
Post by root
Post by Giovanni
Post by root
I was experimenting with creating some one-shot events
using the at command. Sometimes I would kill a process
after it had started, other times the format of my
at command may have been faulty. Whatever the cause
I sometimes ran into the message "at daemon not running".
I shouldn't be easy, or even possible to shut down a
scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to
schedule.
You shouldn't kill the daemon ('atd'). If you have to kill a scheduled
job you can use 'atrm' if the job is still in its queue or kill the
process if already started.
I didn't make myself clear. I an trying to implement an automatic
procedure that generates tasks to be executed at specific but
not foreseealble times. Some of these tasks seem to kill the daemon
themselves, so any subsequent automatic tasks are never executed.
That would be the first thing to investigate. Why do your tasks kill the at
daemon (atd)? Since they /should not/ kill atd, they have a flaw, a bug,
that you should remedy before you proceed.
Post by root
I don't know why the daemon is killed, but I have to assume
that it will be killed. So, when the robot creates a new
task I could see if the daemon is running and, if so,
just execute the at command. If the daemon is not running
then I would start the daemon to execute the task.
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab with a
runlevels list of 2345" and an action of "respawn". This way, init(1) takes
care of restarting atd when (and if) it crashes).
Post by root
It is simpler for the robot to just kill the daemon and
restart it before enabling the new task.
All this is supposed to run without my intervention.
I can be more specific: these tasks are scheduling recordings
of TV programs during the coming day.
Post by Giovanni
Ciao
Giovanni
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
Rich
2017-12-03 18:49:13 UTC
Permalink
Post by Lew Pitcher
Post by root
Post by Giovanni
I was experimenting with creating some one-shot events using the
at command. Sometimes I would kill a process after it had
started, other times the format of my at command may have been
faulty. Whatever the cause I sometimes ran into the message "at
daemon not running". I shouldn't be easy, or even possible to
shut down a scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to schedule.
You shouldn't kill the daemon ('atd'). If you have to kill a
scheduled job you can use 'atrm' if the job is still in its queue
or kill the process if already started.
I didn't make myself clear. I an trying to implement an automatic
procedure that generates tasks to be executed at specific but not
foreseealble times. Some of these tasks seem to kill the daemon
themselves, so any subsequent automatic tasks are never executed.
That would be the first thing to investigate. Why do your tasks kill
the at daemon (atd)? Since they /should not/ kill atd, they have a
flaw, a bug, that you should remedy before you proceed.
Yes, very much so, find the bug and fix it.

In another thread in another newsgroup the same 'root' indicated that
they were running these tasks as the "root" user as well. Which means
the bugs in the tasks have the rights to kill the at deamon if they
shoot in the wrong direction. So they should figure out why they kill
the at deamon rather than jury-rig a restart of the deamon when it gets
killed.
Lew Pitcher
2017-12-03 18:57:01 UTC
Permalink
Post by Lew Pitcher
Post by root
Post by Giovanni
Post by root
I was experimenting with creating some one-shot events
using the at command. Sometimes I would kill a process
after it had started, other times the format of my
at command may have been faulty. Whatever the cause
I sometimes ran into the message "at daemon not running".
I shouldn't be easy, or even possible to shut down a
scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to
schedule.
You shouldn't kill the daemon ('atd'). If you have to kill a scheduled
job you can use 'atrm' if the job is still in its queue or kill the
process if already started.
I didn't make myself clear. I an trying to implement an automatic
procedure that generates tasks to be executed at specific but
not foreseealble times. Some of these tasks seem to kill the daemon
themselves, so any subsequent automatic tasks are never executed.
That would be the first thing to investigate. Why do your tasks kill the
at daemon (atd)? Since they /should not/ kill atd, they have a flaw, a
bug, that you should remedy before you proceed.
Post by root
I don't know why the daemon is killed, but I have to assume
that it will be killed. So, when the robot creates a new
task I could see if the daemon is running and, if so,
just execute the at command. If the daemon is not running
then I would start the daemon to execute the task.
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab with
a runlevels list of 2345" and an action of "respawn". This way, init(1)
takes care of restarting atd when (and if) it crashes).
Oops... wont work

It appears that atd(8) doesn't include a switch to "run in foreground", but
instead, it daemonizes itself. This will cause init to detect the process as
terminated when it is not (the process that init spawns terminates once it
spawns the atd daemon), causing it to repeatedly respawn in error.


So, it looks like your only recourse is to debug your problem.

I believe that, unless you are either writing your own entries in
/var/spool/atjobs (or /var/spool/atspool, for output), or sending unexpected
signals to atd(8), you should see atd crashing unexpectedly. What, exactly,
are you doing in your scripts?
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
Lew Pitcher
2017-12-03 18:58:03 UTC
Permalink
Post by Lew Pitcher
Post by Lew Pitcher
Post by root
Post by Giovanni
Post by root
I was experimenting with creating some one-shot events
using the at command. Sometimes I would kill a process
after it had started, other times the format of my
at command may have been faulty. Whatever the cause
I sometimes ran into the message "at daemon not running".
I shouldn't be easy, or even possible to shut down a
scheduling daemon. I have taken to killing the daemon
and restarting it for every at process I want to
schedule.
You shouldn't kill the daemon ('atd'). If you have to kill a scheduled
job you can use 'atrm' if the job is still in its queue or kill the
process if already started.
I didn't make myself clear. I an trying to implement an automatic
procedure that generates tasks to be executed at specific but
not foreseealble times. Some of these tasks seem to kill the daemon
themselves, so any subsequent automatic tasks are never executed.
That would be the first thing to investigate. Why do your tasks kill the
at daemon (atd)? Since they /should not/ kill atd, they have a flaw, a
bug, that you should remedy before you proceed.
Post by root
I don't know why the daemon is killed, but I have to assume
that it will be killed. So, when the robot creates a new
task I could see if the daemon is running and, if so,
just execute the at command. If the daemon is not running
then I would start the daemon to execute the task.
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab with
a runlevels list of 2345" and an action of "respawn". This way, init(1)
takes care of restarting atd when (and if) it crashes).
Oops... wont work
It appears that atd(8) doesn't include a switch to "run in foreground",
but instead, it daemonizes itself. This will cause init to detect the
process as terminated when it is not (the process that init spawns
terminates once it spawns the atd daemon), causing it to repeatedly
respawn in error.
So, it looks like your only recourse is to debug your problem.
I believe that, unless you are either writing your own entries in
/var/spool/atjobs (or /var/spool/atspool, for output), or sending
unexpected signals to atd(8), you should
NOT
Post by Lew Pitcher
see atd crashing unexpectedly.
What, exactly, are you doing in your scripts?
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
root
2017-12-03 19:48:17 UTC
Permalink
Post by Lew Pitcher
Post by Lew Pitcher
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab with
a runlevels list of 2345" and an action of "respawn". This way, init(1)
takes care of restarting atd when (and if) it crashes).
Oops... wont work
Damn.
Post by Lew Pitcher
It appears that atd(8) doesn't include a switch to "run in foreground", but
instead, it daemonizes itself. This will cause init to detect the process as
terminated when it is not (the process that init spawns terminates once it
spawns the atd daemon), causing it to repeatedly respawn in error.
So, it looks like your only recourse is to debug your problem.
I believe that, unless you are either writing your own entries in
/var/spool/atjobs (or /var/spool/atspool, for output), or sending unexpected
signals to atd(8), you should see atd crashing unexpectedly. What, exactly,
are you doing in your scripts?
Well, the first round of the script treated the at command incorrectly.
I thought I could invoke at like this;

at 5:00 pm do something...
when the correct invocation is:

echo do something....| at 5:00 pm

I let the first attempt run for a few examples and no
tasks were started which led me to the correct invocation.

Then there were several interations of the do something....
command which were wrong. One of those crashed the daemon
and none of the rest were run.

I corrected that problem and have had no problems with
atd since, but I think atd shouldn't have stopped regardless
of how I tried to invoke it, or what the process started
did.

Thanks for the help.
Lew Pitcher
2017-12-03 19:57:48 UTC
Permalink
Post by root
Post by Lew Pitcher
Post by Lew Pitcher
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab
with a runlevels list of 2345" and an action of "respawn". This way,
init(1) takes care of restarting atd when (and if) it crashes).
Oops... wont work
Damn.
Post by Lew Pitcher
It appears that atd(8) doesn't include a switch to "run in foreground",
but instead, it daemonizes itself. This will cause init to detect the
process as terminated when it is not (the process that init spawns
terminates once it spawns the atd daemon), causing it to repeatedly
respawn in error.
So, it looks like your only recourse is to debug your problem.
I believe that, unless you are either writing your own entries in
/var/spool/atjobs (or /var/spool/atspool, for output), or sending
unexpected signals to atd(8), you should see atd crashing unexpectedly.
What, exactly, are you doing in your scripts?
Well, the first round of the script treated the at command incorrectly.
I thought I could invoke at like this;
at 5:00 pm do something...
echo do something....| at 5:00 pm
Or
at 5 pm <<EOF
do something
EOF

or
at -f my_do_something_script 5 pm
Post by root
I let the first attempt run for a few examples and no
tasks were started which led me to the correct invocation.
Then there were several interations of the do something....
command which were wrong. One of those crashed the daemon
and none of the rest were run.
I corrected that problem and have had no problems with
atd since, but I think atd shouldn't have stopped regardless
of how I tried to invoke it, or what the process started
did.
Again, without knowing what it is that you or your scripts did, we can't
help figure out why atd(8) terminated. You are welcome to report the
instability to Pat Volkerding, or to the author of the suite, Thomas Koenig,
but they will want the same debugging information as we've suggested.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
root
2017-12-04 00:26:38 UTC
Permalink
Post by Lew Pitcher
Again, without knowing what it is that you or your scripts did, we can't
help figure out why atd(8) terminated. You are welcome to report the
instability to Pat Volkerding, or to the author of the suite, Thomas Koenig,
but they will want the same debugging information as we've suggested.
I'd solved my problem, my point was that nothing I did short of
killall atd
should have killed the daemon.

Just for the record, commands to the HDhomerun unit involve setting
a channel, a program within that channel, and a tuner. Finally you
start the stream and do what you want with it.

It occurred to me that I don't have to set the tuner. I can just
ask the unit status and pick a tuner that is free. Everything I
do with the unit releases the resource when the process is done.
Sylvain Robitaille
2017-12-04 17:26:42 UTC
Permalink
Post by Lew Pitcher
It appears that atd(8) doesn't include a switch to "run in
foreground", ...
Are we looking at the same atd???

ATD(8) System Manager's Manual ATD(8)

NAME
atd - run jobs queued for later execution

SYNOPSIS
atd [-l load_avg] [-b batch_interval] [-d] [-f] [-s]

DESCRIPTION
atd runs jobs queued by at(1).

OPTIONS
...
-f Run atd in the foreground.
...
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Lew Pitcher
2017-12-04 17:36:04 UTC
Permalink
Post by Sylvain Robitaille
Post by Lew Pitcher
It appears that atd(8) doesn't include a switch to "run in
foreground", ...
Are we looking at the same atd???
Apparently not.

Granted, I run a backlevel version of Slackware on my desktop.
Post by Sylvain Robitaille
ATD(8) System Manager's Manual ATD(8)
NAME
atd - run jobs queued for later execution
SYNOPSIS
atd [-l load_avg] [-b batch_interval] [-d] [-f] [-s]
DESCRIPTION
atd runs jobs queued by at(1).
OPTIONS
...
-f Run atd in the foreground.
...
ATD(8) Linux Programmer's Manual ATD(8)

NAME
atd - run jobs queued for later execution

SYNOPSIS
atd [-l load_avg] [-b batch_interval] [-d] [-s]

But, my server runs a more current version of Slackware

ATD(8) ATD(8)

NAME
atd - run jobs queued for later execution

SYNOPSIS
atd [-l load_avg] [-b batch_interval] [-d] [-f] [-s]

So, given a recent version of Slackware, it appears that it /would/ be
possible to run atd(8) from /etc/inittab.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
root
2017-12-04 19:51:36 UTC
Permalink
Post by Lew Pitcher
So, given a recent version of Slackware, it appears that it /would/ be
possible to run atd(8) from /etc/inittab.
Thanks to both. I will implement right now.
root
2017-12-04 20:26:52 UTC
Permalink
Post by root
Post by Lew Pitcher
So, given a recent version of Slackware, it appears that it /would/ be
possible to run atd(8) from /etc/inittab.
Thanks to both. I will implement right now.
It doesn't run: respawn too fast

Thanks for the idea.
Lew Pitcher
2017-12-04 20:55:42 UTC
Permalink
Post by root
Post by root
Post by Lew Pitcher
So, given a recent version of Slackware, it appears that it /would/ be
possible to run atd(8) from /etc/inittab.
Thanks to both. I will implement right now.
It doesn't run: respawn too fast
That's what you'd see if atd(8) daemonized itself. init thinks that atd
terminated (because, the process that init launched /did/ terminate, the
child of that process is the daemonized atd), and init attempts "respawn"
the process. If the process terminates fast enough and often enough, init
reports that fact, and suspends further respawning, assuming that root needs
to tweak a configuration value or fix a hardware/software issue.
Post by root
Thanks for the idea.
Does your version of atd(8) support the "-f" flag?
Did you specify the -f flag in your inittab entry?
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
root
2017-12-04 22:28:55 UTC
Permalink
Post by Lew Pitcher
Post by root
It doesn't run: respawn too fast
Does your version of atd(8) support the "-f" flag?
Did you specify the -f flag in your inittab entry?
I just used the line from rc.M:
/usr/sbin/atd -b 15 -l 1

and I see I should have run with -f: atd as a foreground
process. Later, I have to shut down the server to
change that again.
root
2017-12-04 22:53:46 UTC
Permalink
Post by root
Post by Lew Pitcher
Post by root
It doesn't run: respawn too fast
Does your version of atd(8) support the "-f" flag?
Did you specify the -f flag in your inittab entry?
/usr/sbin/atd -b 15 -l 1
and I see I should have run with -f: atd as a foreground
process. Later, I have to shut down the server to
change that again.
OK, adding the -f flag allows atd to run from inittab.

I removed the lines killing and restarting atd from
my PVR software.
Sylvain Robitaille
2017-12-05 15:45:33 UTC
Permalink
Post by root
/usr/sbin/atd -b 15 -l 1
and I see I should have run with -f: atd as a foreground
process. Later, I have to shut down the server to
change that again.
No you don't. See "man init" for details.

I hope that helps.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
root
2017-12-04 22:24:27 UTC
Permalink
Post by root
Post by root
Post by Lew Pitcher
So, given a recent version of Slackware, it appears that it /would/ be
possible to run atd(8) from /etc/inittab.
Thanks to both. I will implement right now.
It doesn't run: respawn too fast
Thanks for the idea.
I should have added I am running 14.2 Slack64.
root
2017-12-03 19:35:40 UTC
Permalink
Post by Lew Pitcher
That would be the first thing to investigate. Why do your tasks kill the at
daemon (atd)? Since they /should not/ kill atd, they have a flaw, a bug,
that you should remedy before you proceed.
It isn't my program, it seems to be the process that gets
started. In this case it is a task for the HDhomerun unit
and my invocation of that unit. Without going into details,
every command sent to the unit has things like tuner number
and channel. If I mix the order of those paramets, say, the
unit should not kill the atd.
Post by Lew Pitcher
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab with a
runlevels list of 2345" and an action of "respawn". This way, init(1) takes
care of restarting atd when (and if) it crashes).
That's the ticket, I will do that immediately.

Thanks for the idea.
Lew Pitcher
2017-12-03 19:51:51 UTC
Permalink
Post by root
Post by Lew Pitcher
That would be the first thing to investigate. Why do your tasks kill the
at daemon (atd)? Since they /should not/ kill atd, they have a flaw, a
bug, that you should remedy before you proceed.
It isn't my program, it seems to be the process that gets
started. In this case it is a task for the HDhomerun unit
and my invocation of that unit. Without going into details,
every command sent to the unit has things like tuner number
and channel. If I mix the order of those paramets, say, the
unit should not kill the atd.
It is very difficult to imagine /any/ combination of parameters to an
unknown and unspecified command that would (or would not) cause
/usr/sbin/atd to abnormally terminate. If you want help, you will have to be
specific.

From a very cursory examination, it appears that HDhomerun is a network-
attached TV tuner. The vendor supplies source code for both a library of
service functions (libhdhomerun) and a GTK GUI control application.

If you run some process to interact with the HDHomerun unit through at(1)
and atd(8), you most likely are NOT invoking the GUI control application.
And, since the library is useless on it's own, you aren't invoking the
library either. You are doing something else; either invoking a home-grown
commandline client that uses the libhdhomerun library, or somehow faking the
HDHomerun network protocols (using telnet, netcat, or some other networking
tool), invoked directly from a script. Perhaps I'm wrong here, enlighten me.

In any case, you've told us nothing that would isolate the problem.
Certainly, you've said nothing that would implicate a bug or mis-invoked
feature of atd(8) or at(1) in your troubles.

So, as I said before, you need to re-examine the code that you have written,
the script you pass to at(1), to see where the problem comes from.
Post by root
Post by Lew Pitcher
A much simpler way to do this would be to remove the invocation of
/usr/sbin/atd from /etc/rc.d/rc.M, and place it in your /etc/inittab with
a runlevels list of 2345" and an action of "respawn". This way, init(1)
takes care of restarting atd when (and if) it crashes).
That's the ticket, I will do that immediately.
Thanks for the idea.
See my previous followup. Moving /usr/sbin/atd to /etc/inittab won't work.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
Loading...