[SUMMARY] tip and /var

The question was how to recover tip connection that was broken when /var
was moved. 

Thanks to all who replied.

I got 3 replies. (I quoted them at the end of this email) I haven't
solved the problem, and am still searching for solution. 

By now I moved the /var disk completely, and I suspect perhaps the
incoming tip connection is not broken because of /var, since I tried
various things including:

fuser -k /dev/console
sacadm -a -p zsmon -t ttymon -c /usr/lib/saf/ttymon -v `ttyadm -V`
sacadm -k -p zsmon
sacadm -s -p zsmon
etc.

Right now this is where I stand.

# sacadm -l
PMTAG          PMTYPE         FLGS RCNT STATUS     COMMAND
zsmon          ttymon         -    0    ENABLED    /usr/lib/saf/ttymon #

# pmadm -l
PMTAG          PMTYPE         SVCTAG         FLGS ID       <PMSPECIFIC>
zsmon          ttymon         ttya           u    root     /dev/term/a - -
/usr/bin/login - 9600 - login:  - tvi925 -  #

but the incoming tip connection still does not work.

My original post follows.
===========================================================
> I use a headless Solaris 8/SPARC.
> 
> I had a working tip connection (tip hardwire) on my server, but after
> moving some directories under /var to another disk and symlinking them, I
> lost the tip connection. I get "connected" but no login prompt.
> 
> The only thing that's been changed was the directories being moved out to
> another disk and symlinked back.
> 
> So I'm sure if some directories under /var is causing the problem. I
> checked the directory permissions of /var/uucp, /var/uucppublic,
> /var/spool/uucp, and /var/spool/locks, /var/spool/temp, /var/saf, but all
> are the same as before, except that for example /var/saf actually is
> /new/disk/saf and is symlinked under real /var.
> 
> Could someone tell me what directories under /var the "tip" might use?
> Since it was working fine before moving to another disk, and I didn't
> reboot, I guess it must be something simple. (I used tar / untar so I
> think the permissions were correctly preserved.)
> 
> (I owe a summary regarding "moving ld.config" in /var. I will post the
> summary after completing the change and verifying the results.)

I posted a correction after getting Eric Voisard.
===================================================
Could someone tell me what directories (under /var) sac or ttymon uses,
for an incoming "tip" connection?
                                                                                           
If those files were "mv"ed to another disk and "ln -s"ed (symlinked) back
to /var, what is the proper way to restart related processes to have them
recognize the symlinking?



These are the replies I got.
===================================================

>From Raymond Plassart:
> Tip create a lock file in /var/spool/locks (755 owner:uucp group:uucp) and
> open /var/adm/aculog (600 :uucp group:bin)


>From Eric Voisard:                                                                                            
> I'm not sure to understand you correctly. You mean you have a 'tip'
> connection FROM some Sun box TO your headless server? Were the changes
you
> made on the Sun box or on the headless server?
>
> I'm asking since if the changes are on the headless server, then the
> problem would be a 'sac' and 'ttymon'
> one. I think the daemons would need to be restarted since they might
still
> have handles to files opened before, but not existing anymore...
>
> Most of the problems I got with Sun's damn serial ports were due to
local
> conflicts between ttymon and tip (tip wanting to use resources reserverd
by
> the ttymon daemon). I also had problems with the rights, but on the
serial
> port's drivers: for some run time reason they were left incorrect and it
> was impossible to use them anymore.
> But again, are you sure the problem is on the client's 'tip' side and
not
> on the server's 'ttymon' side?...

From: Daniel Vega 
> maybe you have setup to log all logins so, if you moved /var/adm where
> most of the logs resides, maybe the proper daemons can't write the
> event on them , maybe that's the reason you can't log in.

Thanks.

Ben Kim
Database Developer/Systems Administrator
College of Education 
Texas A&M University
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers