git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] maintenance: specify explicit stdin for crontab

From
Derrick Stolee <stolee@gmail.com>
Date
Mar 30, 2021, 19:38 UTC
Message-ID
<f876cbad-ec12-6ee0-ede2-8f439ad4ad34@gmail.com>
In-Reply-To
<20210330174333.GJ15354@pobox.com>
On 3/30/2021 1:43 PM, Todd Zullinger wrote:
Show 18 quoted lines
> Hi,
> 
> Derrick Stolee wrote:
>> On 3/30/2021 1:41 AM, Martin Ågren wrote:
>>> On Mon, 29 Mar 2021 at 23:23, Kevin Daudt <me@ikke.info> wrote:
>>>>
>>>> There are multiple crontab implementations that require stdin for
>>>> editing a crontab to be explicitly specified as '-'.
> 
> Amusingly, I wrote the exact same patch 2 weeks ago
> (including not dropping the `argc == 2` which Martin
> mentioned).  That was in response to a report in the Fedora
> bugzilla:
> 
>     https://bugzilla.redhat.com/1939930
> 
> I thought cronie might be rather rare with it's non-POSIX
> handling of crontab without arguments.
Thanks for this link! I appreciate the context.
 
Show 9 quoted lines
> In the end, the cronie folks upstream adjusted things so
> that crontab behaves as defined by POSIX if stdin is not a
> TTY:
> 
>     https://github.com/cronie-crond/cronie/commit/8b0241f
>> That allows cronie to behave more sensibly for interactive
> use without breaking tools like git maintenance.  And it let
> me sidestep proposing a patch to git (or worse, maintaining
> it in the Fedora packages).
Nice!
 
Show 36 quoted lines
> But I didn't dig in to find out whether or how many other
> crontab implemntations had also eschewed the (rather poor)
> POSIX-confirming behavior.  Knowing there are several among
> popular OS's makes it easy to see something like this patch
> being generally useful.
> 
> Though, as Derrick notes below, we would break systems which
> implement crontab strictly per the POSIX spec.  I don't know
> how many crontab's don't accept `-`.
> 
> At the time, I checked on an older OmniOS system I had
> access to (based on Illumos/OpenSolaris) and it did not
> accept `-`.  So my quick sample size of 3 (Fedora, CentOS,
> and OmniOS) I had a 1/3 failure rate.
> 
>> Thank you for reporting this, especially with a patch!
>>
>> However, I'm not sure about this adding of '-' being something that
>> crontab ignores so commonly. My Ubuntu machine reports this:
>>
>> $ crontab -e -
>> crontab: usage error: no arguments permitted after this option
>> usage:  crontab [-u user] file
>>         crontab [ -u user ] [ -i ] { -e | -l | -r }
>>                 (default operation is replace, per 1003.2)
>>         -e      (edit user's crontab)
>>         -l      (list user's crontab)
>>         -r      (delete user's crontab)
>>         -i      (prompt before deleting user's crontab)
>>
>> Is there a way we could attempt writing over stdin, notice the
>> failure, then retry with the '-' option?
> 
> You'd skip the `-e` there, no?  Running `crontab -` in a
> current ubuntu container with the cron package installed
> (what looks like vixie-cron-3.0pl1) works as expected.
Yes, this is my mistake. My machine supports "crontab -".
Show 16 quoted lines
> Perhaps a Makefile knob to allow systems with such a crontab
> to adjust the behavior would be an alternative to detecting
> and retrying?
> 
> NEEDS_CRONTAB_STDIN_OPT or something like that, with
> config.mak.uname to override whichever default is chosen.
> Whether that's a better option really depends on how much
> effort it is to add and maintain the detection in the code
> weighed against how many systems would need to have the
> default changed.
> 
> Mildy related, I wonder whether we'll eventually see a patch
> to use systemd timers instead of cron (optionally, of
> course).  Fedora, for example, doesn't install crond by
> default anymore.  (Though, warts and all, I still prefer
> crond myself.)

Perhaps the best way to approach this is to try adding '-' by default, and remove it and try again on a failure. If the usage is actually a problem, that first command should fail quickly. I'm not sure if we could rely upon a specific category of error codes or if we should just say "non-zero exit means retry".

Thanks! -Stolee

Previous: Todd Zullinger
Message 7 of 7 in “maintenance: specify explicit stdin for crontab”
  1. maintenance: specify explicit stdin for crontabKevin Daudt, Mar 29, 2021
  2. Martin ÅgrenMar 30, 2021
  3. Derrick StoleeMar 30, 2021
  4. Kevin DaudtMar 30, 2021
  5. Derrick StoleeMar 30, 2021
  6. Todd ZullingerMar 30, 2021
  7. Derrick StoleeMar 30, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.