stderr maxBuffer exceeded

[allan-bonadio]

Hi, I was getting this to work, and I ran into this glitch. I'd run my little rpmbuilder.js program and after maybe a minute i'd get this:

Error: stderr maxBuffer exceeded

this came from child-process. At first I tried passing in an option:

  execOpts: {maxBuffer: 1e6},

but that wasn't even big enough. Finally I commended out this line in index.js:

var cmd = [
  'rpmbuild',
  '-bb',
  //'-vv',          <<<====****
  '--buildroot',
  buildRoot,
  specFile
].join(' ');

The -vv was generating gobs and gobs of output into stderr. Since it seems to be dropped anyway, you probably don't need it.

BUT, after that the program wouldn't quit. Generated the rpm file, i just have to ^C. could be my problem, but just fyi.

[rictorres]

Hey, @allan-bonadio.

It's weird that execOpts: {maxBuffer: 1e6} didn't work for you :(
Perhaps I could add an option to disable verbose mode when running require('child_process').exec

[jbesta]

I've also encountered this issue.

I think that the main problem is the usage of exec in the first place. It needs to buffer whole output before returning which may be a problem in case of big RPM builds.

I think that the implementation should switch from using exec to spawn.

@rictorres What is your opinion on that?

additional info:
http://www.hacksparrow.com/difference-between-spawn-and-exec-of-node-js-child_process.html

[johnsdavis47]

Changing the "-vv" in index.js to just "-v" worked for me on RHEL 6 and Mac OS 10.14.4

[kvnify]

I created a PR to remove the -vv parameter. It wasn't adding any value and only caused builds that included a lot of files to fail. We need to bundle in our node_modules in our RPM bundles as we deploy to an env where we cannot access NPM and would also like to avoid the back and forth on those networks. As such the debug spam is large and there is no way even a small project would succeed as is. Another option would be to make it configurable. Although I don't see much value it it as is. Debugging could be done by taking the command and trying it outside the scope of this module and and adding the verbose flag back to see what information it provides.

PR: #31