Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#50528 closed defect (fixed)

logwatch: does not properly delete old unregistered /opt/local/bin/logwatch symlink

Reported by: dbevans (David B. Evans) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: kurthindenburg (Kurt Hindenburg)
Port: logwatch

Description

Fails during activation as follows:

Error: org.macports.activate for port logwatch returned: Image error: /opt/local/bin/logwatch already exists and does not belong to a registered port.  Unable to activate port logwatch. Use 'port -f activate logwatch' to force the activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error: /opt/local/bin/logwatch already exists and does not belong to a registered port.  Unable to activate port logwatch. Use 'port -f activate logwatch' to force the activation.

I'm guessing this is a copy installed as part of the buildbot infrastructure? If so perhaps this should be installed in a different location such as /usr/local.

Change History (3)

comment:1 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: khindenburg@… added
Component: server/hostingports
Resolution: fixed
Status: newclosed
Summary: logwatch: build fails on all buildbots during activationlogwatch: does not properly delete old unregistered /opt/local/bin/logwatch symlink

No parts of the buildbot slave infrastructure are installed in /opt/local. /opt/local is under the control of the buildbot, for building MacPorts packages.

The problem affects user systems as well, not just the buildbot machines.

This is a bug in the logwatch portfile. It used to directly install the /opt/local/bin/logwatch symlink, bypassing the destroot. This was fixed in r127811 and r127812 to correctly install the symlink as part of the destroot, but for existing installations the old unregistered symlink remained, preventing upgrades from activating correctly, as you've seen.

Attempts were made to fix this in r127815 and r127816 but the attempts were incorrect. The most recent attempted fix doesn't work as intended because it uses file exists to check for the file's existence, but file exists resolves symlinks, so it is actually checking if the file the symlink points to exists, which it doesn't, so it doesn't get deleted. The existence of the symlink itself needs to be tested.

I fixed this for logwatch in r145392 the same way I had fixed it for nedi in r143403.

comment:2 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

I wrote up this solution in PortfileRecipes#symlink-exists.

comment:3 Changed 8 years ago by dbevans (David B. Evans)

Good idea. Thanks.

Note: See TracTickets for help on using tickets.