Opened 14 years ago

Closed 6 years ago

Last modified 4 years ago

#10226 closed defect (fixed)

BUG: port command can't be interrupted cleanly - creates database inconsistency

Reported by: yaseppochi (Stephen J. Turnbull) Owned by: macports-tickets@…
Priority: High Milestone: MacPorts 2.4.0
Component: base Version:
Keywords: Cc: yaseppochi (Stephen J. Turnbull), markd@…, vinc17@…, pguyot (Paul Guyot), jmpp@…, blb@…, schneider.pj@…, nerdling (Jeremy Lavergne), gardnermj@…, cooljeanius (Eric Gallager), frozencemetery (Robbie Harwood)
Port:

Description (last modified by jmpp@…)

Attempting to upgrade gnupg from 1.4.4_0 to 1.4.5_0 hangs (reported separately).

After waiting 5 min, I interrupted the "port -v upgrade gnupg" process. This left my ports in the following peculiar state:

port info gnupg claims that gnupg is at 1.4.5. The PortIndex file claims that gnupg is at 1.4.5. The Portfile claims that gnupg is at 1.4.5. port outdated doesn't report gnupg as outdated. gnupg 1.4.4_0 has been deactivated, quietly leaving me without gpg.

This is really evil, especially considering that the deactivation normally takes place just before activating the new version. By scrolling back to the beginning, I can see that the deactivation took place, but if one habitually runs with port -d, or immediately reruns the upgrade with -d without looking closely at the output, he'll probably miss the fact that gnupg was deactivated.

port built 1 Aug 2006 00:07 JST from freshly updated CVS.

Change History (26)

comment:1 Changed 14 years ago by markd@…

Cc: markd@… added
Summary: hung upgrade of gnupg leaves port very confusedBUG: hung upgrade of gnupg leaves port very confused

Most programs don't guarantee behavior after an abnormal cancellation. If you could recommend specific changes to be made this could be an RFE rather than a bug.

comment:2 Changed 14 years ago by markd@…

Resolution: duplicate
Status: newclosed

I think we can close this since since the cause is filed in ticket 10227. There is no clear answer to the effect, if there are sugestions it should be done as an RFE.

comment:3 Changed 14 years ago by yaseppochi (Stephen J. Turnbull)

Resolution: duplicate
Status: closedreopened

(1) This is a bug in port, not in gnupg. Any time a user feels the need to interrupt port, she's at risk of this bug. It is in no way restricted to gnupg.

(2) It is a BUG, not an enhancement request. port is not "most programs", it is a database management system. Any action that changes the database should be encapsulated in a transaction, and it should be rolled back on anything but normal completion of the task.

If this facility can't be added to port, then at least trap all aborts and all error terminations (at least the deactivation of random prerequisities can occur without an abort), and report "DANGER! DANGER! DANGER! MacPorts is possibly corrupt! Be prepared for complete loss of functionality in random programs!"

I don't know enough about port to be able to make concrete suggestions, but surely there's enough information available for port to make more specific warnings, and perhaps do some error recovery, even in the case of the user pushing the panic button.

comment:4 Changed 14 years ago by markd@…

What is meant by the term BUG is defined by our community, not you and not me. I didn't regard severity of consequences or desireability to have anything to do with whether something was considered an RFE or BUG, but I suppose I could be wrong. Since these terms are defined by our community, I'll put the question to them on the list. I'll abide by the consensus if you will, fair enough? Getting a request in the wrong slot just guarantees it will get no attention. I'm trying to help. ;-)

comment:5 Changed 14 years ago by wyuenho (Jimmy Yuen Ho Wong)

The definition of a bug is a philosophical question but I think I can try. The most commonly accepted definition for a software bug, as defined by Wikipedia is

"A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result."

The keyword here is "intention", a bug is a bug only if the result of an action doesn't not reflect the original intention.

In this case, I highly doubt the original Macports developers intented to leave the port system states corrupted by leaving the default signal handler to handler interrupts. If I were a judge, I'd rule this as a serious bug. After so many years since this project first started, it surprises me that port still does not have a transaction mechanism or even in a future development plan. Granted, implementing a simple transaction mechanism in ports involves many changes and feature additions, but that still doesn't change the fact that this is a ligitimate bug. The solution to a bug does not define what a bug is, the intention and output do. I recommend bumping this bug to high priority so a transaction system can be within sight.

comment:6 Changed 14 years ago by markd@…

Summary: BUG: hung upgrade of gnupg leaves port very confusedBUG: port command can't be interrupted cleanly - creates database inconsistency

The community says it's a bug. I changed the summary to something I think gets the point across a little better. If not, let me know.

comment:7 Changed 14 years ago by vinc17@…

