Hi Jim, have you checked whether NiFi can actually access the given paths (/bin/7za and /mnt/in)? You might use a script processor just to check both paths exist. If that all works, you might want to dump the processor config as json by either downloading the flow definition or manually fiddling with flow.json.gz (or flow.xml.gz). Maybe some non-printable characters, bad quotes or whatever show up. If the jvm tells you the given path does not exist, the jvm is probably right. So the path itself does not exist or is wrongly typed. Just my reasoning.
Good luck, Lars On 22 September 2022 12:01:20 CEST, James McMahon <[email protected]> wrote: >This continues to fail. I'm wondering if anyone has experience resolving >this problem below? > >It appears that ExecuteStreamCommand cannot seem to find what is a shell >script pointing to an executable, despite my having fully qualified its >path (/bin/7za): > >ExecuteStreamCommand[id=...] Failed to process session due to >java.io.IOException: Cannot run program "/bin/7za" (in directory /mnt/in") >error=2, No such file or directory: java.io.IOException:error=2, No such >file or directory >causes: java.io.IOException: Cannot run program "/bin/7za" (in directory >"/mnt/in") > >Here is my updated configuration of my ESC processor: >Command Arguments Strategy Command Arguments Property >Command Arguments e;-si;${filename} >Command Path /bin/7za >Ignore STDIN false >Working Directory /mnt/in (this dir is owned by user nifi, which is >the user the nifi jvm starts by) >Argument Delimiter ; >Output Destination Attribute No value set >Max Attribute Length 256 > >I've not found a great deal of info through Google that details how to fix >this. There are a few articles that talk about ensuring the path includes >the directory where the binary or script lives, but it's not clear what >they mean. Do they mean where JAVA_HOME gets set in nifi.sh? > >I tried also dropping my 7za script directly into the bin dir where nifi.sh >exists. My reasoning was that this would surely be a place in nifi's path. >But this test did not work. > >Jim > >On Thu, Sep 22, 2022 at 4:15 AM stephen.hindmarch.bt.com via users < >[email protected]> wrote: > >> A quick read of the 7-zip command line guide suggests you need the option >> “-si” to read from stdin. >> >> >> >> *Steve Hindmarch* >> >> >> >> *From:* James McMahon <[email protected]> >> *Sent:* 21 September 2022 17:01 >> *To:* [email protected] >> *Subject:* Re: ExecuteStreamCommand fails to extract archived files >> >> >> >> Now I see. So in the configuration of the ExecuteStreamCommand there was >> one thing we had not touched on, and it allowed this to work: Ignore STDIN >> must be set to true. I did that, I set my Command Arguments to >> e;/mnt/in/${filename} , and it worked as expected. >> >> Thanks again Mike. >> >> Jim >> >> >> >> On Wed, Sep 21, 2022 at 11:50 AM Mike Thomsen <[email protected]> >> wrote: >> >> > ExecuteStreamCommand works on the contents of the incoming flowfile, is >> that understanding correct? >> >> 7za can't read the file from stdin. That's the problem AFAICT in your >> scenario. >> >> On Wed, Sep 21, 2022 at 11:26 AM James McMahon <[email protected]> >> wrote: >> > >> > Thank you Mike. May I ask a few follow-up Qs after trying this and >> failing still? >> > >> > ExecuteStreamCommand works on the contents of the incoming flowfile, is >> that understanding correct? If so, then why does it matter where the file >> sits on the filesystem if it will apply /bin/7za to the flowfile in the >> stream? >> > >> > So I have /bin/7za in the /bin directory, it's an executable program, >> and the user that the nif jvm is running as - user named nifi - has /bin in >> its path. >> > >> > I have an archive file I created in directory /mnt/in, and it is named >> testArchive.7z. I am successfully able to read that archive file in with a >> ListFile / FetchFile, and do get it in my stream. These are its attributes: >> > absolute.path /mnt/in/ >> > filename testArchive.7z >> > >> > Is this java io exception telling us that it can't find the /bin/7za >> program, or it can't find the data itself? And if ExecuteStreamCommand is >> supposed to be applying that command to the flowfile in the stream, why is >> it important that the archive file exists on disk where >> ExecuteStreamCommand can find it? >> > >> > On Wed, Sep 21, 2022 at 11:07 AM Mike Thomsen <[email protected]> >> wrote: >> >> >> >> To do this, you need to do UpdateAttribute (to set the temp folder >> >> location) -> PutFile -> ExecuteStreamCommand to ensure the flowfile's >> >> contents are staged where 7za can find them. >> >> >> >> I think the appropriate parameter would be something like this: >> >> >> >> Command Arguments: e;${path}/${filename} >> >> >> >> Assuming ";" is the argument delimiter. >> >> >> >> On Wed, Sep 21, 2022 at 10:45 AM James McMahon <[email protected]> >> wrote: >> >> > >> >> > Hello. I have a program /bin/7za that I need to apply to flowfiles >> that were created by 7za. One of them is testArchive.7z. >> >> > >> >> > I try to employ an ExecuteStreamCommand to extract from an incoming >> flowfile to into N output flowfiles in output stream, each representing one >> file from the contents in the flowfile. >> >> > >> >> > ESC throws error=2, No such file or directory. >> >> > >> >> > java.io.Exception: Cannot run program "/bin/7za"": error=2, No such >> file or directory >> >> > >> >> > My ExecuteStreamCommand processor has this configuration: >> >> > Command Arguments e >> >> > Command Path /bin/7za >> >> > Ignore STDIN false >> >> > working Directory no value set >> >> > Argument Delimiter ; >> >> > (I do not set an Output Destination Delimiter, intending to send the >> output to output path "output stream" as separate flowfiles) >> >> > >> >> > How can I fix this problem? >> >> > >> >> > Thanks in advance, >> >> > Jim >> >>
