I would like to run jobs once a month on, let's say, the 22nd day of the month, on my laptop running Ubuntu 12.04.
Since it's a laptop, and I may not always even use it every 22nd day of each month, cron is not a very good option.
Looking into anacron, there seems to be a limitation. Namely, you can specify a 'period', but not a specific day of the week or day of the month, as suggested by the anacrontab file format:
# cat /etc/anacrontab
period delay job-identifier command
7 15 test.daily /bin/sh /home/myself/backup.sh
I would like to be able to say, if we're on the 22nd day of the month, and of course the laptop is running, run the job. If the 22nd is passed and you have not run the job, run it as soon as I boot.
I am about to do something ugly, like mixing cron and anacron with custom scripts or writing my own bash script, using timestamps, probably reinventing the square wheel in the process.
Any idea about a best course of action?
Cheers.
Run the command daily, and have the script record the date that it last performed a backup
When it starts up, get the current day of month. If it's the 22nd oh the month, run normally and save the date. If it's >22, and the last run was in the same month, exit. If it's <22, and the last run was the previous month (don't forget to account for wrapping from 12 to 1), exit.
The date should be saved in a file somewhere.
Related
I'm working with nlpcraft to build a parsing system for scheduling. Users are asked when they will be doing certain activities and they can respond with relative or absolute dates, such as "tuesday and wednesday" or "not until 8/15".
While nlpcraft has very nice relative date parsing, near as I can tell it always parses dates relative to the current system time in UTC. Not only does this complicate testing (because the input is relative while the output is absolute), it means that if the server does not parse the input close to the time the user wrote it, relative dates may be parsed incorrectly. For example, if the user says "tomorrow" at 11PM on a Sunday, but the server doesn't parse it until 5AM on Monday, it might result in Tuesday instead of Monday.
I looked into NCDateEnricher where this all seems to happen and then parsing routine computes a base time as the current system time. I didn't see a way to override this with a config variable or request parameter -- am I missing something?
UTC time server on server-side allows users to easily convert times to local timezone. It's the simplest way to support different timezone users with one server.
If you aren't satisfied with nlpcart provided date NER, you can look at date/time NERS from opennlp/stanford/spacy/google, which can be simply used with nlpcraft system (https://nlpcraft.incubator.apache.org/integrations.html)
In a Linux CentOS 5 machine, I am running process.sh using a cronjob at #reboot, every day (the machine gets shut off every night and turned on every morning).
process.sh takes the 'date' of the computer, and writes it to a log file, then exits.
When I check the logfile, the timestamp in it says "Tue Jan 1 13:14:38 GMT 2008"
When I go to the console of the computer and give it the 'date' command, it prints the correct date.
My best guess is that my cronjob is running BEFORE the computer sets its correct time.
Is there a way to fix this?
The battery that powers the CMOS memory on your motherboard may have run out. Try replacing it by a fresh one. It should look something like this.
This advice is based on the fact that the date of your log entry is "Jan 1 2008" which looks conspicuously like an epoch your motherboard may use. However, the time-of-day 13:14:38 is a little off for this; while the 13 hour shift can be explained if you are in the correct time zone, the nearly 15 minute offset seems odd. Unless your computer takes that long to boot to the point where cron executes your job. And of course, the reason why you eventually see the correct time is probably that ntp fixed the system time, as others have noted.
I am working on a shell script computation program wherein I want a script that computes for the total number of hours and minutes a particular user has been logged on to the system. The script accepts one parameter, the login name. Information like the complete name of the user, the current month and the dates the user logged on earliest during the month and the latest during the month. In the pseudo, I wanted somewhat like this:
[prompt]$ <your familyname>user_login mycroft<enter>
For the Month of June :
User : mycroft
In Real life : Mycroft Holmes
period : Mon Jun 16 to Sat Jun 28
total login time : 2 hours and 2 minutes
Is there a possible way to do this in Shell? I have been on blanks and errors until now.
Look at who or finger program. Probably it's all you need.
I want to be able to configure something like this.
I want to run job 'X' at 7 AM everyday starting from 29/june/2009 till 30/12/2009. Consider current date as 4/4/2009.
It can be done in a tricky sort of way.
You need three separate cron jobs for that range, all running the same code (X in this case):
one for the 29th and 30th of June ("0 7 29,30 6 * X").
one for every day in the months July through November ("0 7 * 7-11 * X").
one for all but the last day in December ("0 7 1-30 12 * X").
This gives you:
# Min Hr DayOfMonth Month DayOfWeek Command
# --- -- ---------- ----- --------- -------
0 7 29,30 6 * X
0 7 * 7-11 * X
0 7 1-30 12 * X
Then make sure you comment them out before June 29, 2010 comes around. You can add a final cron job on December 31 to email you that it needs to be disabled.
Or you could modify X to exit immediately if the year isn't 2009.
if [[ "$(date +%Y)" != "2009" ]] ; then
exit
fi
Then it won't matter if you forget to disable the jobs.
Yes, mostly. Some cron implementations have support for years, some don't, so we'll assume yours does not. Also, I'm making the assumption that this job is only being run by the cron daemon, so we can use the execute bit to determine whether or not cron should run the job.
Note that you'll need to leave your script as non-executable until such time as you want it to run.
The following cron expressions will do what you want (every day, including weekends). Tweak as you need to:
# Make the job executable on 29 June.
0 6 29 6 * chmod +x /path/to/my/job/script
# Run the job between June and December, only if it's executable.
0 7 * 6-12 * test -x /path/to/my/job/script && /path/to/my/job/script
# Disable execution after 30 December.
0 8 30 12 * chmod -x /path/to/my/job/script
I'm usually a fan of keeping the logic with the program being run. You might think about setting up one cron job that runs the script every day, then have the script decide on its own whether or not it should do anything useful. When the last useful day (Dec 30) has passed, your script could remove itself from the crontab. In the script you can set up the logic with all the comments necessary to describe what you are doing and why.
If your job is a binary program, you might set up a run_script that does this schedule filtering work before calling the program.
You can use this to generate a crontab that runs at specific intervals:
http://www.robertplank.com/cron/
Or this
http://www.webmaster-toolkit.com/cron-generator.shtml
One solution would be to setup 6 crons, 1 for each month, each would run at 7 am every day that month.
It's probably the easiest way, the next one up would be to script it.
No, afaik, you cannot do that.
The cron fields hold the values for minutes, hours, day of month, month and day of week, respectively.
10 5 10 * * means run at 5:10 on every 10th of every month.
10 5 * 12 * means run at 5:10 on every day in december
10 5 * * 1 means run at 5:10 every Monday
You can make it run on a series of specific months, as the crontab format does accept ranges. April through December would be 4-12 in that case for the month field. But that does not take into account your wish for having this limited to 2009.
There is no mechanism to set start and stop dates for cronjob. You can always script this of course. Make a cronjob run every day and check the current date to be before 30/12. If it is 31/12 make it remove itself. Or something more thought through.
A crontab of
0 7 * * 6-12 command_X
would do what you want partially, but it would start at June 1st and run through December 31st. Skipping the first part of June and December 31st would have to be scripted in the X command.
How can I get a history of uptimes for my debian box? After a reboot, I dont see an option for the uptime command to print a history of uptimes. If it matters, I would like to use these uptimes for graphing a page in php to show my webservers uptime lengths between boots.
Update:
Not sure if it is based on a length of time or if last gets reset on reboot but I only get the most recent boot timestamp with the last command. last -x also does not return any further info. Sounds like a script is my best bet.
Update:
Uptimed is the information I am looking for, not sure how to grep that info in code. Managing my own script for a db sounds like the best fit for an application.
Install uptimed. It does exactly what you want.
Edit:
You can apparantly include it in a PHP page as easily as this:
<? system("/usr/local/bin/uprecords -a -B"); ?>
Examples
the last command will give you the reboot times of the system. You could take the difference between each successive reboot and that should give the uptime of the machine.
update
1800 INFORMATION answer is a better solution.
You could create a simple script which runs uptime and dumps it to a file.
uptime >> uptime.log
Then set up a cron job for it.
Try this out:
last | grep reboot
according to last manual page:
The pseudo user reboot logs in each time the system is rebooted.
Thus last reboot will show a log of all reboots since the log file
was created.
so last column of #last reboot command gives you uptime history:
#last reboot
reboot system boot **************** Sat Sep 21 03:31 - 08:27 (1+04:56)
reboot system boot **************** Wed Aug 7 07:08 - 08:27 (46+01:19)
This isn't stored between boots, but The Uptimes Project is a third-party option to track it, with software for a range of platforms.
Another tool available on Debian is uptimed which tracks uptimes between boots.
I would create a cron job to run at the required resolution (say 10 minutes) by entering the following [on one single line - I've just separated it for formatting purposes] in your crontab (cron -l to list, cron -e to edit).
0,10,20,30,40,50 * * * *
/bin/echo $(/bin/date +\%Y-\%m-\%d) $(/usr/bin/uptime)
>>/tmp/uptime.hist 2>&1
This appends the date, time and uptime to the uptime.hist file every ten minutes while the machine is running. You can then examine this file manually to figure out the information or write a script to process it as you see fit.
Whenever the uptime reduces, there's been a reboot since the previous record. When there are large gaps between lines (i.e., more than the expected ten minutes), the machine's been down during that time.
This information is not normally saved. However, you can sign up for an online service that will do this for you. You just install a client that will send your uptime to the server every 5 minutes and the site will present you with a graph of your uptimes:
http://uptimes-project.org/
i dont think this information is saved between reboots.
if shutting down properly you could run a command on shutdown that saves the uptime, that way you could read it back after booting back up.
Or you can use tuptime https://sourceforge.net/projects/tuptime/ for a total uptime time.
You can use tuptime, a simple command for report the total uptime in linux keeping it betwwen reboots.
http://sourceforge.net/projects/tuptime/
Since I haven't found an answer here that would help retroactively, maybe this will help someone.
kern.log (depending on your distribution) should log a timestamp.
It will be something like:
2019-01-28T06:25:25.459477+00:00 someserver kernel: [44114473.614361] somemessage
"44114473.614361" represents seconds since last boot, from that you can calculate the uptime without having to install anything.
Nagios can make even very beautiful diagrams about this.
Use Syslog
For anyone coming here searching for their past uptime.
The solution of #1800_Information is a good advise for the future, but I needed to find information for my past uptimes on a specific date.
Therefore I used syslog to determine when that day the system was started (first log entry of that day) and when the system was shutdown again.
Boot time
To get the system start time grep for the month and day and show only the first lines:
sudo grep "May 28" /var/log/syslog* | head
Shutdown time
To get the system shutdown time grep for the month and day and show only the last few lines:
sudo grep "May 28" /var/log/syslog* | tail