Version 2.4.0 of debug just got published.

Branch	Build failing 🚨
Dependency	debug
Current Version	2.3.3
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As debug is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build is in progress Details

• ❌ continuous-integration/appveyor/branch AppVeyor build failed Details

Commits

The new version differs by 7 commits .

• b82d4e6 release 2.4.0
• 41002f1 Update bower.json (#342)
• e58d54b Node: configurable util.inspect() options (#327)
• 00f3046 Node: %O (big O) pretty-prints the object (#322)
• bd9faa1 allow colours in workers (#335)
• 501521f Use same color for same namespace. (#338)
• e2a1955 Revert "handle regex special characters"

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

What this repo does is:

https://github.com/mongodb-js/kill-mongodb/blob/15cf3f9/index.js#L7

Which is according to our docs exactly what it should not do.

Using kill -9 (SIGKILL) basically guarantees that the mongod has no chance to trap the interrupt and do important things like flush your data to disk in a consistent (i.e. not corrupted) state.

From Ruthlessly Murdering a Process:

Who's idea was this?!
It has come to my attention that there is a great wave of people out there that think using 'kill -9' on everything is a great idea. Who are these people and how did they acquire such an insidious habit? I wish I knew.

Signals
There exists in Unix a thing called a signal. There are many types of signals that are sent to processes for a great variety of reasons. When a process receives a signal, it may ignore it or catch the signal and execute a "signal handler". This is called "trapping" a signal. Untrapped signals have a default action, which are basicly "do nothing" or "exit". There are two signals that are untrappable, "SIGKILL" and "SIGSTOP".

There is a command line utility called 'kill' that simply sends a signal to a process. 'kill -signal pid' will send signal to pid. 'kill -l' will list all of the available signals. You'll notice each signal has a number and a symbolic name. There are three signals commonly used to make a process exit: SIGTERM (15, terminate), SIGINT (2, interrupt), and SIGKILL (9, kill, untrappable, "El Diablo").

Processes Exiting
Most programs require some sort of cleanup when it exits. These programs setup a signal handler to perform these cleanup duties as a result of SIGTERM and SIGINT. They would setup a signal handler for SIGKILL if they could, but SIGKILL is untrappable.

If a program decided to trap the TERM or INT signals, then it would most likely delete any temporary files, shutdown sockets, remove shared memory segments, close open files, or some other task. For instance, MySQL needs to flush data to disk and close its database files. Killing MySQL with -9 will corrupt your databases. Most user apps that work on some binary formatted data files require temporary files, using kill -9 on these apps would leave around these temporary files. Network daemons need to flush their logs and properly shutdown Internet sockets so that clients aren't left hanging. Killing your web browser can corrupt your bookmarks file, cache files, leave temp files in /tmp (remember that 20MB mpeg you clicked on? yah, it's still sitting in /tmp)

Using kill -9 on a process is like just hitting the power button on your running PC. You already know that powering off a running PC can damage your filesystem because of run-time inconsistent data, why would you do the same thing to your applications? You risk the exact same data corruption.

HOWTO
Therefore, so that your important applications may close themselves, it is very important you follow this procedure when killing them:

kill pid (sends a TERM, wait 5 seconds)
kill pid (yes, try again, wait 5 seconds)
kill -INT pid (wait for it)
kill -INT pid (damn, still not dead?)
kill -KILL pid (same thing as -9)
kill -KILL pid (something is wrong)
If the process is still running, then stop sending it signals. It's either stuck in I/O wait or it's Defunct. 'ps auxw | grep processname', if you see it's in state D, then kill its parent process (the 3rd column of 'ps -ef' is the parent pid). If it's in I/O wait, then you have a deeper system problem. Most home users will never have this problem.

Version 2.1.4 of async just got published.

Branch	Build failing 🚨
Dependency	async
Current Version	2.1.2
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As async is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build is in progress Details

• ❌ continuous-integration/appveyor/branch AppVeyor build failed Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