TeamCity build "Process exited with code 99" - gruntjs

I'm getting this error running a TeamCity build in a step that runs a grunt task.
[Step 1/6] grunt-cli: The grunt command line interface (v1.2.0)
[Step 1/6] Process exited with code 99
Any idea of what code 99 means?

Related

Publishing React+dotnet core application using Github Actions throwing error MSB3073: The command "npm run build" exited with code 1

I am getting the below error while publishing the React+dotnet core application using Github Actions. I am using the GitHub self-hosted runners on my windows server 2016.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! ptrx_backoffice#0.1.0 build: `react-scripts build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the ptrx_backoffice#0.1.0 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!
C:\Users\Administrator\AppData\Roaming\npm-cache\_logs\2021-02-11T15_54_47_880Z-debug.log
D:\aayush\ptrx_backoffice\ptrx_backoffice\PTRX_BackOffice.csproj(49,5): error MSB3073: The command "npm run build" exited with code 1.
Error: Process completed with exit code 1.
Logfile 2021-02-11T15_54_47_880Z-debug.log output is as below. I have tried deleting node-modules, cleaned cache using npm but it doesn't seem an issue with NPM as it's clearly saying in the logs that this is not related to NPM. Please let me know if someone can help on it.
0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli 'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli 'run',
1 verbose cli 'build'
1 verbose cli ]
2 info using npm#6.13.4
3 info using node#v12.16.0
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle ptrx_backoffice#0.1.0~prebuild: ptrx_backoffice#0.1.0
6 info lifecycle ptrx_backoffice#0.1.0~build: ptrx_backoffice#0.1.0
7 verbose lifecycle ptrx_backoffice#0.1.0~build: unsafe-perm in lifecycle true
8 verbose lifecycle ptrx_backoffice#0.1.0~build: PATH: C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;D:\aayush\ptrx_backoffice\ptrx_backoffice\ClientApp\node_modules\.bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\PHP\v7.1;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\;C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\dotnet\;C:\Program Files (x86)\dotnet\;C:\Users\Administrator\AppData\Roaming\npm;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\Git\cmd;C:\Program Files\nodejs\;C:\Apache24\bin;C:\Users\Administrator\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\PuTTY\;C:\python\Scripts\;C:\python\;C:\Program Files\Scripts\;C:\Program Files\;C:\Users\Administrator\AppData\Roaming\npm;C:\Apache24\bin;C:\Program Files\JetBrains\PyCharm Community Edition 2020.1\bin;;C:\Users\Administrator\.dotnet\tools
9 verbose lifecycle ptrx_backoffice#0.1.0~build: CWD: D:\aayush\ptrx_backoffice\ptrx_backoffice\ClientApp
10 silly lifecycle ptrx_backoffice#0.1.0~build: Args: [ '/d /s /c', 'react-scripts build' ]
11 silly lifecycle ptrx_backoffice#0.1.0~build: Returned: code: 1 signal: null
12 info lifecycle ptrx_backoffice#0.1.0~build: Failed to exec build script
13 verbose stack Error: ptrx_backoffice#0.1.0 build: `react-scripts build`
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
13 verbose stack at EventEmitter.emit (events.js:321:20)
13 verbose stack at ChildProcess.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack at ChildProcess.emit (events.js:321:20)
13 verbose stack at maybeClose (internal/child_process.js:1021:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
14 verbose pkgid ptrx_backoffice#0.1.0
15 verbose cwd D:\aayush\ptrx_backoffice\ptrx_backoffice\ClientApp
16 verbose Windows_NT 6.3.9600
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build"
18 verbose node v12.16.0
19 verbose npm v6.13.4
20 error code ELIFECYCLE
21 error errno 1
22 error ptrx_backoffice#0.1.0 build: `react-scripts build`
22 error Exit status 1
23 error Failed at the ptrx_backoffice#0.1.0 build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]
According tho this link:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f70c2425-14de-49cf-b228-d29548c9ef87/getting-error-msb3073?forum=msbuild
You may have a wrong path set somewhere, just to quote the article:
Generally speaking, the Error MSB3073 is generally caused by an incorrect path in the command line.
Now, in your PATH you have, in particular, this value:
D:\aayush\ptrx_backoffice\ptrx_backoffice\ClientApp\node_modules\.bin;
But, and this is where the issue seems to be, you call this command:
C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build"
It looks that you are trying to execute a binary that does not exists.
My feeling is that you are using a development environment variable in your production environment.

Firebase - Error while setup in Firebase CLI in Windows

I am trying to setup firebase Command line interface(CLI) in windows 10, I used the below command to install firebase tools
npm install -g firebase-tools
But my installation get failed saying
npm ERR! Unexpected end of JSON input while parsing near '..."./bin/express"},"dir'
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\raj kumar\AppData\Roaming\npm-cache\_logs\2019-05-11T04_40_26_201Z-debug.log
Log says
148 verbose stack SyntaxError: Unexpected end of JSON input while parsing near '..."./bin/express"},"dir'
148 verbose stack at JSON.parse (<anonymous>)
148 verbose stack at parseJson (C:\snapshot\firepit\node_modules\npm\node_modules\json-parse-better-errors\index.js:7:17)
148 verbose stack at Body.json.consumeBody.call.then.buffer (C:\snapshot\firepit\node_modules\npm\node_modules\pacote\node_modules\make-fetch-happen\node_modules\node-fetch-npm\src\body.js:96:50)
148 verbose stack at process._tickCallback (internal/process/next_tick.js:68:7)
149 verbose cwd C:\Users\raj kumar\Downloads
150 verbose Windows_NT 10.0.16299
151 verbose argv "C:\\Users\\RAJKUM~1\\DOWNLO~1\\firebase-cli.exe" "C:\\snapshot\\firepit\\node_modules\\npm\\bin\\npm-cli" "--script-shell=C:\\Users\\RAJKUM~1\\CACHE~1\\firebase\\bin/shell.bat" "--globalconfig=C:\\Users\\RAJKUM~1\\CACHE~1\\firebase\\bin\\npmrc" "install" "-g" "--verbose" "npm" "firebase-tools"
152 verbose node v10.4.1
153 verbose npm v6.1.0
154 error Unexpected end of JSON input while parsing near '..."./bin/express"},"dir'
155 verbose exit [ 1, true ]
Can anyone help me out with this ?
Node and NPM have newer versions. Try updating them, it may solve the issue.
Then run
npm cache clean --force

Symfony Webpack encore error on run. encore: Permission denied

Symfony 4.1 with webpack encore gives error on run with npm/yarn
I followed the steps mentioned in official documentation of symfony, after successfully installing via composer require webpack-encore and after npm install, I tried npm run dev and got below error, same permission denied occurs when using yarn encore dev.
I'm using debian 9
kamii#kamii-workstation:~$ node -v
v10.9.0
kamii#kamii-workstation:~$ npm -v
6.4.1
kamii#kamii-workstation:~$ yarn -v
1.9.4
VIA NPM:
kamii#kamii-workstation:/media/disks/Development/dev_lab_gen/exim_pos$ npm run dev
> # dev /media/disks/Development/dev_lab_gen/exim_pos
> encore dev
sh: 1: encore: Permission denied
npm ERR! code ELIFECYCLE
npm ERR! errno 126
npm ERR! # dev: `encore dev`
npm ERR! Exit status 126
npm ERR!
npm ERR! Failed at the # dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/kamii/.npm/_logs/2018-09-03T20_11_01_530Z-debug.log
Via Yarn
kamii#kamii-workstation:/media/disks/Development/dev_lab_gen/exim_pos$ yarn encore dev
yarn run v1.9.4
$ /media/disks/Development/dev_lab_gen/exim_pos/node_modules/.bin/encore dev
/bin/sh: 1: /media/disks/Development/dev_lab_gen/exim_pos/node_modules/.bin/encore: Permission denied
error Command failed with exit code 126.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Here is the NPM log file
0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'run', 'dev' ]
2 info using npm#6.4.1
3 info using node#v10.9.0
4 verbose run-script [ 'predev', 'dev', 'postdev' ]
5 info lifecycle #~predev: #
6 info lifecycle #~dev: #
7 verbose lifecycle #~dev: unsafe-perm in lifecycle true
8 verbose lifecycle #~dev: PATH: /usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/media/disks/Development/dev_lab_gen/exim_pos/node_modules/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
9 verbose lifecycle #~dev: CWD: /media/disks/Development/dev_lab_gen/exim_pos
10 silly lifecycle #~dev: Args: [ '-c', 'encore dev' ]
11 silly lifecycle #~dev: Returned: code: 126 signal: null
12 info lifecycle #~dev: Failed to exec dev script
13 verbose stack Error: # dev: `encore dev`
13 verbose stack Exit status 126
13 verbose stack at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
13 verbose stack at EventEmitter.emit (events.js:182:13)
13 verbose stack at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack at ChildProcess.emit (events.js:182:13)
13 verbose stack at maybeClose (internal/child_process.js:961:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:250:5)
14 verbose pkgid #
15 verbose cwd /media/disks/Development/dev_lab_gen/exim_pos
16 verbose Linux 4.9.0-8-amd64
17 verbose argv "/usr/bin/node" "/usr/bin/npm" "run" "dev"
18 verbose node v10.9.0
19 verbose npm v6.4.1
20 error code ELIFECYCLE
21 error errno 126
22 error # dev: `encore dev`
22 error Exit status 126
23 error Failed at the # dev script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 126, true ]
Try this:
./node_modules/.bin/encore dev-server
If so, you probably have the encore installed globally and therefore when you run it you do not have permission to do it in the global folder.
Write echo $PATH and check if encore is here.
I am going to lean on #Jose's comment and share some common pitfalls:
When installing encore did you put -g (for global) flag? If not, that could be the reason.
Another common thing is that your encore was indeed installed globally (possibly /usr/local/bin) but you OS does not see it. This could merely be due to bad $PATH. Try to run source ~/.bash_profile and then retry. If you still cannot run it, the path is probably not included in your $PATH.
Finally, I hit this one pretty hard some months ago with fresh installation of Centos, where node persistently failed to install anything globally. Tutorials on Google will tell you just to chmod 777 your /usr/bin or /usr/local/bin, which is just plain bad idea. Instead, configure your node to use different destination path for its modules.
Hope this helps a bit...
I was on a partition mounted with noexec flag by default. Adding exec flag explicitly in /etc/fstab solved my problem, even solved some other permission issues with gulp.
User mounted partitions, e.g. when using the ‘user’ or ‘users’ mount options in the /etc/fstab file, are done with the ‘noexec’ mount option by default for security reasons. This means that memory mapping (mmap) files for execution will be denied. Another reason can be the lack of kernel support for shared writable mmap which was added to Linux kernel 2.6.26.
Solution: Add the ‘exec’ mount option to the end of the mount options. It’s important that the option to be the last one, otherwise other mount option can over judge its effect. However please also note that Wine was not designed to run arbitrary applications directly from a Windows partition. To do so, one must install the Windows application via Wine onto the Windows partition first.
In my case removing node_modules folder and running yarn install helped. My directory permissions changed and it influenced locally installed encore.

