This script is perhaps more useful.

pids=`/sbin/pidof xscreensaver`
if [ -n "$pids" ]; then
    lock_status=`xscreensaver-command -time | grep -q locked ; echo $?`
    noblank_status=`xscreensaver-command -time | grep -q non-blanked ; echo $?`
    echo "sending SIGHUP to running xscreensaver ($pids)..." >&2
    kill -HUP $pids
    if [ $lock_status = 0 ] ; then
        sleep 1 ; xscreensaver-command -lock
    elif [ $noblank_status = 1 ] ; then
        sleep 1 ; xscreensaver-command -activate
    fi
fi

Sleeping about 1 or so second is necessary; otherwise "sometimes"
xscreensaver-command fails with leaving a message like

xscreensaver-command: no screensaver is running on display :0.0

which means that xscreensaver-command failed to find the running 
xscreensaver.

those are okay work arounds, but the right fix is probably to make xscreensaver
not kill locked sessions when it gets a hangup signal.

Perhaps; but there's no *security* reason for it to ignore -HUP, because if you can send -HUP you can also 
send -9.  So I think either way of fixing it are equivalent.

Hi,

So the scenario is a person starts a yum update, locks their screen and goes
home for the day.  Later that night someone else in the room notices the
screensaver dies and then has access to the machine for the night.

The patch in comment 1 tries to address the above scenario by restarting
xscreensaver if it dies.  There are two problems with it

1) xscreensaver is a session daemon, so starting it from %post in the spec file
will just try to run xscreensaver as root with no display, etc...

2) even if it did work, it gives am (albeit small) window for the person who
notices the screensaver die to type pkill xscreensaver at an open terminal or
something and then gain access to the computer.  Probably not a big threat, but
there's definitely a race.

No, doing "xscreensaver-command -restart" will not launch xscreensaver as root, it will re-launch it as 
the user who initially launched it.  "xscreensaver-command" does not do the exec(), it just sends a 
message to the existing "xscreensaver" process, which does the exec() in the same context it was 
initially started in.  The -restart message does the right thing even if sent by root.  

And "xscreensaver-command -restart" and "kill -HUP" do exactly the same thing, except that the 
former requires a connection to the logged-in user's $DISPLAY while the latter requires only that you be 
able to signal that users' processes.

Simply not re-launching when the screen is locked is probably a good idea, and what I was trying to say 
is that I don't think it makes any difference whether that behavior is in the %post script or hardcoded 
into the daemon itself: they will be functionally equivalent.

However, it's not clear to me that *not* restarting it is safe either.  If /usr/bin/xscreensaver is running, 
and yum has overwritten the file, what happens when it swaps?  Will it get an illegal instruction?  I know 
I've had trouble in the past with other daemons dying as a result of yum having upgraded the rug out 
from under them.

I think reactivating should be handled by xscreensaver instead of the post
installation script as the script won't be able to figure out what $DISPLAY the
screensavers were running on, although it appears to default to :0.0 which is
probably safe in most cases.

Or maybe xscreensaver could just ignore the restart request until it has been
unlocked.

Created attachment 123652 [details]
Example patch to treat restart process

Hello.
In fact, even if I wait for 1 or so seconds to invoke xscreensaver-command
after xscreensaver is restarted by SIGHUP signal (see my comment 1), screen
often fails to blank or lock when system is busy.

As Oskari commented in comment 6, the solution I can think for now is to give
xscreensaver command the state before SIGHUP command was sent by creating some
extra argument.

I attached a sample patch to follow this behaviour. It seems to work for me.
This patch does:
1. Before restarting, check if screen is locked or blanked.
2. Create some extra arguments then restart.
3. Throw away the added arguments

Created attachment 123658 [details]
Renewal patch

Renewal patch with some modification of memory treatment about malloc and so
on.

Hi guys,

What i'm wondering is how root has access to the user's display?  Are you guys
setting $XAUTHORITY to the user's xauth file before starting the upgrade?  maybe
you guys are using sudo?  It seems like it would break in general because
displays require authentication that you don't get automatically as root.

Umm.. when I get login to root by "su -", root's $XAUTHORITY points to root
xauth file (as usual, not the original user's file), $DISPLAY is :0.0, and
executing xscreensaver-command by root blanks or lockes user's display.

Ray, your question means that "why xscreensaver daemon accepts the requirement
to lock or blank screen from root by xscreensaver-command"?

I am not familiar with X authentication framework. As far as I know,
xscreensaver-command simply sends a client message to the display governed by
xscreensaver daemon by XSendEvent ( as the comment 5 by Jamie )

   if (! XSendEvent (dpy, window, False, 0L, &event)) 

(in send_xscreensaver_command() in remote.c), and this client message (event) is
interpreted by xscreensaver daemon.  

Even if I login the other user by "su - (non-root user)", the user can blank or
lock xscreensaver screen (for me).

Created attachment 123709 [details]
log of upgrading xscreensaver where xscreensaver-command FAILS

Okay. I might have understood what Ray is in question. When $XAUTHORITY is not
set, root cannot lock or blank screen by xscreensaver-command.

I usually login with GUI and when I need to upgrade xscreensaver, I launch some

GUI terminal, switch to root in the terminal (then $XAUTHORITY is set to
/root/.xauth...) , then execute 'rpm -F (rpms)' or 'yum -y upgrade (packages)'.
In this case, invoking xscreensaver-command in postinstall process suceeds.

There can be the case where root user trying to  upgrading package doesn't have
$XAUTHORITY value (upgrading automatically by yum is this case?) , where
xscreensaver is running on GUI, which is invoked by normal user. 

I made a experiment:
1. Launch xscreensaver by normal user in GUI.
2. Create xscreensaver rpm with postinstall script like my comment 1.
3. Lock GUI.
4. Switch to CUI,  and try to upgrade xscreensaver rpm
5. Quickly back to GUI (screen is back at this point), and see screen is locked
again by postinstall script

Result: xscreensaver-command fails (see the log attached).

So, as Ray has questioned about this, locking screen again by postinstall
script like my comment 1 or Oskari firstly proposed is not proper: locking or
blanking screen again must be handled by xscreensaver itself.

Even this case, my patch at my comment 8 should suceed: With my patch,
xscreensaver daemon examines the status of screen before restart, and give the
status by adding  some extra argument to new xscreensaver daemon (invoked by
execvp()).

( Oh, I missed typing some information. In my experiment in comment 11, screen
is  unblanked and don't lock again.)

Created attachment 124433 [details]
Again renewal patch

Again renewal patch.
In the previous patch (id=123658), the treatment of lock or blank mode in
second or later cycle was wrong. Fixed it.

Rawhide xscreensaver(-5.01-2) changed so that
* xscreensaver won't restart when upgrading.
* so manual restart is required when necessary.