After interrupting a build with Ctrl-C (SIGINT), cabal install just goes on to the next package

[andersk]

After interrupting a build with Ctrl-C (SIGINT), cabal install just goes on to the next package. So it takes way more Ctrl-Cs than it should to stop a running cabal install command. For example:

$ cabal install cabal-dev
Resolving dependencies...
Configuring HTTP-4000.2.3...
Building HTTP-4000.2.3...
Preprocessing library HTTP-4000.2.3...
[ 1 of 18] Compiling Network.HTTP.Base64 ( Network/HTTP/Base64.hs, dist/build/Network/HTTP/Base64.o )
^CConfiguring tar-0.3.2.0...
Building tar-0.3.2.0...
Preprocessing library tar-0.3.2.0...
[1 of 8] Compiling Codec.Archive.Tar.Types ( Codec/Archive/Tar/Types.hs, dist/build/Codec/Archive/Tar/Types.o )
^Ccabal: Error: some packages failed to install:
HTTP-4000.2.3 failed during the building phase. The exception was:
ExitFailure 1
cabal-dev-0.9.1 depends on tar-0.3.2.0 which failed to install.
tar-0.3.2.0 failed during the building phase. The exception was:
ExitFailure 1

This problem can be prevented by using the WCE method when launching subprocesses.

[bmillwood]

It looks like the information necessary to determine if a process was killed by a signal is not provided by the process library. Should probably take that up as a bug with them.

[bmillwood]

I opened a related bug for the process library on the GHC trac.

[andersk]

As a workaround for this missing functionality, can cabal use the WUE method instead? (That is: while running a subprocess, install a SIGINT handler that sets a flag; when the subprocess ends, if the flag is set, reraise the signal.) WUE is inferior to WCE, but the difference isn’t very noticable for noninteractive subprocesses.

[UnkindPartition]

I believe the correct way to do this on POSIX systems is via process groups.

[andersk]

The process library ticket has been closed for GHC 7.8. The library now provides the negative signal number as the exit status for terminated processes, which allows WCE to be implemented. On previous GHC versions, we could still use WUE, which is better than nothing.

(@feuerbach, process groups have nothing to do with this problem. The child processes are correctly exiting with SIGINT. The bug is just that cabal is ignoring the SIGINT exit status from its child, as well as the SIGINT that it received itself.)

[UnkindPartition]

@andersk thanks for clarifying. But why does it ignore its own SIGINT and have to get this information indirectly through its children?

[andersk]

@feuerbach, this is all explained in detail in the link I posted with the original report: http://www.cons.org/cracauer/sigint.html

[UnkindPartition]

I just realized that it has to do that so as not to die when running a ghci session inside cabal repl (as it used to some time ago).

But I'll make sure to read that article. Thanks.

[23Skidoo]

Assigning to myself so that I don't forget about it, but feel free to take this ticket.

[AndreasPK]

On windows this is still the case with new-build.

Edit: I missread. The issue is that it keeps building the current package but it does not continue with the next one so slightly different issue.

[gbaz]

closing as obsolete