#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Changes (by ryandesign@…): * component: ports => base * port: atlas => Comment: This is not a problem specific to the atlas port; I've seen it before with other ports, and I was not using the `-k` option. I am not yet sure how to reproduce the problem consistently. -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by egall@…): As a temporary workaround until this is fixed, try setting `keeplogs` to `yes` in your `macports.conf`. -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by jdgleeson@…): Since I have a case where this problem is reproducible, I'm trying to think of ways to help debug it. I came across the iosnoop script, which I thought could make it clear what system I/O operations cause the data loss. I've tried many variations on {{{ sudo iosnoop -av -f `port logfile atlas` }}} but I get no trace output. I'd welcome any debugging ideas. NB: It takes 12 hours for this atlas install to run, so it is a rather inconvenient reproducible case. I don't know how much I can perturb it and still see the log file bug. I've tried a trivial "port -f uninstall atlas...; port -k upgrade atlas" without an intermediate clean, but the resulting log file was complete. I'm now looking into making and using my own architectural defaults, which I hope will reduce the build time to about 30 min. Any other ideas would be welcome (for purposes of debugging, I don't care if they give poor atlas libraries). -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by jdgleeson@…): If anyone thinks the complete log file might hold some clues about this problem, it is attached to ticket:38602 https://trac.macports.org/attachment/ticket/38602/main.log.bz2 -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by jdgleeson@…): Replying to [comment:9 jmr@…]:

The log is always overwritten on each run. It's not specific to -k. If you run

I'm confused. If the log is always overwritten, then why do I sometimes get a complete log? For example, the log linked to in comment:7. -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by jmr@…): That's exactly the same situation. Running the same action twice doesn't change the fact that a new log is started for each run. -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by jmr@…): How could the new run produce a complete log if it overwrites the previous log and you didn't clean in between (which is what -k requests)? Already completed phases are skipped, by design. So yes, running the same command twice without cleaning in between will do something different. I'm not saying that the logging behaviour is ideal, just that it is consistent even when -k is used. -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X

#38586: atlas @3.10.1_3: log file contents missing when -k option used --------------------------+-------------------------------- Reporter: jdgleeson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Resolution: | Keywords: Port: | --------------------------+-------------------------------- Comment (by jdgleeson@…): I have started to systematically collect log files and debug output when I do "{{{sudo port -kd upgrade foo}}}" or "{{{sudo port -kd install foo}}}" under different circumstances. So far I have looked carefully at only the case where an outdated port is upgraded after "{{{sudo port selfupdate}}}". I am happy to report that the results are extremely consistent across about 30 upgrades. But they are not what I expected: I expected to see logging of all phases of the upgrades, but I always see only the activation phase. I've attached the log (svmain.log) and debug output (svtermout.txt) from "{{{sudo port -kd upgrade postgresql92 &> svtermout.txt}}}". I expected all of the phases of the upgrade to be present in svmain.log, much like they are in svtermout.txt. But svmain.log has only the activate phase. Should the upgrade log be roughly as complete as the debug output, or not? Keep in mind that the new version postgresql92@9.2.4_0 was not previously fetched, built, installed, upgraded, uninstalled, etc. Furthermore, all of its dependencies are installed and up-to-date (otherwise there would be more variables introduced into the problem that i'd rather not deal with). I noticed that "{{{DEBUG: Starting logging for postgresql92}}}" occurs 3 times in svtermout.txt: [[BR]] LINE 399: at the start of the dependency check phase [[BR]] LINE 6477: at the start another dependency check phase [[BR]] LINE 6514: at the start of the activation phase Is it true that each time we see "{{{Starting logging for foo}}}" in the debug output, any previous logging for foo during that same run of "{{{port upgrade}}}" is lost? In the single instance of upgrading atlas where I have both the debug output and a log file that contains all phases, "{{{Starting logging for atlas}}}" occurs exactly once near the beginning of the debug output. It has an activation phase, too, but so there is some condition under which log file do not get clobbered at the start of the activation phase. This was run under different circumstances (after uninstall -f and clean). -- Ticket URL: <https://trac.macports.org/ticket/38586#comment:16> MacPorts <http://www.macports.org/> Ports system for OS X