Path: utzoo!attcan!uunet!husc6!rice!sun-spots-request
From: kranenbu%HLERUL5I.BITNET@cunyvm.cuny.edu
Newsgroups: comp.sys.sun
Subject: selection_svc
Keywords: Windows
Message-ID: <8905091802.AA29608@SunWS5.rulcs.uucp>
Date: 12 May 89 06:13:35 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 127
Approved: Sun-Spots@rice.edu
Original-Date: Tue, 9 May 89 20:02:01 +0200
X-Sun-Spots-Digest: Volume 7, Issue 285, message 9 of 10

As mentioned in SunSpots v7n194, the selection_svc program hangs around
after exitting suntools. Since I started some experiments with customised
suntools executables this has become a major nuiscance, since installing a
new /usr/bin/suntools (late at night) invariably leads to swapping errors
(the next morning, in client selection_svc's which I forgot to kill).

The following hack seems to get rid of selection_svc as soon as one quits
suntools (please note that this is based on the SunOS3.5 version):

In `suntools.c' declare a variable

  !  static int selection_svc_pid = 0;

somewhere, then look for the code where suntools prepares for exit.  In
SunOS3.5, this is the context:

> * Destroy screen sends SIGTERMs to all existing windows and
> * wouldn''t let any windows install themselves in the window tree.
> * Calling process of win_screedestroy is spared SIGTERM.
> */
> (void)win_screendestroy(rootfd);
> (void)close(placeholderfd);

Add a line

 !   if (selection_svc_pid) kill(selection_svc_pid, SIGTERM);

Finally, make the routine `root_start_service()' (right at the end of
suntools.c) look like this:

static void
root_start_service()
{
        register int    i;
        static char     *args[2] = {"selection_svc", 0 };
        if ((selection_svc_pid = vfork()) == 0)  {
                for (i = 30; i > 2; i--)  {
                        (void)close(i);
                }
                execvp(seln_svc_file, args, 0);
                perror("Couldn't fork selection service");
                sleep(7);
                exit(1);
        }
#ifdef DEBUG
        fprintf(stderr, "Selection_pid is %d\n", selection_svc_pid);
        sleep(4); /* time to reflect on our hacks */
#endif
}

Next comes the tricky part. Merely killing the selection-service program
apperently leaves the service registered at the portmapper, which causes
delay and an error message when suntools is restarted. Somehow we must
unregister this rpc-service. A look at `selection_svc.c' reveals that this
program almost entirely consists of just a call to `seln_init_service()'
(which I couldn't find documented in my copy of the chapter "The Selection
Service & Library" of the SunView System Programmer's Guide). Anyway,
browsing through the output of `nm /usr/lib/libsuntool.a', the eye was
caught by a function named `seln_svc_stop()'. I decided to give it a try:

(Here is the entire modified `selection_svc.c')
__________

#ifndef lint
static  char sccsid[] = "@(#)selection_svc.c 1.3 87/01/07 Copyr 1985 Sun Micro";
#endif

/*
 * Copyright (c) 1985 by Sun Microsystems, Inc.
 */

#include <sys/types.h>
#include <stdio.h>
#include <sys/signal.h>
#include  <sunwindow/notify.h>

#ifdef STANDALONE
#define EXIT(n)         exit(n)
#else
#define EXIT(n)         return(n)
#endif

extern void     seln_init_service(), seln_svc_stop();

void signal_handler(sig)
int sig;
{
    if (sig != SIGTERM) fprintf(stderr, "Pollens!...\n");
#ifdef DEBUG
    fprintf(stderr, "Selection_svc: got SIGTERM...\n");
#endif
    seln_svc_stop();
    exit(0);
}

#ifdef STANDALONE
main(argc, argv)
#else
selection_svc_main(argc, argv)
#endif
    int           argc;
    char        **argv;
{
    int           debug = 0;

    if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'd')
        debug = 1;
    signal(SIGTERM, signal_handler);
    seln_init_service(debug);
    (void)notify_start();

#ifdef DEBUG
    fprintf(stderr, "Selection_svc exitting\n");
#endif
        EXIT(0);
}
---------------

I don't know whether `seln_svc_stop()' actually takes parameters or not
(should the `debug' variable be passed again?).
I also don't know what the call to `notify_start()' is meant for. Comments
are appreciated. So far, things seem to work: if selection_svc is sent
a SIGTERM signal, a message "selection-services stopped normally" appears
on the console, and the service seems to get unregistered from the portmapper.
Additional insights, anyone?

-- Paul Kranenburg, Dept. C. Sc., Leiden University, NL.