SUMMARY: Many clock processes

From: Robert Meisner FE (
Date: Tue Oct 20 1992 - 00:36:31 CDT

Hi all

My original problem was that I had about 20 clock processes running & the
performance of the machine (4/370 Server) went completely down. It was hard to spot were the clocks came from and you could not kill them without getting a

I got very many very different answers.

I did have a problem with the .openwin-init file - someone put a strange option in there :
"-hourcmnd exit"
This may have caused the problem but I don't know. I also applied OW Patch
100568-01 which should fix clock problems.

It was the first question mailed and you find me at my desk deeply impressed
by the numerous reactions to a "minor problem".
( Find the list of all replys attached)
Greetings to all


/^^^^^\ Robert Meisner
| | German Aerospace Research Center (DLR)
| @---0 Remote Sensing Applications
| > 8031 Wessling Tel : 0049-8153-28-1314
| < Germany Fax : 0049-8153-28-1445
| _/ e-mail :


Thanks to david@srv.PacBell.COM for this one :

what does your .openwin-init look like?

Other suggestions were :


Says - use patch 100568-01.

Keywords: alarm, clock, exec, execvp, invalid, hang, freeze, command, maybe, ser
Synopsis: OpenWindows V3: invalid alarm command causes clock and server to hang
Date: 17/Apr/92

SunOS release: 4.1.x

Unbundled Product: OpenWindows

Unbundled Release: 3.0

Topic: patch for clock

BugId's fixed with this patch: 1086168

Architectures for which this patch is available: sun4

Patches which may conflict with this patch:

Obsoleted by:

Files included with this patch: clock

Problem Description: Using the V3 clock to set up an alarm command.

If the user either mistypes the command - or somehow ensures the command
cannot be run, when the time arrives to run that alarm command, the properties
sheet of the clock gets screwed up and event processing of the clock freezes.

This causes the server to freeze if a user then clicks in that tool etc.

If you rlogin to kill off the clock - you will see two clock processes running.


        Kill any and all clock processes now running and then install
        the patched clock.

Warns from calling clock in your .cshrc (obviously happend at their place



Once I was very smart - I changed the shell to /usr/openwin/bin/xterm (you know, allways
run X-windows, so allways use xterm as a shell :-). So when xerm tried to spawn a shell, it actually
spawned a new xterm, which in turn tried to spawn a shell,...

Check your .login and .cshrc's too (and why not check the .openwin-init, .xsession, $OPENWINHOME/openwin-whatever)

Try to check /etc/ttytab and others files involved when you login/spawn shells

Try to rename /usr/openwin/bin/clock to /usr/openwin/bin/ and see what happens
try to run /usr/openwin/bin/

My guess would be that there's either something in your
.cshrc file that is spawning clock processes for you each time the file
is sourced (like when you run new shells, and don't check to see if
they are tied to a tty or not)...

...OR perhaps you have a case of someone running a `clock` process in
the shell prompt, in an attempt to get the time into the prompt...

I'd do a "grep clock .*" in the user's home directory/working directory
and see what shows up...

I am not sure where I read this but I do recall that if a user sets up his clock to report the seconds that CPU performance will come to a crawl.

This may or may not be the case for you.
Good Luck.
>From : xcpgzm@atom.oryx.COM

Is this another clock in .cshrc (.login) trick? That way, every shell you
invoke starts another clock. cute.

Thanks to all who replied :


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:52 CDT