On reboot, the nodes auto start background process modules but do not automatically start the GUI. Historically, we use a startgraphic script to launch manually, either via SSH or via VNC. The script can be automatically launched as an init.d script, but a race condition might occur? Where, proview background modules are not fully started before a graphic startup script launches? That might be what you are encountering? Consider adding a sleep 15 delay in your startup script.

In our case, only the Operator stations are critical to run a GUI. Even then, Operators use RDP to access virtualized OP Stations, so no easy way for them to reboot an OP Station for an auto startup fix. We also provide two or more OP Stations for redundancy, so if one goes down, there is no "loss of view" to the process. In the past couple of years, we received two phone calls. 1) The Microsoft thin client lost connection. 2) The Proview OP Station graphics crashed but the background process continued working. We logged in remotely and simply ran our startup script on the failed Operator station to start the graphics, again. A desktop script shortcut could be provided, but we don't normally do it because of the rarity of an Op Station failure. In practice, we have the most trouble with RDP locking up due to network communication issues. Both Microsoft mstsc.exe and Linux rdesktop versions lock up in a side-by-side comparison during the same network event. I speculate this is an RDP protocol artifact, rather than an O/S issue. That's why we prefer VNC over RDP, but often not our choice.

For what it's worth, our simple startup script is:

source /etc/pwrp_profile
export DISPLAY=:2.0
rt_xtt -qn Op &


For an auto startup script, maybe:

sleep 15
source /etc/pwrp_profile
export DISPLAY=:2.0
rt_xtt -qn Op &

where sleep gives the background modules time to load and establish QCOM communications with the other nodes.

where export DISPLAY=:2.0 is a standardized VNC display session so multiple remote users can share the same desktop while commissioning and debugging. XRDP leverages VNC under the surface, so multiple RDP and VNC users can share the same desktop at the same time, too.

/Ron

jds,

Thinking through your posts, I just remembered something. When first installing Debian 12 and v6.1.1, I was having much trouble with pwr.service. Search the Proview Forum for a thread titled: Proviewr v5.8 Runtime Operator station, post #11127 by Pomplun to Avisopa. Once I made the modifications specified, all of my troubles went away. From my personal installation notes, I wrote:

Fix pwr.service script

> sudo nano /etc/init.d/pwr
line 33, change ( to {
line 34, change 10 to 9
line 37, change ) to } and 10 to 9 and
<ctrl> O <ctrl> X

I don't know why this works, but you should give it a try. Service pwr has been changed extensively during the years to provide additional security? Personally, I like the previous version of pwr better.

/Ron

Hello Ron,
The scripts you mention in your post are scripts to be used in the startup of the grapical interface I suppose?

The chang of 10 -> 9 is idd somthing that 's standard by all my installations otherwise it will not work. The change from ( to { is in my eyes not a neccessary change because "(" is a correct use.

I'm going to try out some other thing like ie. installing older version of debian or proview and/or do a full installation of the graphical interface.

My biggest guess for now is hoping that Claes has countered this issue and has a possible solution to it because all I can do for now is trail and error without the abillity to debug.

jds,

I found your issue. To take full advantage of the Supervisor monitor, graphical X11 GUIs must be installed on all of your nodes. That goes against the grain, I know. And, appreciate you wanting to strip down your controllers. But, to use the supervisor monitor features, a GUI is required. Here's why:

If you man ssh, you will find the -X option that enables X11 forwarding. When invoking the supervisor command, look at the development window. You can also connect manually by opening a new terminal window and typing the following command:

> ssh -X pwrp@ipaddress rt_xtt -qn Op

I'm having trouble with an & operator at the end of the command, but that's a minor point. Proview is using the ssh -X option to forward X11 graphical displays over to your Workstation Desktop. As another test, I am able to ssh -X Proview controller displays and navigator right onto a Window's desktop! Now, that's a really great trick!

Final answer

/Ron

Hey Ron,

I'm going to take this into account but I'm not 100% really convinced this is causing the issue because:
- display forwarding is already working without the installation of the display manager, X11 server is installed through the installation of Proview dependencies in the installation document
- the crashes only occures when doing display forwarding when Proview is automaticly started, when starting manually everything works as expected.

So it's mainly the last parts thats holding me from installing the full graphical envirionment. It could trully be a workaround, that's for shure, but I don't think it's the main problem.

"As another test, I am able to ssh -X Proview controller displays and navigator right onto a Window's desktop! Now, that's a really great trick!"

What do you mean, do you use XMing or something on windows to forward the displays to windows?

jds,

OK then, I see your point. I will build a controller with no graphical X and see what happens. It will be really cool if it works as you say.

/Ron