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 email@example.com who mentioned a couple of
checks for the installation of the original patch, firstname.lastname@example.org
let me know the importance of fixing it because of deletion/modification
ability of the files of the previous users.
Additional comments from email@example.com, yamada-sun!eric@nosun.West.Sun.COM, firstname.lastname@example.org,
and email@example.com proved helpful.
A warning is in order that it is not ok to just ignore these till they
----- Begin Included Message -----
>From firstname.lastname@example.org Mon Oct 29 10:23:44 1990
Received: from charlie.CES.CWRU.Edu by cs.clemson.edu (4.1/SMI-4.1)
id AA06488; Mon, 29 Oct 90 10:23:42 EST
Received: by charlie.CES.CWRU.Edu (5.64+/ane.09.11.90.2)
id AA03097; Mon, 29 Oct 90 10:22:26 -0500
From: Aydin Edguer <email@example.com>
Subject: Re: multiple selection_svcs
Date: Mon, 29 Oct 90 10:22:23 EST
In-Reply-To: <9010291407.AA05920@cs.clemson.edu>; from "firstname.lastname@example.org" at Oct 29, 90 9:07 am
X-Mailer: ELM [version 2.3 PL6]
> 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
Release summary: 4.1, 4.0.3, 3.5
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
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.
Create the /tmp/textsw_shelf file ignoring the umask.
This file is created by the textsw package.
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
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.
======================== 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
# chown root /etc/killsvc
# chmod 4755 /etc/killsvc
system("/bin/echo \"(set psnum=\\`ps ax|\
grep selection_svc|grep -v grep\\`;\
kill \\$psnum)\" | /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