[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20001011: McIDAS-X 7.7 build/install/configure (cont.)

>From: address@hidden
>Organization:  UVa
>Keywords:  200010111541.e9BFfL419853 McIDAS-X 7.70 configure ADDE

Jennie,

re: kill -HUP pid_of_inetd

>Okay, edited the inetd.conf in /etc, but I am not very familiar with
>the HUP signal, I checked the status of inetd and got its pid
>windfall: /etc # ps -lf -u root | grep inetd
> 8 S     root   193     1  0  41 20 60733b08    239 600cc616   Sep 11 ?       
>  0:03 /usr/sbin/inetd -s
> 8 S     root  1987  1870  0  51 20 6166d610    107 60753378 16:06:59 pts/10  
>  0:00 grep inetd
>then I issued the following kill  (this hangs up the process but also
>issues a continue? (got that from the man page)....
>
>windfall: /etc # kill -HUP 193              
>
>so, the question is, did it work?

It should have.  Just as an aside, I usually use 'ps -eaf | grep inetd'.

>I list the process again, and it looks the same
>
>windfall: /etc # ps -lf -u root | grep inetd
> 8 S     root   193     1  0  41 20 60733b08    239 600cc616   Sep 11 ?       
>  0:03 /usr/sbin/inetd -s
> 8 S     root  2005  1870  0  51 20 6142edf0    107 60753878 16:10:25 pts/10  
>  0:00 grep inetd
>
>Shouldn't the time for this process have changed?

No.  The HUP signal is basically telling inetd to reread its configuration
file.  This is the same thing that is used in the LDM.  One can modify
pqact.conf while the LDM is running.  All that has to be done to start
using the new entries is to send a HUP signal to the pqact process, and
it will reread the pqact.conf configuration file.

re: site rep. creating local copies of DSSERVE.BAT and DATALOC.BAT

>I know that.  But I was just trying to find whatever controlled
>the way things had been running (when theoretically mcidas was
>running the adde server because mcadde pointed to /home/mcidas).
>It was working, I had looked at real-time data from home, but,
>I don't see why it was working before.

It could be the case that I did this directly on your system (again during
one of the marathon phone conversations).  If you don't change anything,
then DSSERVE.BAT can be used directly.  DATALOC.BAT has to be changed
since there is a field that must be set to the sites hostname before
anything will work.  The other thing, of course, is that DATALOC commands
can be issued "by hand" serially:

DATALOC ADD RTIMAGES windfall.evsc.virginia.edu
DATALOC ADD RTGRIDS windfall.evsc.virginia.edu
DATALOC ADD RTPTSRC windfall.evsc.virginia.edu
DATALOC ADD RTNIDS windfall.evsc.virginia.edu
DATALOC ADD RTNOWRAD windfall.evsc.virginia.edu
DATALOC ADD RTWXTEXT windfall.evsc.virginia.edu

This is so easy to do from the command line, that it may have been the
way it was done on windfall to begin with.

>> OK, but you now realize that for the remote server, you would have had
>> to do this as 'mcidas' in the previous setup and as 'mcadde' in the current
>> setup.  Right!?
>
>Duh.  Yes, I did understand that, I was only sitting in my account
>happily editing, I would have moved this eventually to /home/mcadde...

OK.  Just wanted to make sure that we were still on the same page. :-)

>My mcadde terminal was busy at the time with the build/installation,
>so I was just working in a different account because it was where
>I was logged in.

OK.

>(but thats okay, its good to keep my misunderstanding's in check)

OK.

>You can have root login if it would help of course.

I don't think I will need it, but if I run into directory permissions that
need to be changed I might.  Let's wait on that.

I will dive in and get the realtime datasets setup right after I end this
email.

Tom