Script that will look the same as Cron

Hi All,.

need your expertise, is there a way to create a script that will run with specific time without using cron. because i dont have access in cron.

TIA

You can use loop to run on a specific time of day:

#!/bin/bash

while true;
do
    TIME=`date | cut -d' ' -f4`
    echo $TIME
    if [[ $TIME == "22:00:00" ]]
    then
            `your command`
            sleep 1s
    fi
done
1 Like

Hi,

If you definitely don't have access to the crontab for the user you want to run the script as, and if you can't get the person who has root on the box in question to set it up for you, then one approach would be to have a script that runs in an infinite loop until a target time arrives, and then runs whatever task it's meant to run at that time.

Here's an example of such a script, showing the code and me starting to run it roughly ten seconds before the appointed time:

$ cat script.sh 
#!/bin/bash

runtime=`/usr/bin/date -d '2019-08-09 14:22:00' +%s`

while true
do
        nowtime=`/usr/bin/date +%s`

        if [ "$runtime" == "$nowtime" ]
        then
                date
                echo "It's time to run"
                exit 0
        else
                date
                echo "It's not time to run, I'll keep waiting"
        fi

        /usr/bin/sleep 1
done

$ ./script.sh 
Fri Aug  9 14:21:50 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:51 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:52 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:53 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:54 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:55 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:56 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:57 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:58 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:21:59 BST 2019
It's not time to run, I'll keep waiting
Fri Aug  9 14:22:00 BST 2019
It's time to run
$ 

So the basic idea is we define our target time in the runtime variable at the top, converting a human-readable date into the UNIX epoch (the number of seconds since the start of 1970). We then in an infinite loop check the current time, compare it to our target time, and do something specific if the two match. If the current time is not the target time, we wait one second, and the loop goes round again until the target time arrives.

Note that this isn't entirely ideal, and you'd need to run this via screen or tmux or something similar to ensure that the script didn't die when your terminal session did. But if you really definitely don't have access to an actual system-level task scheduler, this kind of approach will work in a pinch. You might also want to make the sleep command wait for less than one second, just to be sure you don't ever miss the target second you want your job to actually run, but that's the only other issue that immediately comes to mind.

Hope this helps !

woahh.. its possible.. how about if with specific day?
also is it possible to put * * * like the same function in cron?

Hi,

Using the approach from my script, you would just tweak the runtime variable accordingly. For instance, in the provided example:

runtime=`/usr/bin/date -d '2019-08-09 14:22:00' +%s`

the target time is very specifically 14:22:00 on the 9th of August 2019. If you wanted, for instance, to make your code run on 25th December 2020 at midnight, you'd just change this to:

runtime=`/usr/bin/date -d '2020-12-25 00:00:00' +%s`

and you'd be all set.

--- Post updated at 03:51 PM ---

Hi,

Alternatively, if you wanted a more generic and less specific solution - e.g. a "run this at 14:50 every Friday" kind of situation, without worrying about an actual specific date in the year or specific second - you could do something along these lines:

#!/bin/bash

runday="Fri"
runhour="14"
runminute="50"

while true
do
        nowday=`/usr/bin/date +%a`
        nowhour=`/usr/bin/date +%H`
        nowminute=`/usr/bin/date +%M`

        if [ "$runday" == "$nowday" ] && [ "$runhour" == "$nowhour" ] && [ "$runminute" == "$nowminute" ]
        then
                date
                echo "It's time to run"
                exit 0
        else
                date
                echo "It's not time to run, I'll keep waiting"
        fi

        /usr/bin/sleep 60
done
1 Like

meaning i can add only 1 run time? what if i will run the script every mon tues and wed?

Hi,

In that case, you'd really be into the territory of literally re-inventing crontab . For example, you could define an input file format that consisted of runtimes and their associated commands, and have your script read that file and run the commands when the runtimes arrived - in other words, to do pretty much exactly what the crond daemon does.

I've not got time right now to write a full example unfortunately, but if you defined your input format as something like:

Mon,10,00,/usr/local/bin/foo.sh
Fri,17,00,/usr/local/bin/bar.sh

and had your script read this file line-by-line, breaking out the variables in each line into the days, hour, minutes and commands, you could then run those commands via the same kind of infinite-loop approach as you've seen in the examples given thus far.

If you absolutely don't have access to crontab , and can't get the maintainer of the server to put in the cron entries for you, then this would more or less be the only way you'd get a general-purpose task scheduler going. But you'd probably want to be sure that the maintainer of the server was happy with you doing this, since presumably they've blocked access to cron to prevent people running commands on a set schedule, which is what you'd end up doing anyway here.

1 Like

hi drysdalk,

i see.. can you give me at least sample of script so that i can follow and rewrite on my own. i think thats what im looking for.

TIA

Why not just download the source code for crond and build your own version from source and run your own version?

For example, here is some mcron source:

mcron.git - mcron

What's wrong with the 'at' command?

im not yet familiar with the source. maybe you can help me to create it via script like drysdalk said. thx thx

