I am trying to create a script that watches my college time table and registers them for a class when it is open. Kind of like an Ebay auction sniper. I was wondering if cron is the right tool for this. I need to be able to run the script for every user. The user will enter their username and password and the script will query the timetable.
Looking for some advice on if cron is the tool or if there are other tools out there.
cron runs a particular program or script at a specified time. For example, if you wanted a report compiled and e-mailed every day at 2 a.m., that would be a cron job.
In this sense, cron has a timetable, but I am not sure that it is the sort of timetable of which you are thinking.
From a system-design perspective, the clean way to achieve the effect you want naturally would be to let the students' class requests join a queue, then to have the college's registrar's own computer take requests from the queue as seats became available. However, I assume from your Ebay reference that this is not possible in your case.
Related
For example, a program that sends a token or nft to a specific address once a month.
No program on solana will be executed unless an off-chain actor submits a transaction containing an instruction for that program. There is no timer mechanism inherent to solana that will automatically execute your transactions at a later date.
You can write a program to restrict an instruction such that it can only be executed successfully once per month. The program can check the current timestamp against a previous execution to check if it's allowed to execute now. Or it could check the number of months since the previous execution and transfer the appropriate number of tokens that should be available after that number of months.
Additionally, you need to consider the incentives of the actor who submits the instruction. Does an ordinary user have reason to execute some instructions in your program already? If it fits within the compute budget, you can bundle this monthly logic along with the other logic that users routinely execute. If not, then you need to incentivize someone else to make sure the instruction is executed often enough. You could just submit a transaction once a month on your own. Or you could design your program to collect fees from ordinary users so it can pay rewards to a crank turner who runs these periodic instructions so you don't have to. You also need to let people know they can get paid for running a crank.
So, there are ways to get things to run periodically, but you need to get creative to make it happen. There are some interesting ideas that build on the primitives I have described, you can go pretty far down this rabbit hole. It has been proposed that multisig can play a role in a generic cron timer. As always, this would still require someone to turn the crank by submitting transactions to the network periodically. https://github.com/solana-labs/solana/issues/17218
I am beginner with Linux cron job.
Requirement:
Record attendance of employee. Every dayat 10 AM a Jar should execute and asks to login to record his/her presence.
Cron Job
I have created a cron job and placed at /etc/cron.d/ and has below line.
0 10 * * * /home/user/Documents/attendance.sh
If system get started before 10 AM then a login screen UI comes but if user comes late and start system after 10 AM then it doesn't show login screen UI.
So it should execute JAR even though user login after 10 AM.
Also, pleaes let me know if there is another way to achieve this goal.
Please guide.
Thanks,
Ankur
A couple of alternatives occur to me.
1 If you'd like to have attendance.sh run for every user at login, you could add it to the system-wide login shell rc file, probably /etc/profile.
2 If it's available, you could use anacron, which is well suited for systems that are not running all the time. You could schedule attendance.sh to run daily at a particular time after login.
These alternatives will behave differently. 1 will run at each login, so several times a day or only once in several days, depending upon whether the user logs in and out daily, several times daily or stays logged in when they leave work. 2 will run every day that the user is logged in (assuming that they stay logged in at least as long as the delay you specify).
If your requirements are more exacting, say "run at 10 for all logged in users, otherwise run when a late user logs in". You could make something work, but doing so would require some extra work.
Added following questioners comment
As I alluded to in my discussion of how 1 & 2 differ there can be problems with 1 if the user does not just log in at the start of their work day and log out at it's end. It sounds to me as if what you are really after is an application that is tied into the window manager. I am not experienced with triggering scripts with window manager events, but surely it's possible to do so, e.g. Run script on screen lock/unlock. You may have to do some research depending upon your needs and the sort of systems that you have. One thing to keep in mind is that a solution that works for the user who doesn't log out every day may backfire on those who log out several times a day. Solution 2 may be the best of the easy straightforward solutions for your problem, but you may need something more elaborate to handle edge cases and where (perhaps) employee performance is being monitored.
You can make the script run hourly. Script checks the time, if it's 10 or later, it checks if the user logged in today, and if not asks him to login. So you can record the login hour too.
Edit: You can put your script in /etc/cron.hourly
Right now I have a weekly email job that works by first checking a last_email_sent timestamp against the current time, it then uses setTimeout to schedule a routine that is exactly a week from the last_email_sent timestamp. If the process ever restarts, the setTimeout would be queued again but the interval would of course be smaller. This works for a weekly email job, but is there a better way to handle jobs in node.js? Maybe there's a module out there that can let me manage my jobs that I'm not aware of.
There's a handy module in npmjs.org called node-cron.
It'll give you more flexibility.
Many of the modules listed in the node.js wiki under "Message Queues" will help with this type of system. Being a TJ Holowaychuck fanboy, I myself would probably first look at Kue.
We need to schedule some tasks in Plone 4 (notify users after n days of inactivity, etc.). What is the best way to do it? Is there something in Plone or maybe an old cron job? I would like to avoid cron4plone.
Simply use the built-in <clock-server> functionality in zope.conf; list them in the zope-conf-additional option of plone.recipe.zope2instance:
zope-conf-additional =
<clock-server>
method /Plone/path/to/callable
period 7200
user username-to-invoke-method-with
password password-for-user
host localhost
</clock-server>
The above snippet will call /Plone/path/to/callable every 2 hours, with the Host header set to localhost with the configured user and password.
The clock-server was added to Zope 2.10; before this it was a separate product by Chris McDonough. I generally created dedicated views for such tasks.
The alternative is to use a cron job to call either a view (usually with wget or cron) or a zopectl command line script. I use this when I need precise control over when the script needs to be executed, such as at midnight every day.
I have an application that has to launch jobs repeatingly. But (yes, that would have been to easy without a but...) I would like users to define their backup frequency in application.
In worst case, they would have to choose between :
weekly,
daily,
every 12 hours,
every 6 hours,
hourly
In best case, they should be able to use crontab expressions (see documentation for example)
How to do this? Do I launch a job every minutes that check for last execution time, frequency and then launches another job if needed? Do I create a sort of queue that will be executed by a masterjob?
Any clues, ideas, opinions, best pratices, experiences are welcome!
EDIT : Solved this problem using Akka scheduler. Ok, this is a technical solution not a design answer but still everything works great.
Each user defined repetition is an actor that send messages every period to a new actor to execute the actual job.
There may be two ways to do this depending on your requirements/architecture:
If you can only use Play:
The user creates the job and the frequency it will run (crontab, whatever).
On saving the job, you calculate the first time it will have to be run. You then add an entry to a table JOBS with the execution time, job id, and any other information required. This is required as Play is stateless and information must be stored in the DB for later retrieval.
You have a job that queries the table for entries whose execution date is less than now. Retrieves the first, runs it, removes it from the table and adds a new entry for next execution. You should keep some execution counter so if a task fails (which means the entry is not removed from DB) it won't block execution of the other tasks by the job trying again and again.
The frequency of this job is set to run every second. That way while there is information in the table, you should execute the request around as often as they are required. As Play won't spawn a new job while the current one is working if you have enough tasks this one job will serve all. If not, it will be killed at some point and restored when required.
Of course, the crons of the users will not be too precise, as you have to account for you own cron delays plus execution delays on all the tasks in queue, which will be run sequentially. Not the best approach, unless you somehow disallow crons which run every second or more often than every minute (to be safe). Doing a check on execution time of the crons to kill them if they are over a certain amount of time would be a good idea.
If you can use more than Play:
The better alternative I believe is to use Quartz (see this) to create a future execution when the user creates the job, and reproram it once the execution is over.
There was a discussion on google-groups about it. As far as I remember you must define a job which start every 6 hours and check which backups must be done. So you must remember when the last backup job was finished and make the control yourself. I'm unsure if Quartz can handle such a requirement.
I looked in the source-code (always a good source ;-)) and found a method every, where I think this should be do what you want. How ever I'm unsure if this is a clever design, because if you have 1000 user you will have then 1000 Jobs. I'm unsure if Play was build to handle such a large number of jobs.
[Update] For cron-expressions you should have a look into JobPlugin.scheduleForCRON()
There are several ways to solve this.
If you don't have a really huge load of jobs, I'd just persist them to a table using the required flexibility. Then check all of them every hour (or the lowest interval you support) and run those eligible. Simple.
Or, if you prefer to use cron syntax anyway, just write (export) jobs to a user crontab using a wrapper which calls back to your running app, or starts the job in a standalone process if that's possible.