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
