ankush tiwari
ankush tiwari

Reputation: 83

Why git bash installed in windows runs scripts in background?

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

Answers (1)

VonC
VonC

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 via SetConsoleCtrlHandler(), 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, typically SIGTERM. 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 for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes).

In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL 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 tasks

Co-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 to

C:\Program Files\Git\git-bash.exe

with options "--hide --no-needs-console --command=cmd\git.exe", followed by the arguments currently used.
Since git-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 of git.exe with this use of git-bash.exe in the short term.
In the long term, we can consider creating this GUI shim application within core Git, perhaps in contrib/.

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. The git maintenance start command uses the schtasks 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 form Git 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

Related Questions