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

Open
andersk opened this Issue Jul 9, 2012 · 9 comments

Comments

Projects
None yet
5 participants
@andersk
Contributor

andersk commented Jul 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@bmillwood

bmillwood Sep 7, 2012

Contributor

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.

Contributor

bmillwood commented Sep 7, 2012

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

This comment has been minimized.

Show comment
Hide comment
@bmillwood

bmillwood Sep 8, 2012

Contributor

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

Contributor

bmillwood commented Sep 8, 2012

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

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Sep 21, 2012

Contributor

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.

Contributor

andersk commented Sep 21, 2012

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.

@feuerbach

This comment has been minimized.

Show comment
Hide comment
@feuerbach

feuerbach Feb 12, 2014

Contributor

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

Contributor

feuerbach commented Feb 12, 2014

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

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Feb 12, 2014

Contributor

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.)

Contributor

andersk commented Feb 12, 2014

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.)

@feuerbach

This comment has been minimized.

Show comment
Hide comment
@feuerbach

feuerbach Feb 12, 2014

Contributor

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

Contributor

feuerbach commented Feb 12, 2014

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

@andersk

This comment has been minimized.

Show comment
Hide comment
@andersk

andersk Feb 12, 2014

Contributor

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

Contributor

andersk commented Feb 12, 2014

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

@feuerbach

This comment has been minimized.

Show comment
Hide comment
@feuerbach

feuerbach Feb 12, 2014

Contributor

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.

Contributor

feuerbach commented Feb 12, 2014

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 23Skidoo self-assigned this Mar 3, 2015

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Mar 3, 2015

Member

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

Member

23Skidoo commented Mar 3, 2015

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

@ezyang ezyang modified the milestones: Obsoleted by nix-local-build, _|_ Aug 22, 2016

@23Skidoo 23Skidoo removed their assignment Sep 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment