unsafe-perm in lifecycle true

Bug report

What is the current behavior?
This error shows when I try running the webpack
0 info it worked if it ends with ok
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 ‘webpack’ ]
2 info using npm@5.6.0
3 info using node@v8.11.3
4 verbose run-script [ ‘prewebpack’, ‘webpack’, ‘postwebpack’ ]
5 info lifecycle dms@1.0.0prewebpack: dms@1.0.0
6 info lifecycle dms@1.0.0
webpack: dms@1.0.0
7 verbose lifecycle dms@1.0.0webpack: unsafe-perm in lifecycle true
8 verbose lifecycle dms@1.0.0
webpack: PATH: C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;C:\wamp64\www\dms\node_modules.bin;C:\Users\paul-alcabasa\bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\local\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Users\paul-alcabasa\bin;C:\instantclient_11_2;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\DevSuiteHome_1\jdk\jre\bin\classic;C:\DevSuiteHome_1\jdk\jre\bin;C:\DevSuiteHome_1\jdk\jre\bin\client;C:\DevSuiteHome_1\jlib;C:\DevSuiteHome_1\bin;C:\DevSuiteHome_1\jre\1.4.2\bin\client;C:\DevSuiteHome_1\jre\1.4.2\bin;C:\Program Files (x86)\Intel\iCLS Client;C:\Program Files\Intel\iCLS Client;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\WINDOWS\System32\OpenSSH;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C:\Program Files\Git\cmd;C:\Program Files\nodejs;C:\Program Files (x86)\Yarn\bin;C:\Users\paul-alcabasa\AppData\Local\Microsoft\WindowsApps;C:\Users\paul-alcabasa\AppData\Roaming\npm;C:\Users\paul-alcabasa\AppData\Local\Yarn\bin;C:\Program Files\Git\usr\bin\vendor_perl;C:\Program Files\Git\usr\bin\core_perl
9 verbose lifecycle dms@1.0.0webpack: CWD: C:\wamp64\www\dms
10 silly lifecycle dms@1.0.0
webpack: Args: [ ‘/d /s /c’, ‘webpack’ ]
11 silly lifecycle dms@1.0.0webpack: Returned: code: 1 signal: null
12 info lifecycle dms@1.0.0
webpack: Failed to exec webpack script
13 verbose stack Error: dms@1.0.0 webpack: webpack
13 verbose stack Exit status 1
13 verbose stack at EventEmitter. (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:285:16)
13 verbose stack at emitTwo (events.js:126:13)
13 verbose stack at EventEmitter.emit (events.js:214:7)
13 verbose stack at ChildProcess. (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack at emitTwo (events.js:126:13)
13 verbose stack at ChildProcess.emit (events.js:214:7)
13 verbose stack at maybeClose (internal/child_process.js:925:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
14 verbose pkgid dms@1.0.0
15 verbose cwd C:\wamp64\www\dms
16 verbose Windows_NT 10.0.17134
17 verbose argv “C:\Program Files\nodejs\node.exe” “C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js” “run” “webpack”
18 verbose node v8.11.3
19 verbose npm v5.6.0
20 error code ELIFECYCLE
21 error errno 1
22 error dms@1.0.0 webpack: webpack
22 error Exit status 1
23 error Failed at the dms@1.0.0 webpack script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

If the current behavior is a bug, please provide the steps to reproduce.
The error just popped out after I tried running it again.

What is the expected behavior?
It should run as is.

Other relevant information:
webpack version: 4.19.1
Node.js version: v8.11.3
Operating System: Windows 10
Additional tools:

Author: Fantashit

2 thoughts on “unsafe-perm in lifecycle true

  1. For late readers: on my side it was a RAM issue (running this command inside a docker for which I only allocated 1.5 GiB)
    Moving this limit to 2.5GiB did the trick

Comments are closed.