I had an emerge process stopped in the background, and tried to do a -C / --depclean run... >>> These are the packages that would be unmerged: net-wireless/opd selected: 0.2-r1 protected: none omitted: none net-wireless/ussp-push selected: 0.11 protected: none omitted: none All selected packages: net-wireless/opd-0.2-r1 net-wireless/ussp-push-0.11 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. Would you like to unmerge these packages? [Yes/No] >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging (1 of 2) net-wireless/opd-0.2-r1... ...and basically emerge hanged here with no signs of life. I believe that if the lockfile doesn't become available in some time, emerge should report verbosely that it is waiting for it.
Do you have FEATURES=parallel-install enabled? In that case, the lock message is probably showing up in the log file instead of stdout/stderr. Options like --quiet, --quiet-build, and --jobs cause such output to be directed to a log file.
Even with --quiet, it shows me this message: * waiting for lock on /var/db/.pkg.portage_lockfile Are you sure that it's waiting on a lockfile? How do you know? Please post output of `lsof | grep portage_lockfile`.
(In reply to comment #1) > Do you have FEATURES=parallel-install enabled? In that case, the lock > message is probably showing up in the log file instead of stdout/stderr. > Options like --quiet, --quiet-build, and --jobs cause such output to be > directed to a log file. No, none of that. (In reply to comment #2) > Even with --quiet, it shows me this message: > > * waiting for lock on /var/db/.pkg.portage_lockfile > > Are you sure that it's waiting on a lockfile? How do you know? Please post > output of `lsof | grep portage_lockfile`. Ah, I think I've seen that in backtrace when used ^c. Also, -C started to work when I resumed that background emerge. But I faintly recall that I think the lockfile name was different that usual. Maybe it was a cache lock or something like that. I'm sorry but I can't reproduce it. I think you have to ^z emerge at some exact point when starting a package build to get that.
The other lock file is /var/lib/portage/config, which is locked by vardbapi._fs_lock(). Regardless of which lockfile it is, the waiting/ebegin message is displayed via the portage.util.writemsg() function, which automatically flushes the stream in order to try to ensure that it is displayed immediately.