| Summary: | Konsole freezes on startup when unable to allocate PTY | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | Adam <adam.richard2023> |
| Component: | general | Assignee: | Konsole Developer <konsole-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | lckw |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Listing of pty devices | ||
|
Description
Adam
2004-08-19 02:53:56 UTC
Konsole needs to allocate a pty device to communicate with the command shell, from the symptoms you describe it seems like that fails. Most probably related to udev indeed. Created attachment 7180 [details]
Listing of pty devices
When using udev in Gentoo, it creates tons of devices in /dev, and there are 256 pty devices, which makes me wonder how it couldn't allocate one - or maybe the fact that there are so many is part of the problem. I've attached the list of pty devices that Gentoo creates in case it's useful. I disabled that functionality of Gentoo, and now there are no pty devices in /dev - and I haven't been able to reproduce the problem since. I wonder - if the problem is really that it can't allocate a pty device, shouldn't it print an error message and exit rather than freeze? Strange, I've been running Gentoo with udev for several months w/o any problems with konsole. Note that I run KDE CVS, not the ebuilds. I also don't know where you got that list of ptys... I wonder if we have different kernel versions/configs??? % ls /dev/ adsp@ hda7 loop0@ ram10@ sndstat@ tty20@ tty38@ tty55@ vcs2@ agpgart@ hdb loop1@ ram11@ sound/ tty21@ tty39@ tty56@ vcs3@ audio@ hdb1 loop2@ ram12@ stderr@ tty22@ tty4@ tty57@ vcs4@ cdroms/ hdb2 loop3@ ram13@ stdin@ tty23@ tty40@ tty58@ vcs5@ console hdc loop4@ ram14@ stdout@ tty24@ tty41@ tty59@ vcs6@ core@ hdd loop5@ ram15@ tty tty25@ tty42@ tty6@ vcs7@ discs/ i2c/ loop6@ ram2@ tty0@ tty26@ tty43@ tty60@ vcsa@ dsp@ i2c-0@ loop7@ ram3@ tty1@ tty27@ tty44@ tty61@ vcsa1@ fd@ i2c-1@ lp0 ram4@ tty10@ tty28@ tty45@ tty62@ vcsa2@ fd0@ i2c-2@ mem ram5@ tty11@ tty29@ tty46@ tty63@ vcsa3@ floppy/ i2c-3@ misc/ ram6@ tty12@ tty3@ tty47@ tty7@ vcsa4@ full i2c-4@ mixer@ ram7@ tty13@ tty30@ tty48@ tty8@ vcsa5@ hda ide/ null ram8@ tty14@ tty31@ tty49@ tty9@ vcsa6@ hda1 initctl| port ram9@ tty15@ tty32@ tty5@ urandom vcsa7@ hda2 input/ psaux@ random tty16@ tty33@ tty50@ v4l/ zero hda3 kmem ptmx rd/ tty17@ tty34@ tty51@ vc/ hda4 kmsg pts/ rtc@ tty18@ tty35@ tty52@ vcc/ hda5 log= ram0@ shm/ tty19@ tty36@ tty53@ vcs@ hda6 loop/ ram1@ snd/ tty2@ tty37@ tty54@ vcs1@ %ls /dev/pts 0 1 2 3 4 A possible idea is to start konsole from another terminal (xterm) and see what the output from konsole is. Kurt - it looks like you're using udev in Gentoo without using the default of creating the extra nodes. You must have RC_DEVICE_TARBALL in /etc/conf.d/rc set to "no", whereas I had it set to "yes" until recently.
> A possible idea is to start konsole from another terminal (xterm) and see what the output from konsole is.
That's a good idea - unfortunately, as I said, the bug only happens sometimes, so I'd have to keep trying to get it to happen.
Adam: Yes, I agree, it should not freeze. Can you attach gdb from another konsole or xterm when it freezes and post the backtrace? What does "ps aux" have to say about the process when it freezes? Yea, RC_DEVICE_TARBALL="no" Do you still have the problem when this is set to NO? > Yea, RC_DEVICE_TARBALL="no" > Do you still have the problem when this is set to NO? No, as I said previously - at least I haven't been able to reproduce it. > Can you attach gdb from another konsole or xterm when it freezes and post the backtrace? What does "ps aux" have to say about the process when it freezes? I suppose I could try these; I'll have to reboot before I can make the bug happen again. Sorry, even though I set RC_DEVICE_TARBALL back to "yes" and restarted my computer, the tons of devices didn't re-appear. It seems like there's no going back once you set it to "no", since that setting saves and restores the devices in /dev. I don't know of an easy way to get them back, so I can't make the bug happen anymore. Anyway, to debug it with gdb would require that debugging information be in the konsole executable, wouldn't it? I doubt it's there by default. Do you still have problems? No, as I said I am unable to reproduce it - but it might still be there for people who chose RC_DEVICE_TARBALL as "yes" from the beginning. I agree that Konsole should just quit with an error. CVS commit by hindenburg:
Exit somewhat gracefully when unable to allocate a PTY.
BUG: 87481
M +1 -1 TEPty.cpp 1.89
M +11 -2 session.cpp 1.102
--- kdebase/konsole/konsole/TEPty.cpp #1.88:1.89
@@ -123,5 +123,5 @@ int TEPty::run(const char* _pgm, QStrLis
setUsePty(All, _addutmp);
- if (!start(NotifyOnExit, (Communication) (Stdin | Stdout)))
+ if ( start(NotifyOnExit, (Communication) (Stdin | Stdout)) == false )
return -1;
--- kdebase/konsole/konsole/session.cpp #1.101:1.102
@@ -97,4 +97,7 @@ TESession::TESession(TEWidget* _te, cons
void TESession::ptyError()
{
+ if ( sh->error().isEmpty() )
+ KMessageBox::error(te->topLevelWidget(), i18n("Unable to allocate a pseudo teletype!"));
+ else
KMessageBox::error(te->topLevelWidget(), sh->error());
emit done(this);
@@ -131,7 +134,13 @@ void TESession::run()
QDir::setCurrent(initial_cwd);
sh->setXonXoff(xon_xoff);
- sh->run(QFile::encodeName(pgm), args, term.latin1(), winId, add_to_utmp,
+
+ int result = sh->run(QFile::encodeName(pgm), args, term.latin1(),
+ winId, add_to_utmp,
("DCOPRef("+appId+",konsole)").latin1(),
("DCOPRef("+appId+","+sessionId+")").latin1());
+ if (result < 0) { // Error in creating pseudo teletype
+ kdWarning()<<"Unable to allocate a pseudo teletype!"<<endl;
+ QTimer::singleShot(0, this, SLOT(ptyError()));
+ }
if (!initial_cwd.isEmpty())
QDir::setCurrent(cwd_save);
Great! That certainly looks like an improvement. However, a suggestion - you may want to try to make that error message more understandable. Many people aren't going to know what the heck a "pseudo teletype" is, or even what "allocate" means. What would you suggest? When it happened to you, what error message would you have understood? I can understand people not recognizing 'pseudo teletype' == PTY *** Bug 99618 has been marked as a duplicate of this bug. *** CVS commit by hindenburg:
Try to be more helpful when unable to open a PTY.
CCBUGS: 87481
M +6 -3 session.cpp 1.103
--- kdebase/konsole/konsole/session.cpp #1.102:1.103
@@ -98,5 +98,8 @@ void TESession::ptyError()
{
if ( sh->error().isEmpty() )
- KMessageBox::error(te->topLevelWidget(), i18n("Unable to allocate a pseudo teletype!"));
+ KMessageBox::detailedError( te->topLevelWidget(),
+ i18n("Konsole is unable to open a pseudo teletype!"),
+ i18n("Konsole needs to have read/write access to the system's PTYs. The exact location of the PTYs depends on the Linux kernel version (2.4.x or 2.6.x), the kernel configuration and which dev-filesystem (devfs or udev) is being used. \nUsing Linux kernel 2.6.x and udev this is typically /dev/pts/"),
+ i18n("A fatal error has occurred!") );
else
KMessageBox::error(te->topLevelWidget(), sh->error());
@@ -139,6 +142,6 @@ void TESession::run()
("DCOPRef("+appId+",konsole)").latin1(),
("DCOPRef("+appId+","+sessionId+")").latin1());
- if (result < 0) { // Error in creating pseudo teletype
- kdWarning()<<"Unable to allocate a pseudo teletype!"<<endl;
+ if (result < 0) { // Error in opening pseudo teletype
+ kdWarning()<<"Unable to open a pseudo teletype!"<<endl;
QTimer::singleShot(0, this, SLOT(ptyError()));
}
Sorry for the delay. That error message seems much better - though frankly, I was never completely sure what was causing it to be unable to allocate a pty (which means you probably know better than me what the error message should be). So you believe it's the read/write permissions on the devices in /dev/pts? I see now that what's happening on my system is that when Konsole opens, a new device is created in /dev/pts, with permissions being denied to everyone except the owner of the new Konsole process. So when I had RC_DEVICE_TARBALL set to "yes", there were already the maximum number of ptys created, and perhaps also only root had permission to use any of them. It seems to me that this is a fundamental limitation at a lower level; i.e. there should really be no limit on how many ptys the system can create. If that's the case, it's true that I don't think Konsole can do much better than to give an error message that mentions ptys and is incomprensible to some users; though in the long run I'd say someone should fix that limitation. Some things you might want to add to the error message, though - a notification that "Konsole could not be started because...", as well as "This is probably due to incorrect configuration of the pty devices". CVS commit by hindenburg:
Simplify PTY error message.
CCBUGS: 87481
M +3 -3 session.cpp 1.104
--- kdebase/konsole/konsole/session.cpp #1.103:1.104
@@ -97,8 +97,8 @@ TESession::TESession(TEWidget* _te, cons
void TESession::ptyError()
{
+ // FIXME: sh->error() is always empty
if ( sh->error().isEmpty() )
- KMessageBox::detailedError( te->topLevelWidget(),
- i18n("Konsole is unable to open a pseudo teletype!"),
- i18n("Konsole needs to have read/write access to the system's PTYs. The exact location of the PTYs depends on the Linux kernel version (2.4.x or 2.6.x), the kernel configuration and which dev-filesystem (devfs or udev) is being used. \nUsing Linux kernel 2.6.x and udev this is typically /dev/pts/"),
+ KMessageBox::error( te->topLevelWidget(),
+ i18n("Konsole is unable to open a PTY (pseudo teletype)! This is likely due to an incorrect configuration of the PTY devices. Konsole needs to have read/write access to the PTY devices."),
i18n("A fatal error has occurred!") );
else
|