Cc: vinc17@… added

It depends how the port command was terminated. Signals INT (sent by Ctrl-C), TERM (sent e.g. at shutdown) and HUP should be regarded as normal termination. Therefore port should either clean up (quickly) before exiting or should provide a clean-up command (as Subversion and some other DB do, for instance). But I know that there's no way to clean up easily after a SIGINT... In any case, it is better to have a simple recovery feature, whatever happens (imagine if you would always lose all your hard disk data after an unexpected power down).

comment:8 Changed 14 years ago by yaseppochi (Stephen J. Turnbull)

I think the new summary is accurate.

Regarding the definition of "bug", I certainly agree that the community should define it. I just didn't think there would be a question about whether failure of database integrity should be considered a bug, when put in those terms.

comment:9 Changed 14 years ago by markd@…

No problem. I do agree it is a bug. At the time I just misunderstood the problem you were describing. And when you described it in more detail I hadn't got completely over my confusion so my mind focused in on certain aspects of possible solutions you mentioned in terms of added features, some of which I think would be features. But now I understand the problem better and I agree that the main issue is a bug. I like to get as clear summary lines as possible and sometimes they evolve over time as other people encounter them. Hopefully it will get swatted soon. Thanks for your attention to this.

comment:10 Changed 14 years ago by pipping@…

Milestone: Port Bugs

comment:11 Changed 14 years ago by pipping@…

Milestone: Port BugsMacPorts 1.4

comment:12 Changed 14 years ago by jmpp@…

Cc: pguyot@… jmpp@… added
Description: modified (diff)
Milestone: MacPorts 1.4Needs developer review
Owner: changed from macports-tickets@… to macports-dev@…
Priority: ExpectedImportant
Status: reopenednew

I have to admit I don't fully understand what was the consequence of cancelling the upgrade in this case. Quoting the original report:

"port info gnupg claims that gnupg is at 1.4.5. The PortIndex file claims that gnupg is at 1.4.5. The Portfile claims that gnupg is at 1.4.5."

So far everything is consistent, info reads from the index and the index takes its information from what's listed in the Portfile. Carrying on:

"port outdated doesn't report gnupg as outdated. gnupg 1.4.4_0 has been deactivated, quietly leaving me without gpg."

If the final result and the cause for the bug report is that gnupg is left deactivated, maybe an argument that it should be reactivated before aborting could be made, but that's by no means a database inconsistency. Stephen, what happens if you try to reactivate the old gnupg manually after cancelling the upgrade?

Other than that, I'm not sure whether or not 'port outdated" looks at deactivated ports to do its magic, but in case it doesn't an argument that it should could easily be made too. But then again, that's another bug and/or feature request.

Setting this ticket to "Needs developer review" until we have more information on what's really at fault here, if anything.

-jmpp

comment:13 Changed 13 years ago by ryandesign (Ryan Schmidt)

Cc: stephen@… added

Adding reporter to Cc.

comment:14 Changed 13 years ago by jmpp@…

Milestone: Needs developer reviewMacPorts base bugs

Milestone Needs developer review deleted

comment:15 Changed 13 years ago by nox@…

Priority: ImportantHigh
Version: 1.2

comment:16 Changed 12 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:17 Changed 11 years ago by blb@…

Cc: blb@… added

Perhaps if port were to trap Ctrl-C and have certain actions based on which phase was active at the time:

  • during anything up to and including destroot, just stop since it can be safely resumed from where it left off
  • during install, remove what it installed in ${prefix}/var/macports/software
  • during activate, ignore the signal until it completes activation, perhaps with a message
  • during deactivate, either ignore or go back to activate
  • during uninstall, since this has probably already begun deleting there's probably no choice but to let it finish

comment:18 Changed 11 years ago by schneider.pj@…

Cc: schneider.pj@… added

Cc Me!

comment:19 in reply to:  18 Changed 10 years ago by guillaumesalagnac

CC me!

comment:20 Changed 10 years ago by nerdling (Jeremy Lavergne)

Cc: snc@… added

Cc Me!

comment:21 Changed 9 years ago by gardnermj@…

Cc: gardnermj@… added

Cc Me!

comment:22 Changed 9 years ago by gardnermj@…

This just bit me (CTRL-C during an uninstall corrupted my ports database somehow, forcing me to reinstall MacPorts from scratch).

How do apt, yum & co. handle this problem?

comment:23 Changed 8 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:30 Changed 6 years ago by frozencemetery (Robbie Harwood)

Cc: rharwood@… added

Cc Me!

comment:31 Changed 6 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed

Should be fixed in current trunk.

comment:32 Changed 4 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 2.4.0
Note: See TracTickets for help on using tickets.