Looping dtsession

[Wim Van den Wyngaert]

I'm running VMS7.3 with decwindows 1.2-6 in cde mode.

Some users regularly succeed in making the dtsession process loop (cpu, buf IO). I have no clue of what they exactly did. There is nothing in the log files.

I noticed the same when running VMS 6.2.

A known problem ? Any idea's of how to debug ?

[Lokesh_2]

Hi,

The user might be running some application which is looping. I will first see what application ..exe.. etc...they are running by following command

$sho process/id=/cont

Also, I will try to reduce the priority of the process and will see if it resolves the problem. ( set proce/prio ).

Can you post sho/proc/cont for looping process here ?

HTH,
Best wishes,
Lokesh

[Wim Van den Wyngaert]

Lokesh,

Stupid of me but I did a mon proc/topcpu and
saw only the dtsession. mon proc/topb however showed a second process running dtscreen. I killed it and the dtsession is back to normal. However, when the dtscreen was killed nothing disappeared from the screen. Is it possible that it was "disconnected" in some manner ?

[Lokesh_2 · Accepted solution]

Hi,

AFAIK, DTSCREEN.EXE is screen saver for your workstation. I usually consumes high buffer I/Os . So, when you killed it , nothing but your screen saver session got killed and you session is back to normal.

You can do a experiment . Enable your screen saver on lock. Then lock you screen, so that DTSCREEN got started. Then from other terminal ( telnet..etc ), check moni proc/topbio..you will see high bio for your session. Then kill that process, and you will see the from the locked display, you screen saver has gone !!...oh..will not write more..else you will get confused..just try it.

Thanks & regards,
Lokesh

[Wim Van den Wyngaert]

Bingo. Normally the dtscreen process dies when the saver is no longer active. On this node it didn't. And it took enormous resources (about 1500 bufio per second). It is a satelite cluster station (only disk with pagefile). Maybe that explains why it eats resources (some knows why ?).

I replaced the screensaver by a black screen. Problem solved. Thanks.

[Martin Kirby]

It is a known problem. Fixed in V1.3-1.

You will also find that your session log file is rather large - which is how it is described in the release note.

A race condition can happen if the screen is unlocked at the same time as the screen saver is starting. The starting screen saver should terminate but instead loops reporting errors. As nothing is seen on the screen the user does not realise there is a problem.

The risk of it happening can be reduced by only having a single screen saver pattern selected. This avoids a new screen saver being started every few minutes and therefore reduces the risk of the race condition.

Apart from that race condition, the problem could also happen if a defective application deleted one of the windows associated with the screen saver.

Martin Kirby
A DECwindows maintainer