Re: bin/post command not working when run from crontab
On 4/18/19 4:51 PM, Erik Hatcher wrote: > Jason - thanks for replying > > and I concur, it makes sense to open a JIRA for this.I'm glad there > is an acceptable workaround, at least. > > I recall doing a fair bit of trial and error, asking 'nix folk and > stackoverflow how to handle this stdin situation and honing in on what's > there now. But it's obviously weirdly broken, sorry. Thanks a lot for the feedback, I've filed a report: https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13422?filter=allopenissues Best Carsten -- Carsten Agger Chief Technologist Magenta ApS Skt. Johannes Allé 2 8000 Århus C Tlf +45 5060 1476 http://www.magenta-aps.dk carst...@magenta-aps.dk
Re: bin/post command not working when run from crontab
Hi all I posted the question below some time back, concerning the unusual behaviour of bin/post if there is no stdin. There has been no comments to that, and maybe bin/post is quaint in that regard - I ended up changing my application to POST directly on the Web endpoint instead. But I do have one question, though: Should this be considered a bug, and should I report it as such? Unfortunately I don't have the time to prepare a proper fix myself. Best Carsten On 3/27/19 7:55 AM, Carsten Agger wrote: > I'm working with a script where I want to send a command to delete all > elements in an index; notably, > > > /opt/solr/bin/post -c -d > "*:*" > > > When run interactively, this works fine. > > However, when run automatically as a cron job, it gives this interesting > output: > > > Unrecognized argument: "*:*" > > If this was intended to be a data file, it does not exist relative to /root > > The culprit seems to be these lines, 143-148: > > if [[ ! -t 0 ]]; then > MODE="stdin" > else > # when no stdin exists and -d specified, the rest of the arguments > # are assumed to be strings to post as-is > MODE="args" > > This code seems to be doing the opposite of what the comment says - it > sets MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there > IS an stdin) it assumes the rest of the args can be posted as-is. > > On the other hand, if the condition is reversed, my command will fail > interactively but not when run as a cron job. Both options are, of > course, unsatisfactory. > > It /will/ actually work in both cases, if instead the command to delete > the contents of the index is written as: > > echo "*:*" | /opt/solr/bin/post -c > departments -d > > > I've seen this bug in SOLR 7.5.0 and 7.7.1. Should I report it as a bug > or is there an easy explanation? > > > Best > > Carsten Agger > > -- Carsten Agger Chief Technologist Magenta ApS Skt. Johannes Allé 2 8000 Århus C Tlf +45 5060 1476 http://www.magenta-aps.dk carst...@magenta-aps.dk
post command not working on non-file arguments when run from crontab
I'm working with a script where I want to send a command to delete all elements in an index; notably, /opt/solr/bin/post -c -d "*:*" When run interactively, this works fine. However, when run automatically as a cron job, it gives this interesting output: Unrecognized argument: "*:*" If this was intended to be a data file, it does not exist relative to /root The culprit seems to be these lines, 143-148: if [[ ! -t 0 ]]; then MODE="stdin" else # when no stdin exists and -d specified, the rest of the arguments # are assumed to be strings to post as-is MODE="args" This code seems to be doing the opposite of what the comment says - it sets MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an stdin) it assumes the rest of the args can be posted as-is. On the other hand, if the condition is reversed, my command will fail interactively but not when run as a cron job. Both options are, of course, unsatisfactory. It *will* actually work in both cases, if instead the command to delete the contents of the index is written as: echo "*:*" | /opt/solr/bin/post -c departments -d I've seen this bug in SOLR 7.5.0 and 7.7.1. Should I report it as a bug or is there an easy explanation? Best Carsten Agger -- Carsten Agger Chief Technologist Magenta ApS Skt. Johannes Allé 2 8000 Århus C Tlf +45 5060 1476http://www.magenta-aps.dkcarst...@magenta-aps.dk
bin/post command not working when run from crontab
I'm working with a script where I want to send a command to delete all elements in an index; notably, /opt/solr/bin/post -c -d "*:*" When run interactively, this works fine. However, when run automatically as a cron job, it gives this interesting output: Unrecognized argument: "*:*" If this was intended to be a data file, it does not exist relative to /root The culprit seems to be these lines, 143-148: if [[ ! -t 0 ]]; then MODE="stdin" else # when no stdin exists and -d specified, the rest of the arguments # are assumed to be strings to post as-is MODE="args" This code seems to be doing the opposite of what the comment says - it sets MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an stdin) it assumes the rest of the args can be posted as-is. On the other hand, if the condition is reversed, my command will fail interactively but not when run as a cron job. Both options are, of course, unsatisfactory. It /will/ actually work in both cases, if instead the command to delete the contents of the index is written as: echo "*:*" | /opt/solr/bin/post -c departments -d I've seen this bug in SOLR 7.5.0 and 7.7.1. Should I report it as a bug or is there an easy explanation? Best Carsten Agger -- Carsten Agger Chief Technologist Magenta ApS Skt. Johannes Allé 2 8000 Århus C Tlf +45 5060 1476 http://www.magenta-aps.dk carst...@magenta-aps.dk
bin/post command not working when run from crontab
I'm working with a script where I want to send a command to delete all elements in an index; notably, /opt/solr/bin/post -c -d "*:*" When run interactively, this works fine. However, when run automatically as a cron job, it gives this interesting output: Unrecognized argument: "*:*" If this was intended to be a data file, it does not exist relative to /root The culprit seems to be these lines, 143-148: if [[ ! -t 0 ]]; then MODE="stdin" else # when no stdin exists and -d specified, the rest of the arguments # are assumed to be strings to post as-is MODE="args" This code seems to be doing the opposite of what the comment says - it sets MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an stdin) it assumes the rest of the args can be posted as-is. On the other hand, if the condition is reversed, my command will fail interactively but not when run as a cron job. Both options are, of course, unsatisfactory. It /will/ actually work in both cases, if instead the command to delete the contents of the index is written as: echo "*:*" | /opt/solr/bin/post -c departments -d I've seen this bug in SOLR 7.5.0 and 7.7.1. Should I report it as a bug or is there an easy explanation? Best Carsten Agger -- Carsten Agger Chief Technologist Magenta ApS Skt. Johannes Allé 2 8000 Århus C Tlf +45 5060 1476 http://www.magenta-aps.dk carst...@magenta-aps.dk
bin/post command not working when run from crontab
I'm working with a script where I want to send a command to delete all elements in an index; notably, /opt/solr/bin/post -c -d "*:*" When run interactively, this works fine. However, when run automatically as a cron job, it gives this interesting output: Unrecognized argument: "*:*" If this was intended to be a data file, it does not exist relative to /root The culprit seems to be these lines, 143-148: if [[ ! -t 0 ]]; then MODE="stdin" else # when no stdin exists and -d specified, the rest of the arguments # are assumed to be strings to post as-is MODE="args" This code seems to be doing the opposite of what the comment says - it sets MODE="stdin" if stdin is NOT a terminal, but if it IS (i.e., there IS an stdin) it assumes the rest of the args can be posted as-is. On the other hand, if the condition is reversed, my command will fail interactively but not when run as a cron job. Both options are, of course, unsatisfactory. It /will/ actually work in both cases, if instead the command to delete the contents of the index is written as: echo "*:*" | /opt/solr/bin/post -c departments -d I've seen this bug in SOLR 7.5.0 and 7.7.1. Should I report it as a bug or is there an easy explanation? Best Carsten Agger -- Carsten Agger Chief Technologist Magenta ApS Skt. Johannes Allé 2 8000 Århus C Tlf +45 5060 1476 http://www.magenta-aps.dk carst...@magenta-aps.dk
