Re: [9fans] killing drawterm-left-behind processes on cpu server?

Re: [9fans] killing drawterm-left-behind processes on cpu server?

[forsyth]

you'll find that as bootes you can chmod the ctl files to allow you to kill them.

Re: [9fans] killing drawterm-left-behind processes on cpu server?

[Dan Cross]

> Thanks for the hint. However, unfortunately this is not the cause of
> my problems. After commenting out the upas/fs start line and starting
> and killing drawterm I still get 3 left-behind plumber processes,
> their status in order from oldest to newest: Sleep, Rendez and Read.
> Any magic that might help to diagnose what these processes are doing?

I noticed this many moons ago.  I changed my lib/profile to read, in
part:

	if (! test -e /mnt/term/wsys) {
		# cpu call from drawterm
		font=/lib/font/bit/pelm/latin1.8.font
		plumber
		rio
		kill plumber | rc
		kill fs | rc
	}

Which at least kills the processes.

	- Dan C.

Re: [9fans] killing drawterm-left-behind processes on cpu server?

[rob pike, esq.]

The way threaded process shut down has been completely reworked, thanks
to Sape and Russ.  The new release may fix your problems; it's probably not
worth tracking down what's wrong with the version of the thread library you
now have.

-rob

Re: [9fans] killing drawterm-left-behind processes on cpu server?

[Axel Belinfante]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Thanks for the hint. However, unfortunately this is not the cause of
my problems. After commenting out the upas/fs start line and starting
and killing drawterm I still get 3 left-behind plumber processes,
their status in order from oldest to newest: Sleep, Rendez and Read.
Any magic that might help to diagnose what these processes are doing?

I assume that the problem may be in the order in which I start things?
I attach lib/profile, just in case the problem may be found there.
In the 'cpu' case I moved the plumber invocation from where it
is commented out to where it is now, without any effect.
If I leave the plumber commented out completely, and start it
from within a rio window, it dies nicely when I exit drawterm.

Axel.

> | When I 'exit' from drawterm (by killing/destroying its window --
> | there is no other way, right?) I leave 3 plumber and 2 fs processes
> | behind that stay running on the cpu server, as user != bootes.
> |
>
> hmm... purely by coincidence I happened to be looking at 'man mail' as
> I was reading that.
>
>      BUGS
>
>           Biff and the -b option of fs perform the same function but
>           in slightly different environments.  The duality is confus-
>           ing.  The -b option exists because starting both fs and biff
>           in a Telnet session results in a number of processes that
>           don't die when the session is terminated; the plumber(4) is
>           held open by fs and biff still having it mounted, while fs
>           is held open by biff which is blocked waiting for plumbing
>           input.

[-- Attachment #2: profile --]
[-- Type: text/plain , Size: 1061 bytes --]

bind -a $home/bin/rc /bin
bind -a $home/bin/$cputype /bin
bind -a /usr/inferno/Plan9/$cputype/bin /bin
bind -bc $home/inferno /usr/inferno/usr
bind -bc $home/lib/face /lib/face
bind -c $home/tmp /tmp
font = /lib/font/bit/pelm/euro.9.font
EMU='-c1 -G -g800x600'
LPUSERID=foo
LPDEST=bar

switch($service){
case terminal
	plumber
	upas/fs
	echo -n accelerated > '#m/mousectl'
	echo -n 'res 3' > '#m/mousectl'
	prompt=('term% ' '	')
	fn term%{ $* }
#	exec rio
case cpu
	if (test -e /mnt/term/mnt/wsys) {
		# rio already running
		wsys = /mnt/term^`{cat /mnt/term/env/wsys}
		bind -a /mnt/term/mnt/wsys /dev
		echo -n $sysname > /dev/label
	}
	if not {
		# plumber
	}
	bind /mnt/term/dev/cons /dev/cons
	bind /mnt/term/dev/consctl /dev/consctl
	bind -a /mnt/term/dev /dev
	prompt=('cpu% ' '	')
	fn cpu%{ $* }
	# upas/fs -b
	news
	if (! test -e /mnt/term/mnt/wsys) {
		# cpu call from drawterm
		plumber
		font=/lib/font/bit/pelm/latin1.8.font
		TEXINPUTS=blablabla
		exec rio
	}
case con
	prompt=('cpu% ' '	')
	news
}

Re: [9fans] killing drawterm-left-behind processes on cpu server?

[markp]

| I think this (or something similar) has come up before, but anyway:
|
| When I 'exit' from drawterm (by killing/destroying its window --
| there is no other way, right?) I leave 3 plumber and 2 fs processes
| behind that stay running on the cpu server, as user != bootes.
|

hmm... purely by coincidence I happened to be looking at 'man mail' as
I was reading that.

     BUGS

          Biff and the -b option of fs perform the same function but
          in slightly different environments.  The duality is confus-
          ing.  The -b option exists because starting both fs and biff
          in a Telnet session results in a number of processes that
          don't die when the session is terminated; the plumber(4) is
          held open by fs and biff still having it mounted, while fs
          is held open by biff which is blocked waiting for plumbing
          input.

---mp

[9fans] killing drawterm-left-behind processes on cpu server?

[Axel Belinfante]

I think this (or something similar) has come up before, but anyway:

When I 'exit' from drawterm (by killing/destroying its window --
there is no other way, right?) I leave 3 plumber and 2 fs processes
behind that stay running on the cpu server, as user != bootes.

I tried killing them on the cpu server (from the console) as user bootes,
but that doesn't work (no permission to write to ctl nor note files).
So, two questions:

 - how do I avoid leaving those processes behind (I can kill them
   by hand before I kill the drawterm window, but something more
   automatic would be nicer)

 - how can I kill them on the cpu server (from the console, where I'm bootes)
   (if at all)

thanks,
Axel.