I am using the below code to execute a TCL script inside a cisco router.
Router#tclsh
Router(tcl)#source tftp://tftp-server/tcl-script.tcl
Everyday I wanted to execute same script in my router at 10 PM. how can I schedule it?
Regards,
Varghese
You need look at kron command. See Cisco command reference.
And write something like this:
configure terminal
kron policy-list policy-day10pm
cli tclsh tftp://tftp-server/tcl-script.tcl
exit
kron occurrence day10pm at 22:00 recurring
policy-list policy-day10pm
exit
exit
show kron schedule
>> policy-day10pm inactive, will run again in 0 days 08:05:41 at 22:00 on
Related
I'm running a DAG that runs once per day. It starts with 9 concurrently running tasks that all do the same thing - each is basically polling S3 to see if that tasks's designated 1 file exists. Each task is the same code in Airflow and is put into the structure in the same way. I have 1 of these tasks, which, on random days, fails to "begin" - it won't enter the running stage. It just sits as queued . When it does this, here's what its log says
*** Log file isn't local.
*** Fetching here: http://:8793/log/my.dag.name./my_airflow_task/2020-03-14T07:00:00
*** Failed to fetch log file from worker.
*** Reading remote logs...
Could not read logs from s3://mybucket/airflow/logs/my.dag.name./my_airflow_task/2020-03-14T07:00:00
Why does this only happen on random days? All similar questions I've seen point to this error happening consistently, and once overcome, no longer continues. To "trick" this task into "running" I manually touch whatever the name of the log file is supposed to be, and then it changes to running.
So the issue appears that it had to do with the system's ownership rules regarding the folder the logs for that particular task wrote to. I used a CI tool to ship the new task_3 when I updated my Airflow's Python code to the production environment, so the task was created that way. When I peaked for log directory ownership, I noticed this for the tasks:
# inside/airflow/log/dir:
drwxrwxr-x 2 root root 4096 Mar 25 14:53 task_3 # is the offending task
drwxrwxr-x 2 airflow airflow 20480 Mar 25 00:00 task_2
drwxrwxr-x 2 airflow airflow 20480 Mar 25 15:54 task_1
So, I think what was going on, was that randomly, Airflow couldn't get the permission to write the log file, thus it wouldn't start the rest of the task. When I applied the appropriate chown command using something like sudo chown -R airflow:airflow task_3 . Ever since I changed this, the issue has disappeared.
I would like to assign some code that will be run when R is killed, for instance, save(list=ls(),file="dump.RData"). I thought this would be by trapping signals, e.g. SIGTERM, as referred to in this post, but there's nothing about signals from the shell in ?conditions.
?conditions does mention user interrupts; you can e.g. catch a Ctrl-C with withCallingHandlers( Sys.sleep(10), interrupt=function (e){cat("I saw that.\n")} ), but this doesn't catch SIGTERM.
How can I do this?
Indeed if you send SIGUSR1 to an R process, it will dump the workspace and stop. On Linux you can do that with
kill -USR1 Rpid
where Rpid is the process id of the R instance you want to stop. You can find it with pgrep for instance.
If R is running in a terminal, you can interrupt it with CTRL-Z and then type
kill -USR1 %
We have jobs getting stuck in autosys R11 screen due to app server down
So is there any way to monitor autoys itself is up and running
Note-The jobs which got stuck shows completed in database but the dependent jobs cannot start though from front end the jobs are still in runnig status
Please help
chk_auto_up command will check if application server, event server,
scheduler and agent are working fine.
chase command checks if agent is running fine.
autoping command checks if agent is able to communicate with the
application server.
Check the log files of components by below commands :
autosyslog -e (scheduler)
autosyslog -s (server)
autosyslog -d j (job)
check the status of each components manually by below commands
unisrvcntr status waae_server.$AUTOSERV
unisrvcntr status waae_agent-$AGENT_NAME
unisrvcntr status waae_webserver.$AUOTSERV
unisrvcntr status waae_sched.$AUTOSERV
I'm using monit 5.4 on Mac 10.7.4 machine. When i tried to execute a example configuration
check process syslogd with pidfile /var/run/syslogd.pid
start program = "/etc/init.d/sysklogd start"
stop program = "/etc/init.d/sysklogd stop"
if 5 restarts within 5 cycles then timeout
from monit wiki page, I get the following error.
'syslogd' process is not running
'syslogd' trying to restart
'syslogd' start: /etc/init.d/sysklogd
'syslogd' failed to start
Monit does not take the complete command given in the "start program" of the monitrc file. It just takes the first word in the command and tries to execute it and fails. Is this a known issue? If yes, does it have a workaround? If not, what am i missing here and how to get it working?
Thanks in advance.
Try this (from http://mmonit.com/wiki/Monit/FAQ#execution)
start program = "/bin/bash -c '/etc/init.d/blah start'"
Does /etc/init.d/sysklogd actually exist?
On 10.8 I have /etc/init.d/syslog and manually running /etc/init.d/syslog restart works fine.
I have a simple script that I'm trying to get Monit to monitor. After some digging around I found this little nugget: start program = "su - myuser -c '/home/user/myscript.rb start' " which I believe should work but looking at the log files it says:
[PDT Oct 30 02:47:17] info : 'simple_script' start: su
[PDT Oct 30 02:47:17] error : Error: Could not execute su
Likewise earlier attempts only seem to read the part preceding a space so:
start program = "/home/user/.rvm/rubies/ruby-1.9.2-p290/bin/ruby /home/user/simple_script_daemon.rb stop"
results in…
[PDT Oct 30 03:09:49] info : 'simple_script' start: /home/user/.rvm/rubies/ruby-1.9.2-p290/bin/ruby
Which doesn't fail like the first example but still seems to only execute the part preceding the space.
This is my full statement:
check process simple_script
with pidfile /home/user/simple_script.rb.pid
start program = "su - user -c '/home/user/simple_script_daemon.rb start' "
stop program = "su - user -c '/home/user/simple_script_daemon.rb stop' "
group simple_script
If you've got an idea what might be going on I'd love to hear from you!
I guess you could try something like:
check process simple_script
with pidfile /home/user/simple_script.rb.pid
start program = "/home/user/simple_script_daemon.rb start" as uid user and gid user
stop program = "/home/user/simple_script_daemon.rb stop" as uid user and gid user
group simple_script
as stated in monit doc.
You may need to provide full path to su, i.e. /bin/su