[X-Servers] "Clear" a hung port?

[Peter Krug]

Lisa,

Thank you for your reply.  In activity monitor, I cannot see the  
individual connections, just a process called MYOBFileConnect.  If I  
force quit the process (quitting does not work), I cannot restart the  
process via the control panel unless I change the port that it uses  
(that is pretty much all the control panel does - turn on/off sharing  
of the data file and choosing the port for listening).    I can  
normally stop sharing via the control panel if none of the users are  
connected to the data file, but once the network snafu causes the  
connection break, the control panel still thinks that the user is  
connected.  That's why I wanted something that could "clear the port"  
so that the control panel would not register connection anymore and  
could be restarted.

Currently my only options are to 1) forcequit the process, reset the  
port, start it back up, tell the users to change their ports or 2)  
restart the server hardware.  I am strongly considering moving the  
data file to one of their computers since taking down the server  
hardware once or twice a day breaks many more connections to other  
users of the server.

I wonder if I just closed the port and reopened it via the command  
line if that might make the control panel forget that it had a  
connected "phantom user"...  except that I'm not sure how I would go  
about doing that. <sigh>

Thanks for your help,

Peter

On Sep 15, 2006, at 9:58 PM, lisa wrote:

> Hi,
>   From a strictly UNIX perspective, with what you're describing it  
> seems like you should still be able to see that phantom connection  
> process out there connected to your box.  So I don't know if you  
> need to clear the port so much as clear all connections to that  
> port. (Not having used MYOB FileEdge I can't really speak to how  
> the application handles locking)  When your users login using the  
> MYOB FileEdge server can you see their individual connections in  
> Activity Monitor?  If so you should be able to clear the individual  
> connection to the MYOB FileEdge server as opposed to clearing the  
> application itself.  If you're not sure what the user process looks  
> like then you could open Activity Monitor before anyone logs in and  
> then have them login to the MYOB FileEdge server and see what new  
> connection is created.  Once you can identify their connections and  
> kill them through activity monitor you can also kill them through  
> terminal by using the ps command to find the connections and the  
> kill command to kill them.  (In the advent you need to kill both  
> the user connections *and* the MYOB FileEdge server all of that can  
> be done by command line commands in terminal using the same ps and  
> kill commands.)
> Let me know if I need to be more clear.  I just woke up from nap. :)
> -lisa
>
> On Sep 15, 2006, at 12:55 PM, Peter Krug wrote:
>
>> XServerfolk,
>>
>> I am running Server 10.3.9 on a G5 tower.  One of the services I  
>> am running is an MYOB FileEdge server to share a single data file  
>> among 3 licensed users - it is shared via an MYOB control panel  
>> that lets you turn on/off sharing and set the port the spftware  
>> uses to share the file.  My problem is that one of the users of  
>> the software gets bumped off her network periodically, which  
>> causes the server to think she is still logged in because she does  
>> not log out properly.  At that point, one of our 3 licenses is  
>> lost until I restart the Xserver because the serving software  
>> still thinks this person is using the data file. I cannot turn  
>> sharing off via the control panel for the same reason.
>>
>> I can force quit the control panel via Activity Monitor to stop  
>> sharing the file, but unless I change the port, when I start it  
>> back up we still have the logged in user problem.  I am wondering  
>> if there is a way to "clear" the port of all network activity to  
>> bounce this phantom user off the server.  IF there is a terminal  
>> command for this, it would be wonderful because I could do this  
>> remotely.
>>
>> Sorry to be so long-winded.  Thanks in advance for any help.
>>