[Bug 294182] Re: GNOME's Help Slow to Load
Thanks to Shaun McCance for comment #12. I see what the trouble is. Yelp is setting itself up to display its full glorious range of capabilities before it starts drawing to the screen. Hence the long delay with nothing happening on screen. Make it draw its window, menu bar and the content of the help file as the first thing it does. Defer other processing until after the window and content are there on screen. Do the minimum possible amount of processing before starting to draw. Most users just want to see their help content as soon as possible, then do a bit of scrolling, go to the next page and that is about it. Make the common things fast and on the critical path. Defer processing for the uncommon things. It is quite possible the user may never use some advanced features, such as search. It is wasteful to go to the trouble of setting something up, then throw away all that work when Yelp quits. Do not set advanced features up at all, until the user first asks to use them. On the subject of advanced features to defer or cut, I never use bookmarks, man and info pages or text search. Help Topics is used rarely. I agree that it is a pain that GTK+ 3 is different from GTK+ 2. Further, I agree that GTK+ 3 gets used for new development. However, is it not the case that GTK+ 3 is a superset of GTK+ 2? So it should not be too difficult to use only GTK+ 2 for common actions, with advanced features which use GTK+ 3, simply left out. That would give a cut-down version of Yelp suitable for Lucid and Maverick. Fix this bug, at the cost of some features regressions. That would be a better option for most users than sticking with the present buggy version of Yelp. Yes, a few might be unhappy. Give those people instructions on how to go back to Yelp 2.30.0. I look forward to the next contribution by Shaun McCance. -- GNOME's Help Slow to Load https://bugs.launchpad.net/bugs/294182 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 294182] Re: GNOME's Help Slow to Load
Lucid still seems to have Yelp 2.30.0 (with the bug), as of today. If this bug is fixed in Yelp 2.31.1 then why not push that out as an update? I was showing Ubuntu to someone who had never heard of Linux, the other day. And they wanted to know, What is this Ubuntu thing? So I did System About Ubuntu. Well, how to make a bad first impression in one easy lesson, without even trying. This miserable Yelp thing took around 40 seconds to load, with nothing happening on screen until the last second or so. It is appalling ergonomics. I had to apologize, Gee, I can't understand why this is taking so long -- it is taking even longer to start than Firefox. Sorry about that. This long delay in Yelp starting is just not acceptable. Restarts are OK at around 2 seconds, but that first start is bad bad. Frankly, Yelp should be a tiny fraction of the size of Firefox and it should be reading relatively tiny data files. I expect under 1 second starts every time. I want (1) Yelp really fixed, (2) this bug raised in importance. Other people are reporting having to wait over a minute. When you are looking for help, you are not sure what you are doing. To have the help system itself malfunctioning, that gives a very bad impression. -- GNOME's Help Slow to Load https://bugs.launchpad.net/bugs/294182 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 554172] Re: system services using console output not starting at boot
The revised version of Upstart fixed it for me. Thanks to Scott James Remnant and Andy Whitcroft. I have done many cold boots and restarts since the fix, and the bug is gone. To avoid problems with Plymouth, get rid of quiet splash in the Grub kernel command line. Alas, Grub and Grub 2 are different. The following instructions apply to Grub. Start a root terminal. Enter: grub-install -v You should get the response 0.97. That is the Grub version number. If it reads 1.96 or higher, you have Grub 2, check the documentation at: https://help.ubuntu.com/community/Grub2 Assuming you have Grub, edit /boot/grub/menu.lst , find the line like: # kopt=root=UUID=87c74523-fd13-4bca-97e4-5aba28218222 ro quiet splash Notice that the 32 hex digits on your UUID will be different to mine. Keep your own. Delete quiet splash. Look down further in the file and you will find a line like: kernel /boot/vmlinuz-2.6.32-24-generic root=UUID=87c74523-fd13-4bca- 97e4-5aba28218222 ro quiet splash Delete the quiet splash. Save the file. Restart the computer. Now you should have a Linux boot that looks like a Linux boot, with real console messages and none of that wimpy graphical splash screen rubbish. However, then your graphical interface (X Windows) will start normally. Feel proud. -- system services using console output not starting at boot https://bugs.launchpad.net/bugs/554172 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 554172] Re: system services not starting at boot
Many thanks to Andy Whitcroft for his truly excellent analysis above in comment #245. REPRODUCING THE BUG: It looks to me as though what is required to reproduce this bug is a fast multi-core machine with a slow video card. It just so happens that is exactly what my machine is like. When I build a machine, I always buy a high-end gamer-style motherboard and put a close-to-top-of-the-line CPU in it. My experience has been that motherboards are a reliability problem area, so I spend up on the motherboard. I tend to prefer motherboards and CPUs that have been out for a little while, so the bugs have been worked out of them. However, I do not like the noise and power consumption of high-end video cards, so I buy quiet (preferably silent) video cards. Such cards are inevitably slow. Many server machines also have fast CPUs and slow video. Most servers spend almost all of their lives with their video never being looked at by a human being, so fast video performance is unimportant in that market. So server computer manufacturers put in cheap slow video systems. Meanwhile, the CPU performance is critical, so server manufacturers put in big fast multi-core CPUs. This explains the prominent presence of the server guys in the comments on this bug. They have the kind of machines that show the bug. FLOW CONTROL PROBLEM: One problem not mentioned by Andy is the possibility of flow control happening. For example, suppose the console was something really slow such as an actual teletype, joined to the computer via modems. The word teletype is where tty came from. Of course, few of you young people know what a real teletype looks, sounds or smells like, but there are some of us who remember that they only went at 10 characters per second. Now suppose that the telephone line connecting the modems has got signal quality problems, maybe it has noise or crosstalk. So there are hangups and redialling going on as the modems struggle with the telephone line. Then do a few restarts and generate a lot of console traffic. The poor old console could end up hours behind. Linux should cope with all that and keep right on working properly. If there is spooling for the console, there will be short hesitations in the flow of data as the data is written to disk. Then there has to be a flow-control-asserted signal back to whatever is writing the data, to say, Hey, wait up, my buffer is nearly full. Then the writer has to wait until flow control is deasserted and writing may resume. Flow control should always be present between any two asynchronous processes transferring data. If there is no spooling for the console, the short hesitations can become quite long waits, as the console labours to catch up. I do not know whether there is a spooling option for console traffic. Perhaps someone more knowledgeable might comment. However, the problem will always be there, of the writer to the console possibly getting to be faster than the console device can take the data. CPUs keep on getting faster. Spooling disks or video cards cannot necessarily keep up. So there will always be the necessity for flow control. Linux in general, and upstart in particular, must cope satisfactorily with this problem. Otherwise, we are just headed for yet more nasty bugs like this one. CONCLUSION: The fact is, the console is not always available for writing. So any software writing to the console has to cope with that. That insight sounds like progress to me. I still think the problem is within upstart. I look forward to the next contribution from Scott James Remnant. -- system services not starting at boot https://bugs.launchpad.net/bugs/554172 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 554172] Re: CUPS and other system services not starting at boot
Alas, I too am being regularly bitten by this bug. I have a fully up to date version of Lucid, V10.04. Computer: mobo Asus M2N-SLI DELUXE, nVidia chipset, CPU dual core Athlon 64, main memory 1GiB, video chipset nVidia 7600GS, monitor 19-inch Hitach CM766ET CRT. Computer was built by me in 2006, it would be considered very humble and ordinary these days. INCIDENCE: I cold boot every day, and the bug usually happens. If I restart, the bug usually does not happen, however, restarts are usually useless to clear the bug, once it does happen. It has only happened since around late July 2010. Previously, Ubuntu would boot satisfactorily. DETECTION: After every cold boot or restart, I do System Administration Printing. If there is no printer shown in the Printing - localhost window, then CUPS did not start and I cannot print. Then I do the workaround (see below), that fixes it. If the printer is there in the window, the bug is not present and I continue as normal. WORKAROUND: Do Applications Accessories Terminal, Gnome Terminal starts. Enter command: sudo telinit 2 Put in the user password, command returns, then quit Terminal. Recheck System Administration Printing to verify that CUPS is now running. Continue as normal. RUNLEVEL: I have spent many hours doing CLI commands to try to investigate this bug. At all times when the bug is present, doing the runlevel command gives the result unknown. When the bug is not present, runlevel reports N 2. This suggests that the Upstart job /etc/init/rc.rc-sysinit.conf is not running. In an attempt to make it run more reliably, I changed the line in rc-sysinit.conf reading: start on filesystem and net-device-up IFACE=lo to: start on filesystem I had a theory that the parsing for events in Upstart was not working properly, so simplifying the event might help. Nope. That did not fix the bug. SCRIPT rc.local NOT RUNNING: When the bug happens, /etc/rc.local does not run. I verified that by putting into rc.local, just after the initial comments, the following two lines: # Put a status line in /var/log/syslog logger Running /etc/rc.local Then, whenever /etc/rc.local is run, there gets to be a line in /var/log/syslog which includes the text: localhost logger: Running /etc/rc.local Such lines can easily be found by doing gedit /var/log/syslog (or gedit /var/log/syslog.1, if syslog is too recent), then search for logger. When the bug happens, there is no line such line in /var/log/syslog, for the buggy start. IMPORTANCE: I am not happy that the importance of this bug has been downgraded to High from Critical. This is a very serious bug for users who do not know a workaround (as given above). It is the sort of thing that gets people giving up on Linux and going back to Windows. Please put it back up to Critical. SUSPICIONS: I have a low level of suspicion about the kernel and Plymouth. I have a high level of suspicion about Upstart. I think Scott James Remnant should take more interest this bug, even though he is pointing the finger at the kernel in comment #136. COMMENT FOR SCOTT: How about making all Upstart job files have the extension .upjob ? -- CUPS and other system services not starting at boot https://bugs.launchpad.net/bugs/554172 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 554172] Re: CUPS and other system services not starting at boot
Oops, hasty proofreading. In comment #208 of mine, the sentence: This suggests that the Upstart job /etc/init/rc.rc-sysinit.conf is not running. should read: This suggests that the Upstart job /etc/init/rc-sysinit.conf is not running. Wrong filename. Sorry about that folks. -- CUPS and other system services not starting at boot https://bugs.launchpad.net/bugs/554172 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
