Created attachment 1764056 [details]
fix git-maintenance crontab command for cronie

The maintenance command is relatively new.

At a glance, it looks like the code is calling `crontab` with no arguments to get the edit mode, which cronie stopped supporting.  References:

https://github.com/cronie-crond/cronie/issues/28
https://github.com/cronie-crond/cronie/commit/39a67fdb6
39a67fd (crontab: Make crontab without arguments fail., 2019-02-15)

A patch like this fixes the issue for Fedora (also attached as a git formatted patch):

```
diff --git i/builtin/gc.c w/builtin/gc.c
index ef7226d7bc..9ed8058356 100644
--- i/builtin/gc.c
+++ w/builtin/gc.c
@@ -1904,6 +1904,7 @@ static int crontab_update_schedule(int run_maintenance, int fd, const char *cmd)
        rewind(cron_list);
 
        strvec_split(&crontab_edit.args, cmd);
+       strvec_push(&crontab_list.args, "-");
        crontab_edit.in = -1;
        crontab_edit.git_cmd = 0;

```

However, I would be very reluctant to carry such a patch in the Fedora package.  It's unlikely to be acceptable upstream because it breaks on POSIX-compliant crontab implementations.

It's really a cronie "bug" here, since it deviates from POSIX.  I completely understand why cronie does this.  But I'm not sure that trying to fix such usage issues in commands like crontab is worth the cost.  Anyone running crontab should read the man page.

In the bigger picture it seems like the git maintenance command should setup a systemd timer on systems which use systemd, since crond may not even be installed or enabled.  But that's something for upstream to consider and someone interested in git maintenance to implement.  That may be worth bringing up on the git list (git.org).

Re-assigning to cronie to register the "complaint" which Tomáš asked for in https://github.com/cronie-crond/cronie/issues/28 (2 years ago). :)

If there's been 1 complaint in 2 years, I can understand if cronie doesn't wish to revert to the POSIX-compliant behavior.  (Though I hope it does, on the grounds that users of cron should be willing to accept some of the warts of an old and widely-implemented command like crontab specified by POSIX.)

I'm not yet sure if I'd want to carry a local patch in git to support git maintenance with cronie or not.  The git maintenance code is relatively new and may change which will bring work to rebase it over time.  So even though it's a tiny patch it could cause more work than it's worth.

I have no plan to change the crontab behavior in upstream cronie to revert back. The posix mandated behavior is really stupid as accidentally typing crontab without any options will overwrite your crontab unless you do CTRL-C.

But thinking about it more, perhaps there is one thing that could be done - test whether stdin is TTY and if not revert back to the POSIX behavior. This might work for you and it would fix the accidental overwrite as well.

if (isatty(0)) { /* print helpful comment to user */ }

=> https://github.com/cronie-crond/cronie/issues/28#issuecomment-801143756

Understood.  No argument that the POSIX behavior is an ugly foot gun.  I didn't know that it would overwrite the crontab as easily either (I guess ^C is deeply ingrained in me).

Thanks for considering the fallback to POSIX behavior.  That does seem like a good middle ground -- I've implemented that sort of test in python command-line tools which can be used in pipelines as well as directly.  If the implementation isn't too bad it would be a nice way to handle things.

I do hope that eventually there is support for systemd timers in git maintenance which will make this particular method of hitting the issue moot.  But that's not an itch of mine. :)

Created attachment 1764110 [details]
fix git-maintenance crontab command for cronie

FEDORA-2021-93a62df830 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-93a62df830

FEDORA-2021-b55af90afe has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b55af90afe

Thanks for the impressively quick fix Tomáš!  Nicely done.

I tested cronie-1.5.6 with git maintenance (on the 32 laptop I have handy).  It works perfectly when called by git and it continues to provide the expected usage output when run directly.

I shall try to spin up an f33 and/or f34 system to test the official updates and leave positive karma in bodhi.

FEDORA-2021-b55af90afe has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b55af90afe`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b55af90afe

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-93a62df830 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-93a62df830`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-93a62df830

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-b55af90afe has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-93a62df830 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.