• Crontab (cronie) doesn't start (last line missing line-feed 0x0A bug)

    So, it’s just another day, only yesterday I spent a good part of Sunday testing the KDE5 Plasma implementation for Antergos. In short, I didn’t like it. There’s too many levers and buttons and things which can go fubar. The average ‘Joe Six-Pack’ will not use it. So, today, I have switched back to Gnome-Shell by doing a clean install with the Live Antergos ISO (not minimal).

    I have this time decided to install ZFS. But, I have had for the past two years an external BlacX SATA docking station that connects via the express pcmia card slot with an eSATA interface.

    In configuring my system, I chose to install BackIntime and historically it has run like a ‘Swiss Watch’ never missing a beat. With the ext4 filesystem, I have had to use it to restore several times so it is worth the investment particularly if you are a developer.

    Anyway, I’ve installed cronie (crond), enabled and started the service using systemctl. Verified the status is ok and have manually copied the root crontab entry that BIT creates upon configuring a backup-job and pasted it to the root command prompt to certifify the backup is working correctly. All fine.

    Then I took the midnight crontab and changed the time to a few minutes ahead to see if the cronie.service would wake and run the job. Several times I changed the time with a reboot of the system. Still the crontab won’t run.

    I don’t think I should start by ‘barking’ up the cronie developer’s tree and thought I might enlist your assistance first.

    Does anyone have an idea of what I am missing?

    I don’t see anything unusual in journalctl -f either for crond. And there is no mail for root.

    Thanks in advance for any help you may be able to provide.
    – Dietrich

  • @dtschmitz
    Ok, ran across this article.

    Turns out that cronie ignores the crontab ‘if’ the last line in the file is not terminated with a line feed (0x0A).

    I added the line feed to the end of the line, saved with a new near start time and the job fired.

    Odd. But this fixes it.
    P.S. I have reopened the issue on the BackInTime github site and identified it as a bug for their remediation.

root14 backup10 cronie1 crontab1 Posts 2Views 259
Log in to reply