Summary- multiple selection_svc

Date: Thu Nov 01 1990 - 10:10:55 CST

Many thanks for the tremendous response! The first answer I got took
care of the problem. It was from Aydin Edguer and arrived a minute
before I even got my copy of the request for help. Wow.

I'm including his fix and comments as they are.

Additionally thanks to who mentioned a couple of
checks for the installation of the original patch,
let me know the importance of fixing it because of deletion/modification
ability of the files of the previous users.

Additional comments from, yamada-sun!eric@nosun.West.Sun.COM,,
and proved helpful.

A warning is in order that it is not ok to just ignore these till they
go away!


----- Begin Included Message -----

>From Mon Oct 29 10:23:44 1990
Return-Path: <>
Received: from charlie.CES.CWRU.Edu by (4.1/SMI-4.1)
        id AA06488; Mon, 29 Oct 90 10:23:42 EST
Received: by charlie.CES.CWRU.Edu (5.64+/ane.
        id AA03097; Mon, 29 Oct 90 10:22:26 -0500
From: Aydin Edguer <>
Message-Id: <9010291522.AA03097@charlie.CES.CWRU.Edu>
Subject: Re: multiple selection_svcs
Date: Mon, 29 Oct 90 10:22:23 EST
In-Reply-To: <>; from "" at Oct 29, 90 9:07 am
X-Mailer: ELM [version 2.3 PL6]
Status: RO

> Since the upgrade to SunOS 4.1,i I've noticed that multiple
> selection_svc processes continue to run after the user has
> exited sunview. I've installed the patch for selection_svc,
> and still I've noticed up to 9 of these processes running
> at the same time on a commonly used machine (a 3/50). Some users that
> have exited and entered sunview, own 2 or 3 of the processes.

Is anyone there using OpenWindows??

OpenWindows (X11/News) uses a different selection service. OpenWindows
selection service (sv_xv_sel_svc) will take over the selection service
RPC port when it starts (it does not kill selection_svc however). When
you exit OpenWindows, the OpenWindows selection service unregisters
itself and exits. The next time someone starts SunView, a new selection_svc
is started (because there is no selection service registered with RPC).
BUT THE ORIGINAL selection_svc is STILL running. ARGHH!

The work around from for this problem (and the mailtool problem) is as

1) compile killsvc and place in the /usr/bin/sunview1 directory.
        cc -o killsvc killsvc.c
        install -c -m 4755 -o root killsvc /usr/bin/sunview1

2) rename sv_release to sv_release.ORIG
        mv sv_release sv_release.ORIG

3) create a new sv_release with the contents:
        /usr/bin/sunview1/killsvc > /dev/null 2>&1 &

This should automatically kill the selection_svc for anyone when they are
done using sunview.

I am including the note from Sun support here that lists the source to

======================== Bug Copy =========================
 Bug Id: 1030932
 Product: sunos
 Category: sunview1
 Release summary: 4.1, 4.0.3, 3.5
 Bug/Rfe: bug
 State: evaluated
 Synopsis: selection_svc permission problem using textsw and umask
        when a user uses umask 027 in his environment the selection file
        /tmp/textsw_shelf is created for the textsw package under those
        If the selection_svc process was started by another regular user
        (Usually in a previous session), the selection_svc won't be able
        to work with this file.
        The following message will appear in the console window :
        Selection service couldn't open selection file: Permission denied
        filename: "/tmp/textsw_shelf"
 Work around:
        1. Encourge the usesr to kill the selection service process
            after they exit SunView.
           i.e : a script that grab the selection_svc process number
                  and kill it when exiting SunView
                  A suid program owned by root to kill this process.
 Suggested fix:
        Create the /tmp/textsw_shelf file ignoring the umask.
        This file is created by the textsw package.
 State triggers:
        19-Dec-89 --
        The problem is that the selection service is not killed when sunview
        terminates. This was done to eliminate the need to start the
        selection service each time sunview is started. The fix is to
        save the pid of the selection service **if it is spawned** and kill
        it **if it was spawned** when sunview terminates. If the user
        starts the selection_service before starting sunview, it will not
        be killed.
The work around should be changed. Starting selection_svc as root can
lead to selection_svc using a privilaged port < 1024 then when another
user tries to use the service he/she may get:
Cannot register service, RPC timed out
See bug id 1032415.

 Bug End:
======================== killsvc.doc ======================
1) Use rpcinfo -p to get the program and version number that
   selection_svc is registered under, and use rpcinfo -d to
   unregister the selection_svc with the privileged port.
2) Also "ps ax | egrep selection" and "kill -9 pid_for_selection_svc

*** BETTER ****
A) The program can be called /etc/killsvc and should be setuid-ed as

                % su
                # chown root /etc/killsvc
                # chmod 4755 /etc/killsvc

B) killsvc.c:
                system("/bin/echo \"(set psnum=\\`ps ax|\
                                grep selection_svc|grep -v grep\\`;\
                                kill \\$psnum[1])\" | /bin/csh -s");
                system("rpcinfo -d 100015 6");

C) Then the following should be in your .login:

                if ( `tty` == "/dev/console" ) then
                        echo Killing existing selection service...

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT