xf86OpenConsole: setpgid failed

[dino99]

Binary package hint: lightdm

Oneiric i386 on nvidia (xorg-edgers)

got logged into xorg.log:

 xf86OpenConsole: setpgid failed: Operation not permitted
 xf86OpenConsole: setsid failed: Operation not permitted

i've found similar issue reported but against xdm/slim/wdm: Bug #585853
#19 post seems to point the real problem:
- This appears to be caused by the lightdm package not integrating with upstart.
- The plymouth process which holds the console open is waiting for a signal that the lightdm job is starting up, so that it can let go of the console; but the lightdm package doesn't have an upstart job, so there's no signal sent, which means the plymouth and lightdm processes are fighting over the console.

Note: need to check that the above comments are correct

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: lightdm 0.4.0-0ubuntu5
ProcVersionSignature: Ubuntu 3.0-1.2-generic-pae 3.0.0-rc3
Uname: Linux 3.0-1-generic-pae i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Sat Jun 18 09:26:09 2011
ProcEnviron:
 LANGUAGE=fr_FR:fr:en_GB:en
 PATH=(custom, no user)
 LANG=fr_FR.utf8
 LC_MESSAGES=fr_FR.utf8
 SHELL=/bin/bash
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

[Lucazade (lucazade)]

Get the same here... I didn't think to lightdm.

I was trying to make Oneiric work on a IntelGma 500 netbook by using the new kernel driver 'psb_gfx' included in Kernel 3.0.0
Unfortunately there were some issues with frambuffer/fbdev (and X doesn't start) so I was checking /var/log/Xorg.0.log and found this issue about xf86OpenConsole.

[ 18.386] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
[ 18.386] (WW) xf86OpenConsole: setsid failed: Operation not permitted

Don't know if the issue with framebuffer I have is the common cause of this problem of opening console (which should work on top of framebuffer itself if I am not wrong)

[papukaija (papukaija)]

This bug is confirmed in the previous comment.

[Yves-Alexis Perez (corsac)]

I get the same problem when forcing lightdm to use vt7/8/... (but not on vt1, though there's already a getty on vt1). This is on GMA965 so i915 driver with KMS.

[Yves-Alexis Perez (corsac)]

It looks indeed like a bad interaction with plymouh.

Booting with splash to lightDM = NOK
Booting with no splash = OK
Booting with splash, starting/stopping gdm then starting lightdm = OK

So something is done by gdm to clean the vt used by plymouth or something like that, which is not done by lightDM.

What puzzles me is that it was working at some point and I'm not too sure what changed. Here it's on Debian so it's unrelated to upstart.

[Yves-Alexis Perez (corsac)]

Hmhm, it seems that lightdm checks plymouth and there might be a race condition. It seems to ping plymouth, then ask about the active vt, then desactivate it. I'm not to sure if it works fine or not, but at least it seems that it breaks X startup.

[Yves-Alexis Perez (corsac)]

Ok I think I got it.

I'm not using "active" vt, I always put it on vt7. I'm not too sure where plymouth is running but it might be on vt7, which means they'll both compete for the display and, as I don't chose to run on "active" vt, it'll be only deactivated and not quitted, which doesn't seem enough.

Running only plymouth (no lightdm) and then running:

plymouth deactivate
X vt7

leads to X not starting because of the non returning ioctl. I guess that quitting plymouth unconditionally would work, no idea if that's a problem in the general case though. As far as we (Debian) are concerned, we quit plymouth anyway so it shouldn't break anything.

[Yves-Alexis Perez (corsac)]

(sorry for flooding)

It's even worth, when *not* deactivating plymouth, X actually starts fine, so I'm not sure it's worth deactivating it at all.

[Robert Ancell (robert-ancell)]

Anyone know if this is still valid?

[dino99 (9d9)]

Its no more logged on my side now, using genuine oneiric packages. Seems the latest upgrades have fixed it.

[Yves-Alexis Perez (corsac)]

Sorry I somehow missed the question. In Debian we still ship the patch, but I'll try without and report back.

[Yves-Alexis Perez (corsac)]

Seems we don't use the patch since long, and it seems to work fine even with plymouth. Sorry for the delay.