Article: 161296 of comp.unix.solaris
From: rlhamil@smart.net (Richard L. Hamilton)
Newsgroups: comp.unix.solaris
Subject: Re: Solaris suspend/resume and xntpd (and more)
Date: 21 Jan 1999 06:48:29 GMT
Organization: Timetravellers Anonymous
Lines: 144
Distribution: inet
Message-ID: <786ijt$ctf$3@news.smart.net>
References: <785tf9$bak$1@news.smart.net>
NNTP-Posting-Host: mindwarp.smart.net
Mime-Version: 1.0
Content-Type: multipart/mixed;
    boundary="=-=-=__/EKzzEboDFe8nKBVEYgzUDAbq__=-=-="
Content-Transfer-Encoding: 8bit
X-Newsreader: knews 1.0b.0
Path: news1.meer.net!news3.best.com!news2.best.com!newsfeed.berkeley.edu!newsfeed.cwix.com!207.176.80.103!news.smart.net!not-for-mail
Xref: news1.meer.net comp.unix.solaris:161296

--=-=-=__/EKzzEboDFe8nKBVEYgzUDAbq__=-=-=

Attached is my first attempt at a workaround for some
of this stuff - really ugly.

In article <785tf9$bak$1@news.smart.net>,
	rlhamil@smarty.smart.net (Richard Hamilton) writes:
> What, if anything, does Solaris (>= 2.6) xntpd do to
> account for having been subjected to a system suspend/resume?
> Since it hasn't been active, the hardware clock has been going
> on its own for some amount of time, meaning that xntpd's idea
> of what was going on (prior to the suspend) is no longer
> accurate.
> 
> I think the simplest solution would be to have it catch
> SIGTHAW, and re-exec itself in the signal handler.  Better
> would be an additional configuration option of a command line
> to re-exec, so that instead of re-exec'ing itself directly,
> it could exec /etc/init.d/xntpd start     instead, so that
> the initial synch-up using ntpdate would be done.  That
> would be particularly important if the system had been down
> for enough days to have a > 1 second clock skew (which would
> cause xntpd to just give up).
> 
> As a workaround, I could write a program that caught SIGTHAW,
> looked around to see if xntpd was running, and if it was, killed
> it and forked and exec-ed the xntpd startup script.
> 
> Unrelated to xntpd, suspend/resume doesn't restore keyboard
> click.  Yeah, I've read where you can't query the keyboard
> click state, but the driver could still track what it had
> last been set to, and set the keyboard to the last known state
> after a suspend/resume (and possibly at other appropriate points
> where there was  cause to believe that the actual state didn't
> reflect the last-known state) which would generally be good enough; if
> someone managed to confuse it by bypassing certain modules
> and talking directly to the keyboard, they'd deserve an
> inconsistent result anyway.  Alternatively, the X server could
> catch SIGTHAW and redo operations such as setting the keyboard
> click state to it's idea of the last known state.
> 
> Also, after a suspend/resume, one may get interleaved shell and
> login prompts in a console dtterm.  Usually closing the console
> dtterm and starting a new one straightens that out.
> 
> Finally, is it a bug or a feature that you can't suspend from the
> CDE login screen?
> 
> NOTE: I haven't had time to go patch-happy yet, so if some of these
> problems have a fix already, I'll get to it soon; don't hesitate to
> say _which_ patch(es) might help.
> 
> (FYI, I just picked up a 2nd-hand Voyager, which is what got me
> to thinking about suspend/resume related issues, as my other systems
> were either too old to support suspend/resume, or were unable to due
> to 2nd party drivers that didn't support suspend/resume.  But none
> of the problems with suspend/resume should be peculiar to the Voyager;
> any system where suspend/resume can be used would benefit from solutions.)

-- 
ftp> get |fortune
377 I/O error: smart remark generator failed

Bogonics: the primary language inside the Beltway

mailto:rlhamil@mindwarp.smart.net  http://www.smart.net/~rlhamil
--=-=-=__/EKzzEboDFe8nKBVEYgzUDAbq__=-=-=
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="resume_fixes"

#!/bin/ksh
#
# /etc/init.d/resume_fixes
#
# Fix up some of the quirks in suspend/resume.
# Requires package SUNWesu (Extended System Utilities) for
# the /usr/proc/bin commands.
#

PATH=/usr/bin:/usr/openwin/bin:/usr/proc/bin;export PATH

Usage="usage: ${0} start | stop | user loginid"

restart_xntpd () {
   if [ -f /etc/inet/ntp.conf ]; then
      /etc/init.d/xntpd stop
      /etc/init.d/xntpd start
   fi
}

console_user_fixes () {
   Xuser=`who|awk '$2=="console" && $NF=="(:0)" {print $1;exit}'`
   if [ -n "${Xuser}" ]; then
      su - ${Xuser} -c "/etc/init.d/resume_fixes user \"${Xuser}\""
   fi
}

restore_keyclick () {
   # wait until the screen is unlocked and therefore server not grabbed
   Pid=`ps -e|awk '$NF=="dtscreen" || $NF=="xlock" {print $1;exit}'`
   while [ -n "${Pid}" ]
   do
      pwait ${Pid} # wait for locker to finish
      sleep 5  # allow time for dtscreen to be restarted by dtsession
      Pid=`ps -e|awk '$NF=="dtscreen" {print $1}'`
   done

   Percent=`xset q|sed -n 's/.*key click percent: *\([0-9][0-9]*\).*/\1/p'`
   if [ ${Percent} -gt 0 ]; then
      xset c off c ${Percent} # setting current value alone may not work
   fi
}

case "${1}" in
start)
   # in the background, wait as passively as possible for SIGTHAW
   # and when it is received, run the various fixups
   (
      trap "restart_xntpd;console_user_fixes" THAW
      while :
      do
         pwait $$  # as close to pause(2) as I can think of
      done
   ) &
   ;;
stop)
   # haven't figured this part out yet - it may not matter
   ;;
user)
   if [ "${#}" -eq 2 ]; then
      DISPLAY=":0";export DISPLAY
      restore_keyclick
      # other console user fixes could go here
   else
      echo "$Usage" >&2
      exit 1
   fi
   ;;
*)
   echo "$Usage" >&2
   exit 1
   ;;
esac
--=-=-=__/EKzzEboDFe8nKBVEYgzUDAbq__=-=-=--