>>> cfg-update-1.8.2-r1: Creating checksum index... This can ultimately run forever. Most of the time, it takes longer to run cfg-update, than it does to compile the package. I don't know how many packages I have installed. But it seems like cfg-update is repeating the same procedure for each and every package. So I'm thinking there must not be a database that cfg-update creates, which only then needs to be checked, not rebuilt by each new package. For an analogy, this thing has packages sitting on the tarmac longer than most flights at some international airport in bad weather. Would someone please de-ice this procedure! And I'm not exaggerating about taking an hour for a package waiting to be compiled. I'm right now in the midst of processing all of the packages in dev-lisp. And these are TINY packages. But yet these things are taking up to an hour to start. This is getting to be excruciating. Shingoshi Reproducible: Always Steps to Reproduce: 1. emerge any package 2. sit and wait for: 3. >>> cfg-update-1.8.2-r1: Creating checksum index... 4. Forget the coffee, go take a nap!! Actual Results: The passengers are getting boisterous!! I'm laughing. But it's really not funny. Expected Results: Quicker take-offs Is there a command for Gentoo to tell the user how many packages in total are installed on their system? If not, there needs to be one.
Created attachment 151482 [details] shingoshi_emergeinfo-2008.04.29_06:24:51.gz My last emerge --info. Does this give any indication why this is taking soooooo long? Shingoshi
What cfg-update should be running at that time is for dir in /etc /opt/openjms/config /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config /usr/spool/PBS /var/bind /var/service do echo /var/db/pkg/*/*/CONTENTS | xargs grep "^obj $dir" | cut -d" " -f2-3 done What happens if you run that manually? Does it also take too long?
(In reply to comment #2) > What cfg-update should be running at that time is > > for dir in /etc /opt/openjms/config /usr/kde/4.0/env /usr/kde/4.0/share/config > /usr/kde/4.0/shutdown /usr/share/config /usr/spool/PBS /var/bind /var/service > do > echo /var/db/pkg/*/*/CONTENTS | xargs grep "^obj $dir" | cut -d" " -f2-3 > done > > What happens if you run that manually? Does it also take too long? > I finally got around to running this this morning. I did it by typing as follows: test, space, shift-insert. This started the process and ran for what seemed to be at least a half hour. I then feel asleep. Upon waking up, I was curious how come my screen saver hadn't come on. It was only when I looked at my keyboard clock, that I realized that my system had froze. Like I said, it seemed to have been running for a half an hour. I think I may try it again. But I better post this now, just in case this was the cause of my system crashing, and this gets lost in the process. I don't need to rerun this to know the following though. When the command stopped, it was still in the /usr/share directory, and likely had a long way to go before finishing. You need to consider a different approach to storing the data created by cfg-update. I would suggest storing it in a place like ccache. The current conceptual approach, reminds me of this analogy. Can you imagine a major national bank having to reload it's entire customer database every time any customer made a deposit. I hope that explains my point. No business could survive, having to function the way cfg-update is now setup, if that meant rebuilding their databases for every transaction. It simply wouldn't work. And since I'm building a new Linux distribution dedicated for clustered research and development environments (meaning large businesses), they would quickly balk at the idea of this tying up their system any time they needed to install packages. So I really hope you can do something to make this more efficient. Otherwise, I'll have to stop using it entirely. Shingoshi
(In reply to comment #3) > I finally got around to running this this morning. I did it by typing as > follows: test, space, shift-insert. > This started the process and ran for what seemed to be at least a half hour. I > then feel asleep. Upon waking up, I was curious how come my screen saver hadn't > come on. It was only when I looked at my keyboard clock, that I realized that > my system had froze. Like I said, it seemed to have been running for a half an > hour. I think I may try it again. But I better post this now, just in case this > was the cause of my system crashing, and this gets lost in the process. If you get a crash or buggy behaviour again, I think it would be a good idea to run fsck, as this could easily be caused by a corrupted filesystem. (And if it is, there's not a lot I can do about it.) > I don't need to rerun this to know the following though. When the command > stopped, it was still in the /usr/share directory, and likely had a long way to > go before finishing. [...] Oh, it's not looking in /usr/share, it's looking _for_ /usr/share. It's just checking which files portage wrote into /usr/share, by checking what portage recorded in /var/db/pkg. This is the same location portage loads when checking if 'emerge foo' is a new installation or an upgrade, and if it's an upgrade, which files from the old version to remove.
I'm using xfs as my filesystem on all partitions except my /. It runs a system check at every start, and has run flawlessly for me for years. While it's possible that one got corrupt, I think it more like related to my memory issues. Although my machine has 2Gb installed, only 1 is actually being recognized. I'm waiting until next week to install a new board. I just hope this thing is still running until I get it fixed. My Gentoo system is on a separate partition, and is only run in chroot (for development). And I think the problem occurred from the main system too. I may be wrong. But I do know that whenever I tried to run emerge, the system crashed. It's not really something I wish to bug check, for fear that I will only make things worse and end up with a completely unusable system. So in the meantime, I'm limiting my activities to things which don't stress the system at all. Although, when I'm ready to install my new motherboard, I may go ahead and try this again. That way we'll have a reference from which to compare the new installation. But the process seemed to be running without trouble. It was just taking a very long time. I should have mentioned that I'm building a complete redistributable OS with Gentoo. So I have a very large system. It's @29Gbs without any (personal) files other than those installed by the system. Even my /usr/portage is mounted outside of the main Gentoo dist. The same thing is true for my ccache as well. I though about running this and creating a file to determine the size of it. Do you have any idea what I might see in terms of size, giving an indication of how much work is actually being done? I just ran du to determine the total size of my /usr/portage, including the separate partition. The result is 18Gbs. So that may give you an idea of how much stuff I have installed. I the following stats: 7,717,216K @ 5364 files in portage/packages/All 10,266,168K @ 7537 files in portage/distfiles /var/cache/db is 654Mbs I'm going to try this once more. This time though, I'm going to create a file from the output. But I'm going to send this first, just in case the system crashes again. If it does, at least you will have this info. So there will hopefully be another post made here without another crash. Shingoshi
Now this is weird. Not only did it complete without trouble, it did so very fast. But then again, it wasn't having to write out to the terminal either. Here's the time that it took. real 3m0.899s user 1m11.488s sys 0m2.192s So I'm going to try this again, writing it out to the terminal now. Shingoshi
Created attachment 151676 [details] cfg-update file The file created from your script.
I really can't believe this! real 1m51.606s user 1m11.232s sys 0m2.144s How much effect should my system load have upon this? Because right now, there's hardly anything running. I'm going to check again, just to be certain. Shingoshi
This ran even faster! time for dir in /etc /opt/openjms/config /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config /usr/spool/PBS /var/bind /var/service do echo /var/db/pkg/*/*/CONTENTS | xargs grep "^obj $dir" | cut -d" " -f2-3 done > /pub/gentoo/portage/cfgpupdatefile2 real 1m22.947s user 1m11.872s sys 0m1.752s Ok. I give up. This must really be the result of a marginally running system. I'm sorry for all of this trouble. I apologize. But then, if I hadn't contacted you, I would have never found out just how bad things are. I'm going to close this bug then. I think it's fair to say, it's INVALID. Shingoshi
No problem, I'm glad it's working for you now. If you happen to run into problems again, please don't hesitate to reopen this bug.
(In reply to comment #10) > No problem, I'm glad it's working for you now. If you happen to run into > problems again, please don't hesitate to reopen this bug. > Thank you for your patience. I still have no idea about this. I mean I think it was cause by my system load. Because there were times it seemed to run right, and others felt like swimming in a tar pit. Oh, and the crashing thing is definitely related to portage, specifically, emerge. Last night I tried doing an emerge --sync, but the system froze again and gave this message: emergelog(): [Error 5] Input/output error: "/var/log/emerge.log' What's obvious, is that immediately after it starts, it hangs. But I have no idea why it would hang the system. I don't know if this could be a disk error, or simply a corrupted database. Don't know. Anyway, that's my issue. This one seems to be resolved, simply by having been INVALID. I do want to know something from you though. I use a program called portato. You may very well know what it is, A Portage Manager. Anyway, the author (Necoro) uses etc-proposals to handle changes made to files in etc. It works well enough, except that it doesn't work like yours. Unless I have it set up improperly, it runs even for trivial changes that cfg-update would have made without intervention. Now some may feel more secure about having direct control over that. But when you're building anywhere from 30-100 packages at a time, it quickly becomes burdensome. So what I want to know is this. I'm modifying portato for heavy usage (like what I put it through), and I would like to know if you'd be willing to help me integrate your package into mine or not? If so, you can find my forum (basically now just between Necoro and I) for it here. http://portato.origo.ethz.ch/node/67 And the original portato forum is here, where I participate heavily. http://forums.gentoo.org/viewtopic-t-502350-postdays-0-postorder-asc-start-375.html?sid=825b49673bc4c67eda8d8e82a0d87ccf Most of my changes to portato may seem to be only cosmetic. But the foundation of those cosmetic changes, is ergonomics. As I sit in front of portato virtually all of the time I'm working, I have (a very tired) firsthand knowledge of it's inefficiencies. So I completely redesigned it to make the interface extremely functionally compact and process linear. All of the operating controls now reside in a horizontal strip across the center of the screen, less than an inch wide. The result is very limited mouse movement to achieve more work and less effort. Every action is more closely followed in location by it's next step. It is in that logic, that I want to use cfg-update to pre-process any trivial changes made to configuration files. Please, if you're willing, take a look and let me know if it would interest you. BTW. I very glad there never was an issue with cfg-update. Because it really is quite good at what you intended it to. Thanks so much! Shingoshi
Created attachment 151719 [details] The working edit in progress file for portato. Here you'll see what I've done with portato. It looks nothing like the original now. And you'll see that narrow working strip that I've referred to. My basic concept, is that the dashboard belongs below the windshield, not the reverse. And the driver shouldn't have to be stretching over to the passenger's side to control the vehicle. So I've tried my best to make portato work like an aircraft cockpit. If the picture intrigues you, you can write me directly and I'll tell you how to use it. Shingoshi
Created attachment 151721 [details] Posted the wrong file. Here's the image that's created by the glade file I erroneously posted first. Shingoshi
(In reply to comment #11) > So what I want to know is this. I'm modifying portato for heavy usage (like > what I put it through), and I would like to know if you'd be willing to help me > integrate your package into mine or not? I'm not the author of cfg-update, I just deal with the ebuild and try to help out with bugs :) cfg-update is written by Stephan van Boven; you can find him on the Gentoo forums as xentric. You should ask him directly and see if he's interested.
(In reply to comment #14) > (In reply to comment #11) > > So what I want to know is this. I'm modifying portato for heavy usage (like > > what I put it through), and I would like to know if you'd be willing to help me > > integrate your package into mine or not? > > I'm not the author of cfg-update, I just deal with the ebuild and try to help > out with bugs :) cfg-update is written by Stephan van Boven; you can find him > on the Gentoo forums as xentric. You should ask him directly and see if he's > interested. > Ok. I'll contact Stephan. Thanks for the advice.
Unfortunately, I'm having to reopen this bug. The reason for this is as follows: 1. I'm experiencing the same behavior as before. (Apparently, the tests I ran don't work in the real world.) real 1m22.947s user 1m11.872s sys 0m1.752s 2. When I take into consideration, the shortest time recorded by the tests I ran, it becomes obvious that any time I have to rebuild my system, either with emerge --system or emerge --world, I'm going to have to multiply the shortest time I recorded here (and isn't representative of actual results), by the total number of packages I'm having to emerge. I'm guessing right now, my package count is somewhere around 3500. And by time I get ready to release this stage4/5 tarball(s), that number will be even greater. 3. 3500 minutes amounts to 60 hours, or 2.5 days, computed from the smallest amount of time that cfg-update has taken to run. That will quickly become unmanageable for everyone who will subsequently need to perform global emerges of this system. And this is especially concerning, when I still find that in many cases, it takes longer to complete cfg-update, than it does to compile the package it's running for. So I really need to know if my settings for cfg-update are improperly set, or if this is simply the expected behavior I can do nothing about? Shingoshi
I've been running emerge for the past three hours to install 28 packages. 14 of these are perl modules. And we know how small they are. I am now only up #12, and it's still held up on cfg-update. So this bug is definitely still open and unresolved. This is simply ridiculous, Shingoshi
Sorry for the delay. Possibly, when rebuilding such a large number of packages, it will be better to temporarily disable cfg-update (even if cfg-update were faster in its search), and re-enable it afterwards. Stephan, can you say anything about this?
The problem is, what do you consider a large set of packages? Because I'm right now running a queue that had 73 packages in it, and it's only up to merging #46. I started this queue over 5 hours ago. Now I do realize some of this may be due my system resources being somewhat limited at this time. But I don't know how much of a difference this will make, having 2 or more processors and more than 4 Gbs of memory. And, I'm running ccache on RAID0. There might be some improvement, but I don't see how much there will be. Basically, I would simply have to remove cfg-update altogether. Shingoshi
What if any other packages depend on cfg-update, that if removed, would compromise the functionality of my system. Because I am at this point convinced of the need to remove it, due to the heavy load it imposes during emerge, and the very little benefit I seem to be deriving from it. This is not a package I would recommend to anyone attempting to build an entire OS, and would in fact strongly discourage it's use. I will likely remove it during the compilation of one of the packages remaining in this current queue. As since I wrote here some time ago, I have only advanced to package #53 from #47 at that time. So, to anyone having more than 1500 packages on their system, remove this one, and you'll see a substantial increase in the performance (as a reduction of time) of emerging packages. Shingoshi
Free at last Free at last Thank God Almighty I'm free at last Removing this package was simply the best thing I could have done for my system. I will never reinstall it again unless it's guaranteed that it's 60 times faster than it is now. And even then, I don't see what benefit I would get from doing so. Since I use portato (which uses etc-proposals), and I use conf-update to first check for changes that can be automatically made, I really have no need of this. Good luck on whatever you choose to do with it. However, I'm leaving this open, because it most definitely has not been resolved. Shingoshi
>(In reply to comment #18) Hi, sorry for dropping in so late! I won't argue that rewriting the checksum-index-file is slow, but I haven't had a single complaint from users about that in the last 5 years! The problem lies in the Portage hook that cfg-update now uses... Hook method 1. The old-style method with an alias for emerge in /etc/profile, this has the effect that cfg-update indexing is done once right before the emerge session starts. However, due to Gentoo's default setup you need to edit /root/bashrc in order to get the shell to source /etc/profile when the root user logs in. Ebuilds are not supposed to modify /root files so installation included manual steps in order to get cfg-update properly set up. When looking for a way to get rid of the manual installation steps I stumbled on method number 2. Hook method 2. The new-style method that uses the $EBUILD_PHASE variable in Portage as a hook. This can be set up by the ebuild script during installation of the cfg-update package. Unfortunately there's no way to run cfg-update indexing only once. Paludis has a superior hook mechanism so if you use Paludis then indexing is only done once at the beginning of an install session. Shingoshi, you should use the old style Portage hook so cfg-update only runs once right before the emerge command is executed. For this to work you need to change some things: 1. Run: "cfg-update --disable-portage-hook" This temporarily disables the hook. To keep it disabled you need to run cfg-update with the --ebuild option otherwise it automatically re-enables the hook! 2. So add an alias for cfg-update to /etc/profile, this keeps the hook disabled for you: --SNIP-- alias cfg-update = 'cfg-update --ebuild' --SNIP-- 3. Create and/or add the following lines to the bottom of /root/.bashrc: -- SNIP -- ## Quick fix to set up environment when su'ed to root: [ -f /etc/profile ] && source /etc/profile --SNIP-- 4. Create and/or add the following lines to /root/.bash_profile: --SNIP-- ## This file is sourced by bash when you log in interactively. [ -f ~/.bashrc ] && . ~/.bashrc --SNIP-- 5. Add an alias for emerge to /etc/profile: --SNIP-- alias emerge = 'emerge_with_indexing_for_cfg-update' --SNIP-- 6. Create file /usr/bin/emerge_with_indexing_for_cfg-update and add: --SNIP-- #!/bin/bash if [ -e "/usr/bin/cfg-update" ]; then cfg-update --ebuild --index else echo "*** cfg-update not found, disable the alias for emerge in /root/.bashrc !" fi emerge $* # run emerge whatever the case may be... --SNIP-- 7. Run: "chmod +x /usr/bin/emerge_with_indexing_for_cfg-update" 8. Run: "source /etc/profile" 9. Test installing something with emerge to check if the old-style hooks works. Hope this helps you...
WONTFIX per bug 303199
