-fg is not implemented when -noxstartup is used

[fhriley]

The only place -fg is implemented in vncserver is when -noxstartup has not been given. Thus, if you use -noxstartup, -fg does not work.

[dcommander]

That's a failure of documentation, which I will correct shortly. The vncserver man page says that -fg "runs Xvnc as a foreground process", but it should say "runs the X startup script as a foreground process." -fg was implemented before -noxstartup, so at the time -fg was implemented, there was no distinction between running Xvnc and running the X startup script. Xvnc has to be started asynchronously so that vncserver can record the PID and optionally start the noVNC web server. You should be able to accomplish what you want by creating a script that contains sleep infinity and passing it using the -xstartup argument, along with -fg.

[dcommander]

Scratch that. Ugh. The architecture of vncserver relies on the fact that the X startup script launches X applications, so presumably those application will abort, thus causing the X startup script to exit, when Xvnc is killed. sleep infinity won't do the job. Stand by.

[dcommander]

At this point, I need a better understanding of what you're ultimately trying to accomplish. The more I look at it, the less it seems to make sense to use -fg without an X startup script. -fg was intended for grid environments that expect processes to return control to the console only when they exit. The idea is that the grid environment starts the vncserver script with the -fg argument, the vncserver script starts the X startup script, the X startup script starts a window manager, and vncserver doesn't return control to the console until the user logs out of the window manager. So -fg basically puts the user in control of when Xvnc is killed. -autokill (which is now enabled by default) does that as well, but it returns control to the console immediately. (-autokill is essentially the same as vncserver -fg </dev/null &.)

[fhriley]

I'm running a full screen X11 app in a docker container. Turbovnc is the display for the app. Supervisord is used to start the processes so turbovnc needs to be in the foreground. Since the app is full screen, I don't need a window manager. I'm currently working around -fg not working with -noxstartup by invoking vncserver and then grabbing the Xvnc command using ps. I have supervisord execute that Xvnc command, which stays in the foreground.

[dcommander]

Why can’t you just pass your own X startup script using -xstartup?

[fhriley]

Are you talking about using an empty xstartup script or putting the app in there? If it's the latter, I want that in supervisord because it gives me configuration options that I would otherwise have to implement myself in the xstartup script. If it's the former, I guess I could do that. It just seems kinda hacky to include an empty file just to get the vnc server to be foregrounded. As it stands, if you want to close this as "won't fix", that's ok. My workaround is working fine.

[dcommander]

I meant putting the app into a custom X startup script. I don't have any familiarity with supervisord, so I can't speak to how best to integrate with it, but your workaround sounds like the most reasonable approach if you are unable to create a custom X startup script. Note that you might not need to grab the Xvnc command using ps. vncserver stores the PID of the Xvnc command under ~/.vnc.