Is there a way to add Seconds to Cronical.dat file

[venkata40]

I am trying to add seconds to Cronical.dat file to trigger a specific event every 30 seconds. Can you please let me know how to add seconds.

[mgefvert]

Seconds are not traditionally part of the crontab file format and would require some form of extension... And I don't know of any other crond daemons that support that.

Internally, I see a few problems with it.

• It would mean a 60-fold increase in calculation time per task, since right now we iterate over every minute to find the next run time.
• It could possibly get very messy if we try to run tasks every second.
• Since we don't necessarily tick() every second either, it also means we could miss tasks.

In order to implement task management on a second level, there would have to be some kind of really large benefit which I don't currently see.

A possible extension format might be to preface the whole line with a custom markup, like "s=0,30" to indicate run times - but both just the asterisk and variants like "*/10", would be overkill.

[venkata40]

Thank you so much for quick response. I will explain what I am trying to do

1. I wrote a console application that constantly pull data on every 30 seconds from IOT devices (Counting devices used in manufacturing).
2. Instead I write a service, I would to add my console application executable to Cronical and schedule it to run every 30 seconds.

If the current functionality do not support, I will write my own service application, that runs and captures the data on every 30 seconds interval.

Thanks, Venkat

On Mon, Jan 28, 2019 at 1:47 PM Mats Gefvert notifications@github.com wrote:

Seconds are not traditionally part of the crontab file format and would require some form of extension... And I don't know of any other crond daemons that support that.

Internally, I see a few problems with it.

• It would also mean a 60-fold increase in calculation time per task, since right now we iterate over every minute to find the next run time.
• It could possibly get very messy if we try to run tasks every second.
• Since we don't necessarily tick() every second either, it also means we could miss tasks.

In order to implement task management on a second level, there would have to be some kind of really large benefit which I don't currently see.

A possible extension format might be to preface the whole line with a custom markup, like "s=0,30" to indicate run times - but both just the asterisk and variants like "*/10", would be overkill.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mgefvert/Cronical/issues/12#issuecomment-458274703, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae-_XpsTexJcxHLloTCJpHDU-DkHHAcdks5vH1O9gaJpZM4aWm3o .

[mgefvert]

I'll consider it for an upcoming release, but I can't make any promises :)

It would probably make more sense to do option 2 for right now, just have a small program running which polls the devices regularly and that listens to a CTRL-C to do a graceful shutdown, optionally. We have plenty of service processes running from Cronical that all do certain tasks at regular intervals, from every second to up to every 15 minutes. That also gives us the benefit of listening for messages and triggering runs immediately, but I suppose that's not required in your case.

Anyway, thanks for your interest in Cronical!

[venkata40]

I do a lot of development in AWS / Azure. Let me know if we can team up and do development to make product good to great.

Thanks, Venkat

On Mon, Jan 28, 2019 at 4:26 PM Mats Gefvert notifications@github.com wrote:

I'll consider it for an upcoming release, but I can't make any promises :)

It would probably make more sense to do option 2 for right now, just have a small program running which polls the devices regularly and that listens to a CTRL-C to do a graceful shutdown, optionally. We have plenty of service processes running from Cronical that all do certain tasks at regular intervals, from every second to up to every 15 minutes. That also gives us the benefit of listening for messages and triggering runs immediately, but I suppose that's not required in your case.

Anyway, thanks for your interest in Cronical!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mgefvert/Cronical/issues/12#issuecomment-458327213, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae-_XlJdjufG3ucGkJkQqO1f49WdxPKLks5vH3kwgaJpZM4aWm3o .

[mgefvert]

I'm in the middle of some refactoring right now to make the class design a little bit more modular, so the master branch is not entirely stable right now, but I should have that cleaned up in a couple of days. I don't mind at all if you take a look at it and see if you can improve on it!

If you do look at it, I would suggest that the crontab format would be expanded to allow for a definition like, in your case:

s=0,30 * * * * * command

That would make it easier to understand what's going on, and possibly eliminate some confusion about the format for others. That would have to be saved in a list somewhere in CronJob, and RecalcNextDate (or what it's called) would have to consider that list when calculating the next run time.

[venkata40]

Sure, I will look into it adding seconds like I explained my case. Let me go through code and work towards it.

On Mon, Jan 28, 2019 at 5:40 PM Mats Gefvert notifications@github.com wrote:

I'm in the middle of some refactoring right now to make the class design a little bit more modular, so the master branch is not entirely stable right now, but I should have that cleaned up in a couple of days. I don't mind at all if you take a look at it and see if you can improve on it!

If you do look at it, I would suggest that the crontab format would be expanded to allow for a definition like, in your case:

s=0,30 * command

That would make it easier to understand what's going on, and possibly eliminate some confusion about the format for others. That would have to be saved in a list somewhere in CronJob, and RecalcNextDate (or what it's called) would have to consider that list when calculating the next run time.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mgefvert/Cronical/issues/12#issuecomment-458346978, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae-_XgV4BuSBijKWjANE-KMMAeY3hkW7ks5vH4pLgaJpZM4aWm3o .