Reputation: 83
I am using git bash in windows to run some nodejs scripts but whenever I use it and exit git bash automatically shifts that process to background and doesn't let me use that port until unless I kill that port using command.
But when I use cmd it works perfectly and process doesn't run in background and there no need to kill process running on port any answer why?
Upvotes: 2
Views: 1787
Reputation: 1323753
That is also reported in vscode issue 24452 leading to node-pty issue 7.
Both refer to git-for-windows/git issue 227
The official maintainer Johannes Schindelin (dscho) mentions 3 months ago (June 2017):
Alas, it is not. In v2.13.1, I changed the way Ctrl+C works and the problem described in this ticket still persists.
Any help would be very much appreciated.
ConEmu/issue 402 includes:
The problem comes from different implementations of Ctrl+C processing in cygwin/msys applications.
POSIX applications are ready to process "signals" in most cases, but often ignores console events.
Update April 2018, Johanes just added:
After testing this with my fix for #1491 (which will hit https://wingit.blob.core.windows.net/files/index.html soon, so you can verify my claim, and you should, if you are interested in this issue) it would appear that there is no longer a freeze (although quite a bit of delay if you hit Ctrl+C tons of times).
See git-for-windows/MSYS2-packages commit f4fda0f:
msys2-runtime
: revamp Ctrl+C handling yet again
This thing again...
Background: when you hit Ctrl+C on Linux or macOS, a signal (
SIGINT
) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal.
On Windows, there is no precise equivalent for this system.Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a
ConsoleCtrl
event that is sent to all processes attached to that Console. If any of these processes installed a handler viaSetConsoleCtrlHandler()
, they can intercept that event (and avoid exiting or doing some cleanup work).On Linux and macOS (and every Unix flavor, really), processes can also be killed via the
kill
executable, which really just sends a signal to the process, typicallySIGTERM
. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that,SIGKILL
can be sent.
There is no equivalent forSIGTERM
on Windows. To emulateSIGKILL
on Windows,TerminateProcess()
can be used, but it only kills one process (unlikeSIGKILL
, which is sent also to the child processes).In Git for Windows, we struggled with emulating
SIGINT
,SIGTERM
andSIGKILL
handling essentially since the beginning of the efforts to port Git to Windows.
The rest of the comment describes the original attempt and the new one.
That might go into Git 2.18 (Q2 2018).
Another cause for background job with Git for Windows: the new command git maintenance
(Git 2.29 (Q4 2020)).
But that changes with Git 2.31 (Q1 2021), and the introduction of the scheduled maintenance tasks to support platforms whose native scheduling methods are not 'cron'.
See commit 3797a0a, commit 2afe7e3 (05 Jan 2021), and commit 16c5690, commit 31345d5 (24 Nov 2020) by Derrick Stolee (derrickstolee
).
(Merged by Junio C Hamano -- gitster
-- in commit b2ace18, 15 Jan 2021)
maintenance
: use Windows scheduled tasksCo-authored-by: Eric Sunshine
Signed-off-by: Eric Sunshine
Signed-off-by: Derrick Stolee
Git's background maintenance uses cron by default, but this is not available on Windows.
Instead, integrate with Task Scheduler.Tasks can be scheduled using the 'schtasks' command.
There are several command-line options that can allow for some advanced scheduling, but unfortunately these seem to all require authenticating using a password.Instead, use the "
/xml
" option to pass an XML file that contains the configuration for the necessary schedule.
These XML files are based on some that I exported after constructing a schedule in the Task Scheduler GUI.
These options only run background maintenance when the user is logged in, and more fields are populated with the current username and SID at run-time by 'schtasks'.Since the
GIT_TEST_MAINT_SCHEDULER
environment variable allows us to specify 'schtasks' as the scheduler, we can test the Windows-specific logic on other platforms.
Thus, add a check that the XML file written by Git is valid when xmllint exists on the system.Since we use a temporary file for the XML files sent to '
schtasks
', we prefix the random characters with the frequency so it is easier to examine the proper file during tests.
Instead of an exact match on the 'args
' file, we 'grep
' for the arguments other than the filename.There is a deficiency in the current design.
Windows has two kinds of applications: GUI applications that start by "winmain()
" and console applications that start by "main()
".
Console applications are attached to a new Console window if they are not already associated with a GUI application.
This means that every hour the scheduled task launches a command window for the scheduled tasks.
Not only is this visually obtrusive, but it also takes focus from whatever else the user is doing!A simple fix would be to insert a GUI application that acts as a shim between the scheduled task and Git.
This is currently possible in Git for Windows by setting the<Command>
tag equal toC:\Program Files\Git\git-bash.exe
with options "
--hide --no-needs-console --command=cmd\git.exe
", followed by the arguments currently used.
Sincegit-bash.exe
is not included in Windows builds of core Git, I chose to leave out this feature.
My plan is to submit a small patch to Git for Windows that converts the use ofgit.exe
with this use ofgit-bash.exe
in the short term.
In the long term, we can consider creating this GUI shim application within core Git, perhaps incontrib/
.
git maintenance
now includes in its man page:
BACKGROUND MAINTENANCE ON WINDOWS SYSTEMS
Windows does not support
cron
and instead has its own system for scheduling background tasks. Thegit maintenance start
command uses theschtasks
command to submit tasks to this system. You can inspect all background tasks using the Task Scheduler application. The tasks added by Git have names of the formGit Maintenance (<frequency>)
. The Task Scheduler GUI has ways to inspect these tasks, but you can also export the tasks to XML files and view the details there.Note that since Git is a console application, these background tasks create a console window visible to the current user. This can be changed manually by selecting the "Run whether user is logged in or not" option in Task Scheduler. This change requires a password input, which is why
git maintenance start
does not select it by default.If you want to customize the background tasks, please rename the tasks so future calls to
git maintenance (start|stop)
do not overwrite your custom tasks.
Upvotes: 2