Fail to connect to policy manager on Linux
Hi,
We've migrated our policy manager from windows server to linux server there are 3 weeks ago.
Last week, our clients couldn't update from policy manager. A reboot of the PM solved the problem.
Today, we have the same problem. We're unable to connect to PM from the clients and a reboot solved the problem.
Wich logfile I'm supposed to read to have informations ? I found the directory but I don't find any important information in the logs.
I use the 14.20 version of Policy manager, on a centos 7 minimal install os version.
Thanks.
Comments
-
Trouble shooting should start on the client side.
what version are the clients?
where is the client trying to connect to?
what is the response?
Did you change IP or name of the server?
Was that communicated to the clients correctly?
What Version was the Windows Server?0 -
The problem occurs on differents versions of clients (12.30, 13.11 and 14.1).
The clients try to connect to our policy manager on our LAN. When they obtain a time out, they do their update from a F-Secure server on the web.
For the migration, we kept the IP address of the old PM and we have modified the cname record on our dns servers. The old server is shutdown. It was a Windows 2012 R2 server.
After the reboot of the PM (centos 7), the problem disappeared. We can send policy, the clients can update from our PM.
Thanks
0 -
Hi tom1855,
Just noticed your post thus apologize for delayed answer.Recently we got several reports from PM Linux users with similar symptoms: PM works fine, but stops accepting connections at some point. All affected systems were reporting java.io.IOException “Too many open files” to PM logs on attempt to open file or establish new connection. According to our investigation there are two reasons behind:
• Default ulimit at most Linux distros is set to 1024/4096 for soft/hard correspondingly. We suggest to increase this limit for processes running by fspms user:
Please create file as root user:
/etc/security/limits.d/fspms.conffspms soft nofile 65536 fspms hard nofile 65536
Reboot the host and run the following as root user to check that limits have been updated:
su fspms -s /bin/bash -c 'ulimit -n' su fspms -s /bin/bash -c 'ulimit -n -H'
Both should return 65536
• Looks like WinHTTP used by Client Security and Server Security to communicate with the Policy Manager sometimes does not close connections properly, thus it is kept at PM host in Established state even though connection is terminated at Windows host. Linux OS does not terminate these idle connections as well. Investigation is still in progress. Most probably hotfix will be published once we get working solution for such corner cases.
Regards,
Alex6 -
Hello,
This solution works for us.
I thank you for your help.
0 -
Hello A-Grinkevitch,
is there a hotfix for the WinHTTP issue available?
We are running 3000 (non persistend) VDI Clients, with 5 FSPMP on Linux, and every night the first FSPMP has reached the max allowed open files (65536).
Side-Effect: If the FSPMP isnt responding, it seems the new born VDI machines arent imported in the PM, and are seen in the "Unmanaged" Tab.
I could reboot the service every night, but i prefer an out of the box experience
0 -
Hello HiggsBoson,
Fix will be available in PM/PMP 14.30 that is coming in two weeks. As an option, you can try PMP 14.30 Beta2 that is already available for downloads…Regards,
Alex1 -
Thanks alot!0
Categories
- All Categories
- 4.7K WithSecure Community
- 3.6K Products
- 1 Get Support