Open mindplay-dk opened 6 years ago
By the way, the extra ^C
in the output was me unnecessarily pressing CTRL+C
, because I wasn't getting a command prompt... it's not that concurrently
is still hanging, it does stop after the last process terminates, pressing ENTER will do, as you can see here:
$ ps -a
PID TTY TIME CMD
1723 tty1 00:00:00 node
1867 tty1 00:00:06 node-sass
5220 tty2 00:00:00 sudo
5221 tty2 00:00:03 caddy
5504 tty1 00:00:00 node
5648 tty1 00:02:16 node-sass
6043 tty1 00:00:00 ps
$ kill -9 1867
$ [1] npm run watch-sass exited with code null
$ ps -a
PID TTY TIME CMD
5220 tty2 00:00:00 sudo
5221 tty2 00:00:03 caddy
5504 tty1 00:00:00 node
5648 tty1 00:02:16 node-sass
6044 tty1 00:00:00 ps
I've been having a similar problem. Launching tsc -w
+ docker-compose up
, and after pressing ctrl+c it stuck there :
If I press ctrl+c again, it seems to stop tsc -w
but my docker-compose is still up.
In my case, I think I've isolated it to node-sass
- it seems to be the cause of the hang-up every time. Maybe. Or maybe I've just been doing more SASS work lately. Either way, I suppose concurrently
ought to have a timeout setting of some sort? And if the process gets terminated, ideally, should never leave hanging processes in the background. (?)
Heya, do you mind giving v4 a try? It fixed a similar case of processes hanging (#105).
@gustavohenke same problem here with v4.0.1 (windows 10) At first I thought as @mindplay-dk did, that it was node-sass related but problem occurs with webpack alone too.
Anyway, I use git bash (inside vscode) but noticed the problem doesn't happen in Cmder nor in cmd (you still have to press "O" to confirm exit and return to prompt, wich is quite boring but it doesn't hang as in bash). I hope it will help to solve this, until this is fixed I go back to parallelshell (so sad 😢 )
I haven't experienced it in a while (a few months, probably) so maybe this was due to bugs in earlier versions of WSL? It's hard to say, since there are so many different moving pieces when running a bunch of scripts/commands from different vendors concurrently.
Sounds like @tfritsch-km is still having problems though.
I'll be sure to chime in if I encounter any problems again.
@tfritsch-km are you able to isolate this issue in a small repo that I could clone and test?
@redaxmedia can you isolate this issue in a small repo that I could clone and test?
same issue here, concurrently run babel and nodemon, after press command + c, the nodemon still running.
nodemon still runs even after a couple of ctrl + c
This workaround solved the issue for our project https://github.com/webpack/webpack-dev-server/issues/1479#issuecomment-476187719
I confirm problem still there with docker-compose (concurrently version 4.1.1). I have 3 docker containers running but on ctrl+c only 1 of them closes:
Not 100% sure if this is the same problem but I was having issues when running some Webpack process and AWS amplify mock. Running from yarn scripts with a command like: "concurrently \"amplify mock api\" \"NODE_ENV=development node ./amplify/backend/scripts/start.js\"",
, I could never get both process to exit by pressing ctrl+c
, I would always need to press it twice for it to exit and even then it didn't do some of the cleanup that running the process independently would normally do.
However, I have found that by specifying the --raw
flag, I get the expected behaviour and, since I don't need any of the extra log output, this is a fine workaround for me.
I was having the same issue with docker-compose in a concurrently script command. Removing the -k
flag now terminates docker. Previously it would hang. The error message from --raw
is:
Gracefully stopping... (press Ctrl+C again to force)
Traceback (most recent call last):
File "compose/cli/main.py", line 1424, in up_shutdown_context
File "compose/project.py", line 296, in stop
File "compose/project.py", line 725, in containers
File "compose/project.py", line 707, in _labeled_containers
File "site-packages/docker/api/container.py", line 211, in containers
File "site-packages/docker/utils/decorators.py", line 46, in inner
File "site-packages/docker/api/client.py", line 230, in _get
File "site-packages/requests/sessions.py", line 546, in get
File "site-packages/requests/sessions.py", line 533, in request
File "site-packages/requests/sessions.py", line 646, in send
File "site-packages/requests/adapters.py", line 449, in send
File "site-packages/urllib3/connectionpool.py", line 677, in urlopen
File "site-packages/urllib3/connectionpool.py", line 426, in _make_request
File "<string>", line 3, in raise_from
File "site-packages/urllib3/connectionpool.py", line 421, in _make_request
File "http/client.py", line 1344, in getresponse
File "http/client.py", line 330, in begin
File "http/client.py", line 224, in parse_headers
File "email/parser.py", line 67, in parsestr
File "email/parser.py", line 56, in parse
File "email/feedparser.py", line 176, in feed
File "email/feedparser.py", line 180, in _call_parse
File "email/feedparser.py", line 224, in _parsegen
File "email/feedparser.py", line 129, in __next__
File "email/feedparser.py", line 89, in readline
File "compose/cli/signals.py", line 18, in shutdown
compose.cli.signals.ShutdownException
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "contextlib.py", line 130, in __exit__
File "site-packages/requests/utils.py", line 685, in set_environ
File "site-packages/requests/utils.py", line 745, in should_bypass_proxies
File "urllib/request.py", line 2610, in proxy_bypass
File "urllib/request.py", line 2480, in getproxies_environment
File "/Users/administrator/jenkins/workspace/dsg_compose_1.26.2/venv/lib/python3.7/_collections_abc.py", line 743, in __iter__
File "os.py", line 703, in __iter__
File "compose/cli/signals.py", line 18, in shutdown
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "compose/cli/main.py", line 72, in main
File "compose/cli/main.py", line 128, in perform_command
File "compose/cli/main.py", line 1120, in up
File "contextlib.py", line 130, in __exit__
File "compose/cli/main.py", line 1426, in up_shutdown_context
File "compose/project.py", line 323, in kill
File "compose/project.py", line 725, in containers
File "compose/project.py", line 707, in _labeled_containers
File "site-packages/docker/api/container.py", line 211, in containers
File "site-packages/docker/utils/decorators.py", line 46, in inner
File "site-packages/docker/api/client.py", line 230, in _get
File "site-packages/requests/sessions.py", line 546, in get
File "site-packages/requests/sessions.py", line 524, in request
File "site-packages/requests/sessions.py", line 700, in merge_environment_settings
File "site-packages/requests/utils.py", line 761, in get_environ_proxies
File "site-packages/requests/utils.py", line 747, in should_bypass_proxies
File "contextlib.py", line 158, in __exit__
File "compose/cli/signals.py", line 18, in shutdown
compose.cli.signals.ShutdownException
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "logging/__init__.py", line 1619, in isEnabledFor
KeyError: 40
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "docker-compose", line 6, in <module>
File "compose/cli/main.py", line 74, in main
File "logging/__init__.py", line 1406, in error
File "logging/__init__.py", line 1621, in isEnabledFor
File "logging/__init__.py", line 218, in _acquireLock
File "compose/cli/signals.py", line 18, in shutdown
compose.cli.signals.ShutdownException
[28222] Failed to execute script docker-compose
@gustavohenke I isolated the issue in a small repo https://github.com/tiagob/concurrently-docker-compose
@gustavohenke my version is "concurrently": "^5.3.0"
which is also in the minimal reproducible repo. Let me know if there's anything else you need
I've started using
concurrently
quite heavily.For example, I might have
tsc
,webpack
andnode-sass
all running with--watch
during development.I started noticing weird behavior, including on several occasions, my source files randomly getting deleted when I run
git
commands! Fortunately these are usually under source-control, so I can get them back with agit reset
, but it's quite confusing.The problem, it seems, is when I try to shut down
concurrently
, I can sometimes wait for several minutes and nothing happens - often this happens after e.g.webpack
has crashed or stalled, which is tends to do if I remove one of the source-files it's watching.So eventually I press
CTRL+C
again, which terminatesconcurrently
, but appears to leave running processes hanging in the background.Here's some terminal output:
As you can see, my first attempt to
kill 1685
fails - I'm betting this is whyconcurrently
hangs as well, it isn't able to shut down the hangingnode-sass
process the normal way.Forcing
node-sass
to stop withkill -9 1685
also apparently causes the hangingnode
process (which is runningconcurrently
) to report thatnode-sass
has finally stopped - and as you can see from the lastps -a
, both thenode
process that was runningconcurrently
, and thenode-sass
process it was running, have finally stopped.Is it possible to set a timeout for
concurrently
, e.g. forcing child processes to stop after a set maximum period of waiting? I didn't see a command-line option for that.Any idea how to resolve this?