Maybe you should not try to write a crond process using a shell script ( smells like homework ) and just install your own version of crond from the many sources on the net.

We are not here to do your homework for you.

no sir its not. we are not allowed to used cron to our server and install, we are looking for a solution because we have many script that we need to run. thats why im seeking assistance to all of you who who are veteran. at least idea or a sample short script then i will create my own. because this is my first tym i encountered this. apology.

So download and run your own crond as mentioned .... :slight_smile:

You do not need to rewrite, in a shell script, code available in C to build and / install in your own directory and run yourself.

Hello,

OK, here's a quick hacked-together version of a script that more-or-less does what crond would do. As Neo has mentioned however, this is not the best idea, as you're kind of needlessly re-inventing something that already exists and which will definitely do a far better job than this shell script. If the customer/client/maintainer/whoever actively doesn't want you running scheduled tasks on the server, then they're not going to be happy about you doing it no matter how you go about doing it. Alternatively if you have a hard requirement to run scheduled tasks and the customer just doesn't want you installing software, then you need to have a conversation with your customer explaining that they need to install crond to enable you to do the work that you've been asked to do, otherwise you can't do it. If the job you need to do has a 100% requirement for scheduled tasks, then whoever provides this system either has to install or let you install crond , or they need to accept that the job can't be done since they won't let you have the tools you need to do it.

Anyway - bearing in mind all the above caveats (and the potential no doubt for bugs and issues that could be lurking with this approach), here's a quickly knocked-together script that would do more or less what you need.

$ cat cron.tab
Fri,16,13,echo "It's thirteen minutes past four !"
Fri,16,15,echo "It's quarter past four !"
$ cat script3.sh
#!/bin/bash

crontab=/home/unixforum/282472/cron.tab

while true
do
        while read cron
        do
                runday=`echo "$cron" | /usr/bin/awk -F, '{print $1}'`
                runhour=`echo "$cron" | /usr/bin/awk -F, '{print $2}'`
                runminute=`echo "$cron" | /usr/bin/awk -F, '{print $3}'`
                runcommand=`echo "$cron" | /usr/bin/awk -F, '{print $4}'`

                nowday=`/usr/bin/date +%a`
                nowhour=`/usr/bin/date +%H`
                nowminute=`/usr/bin/date +%M`

                if [ "$runday" == "$nowday" ] && [ "$runhour" == "$nowhour" ] && [ "$runminute" == "$nowminute" ]
                then
                        /usr/bin/date
                        $runcommand
                fi
        done < "$crontab"

        /usr/bin/sleep 60
done

$ date
Fri Aug  9 16:11:14 BST 2019
$ ./script3.sh
Fri Aug  9 16:13:16 BST 2019
"It's thirteen minutes past four !"
Fri Aug  9 16:15:16 BST 2019
"It's quarter past four !"
^C
$
2 Likes

thank you very much sir. i will take note of that. from here i will create my own. thx thx..

Probably a daft question, but why can you not use cron? It seems an odd enforcement. If you are writing the code, then you probably have access to do all sorts of nasty stuff anyway. I would not think that a scheduled job is necessarily any more dangerous. The schedules would need to be preserved or shared if you have clustered servers or you migrate to a new server. There may be restrictions that are in place to avoid everybody scheduling loads of things and clogging the machine up and there needs to be some control. Assuming that this job that will do a thing in general rather than for you personally, then maybe a service account would be more suitable (a non-personal account that you/team can sudo to) which could be given access to use cron.

Is there a good reason for the rule? Personally I have not restricted anyone because of one from these:

  • They cannot get to the command line (business users)
  • They know what they are doing (application developers or support staff)
  • If they get it wrong, it's only what they could do anyway.......

It's important that jobs run as a person don't become critical to production running, I agree, but that's a cultural thing too. I've had much experience where a savy person has set something up themselves and then they get their PC replaced and it's all lost or credentials to a database change or are restricted and suddenly their entirely unsupported report stops working. It's worse when they leave and nobody knows wheat was done, what it did or anything except "Bob used to do something each month"

Can you say why you are not permitted to use a scheduler? Anything else is either a bad solution calling at repeatedly (probably also restricted) or requires you to have code running all the time all over the place which is exposed to failure and is unlikely to get restarted on boot until you restart it.

Thanks, in advance,
Robin

Be a little careful how you schedule jobs with this concept, as only one job will run at a time and if another job is due and a long running job hasn't finished yet the other job will not be run. Also if the machine is restarted or you script is killed then the jobs will not be run.

Cron is still your preferred option hear, as all these sort of issues, and others we haven't thought of yet, are dealt with out of the box.

1 Like

My best guest is that it is disguised schoolwork. When people post these types of posts the main reason is that their instructor has told them to "write a script like cron" and then they make up a story about "not having access to cron at work," for example, to get others to help them online.

That's my experience over the past two decades as to why people ask questions with such "constraints" and insist on using a particular solution or approach.