OpenVZ Forum


Home » General » Support » Unable to open pty: No such file or directory
Re: Unable to open pty: No such file or directory [message #34077 is a reply to message #34069] Sun, 30 November 2008 20:11 Go to previous messageGo to previous message
mhw is currently offline  mhw
Messages: 12
Registered: March 2007
Junior Member
You don't say what distribution you are running in that container. The fixes you pointed to are largely for rpm based guests, Fedora / RedHat / CentOS. All of those should have an /etc/rc.sysinit file (/vz/root/101/etc/rc.sysinit in the case of 101 seen from the host system). You would probably only see a /sbin/udev_start file if you had updated that container and yum had installed/updated the udev package. Neither of those files exist in an Ubuntu system, if that's what your guest is.

I found that the fix of commenting out the udev_start command in /etc/rc.sysinit less than reliable simply because an update may replace that script (rare but happens, especially during distro upgrades) and you don't find this out until after you reboot the container and get the exact symptoms you describe. I found it more effective to put an "exit 0" at the top of the /vz/root/{$VE}/etc/udev/udev.conf file (that's sourced by start_udev and causes the script to terminate). That shouldn't get overwritten by an update / upgrade. Which probably also doesn't help you if you're not running one of the rpm based distros. The /etc/udev/udev.conf file does exist on Ubuntu but I don't know what impact adding the "exit 0" at the top will have.

If you are running Debian / Ubuntu or Slackware, you'll have to figure out how they are handling udev. I see it running on one of my Ubuntu systems but that system has neither /etc/rc.sysinit or /sbin/start_udev. It's started somewhere else. But I don't run apt based guests on my OpenVZ engines.

What I find strange is your claim that you have to reboot to fix this. That doesn't make sense if it's the udev problem described in those other links. Udev starts at boot and you should immediately fail trying to enter right after boot. The symptoms that those other fixes were addressing was getting that error after rebooting following an update. When does this problem occur? Immediately? Shortly after boot? After a few days? If you can get in right away after boot, see if and when udev starts and keep that shell open until things fail and you can't start new shells. The old shell should be still connected.

The problem with MAKEDEV is that /proc/devices is not showing up in the VE /proc directory. I see that on my systems as well. Not sure what the solution there is but I haven't needed MAKEDEV after disabling udev.

Oh... And the fact that vzctl is saying "enter into VE 102..." instead of "entered into CT 102" probably means you need to update your utilities. Just as a WAG. I think that change in nomenclature is fairly recent.

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Previous Topic: portable IP problem[solved]
Next Topic: Deleting personal data in vps (and rpms from updates etc) for rebuild new personalized vps template
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Sep 05 10:07:27 GMT 2026

Total time taken to generate the page: 0.05481 seconds
Powered by FUDforum Powered by Virtuozzo Containers