net.corda.core.serialization.SerializationWhitelist: Error reading configuration file

I downloaded cordapp template (Java) from https://github.com/corda/cordapp-template-java.
Everytime I make chage to the project gradlew deplyNodes fails with below error. However, it automatically gets resolved once I restart my system.
Is there anything, I am missing?
> Configure project :
Gradle now uses separate output directories for each JVM language, but this build assumes a single directory for all classes from a source set. This behaviour has been deprecated and is scheduled to be removed in Gradle 5.0
at build_d668pifueefmtb65xfqnh374z$_run_closure5.doCall(C:\Users\amit.pamecha\Documents\workspace\abcdwork\capital-coin\cordapp-template-java\build.gradle:83)
The setTestClassesDir(File) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use the setTestClassesDirs(FileCollection) method instead.
at build_d668pifueefmtb65xfqnh374z$_run_closure5.doCall(C:\Users\amit.pamecha\Documents\workspace\abcdwork\capital-coin\cordapp-template-java\build.gradle:83)
> Task :deployNodes
Bootstrapping local network in C:\Users\amit.pamecha\Documents\workspace\abcdwork\capital-coin\cordapp-template-java\build\nodes
Node config files found in the root directory - generating node directories
Generating directory for Notary
Generating directory for PartyA
Generating directory for PartyB
Nodes found in the following sub-directories: [Notary, PartyA, PartyB]
Waiting for all nodes to generate their node-info files...
Distributing all node info-files to all nodes
Gathering notary identities
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':deployNodes'.
> net.corda.core.serialization.SerializationWhitelist: Error reading configuration file
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 26s
12 actionable tasks: 4 executed, 8 up-to-date
This is caused by a stale Gradle process. You need to kill this process.
You can use killall java -9 or pkill java on Unix, or wmic process where "name like '%java%'" delete, to kill all Java processes.
Or you can use something like:
lsof -nP +c 15 | grep LISTEN to find processes and ports
ps ax | grep <pid> to confirm the command line of the process
kill -9 <pid>

