Crashes strider

[knownasilya]

Not sure how to recreate this, but it seems like during npm install process in prepare phase, if it takes a while, it crashes strider. No errors that I can see.

Have strict caching enabled and node stable.

[fernandoneto]

having same issue and can't found any errors.

[knownasilya]

@fernandoneto one issue i've found is that big processes take more memory, and if your system is low on swap memory, the OOM Killer takes over and kills the process.

[fernandoneto]

im running in a instance with 1 gb of memory. when the npm install process start cpu go to 100% and memory 800/900 :( .

[knownasilya]

@fernandoneto I've solved this by doing builds locally and doing npm install --production instead. This saves on significant overhead for npm install. This might not be feasible for your situation..

[fernandoneto]

@knownasilya sorry but i don't understand your aproach.

[knownasilya]

Meaning that I forgo installing the development dependencies since I build my client assets locally. But this would only work if you don't run tests and only use Strider as continuous deployment to a like an alpha server.

[cusspvz]

@fernandoneto, npm install --production installs only resources we need to initialize a server environment bypassing development dependencies, although we need those to test our environment which isn't a good solution for a CI.

@knownasilya unfortunately we may discard the use of strider since, as @fernandoneto told me personally, doesn't clean up testing containers. :/

[knownasilya]

By testing containers are you referring to the fact that build data doesn't get wiped out?

[cusspvz]

@fernandoneto is in charge of it, and on last crashes we experienced he reported that the system had lots of containers, and probably strider wasn't removing all of them.

EDIT: I meant stopped containers.

[knownasilya]

Like Docker containers? Would love to know more..

[cusspvz]

ping @fernandoneto

[fernandoneto]

@knownasilya
yes docker containers, our tests runs inside docker containers. When we facing the last crash i have to reboot the server to can acess over ssh and there are lots of stoped containers.
The most of then in the status have exit a couple of minutes ago, so maybe all the container's runnig caused a lot of memory usage and server crash.
I can not specify the number of container's stoped but is something around 15,20.