with /bin/sh = dash, computer freezes completely; runs fine when sh = bash.

[Rolf Leggewie]

Binary package hint: dash

I think dash is not ready to be the default shell.

The worst I experienced was frequent and impossible to troubleshoot freezes of one of my servers (https://answers.launchpad.net/ubuntu/+source/linux-source-2.6.17/+question/4377/+index). I also had problems with openembedded.org which produced strange compilation results. It was via the help of the openembedded people that I only found out about sucky dash and that whenever there is a problem on ubuntu the first thing to do is make sure that /bin/sh does not point to dash (http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-April/001862.html). Take a look at bug 71887 for more reasons why dash as default is a bad choice at this point in time.

This bug report is about the freezes that dash introduced on my server. I can not say what exactly triggered the freezes. But they are gone after /bin/sh points to bash. The machine could not sustain uptimes of 15 minutes or more previously. I can change it back anytime to test if somebody has an idea of what to look for in trying to pinpoint the cause of this and improve dash. Sorry about the information being rather incomplete at this point in time.

up-to-date edgy
Via C3 600 MHz
Kernel 2.6.15-23-386, but 2.6.15-28-386 is the same (unlike the reports in bug 71212 which first led me to believe this is an NFS issue)
possibly some left-over 3rd party packages (unlikely), but currently official ubuntu repos only in sources.list

[Rolf Leggewie (r0lf)]

Another report of mysteriously failing compilations: http://bugs.openembedded.org/show_bug.cgi?id=2035

[Micah Cowan (micahcowan)]

Thank you for your bug report. Please post about separate bugs in separate bug reports. Additionally, note that the bug in http://bugs.openembedded.org/show_bug.cgi?id=2035 is not with dash, but rather with Perl, as other commentors have pointed out.

I understand that you're frustrated by your experiences, but the bug tracking tool is not the appropriate forum to complain about development decisions; that's what the mailing lists, etc, are for.

I'm going to need significantly more information from you regarding this bug in order to address the problem. "Freezing" your server is a little vague; could you explain in more detail what the symptoms are? Does the entire server just lock up and become available? Can you connect via some ports and not others? Are you able to login via direct console access?

Thank you for your help.

[Rolf Leggewie (r0lf)]

Hi Micah,

thanks for picking this up.

I have since learned that apparently dash is not at fault but the programs using /bin/sh that really expect /bin/bash. I think the conclusion remains the same that it is not a good idea to shove dash down people's throat when it leads to massive instabilities. This is the only issue I rais in this bug and therefore I don't quite understand your introductory remark of "one issue - one bug"

You asked for more information. The server completely freezes as there is absolutely no way to reach it. It will not react to ping, the keyboard and the screen will receive no updates. This makes it hard to find out anything about what is causing this.

[Micah Cowan (micahcowan)]

Hi Rolf,

What I meant regarding "one issue - one bug" is that your comment regarding "mysteriously failing compilations" is a completely separate issue from the one you reported in this bug, and so doesn't really belong. That particular issue is definitely not dash's fault, but rather is the fault of the compilation tools depending on bashisms in #!/bin/sh (as you said). It is less clear that your freeze is due to "bashism dependency", since we still don't know much about what is causing the freezes. It does very much sound like there is an unterminated loop going on, and it could very well be the result of some sh-is-bash assumptions, but we need to know more.

In order to proceed with this bug, I need to see the entries in /var/log/dmesg, /var/log/boot, /var/log/messages, and /var/log/syslog from during the attempted boot. It would be helpful if you'd clarify what time you booted the computer, and what time it was rebooted or powered down (due to the freeze). Also, it could help to remove the "splash" kernel option to grub when you load up (you can remove this at boot time, or from your /boot/grub/menu.lst), so you can see the messages going until they stop.

[Rolf Leggewie (r0lf)]

The boot completed fine. The computer is also running fine right now. It was only when running some NFS tasks, after eventually after some unknown amount of time or by doing an openembedded compilation.

The thing is that the files you request are of course gone after the reboot that is necessary to get back to the machine.

[Rolf Leggewie (r0lf)]

> The thing is that the files you request are of course gone after the reboot that is necessary to get back to the machine.

that is of course nonsense ;-)

I thought I had mounted the relevant part as tmpfs which is not the case. I can give it a shot.

[Micah Cowan (micahcowan)]

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.