4 ms·

> We created Cronitor because cron itself can't alert you if your jobs fail or never start. That's a lie. A mail is sent on failed jobs. The receiving mailbox

by y4mi 7y ago

> We created Cronitor because cron itself can't alert you if your jobs fail or never start. That's a lie. A mail is sent on failed jobs. The receiving mailbox is by default the executing user (so usually root) There is also an entry into the systemlog which should already be monitored. The user might not get the notifications because he doesn't pay attention, but cron does notify.

gerdesj 7y ago
Lie is a little harsh but absolutely - cron has had notifications built in for as long as I can remember and a Unix box that can't send email is a pretty rare beast and is probably broken.
- SnarkAsh 7y ago
  Really? I imagine that fewer than 1% of Linuxes boxes out there can successfully send email to a public email address.
  - gerdesj 7y ago
    I take it you are describing policy rather than capability. What I was getting at is that email is kind of built in by default with Unix like systems. It is actually quite hard to install a Linux or BSD box without the capability to send email. SMTP is at heart, very, very simple and can be conducted via telnet if necessary although doing TLS via telnet by hand might be a bit tricky. I have deployed many Ubuntu boxes and sometimes been surprised to receive emails - cron (logwatch) usually. Our central SMTP daemon has me as an alias for root, postmaster etc. Don't know why I'm surprised - I set the bloody things up to work - perhaps I'm going a bit senior.
    - snagglegaggle 7y ago
      No -- sending external mail is very difficult and requires setting up at least DKIM. "Email" is built in and a LAN of *nix servers can usually send messages to each other but they are not set up as a state of the art public mail server would be. Even the LAN sending is being phased out, if you get a message it may be local delivery only. If the messages are going out they probably use an MTA and are logging in to a hosted service, which is something that needs to be set up.
      - gerdesj 7y ago
        You are having a laugh - SMTP is not hard (for a given value of hard.) I've run Unix SMTP daemons and Exchange (and GroupWise and L Notes) for over 20 years. My weapon of choice is Exim with rspamd these days but I know Postfix, Qmail and sendmail and of course Spamassassin with extras. DKIM is the second of the trifecta, SPF first and then DMARC after DKIM. DMARC is when things start to go horribly wrong or wrongerer than normal in the world of email. Mailing lists get funky shortly after you proudly publish a TXT record starting "v=DMARC1; and p=<unwise choice>. I'm not sure that state of the art is appropriate when describing SMTP. It is what it is and no more, nor less. It transfers a huge amount of data daily, without fuss or comment. Perhaps that is the state of the art - it is in my world: I like stable and boring and just works. I'm (nearly) a Civil Engineer and I think of SMTP as an odd analogy for concrete. It's fundamental and very boring but can be surprisingly complicated and interesting if you get it wrong. Conc. can burn or get tricky in all sorts of ways if poured in excessive amounts - setting is an exothermic reaction and will work under water as well. Conc can suffer from concrete cancer which is where sea air and a few other factors causes "map cracking" and potentially failure. SMTP is another function that is dumped into the background, forgotten about and relied upon to just work until the wheels fall off.
        snagglegaggle 7y ago
        Yes, yes, I've set up a working mail server also. All my point is is that any SMTP daemons in a Linux installation are not really in a usable state by default and require a lot of reasonably tedious actions to set up. Every distro I have used in recent memory has not been able to do anything but local delivery, and even then sometimes an SMTP daemon is missing.
      - stonogo 7y ago
        > Even the LAN sending is being phased out, By who? This isn't even almost true.
        snagglegaggle 7y ago
        Every distro I have used in recent memory has only ever had local delivery working by default, and sometimes not even that. So the GP (or GGP) post about cron not having a failure detection mechanism is mostly true.
penagwin 7y ago
I think it's fair to compare with the classic Dropbox vs ftp argument. It takes some configuring to make sure crown sends emails to the right place - and without the email going straight to spam. Sure you can setup filters, etc. But that's manual work. Not to mention of you'd rather have it text you, send a message to slack etc. Also cron can't alert you if you accidentally removed the cron job, the host is down, host loses its connection etc.
- debaserab2 7y ago
  I'd make a bet that the resiliency of your average crontab is greater than most SaaS companies.
  - penagwin 7y ago
    We have certain cron jobs that if they failed we could be losing thousands of dollars an hour. Of course they're tested, and you're right they've worked fine for a looooong time. But I don't care if they "normally work fine", I need to know immediately if it didn't run for any reason. We self hosted a cron monitor, it was free and only took less then a day to add and have fully integrated, including text message and MS teams notifications.
ggm 7y ago
That's a lie. A mail is sent on failed jobs. Please don't use the lie word: it goes to intentionality. It's wrong, true: Cron has (for a very long time) been designed to mail and log on failure. The thing is that a huge number of deployments these days don't run functional mail send, and so the failure states go to /dev/null (in effect) Also, cron can fail to run: Linux moved cron to a different execution state from BSD, which has also introduced (on linux) the interaction between cron and anacron. Changing the state of cron.d/ doesn't always register in cron, and cron won't always send mail if it doesn't know new things have to be run. The older crontab -e method reliably made cron re-read the state of the file. (I think this predated Vixie cron, cron existed since time immemorial in UNIXEN. Vix improved things, but the underlying system behaviour was established before he coded in this space)
- scbrg 7y ago
  > Please don't use the lie word: it goes to intentionality. If someone built a whole product around it - and use it as their marketing pitch when it takes like 30 seconds of man-page reading to find out that it's wrong, I'd argue you have some fairly good reason to assume intentionality. (That said, yes, I agree that there are failure states in traditional cron that won't alert you with an email, so the service might of course be useful.)