Baffling Debian installation script: service starts but then quits mysteriously - Why?

I've been struggling with this one for a while and I'm thoroughly baffled.
I have this postinst Debian script that is supposed to start a service once installation (of the service executable) is complete. As best I can tell, the service does start successfully, but it then immediately and mysteriously quits. Restarting the service from the command-line works fine once Synaptic concludes.
I tried writing a dummy package to verify this. The dummy package installs /etc/init/service-dummy.conf and a symbolic link to that file, named /etc/init.d/service-dummy (just like the original service). The contents of service-dummy.conf are the same as service.conf. The dummy starts the service...and then the service keeps on running. So I can't even reproduce my problem!
The postinst script does this:
#!/bin/sh
set -e
case "$1" in
configure)
# (instructions which config, make and install the freshly installed source code)
ldconfig
echo "Install concluded"
if [ -e "/etc/init/service-dummy.conf" ]; then
echo "Starting service-dummy root service" | tee service.log
service service-dummy restart | tee --append service.log
else
echo "service-dummy.conf not installed"
fi
echo "Postinst complete"
;;
*)
echo "postinst called with unknown argument '$1'" >&2
;;
esac
# exit 1 to ensure installer stalls
exit 1
Synaptic displays the log:
...
Starting service-dummy root service
stop: Unknown instance:
service-dummy start/running, process 9207
Postinst complete
dpkg: error processing service-dummy (--configure):
subprocess installed post-installation script returned error exit status 1
...
It's as if upstart needed to be refreshed?
I tried more things and then I did get it to work, sort of: I try starting the service, then abort the script with an exit 1, and when the script runs a second time (postinst, same parameters, so I detect the second run otherwise), I start the service again, and this time it sticks.
A key clue is in the log:
Postinst complete (aborting script)
dpkg: error processing service-dummy (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
service-dummy
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up service-dummy ...
service-dummy postinst configure
Starting service-dummy a second time
stop: Unknown instance:
service-dummy start/running, process 4034
Postinst complete (aborting script recovery attempt)
So I guess my question now becomes:
How do I force ldconfig to not defer its processing?
Found the right clue here: http://lists.debian.org/debian-glibc/2008/07/msg00169.html
Turns out apt-get temporarily prevents use of ldconfig by replacing it with something else. The solution to my problem is to very simply call ldconfig.real instead of ldconfig in the script.

Resources