hang command and time synchronization

  • Dr. Martin Lehr

    Dr. Martin Lehr - 2003-07-10

    Changing the system time can produce unwanted
    hangs of gt.m-processes, the hangs originate from the
    - HANG
    - LOCK with timeout
    - READ with timeout (but only under certain conditions, see below)

    For example:
    at the gt.m prompt, type

    F I=1:1:100000 H 1 W !,I

    Login as root on another console and
    change the system time, the new system time
    must be in the past!
    (syntax: date 071013302003 is Jul 10 13:30 2003)
    After that the for-loop will hang, and it's the
    hang command which is the cause of the problem.

    This hang does not occur if the new system time
    is a time in the future.

    These hang problems can also be observed if Locks
    are used:

    L ^DUMMY
    at the gt.m prompt

    On another console, type
    F I=1:1:100000 L ^DUMMY:1 W !,I

    On a third console, change system time (must be in the past)

    Normally, reads do NOT generate suchs hangs:
    F I=1:1:100000 R *X:1 W !,I
    will always work, I tested it with serial lines, console and telnet
    There are two execeptions: timeout reads on fifos and tcp sockets
    also produce the hangs.

    The test system was a GT.M 4.2-002 on Suse Linux 8.2
    At the moment I dont know if these statements
    also apply to GT.M 4.3 FT18, I will test it in
    the next days.

    Perhaps this hang effect can occur if
    time synchronization is used on systems with gt.m processes.
    Particularly gt.m background processes are at risk
    because something like H 1 is typically used in this case.

    • Chunling Zhou

      Chunling Zhou - 2003-07-14

      Hi, Martin,

      Thanks for your post. We will take a look at this and fix it in a future release.

        Chunling Zhou.

    • George James

      George James - 2004-11-25

      Does anyone have a workaround for this problem?

      Has anyone tried MUPIP INTRPT?  Would that interrupt a process while it was in a hang state?

    • George James

      George James - 2004-11-25

      In a GT.M process:
      s $zinterrupt=";"
      h 300

      From another shell process:
      date <back-one-hour>
      mupip intrpt pid

      This seems to work.  The hang command is interrupted and restarted after the interrupt.  So if you have been waiting 250 seconds then you would wait another 300 seconds after the interrupt, but this is better than waiting one hour.

    • George James

      George James - 2004-11-29

      Actually, it's not even necessary to set $zinterrupt, so there's no need to make any application code changes at all.

      All you need to do is issue a mupip intrpt to all GT.M processes immediately after a time change and everything will step back into line.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks