The build failed because the process exited too early.

hen I run my application on the microSd ( having 4G ) on my Beaglebone, I get this error :

The build failed because the process exited too early. This probably means the system ran out of memory or someone called kill -9 on the process.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @coreui/coreui-free-react-admin-template@2.0.5 start-js: export PORT=5000 && react-scripts start
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @coreui/coreui-free-react-admin-template@2.0.5 start-js 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! /root/.npm/_logs/2018-08-15T11_19_14_856Z-debug.log

It is the problem of size of my microSD ?

How can I fix that please ?

Why did you send 4 messages?

https://i.imgur.com/nHGmbh7.png

That's kinda rude..

hen I run my application on the microSd ( having 4G ) on my Beaglebone, I get this error :

The build failed because the process exited too early. This probably means the system ran out of memory or someone called `kill -9` on the process.

So you ran out of RAM and the OOM killer stopped it.. Add some swap.

sudo fallocate -l 512M /swap.file
sudo chmod 600 /swap.file
sudo mkswap /swap.file
sudo swapon /swap.file

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @coreui/coreui-free-react-admin-template@2.0.5 start-js: ` export PORT=5000 && react-scripts start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @coreui/coreui-free-react-admin-template@2.0.5 start-js 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! /root/.npm/_logs/2018-08-15T11_19_14_856Z-debug.log

Did you open that file ^

It is the problem of size of my microSD ?

Or the location of the moon..

Regards,

Thank you Robert.
But when I used a microSD with 16G, I need to make a swapfile also?

Thank you Robert.
But when I used a microSD with 16G, I need to make a swapfile also?

On Thu, 23 Aug 2018 16:52:08 +0200, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:

Thank you Robert.
But when I used a microSD with 16G, I need to make a swapfile also?

  IF it is running out of RAM then yes, you likely need a swapfile.
Programs don't run "on the SD card" (or eMMC). They are /stored/ as files
there and get loaded into RAM when executed.

  The BBB RAM is only 512kB. If the program needs more RAM than is
available the OS will kill it. Using a swapfile lets the OS copy currently
idle code/data from RAM to the SD card (or other device -- I'd recommend
using a USB hard-disk, to reduce wear on flash memory) and map in the freed
RAM as more data space for the current program.

"""
Flash memory has a finite number of erase-write cycles (see Limitations of
flash memory), and the smallest amount of data that can be erased at once
might be very large (128 KiB for an Intel X25-M SSD [27]), seldom
coinciding with pagesize. Therefore, flash memory may wear out quickly if
used as swap space under tight memory conditions. On the attractive side,
flash memory is practically delayless compared to hard disks, and not
volatile as RAM chips. Schemes like ReadyBoost and Intel Turbo Memory are
made to exploit these characteristics.
"""

I create a swapfile and I run it, but every time, I get the same error…

Such as I run my application on the microSD having 16G on my BeagleBONE.

On Fri, 31 Aug 2018 20:22:06 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:

I create a swapfile and I run it, but every time, I get the same error...

  Where did you create the swap, and how big is it? Best would be to show
the actual commands used.

This is how I created my swap file :

swaap.png

On Fri, 31 Aug 2018 22:29:32 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:

This is how I created my swap file :
[image: swaap.png]

  And once again you attach an 80MB IMAGE that is unusable for cut&paste
into a command line. I don't write code in a paint program. In the future,
I will ignore any message with an image of a screen capture where text
cut&paste would be useful.

  In a second console window, run

top -o '%MEM'

and monitor the display while running whatever is using up memory. That
/should/ put the main memory hog process at the top of the list. You should
also be seeing the summary row for "KiB Swap" showing total swap usage.
(NOTE: you have to watch this live, since as soon as the OOM kill takes
place, that process will disappear from the display).

  If the total swap usage is still running out, I can only suggest trying
with a larger swap file (one reason I also recommend using a USB hard-drive
-- since each GB of swap is 15% of an 8GB SD card, and a process using a
lot of swap /could/ wear out the SD card [depends on if it is just
allocating and writing to swap vs thrashing stuff in and out of swap
space]).

  If it still gets OOM killed with 2 or 4 GB swap -- I'd think there is
something wrong with the program you are running. The only time I've had
OOM kills was when I was running the HINT benchmark (about two years ago)
and had to put in that hard drive for swap (I /did/ kill a Raspberry-Pi SD
card with that benchmark before re-running using the drive on it). HINT,
however, is smart-enough to detect when the run-time on swap grows rapidly
and ends the benchmark run at that time. On a bare-board embedded system,
HINT ends the run when malloc() returns 0 memory -- apparently Linux kills
the process rather than having malloc() fail.

I’am Sorry …
When I run this command, I get :

root@beaglebone:/home/debian# top -o ‘%MEM’
top - 00:07:42 up 14 min, 1 user, load average: 0.66, 1.51, 1.67
Tasks: 93 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 1.3 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 494588 total, 24908 free, 409256 used, 60424 buff/cache
KiB Swap: 1048572 total, 956924 free, 91648 used. 71880 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1492 root 20 0 484960 361796 11372 S 0.0 73.2 6:32.76 node
2069 root 20 0 9656 4840 4096 S 0.0 1.0 0:00.13 sshd
2071 debian 20 0 8156 4684 4032 S 0.0 0.9 0:00.15 systemd
2076 debian 20 0 9656 3728 2956 S 0.0 0.8 0:00.06 sshd
2077 debian 20 0 5568 3604 2212 S 0.0 0.7 0:00.34 bash
1254 mysql 20 0 593356 3556 2564 S 0.3 0.7 0:02.62 mysqld
1 root 20 0 25492 3432 2740 S 0.0 0.7 0:03.53 systemd
891 root 20 0 6064 3020 2772 S 0.0 0.6 0:00.15 systemd-logind
2086 root 20 0 6272 2884 2476 S 0.0 0.6 0:00.05 sudo
2090 root 20 0 7044 2820 2292 R 1.0 0.6 0:00.81 top
2087 root 20 0 6032 2636 2268 S 0.0 0.5 0:00.02 su
2088 root 20 0 4596 2628 2208 S 0.0 0.5 0:00.02 bash
2072 debian 20 0 26964 2296 1336 S 0.0 0.5 0:00.00 (sd-pam)
772 root 20 0 22592 2144 1960 S 0.3 0.4 0:11.96 systemd-journal
827 systemd+ 20 0 15948 1864 1720 S 0.0 0.4 0:00.98 systemd-timesyn
897 message+ 20 0 5324 1500 1292 S 0.0 0.3 0:00.37 dbus-daemon
1265 dnsmasq 20 0 7940 1328 1228 S 0.0 0.3 0:00.54 dnsmasq
927 root 20 0 22200 1112 844 S 0.0 0.2 0:04.29 rsyslogd
1032 root 20 0 8500 956 864 S 0.0 0.2 0:00.07 sshd
788 root 20 0 14104 848 784 S 0.0 0.2 0:02.79 systemd-udevd
882 avahi 20 0 5324 796 680 S 0.0 0.2 0:00.28 avahi-daemon
870 root 20 0 4628 636 588 S 0.0 0.1 0:00.03 cron
1068 root 20 0 6496 636 580 S 0.0 0.1 0:00.12 apache2
1079 www-data 20 0 228896 364 308 S 0.0 0.1 0:00.65 apache2
1077 www-data 20 0 228896 360 304 S 0.0 0.1 0:00.65 apache2
901 avahi 20 0 5200 8 0 S 0.0 0.0 0:00.00 avahi-daemon
979 root 20 0 4404 8 4 S 0.0 0.0 0:00.02 bash
836 root 20 0 7216 4 4 S 0.0 0.0 0:03.56 haveged
876 daemon 20 0 2968 4 4 S 0.0 0.0 0:00.01 atd

On Sun, 2 Sep 2018 00:06:20 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:

I'am Sorry ...

  Yay! A text cut&paste instead of an image! Thank you.

When I run this command, I get :
root@beaglebone:/home/debian# top -o '%MEM'

  Remember -- I said to watch it to see what is using up the memory
(since this command will update periodically)

top - 00:07:42 up 14 min, 1 user, load average: 0.66, 1.51, 1.67
Tasks: 93 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 1.3 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
KiB Mem : 494588 total, 24908 free, 409256 used, 60424 buff/cache
KiB Swap: 1048572 total, 956924 free, 91648 used. 71880 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1492 root 20 0 484960 361796 11372 S 0.0 73.2 6:32.76 node

  At the moment you did this cut&paste, "node" was sucking up 73% of the
available memory (and practically NO CPU time -- the journal and top are
the CPU users). Unless I misunderstood the documentation for "top", %mem is
based upon the total of RAM and swap. That's nearly 1.2GB right there
(though some is in memory shared with other processes)..

  Google on npm, ELIFECYCLE, and react seems to show lots of problems
with it, none with a clear explanation or solution. Some seem to imply a
problem with how packages were installed (mismatches, etc.).

  Other than kicking the swap space up to maybe 4GB as a test, I'm now
out of suggestions. I don't do stuff with node.js (I can work with Python
thread, Ada tasking -- but systems based upon asynchronous callbacks just
confuse me, and that is what node.js relies upon; even Python's async
system confuses me). Whatever node is running is sucking up memory, and one
has to be ready to debug node.js source files to make any progress.

Thank you for explanation.
In fact, Iwant to run my application developed in ReactJS and node JS at the start of Bealebone, it is necessary to execute the node then the Reactjs, the node is always executable, while reactjs once executable and another time I wait a lot and I do not does not get the application, it can generate systemd time?

On Sun, 2 Sep 2018 15:36:25 +0100, Ichrak Mansour
<ichrakmansour.ing@gmail.com> declaimed the
following:

Thank you for explanation.
In fact, Iwant to run my application developed in ReactJS and node JS at
the start of Bealebone, it is necessary to execute the node then the
Reactjs, the node is always executable, while reactjs once executable and
another time I wait a lot and I do not does not get the application, it can
generate systemd time?

  I'm sorry -- that sentence is too convoluted to be understandable.
"...and another time I wait a lot and I do not does not get the
application..." in particular.

<https://en.wikipedia.org/wiki/React_(JavaScript_library)&gt; does state:
"""
A criticism of ReactJS is that it has high memory (RAM) requirements, since
it uses the concept of a "Virtual DOM". This is where "a representation of
a UI is kept in memory and synced with the 'real' DOM by a library such as
ReactDOM."
"""

  As I'd mentioned -- I don't do node.js at all. So I can't interpret
your original traceback enough to tell if the failure occurs starting
ReactJS (if that is even an activity -- if it really is a library, it would
be your application that calls the library; not ReactJS calling your
application).

  Does ANY React-based application cause the failure, or only when your
application is invoked? If it is only your application, I'd suspect that
1) your application is much too complex and large for the intended usage
(ReactJS was meant to generate web-pages using JavaScript for interactive
user interfaces);
2) your application has something that is maybe recursive, with each
recursion eating more and more memory (given that node.js relies upon
asynchronous/callbacks I could see this as a problem -- something gets
triggered which attempts to respond in such a way that it triggers itself
again...)

I mean that when I run my application on the startup, once it will be executed, in other once, it does run after 30 minutes