by y4mi 7y ago

gerdesj 7y ago

Lie is a little harsh but absolutely - cron has had notifications built in for as long as I can remember and a Unix box that can't send email is a pretty rare beast and is probably broken.

SnarkAsh 7y ago
Really? I imagine that fewer than 1% of Linuxes boxes out there can successfully send email to a public email address.
- gerdesj 7y ago
  I take it you are describing policy rather than capability. What I was getting at is that email is kind of built in by default with Unix like systems. It is actually quite hard to install a Linux or BSD box without the capability to send email. SMTP is at heart, very, very simple and can be conducted via telnet if necessary although doing TLS via telnet by hand might be a bit tricky. I have deployed many Ubuntu boxes and sometimes been surprised to receive emails - cron (logwatch) usually. Our central SMTP daemon has me as an alias for root, postmaster etc. Don't know why I'm surprised - I set the bloody things up to work - perhaps I'm going a bit senior.
  - snagglegaggle 7y ago
    No -- sending external mail is very difficult and requires setting up at least DKIM. "Email" is built in and a LAN of *nix servers can usually send messages to each other but they are not set up as a state of the art public mail server would be. Even the LAN sending is being phased out, if you get a message it may be local delivery only. If the messages are going out they probably use an MTA and are logging in to a hosted service, which is something that needs to be set up.
    - gerdesj 7y ago
      You are having a laugh - SMTP is not hard (for a given value of hard.) I've run Unix SMTP daemons and Exchange (and GroupWise and L Notes) for over 20 years. My weapon of choice is Exim with rspamd these days but I know Postfix, Qmail and sendmail and of course Spamassassin with extras. DKIM is the second of the trifecta, SPF first and then DMARC after DKIM. DMARC is when things start to go horribly wrong or wrongerer than normal in the world of email. Mailing lists get funky shortly after you proudly publish a TXT record starting "v=DMARC1; and p=<unwise choice>. I'm not sure that state of the art is appropriate when describing SMTP. It is what it is and no more, nor less. It transfers a huge amount of data daily, without fuss or comment. Perhaps that is the state of the art - it is in my world: I like stable and boring and just works. I'm (nearly) a Civil Engineer and I think of SMTP as an odd analogy for concrete. It's fundamental and very boring but can be surprisingly complicated and interesting if you get it wrong. Conc. can burn or get tricky in all sorts of ways if poured in excessive amounts - setting is an exothermic reaction and will work under water as well. Conc can suffer from concrete cancer which is where sea air and a few other factors causes "map cracking" and potentially failure. SMTP is another function that is dumped into the background, forgotten about and relied upon to just work until the wheels fall off.
      - snagglegaggle 7y ago
        Yes, yes, I've set up a working mail server also. All my point is is that any SMTP daemons in a Linux installation are not really in a usable state by default and require a lot of reasonably tedious actions to set up. Every distro I have used in recent memory has not been able to do anything but local delivery, and even then sometimes an SMTP daemon is missing.
    - stonogo 7y ago
      > Even the LAN sending is being phased out, By who? This isn't even almost true.
      - snagglegaggle 7y ago
        Every distro I have used in recent memory has only ever had local delivery working by default, and sometimes not even that. So the GP (or GGP) post about cron not having a failure detection mechanism is mostly true.

penagwin 7y ago

I think it's fair to compare with the classic Dropbox vs ftp argument. It takes some configuring to make sure crown sends emails to the right place - and without the email going straight to spam. Sure you can setup filters, etc. But that's manual work. Not to mention of you'd rather have it text you, send a message to slack etc. Also cron can't alert you if you accidentally removed the cron job, the host is down, host loses its connection etc.

debaserab2 7y ago
I'd make a bet that the resiliency of your average crontab is greater than most SaaS companies.
- penagwin 7y ago
  We have certain cron jobs that if they failed we could be losing thousands of dollars an hour. Of course they're tested, and you're right they've worked fine for a looooong time. But I don't care if they "normally work fine", I need to know immediately if it didn't run for any reason. We self hosted a cron monitor, it was free and only took less then a day to add and have fully integrated, including text message and MS teams notifications.

ggm 7y ago

That's a lie. A mail is sent on failed jobs. Please don't use the lie word: it goes to intentionality. It's wrong, true: Cron has (for a very long time) been designed to mail and log on failure. The thing is that a huge number of deployments these days don't run functional mail send, and so the failure states go to /dev/null (in effect) Also, cron can fail to run: Linux moved cron to a different execution state from BSD, which has also introduced (on linux) the interaction between cron and anacron. Changing the state of cron.d/ doesn't always register in cron, and cron won't always send mail if it doesn't know new things have to be run. The older crontab -e method reliably made cron re-read the state of the file. (I think this predated Vixie cron, cron existed since time immemorial in UNIXEN. Vix improved things, but the underlying system behaviour was established before he coded in this space)

scbrg 7y ago
> Please don't use the lie word: it goes to intentionality. If someone built a whole product around it - and use it as their marketing pitch when it takes like 30 seconds of man-page reading to find out that it's wrong, I'd argue you have some fairly good reason to assume intentionality. (That said, yes, I agree that there are failure states in traditional cron that won't alert you with an email, so the service might of course be useful.)