Too many users

Thu Nov 12 10:42:21 PST 2020

Thanks Mark
I have always used kill -9 so learn something everyday I guess
Is there a distinct difference why this doesn't seem to cause issue if the
person connects internally here at the office vs if they're over the VPN
Wouldn't seem to me this would make a difference since I've never had this
issue pre-lockdown - only when users have started working remotely has this
caused an issue where it's affecting user counts in fP - just seems odd to
me but maybe I'm missing something
I appreciate everyone's assistance

Scott

On Thu, Nov 12, 2020 at 11:50 AM Fairlight via Filepro-list <
filepro-list at lists.celestial.com> wrote:

> You should not be using -9 unless you need to.  Good way to bork an
> index.  Use SIGHUP (1), which is the signal that comes from a natural
> session timeout/hangup.
>
> m->
>
>
> On Thu, Nov 12, 2020 at 04:35:27PM +0000, Josh Reader via Filepro-list
> thus spoke:
> > Hi Scott,
> >
> > In the past I used the kill command to kill individual PIDs but now I
> use pkill to kill all sessions for a user.  The syntax for that would be:
> >
> > pkill -u <username>
> >
> > I have the user close all their open PuTTY windows, issue the command,
> and then they can get back in.
> >
> > Josh
> >
> > -----Original Message-----
> > From: Filepro-list <filepro-list-bounces+josh.reader=
> mercuryelectronics.com at lists.celestial.com> On Behalf Of scooter6--- via
> Filepro-list
> > Sent: Thursday, November 12, 2020 10:45 AM
> > To: James Flanagan <James at flantec.com>
> > Cc: filePro Mailing List <filepro-list at lists.celestial.com>
> > Subject: Re: Too many users
> >
> > Well, that makes sense to a degree
> > So is there a different kill command that would alleviate this problem?
> > (i.e. not using -9)
> > When we had everyone working in house and not remotely, this was never
> an issue, with the timeouts - they would just die and we never encountered
> the too many users error - so it must be some iteration of doing kill -9
> with those working remotely and accessing the VPN I appreciate the feedback
> though and try it out if need be Thanks again Scott
> >
> >
> > On Thu, Nov 12, 2020 at 9:04 AM James Flanagan <James at flantec.com>
> wrote:
> >
> > > Scott,
> > >
> > > I have experienced a similar situation with filepro, on at least 3
> > > different software platforms, over the years.  I have exhaustively
> > > tried to both understand and remedy this issue WITHOUT rebooting, and
> > > I will share the latest information I received from FPTech.
> > >
> > > According to the developers, one possible cause of the phantom license
> > > issue is using kill command with the -9 argument.  This is incredibly
> > > unfortunate because as most unix admins know, most times, it is the
> ???-9???
> > > switch that actually kills what you are trying to kill.
> > >
> > > In the event that you want to reset the license count back to 0 (I am
> > > not aware of any function that will reset only some of the license
> > > count, so it is an all or nothing consideration), you need to get
> > > everyone off the system, and then run the following command:
> > >
> > > ipcs -m | grep filepro
> > >
> > > This will display the shared memory segments for filepro.  Use the
> > > ipcrm -m command to remove those shared segments, and your license
> > > count will be reset to 0.  That being said, depending upon time it
> > > takes to reboot your server hardware, by the time that you get
> > > everyone off of the system anyway, it may be more efficient to
> reboot.
> > > But, now at least you can reset the license count without a reboot
> whenever necessary.
> > >
> > > Good luck,
> > >
> > >
> > > James Flanagan
> > > Flantec.com
> > >
> > > email: James at Flantec.com
> > > mobile: 760-458-8498
> > > home:  219-221-6219
> > > text: 7604588498 at txt.att.net
> > >
> > > Skype: Flantec
> > > ichat: James at Flantec.com
> > >
> > > home: 1901 Cidermill Road
> > > Michigan City, IN 46360
> > >
> > >
> > > On Nov 11, 2020, at 3:03 PM, scooter6--- via Filepro-list <
> > > filepro-list at lists.celestial.com> wrote:
> > >
> > > As with many companies, we have a ton of our staff working remotely.
> > > They access our network via OpenVPN and work as normal via putty We
> > > have CentOS 7 and fP 5.6.10R4 Internally, in the office, ssh times out
> > > in 10 minutes, but it kills the session entirely (at least through
> > > past years experience, we've never encountered this will staff working
> > > here at the office) But over OpenVPN, it has 10 minute timeout built
> > > in to the config but it doesn't kill their putty session.
> > > I monitor every now and then and kill them when I see this However,
> > > this appears to be causing a problem where we get 'too many users'
> > > error
> > > We have 95 user license, and I know that doesn't mean 95 'users' -
> > > it's occurrences of rclerk, etc But we keep getting this error
> > > occassionally and when I got it, I looked and we had combined, a total
> > > of 47 instances of rclerk, rreport etc running
> > >
> > > The only solution is to reboot the server.
> > >
> > > Is there a way, either in fP or in OpenVPN, where I can make sure it
> > > fully kills their session and we can stop getting this 'too many
> users' error?
> > >
> > > Thanks
> > > Scott
> > > PDM
> > > -------------- next part -------------- An HTML attachment was
> > > scrubbed...
> > > URL: <
> > > http://mailman.celestial.com/pipermail/filepro-list/attachments/202011
> > > 11/63612a1f/attachment.html
> > > >
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > Subscribe/Unsubscribe/Subscription Changes
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> > >
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mailman.celestial.com/pipermail/filepro-list/attachments/20201112/c2ac876d/attachment.html
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: PastedGraphic-1.tiff
> > Type: image/tiff
> > Size: 19328 bytes
> > Desc: not available
> > URL: <
> http://mailman.celestial.com/pipermail/filepro-list/attachments/20201112/c2ac876d/attachment.tiff
> >
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > Subscribe/Unsubscribe/Subscription Changes
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
>
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20201112/317be6e0/attachment.html>