06.10.2018

Java: Slow java with server.policy enabled - how to fix this issue

If you use Java security manager for hardening your java processes, you have to add the following JVM options:
-Djava.security.manager
-Djava.security.policy=server.policy 
Create a server.policy file (you can use jdkXXX/jre/lib/security/java.policy as a tamplate) and add the following line:
permission java.net.SocketPermission "localhost:*", "listen, accept, connect, resolve"; 
Now create a small java program, which listens on a port (like this example).

If you send a message with netcat
nc -u localhost 9876
Everyhting is fine.
Now send a message from a remote host. This does not work - like expected.

Try it again with the following network tracing running (capturing all DNS packets):
tcpdump -i any port 53
Cool. For each connect a DNS-Lookup is done.
This could be a problem for high performance systems or for systems, which have to running/reachable DNS-Servers. In the latter case all requests will be sent to localhost:53 and of course, localhost will not give any answer. (This is not true - there will be a "ICMP - not reachable", but no DNS answer.).
If you add now line with *.*, to allow the connection the server.policy file should contain the following lines:
permission java.net.SocketPermission "*:*", "listen, accept, connect, resolve";
permission java.net.SocketPermission "localhost:*", "listen, accept, connect, resolve"; 
Hmmm. The connection is allowed, but there still DNS requests happening. The problem is that "*:*" is behind the "localhost:*" because Java reads this file from bottom to top - so if you write it this way:
permission java.net.SocketPermission "localhost:*", "listen, accept, connect, resolve";
permission java.net.SocketPermission "*:*", "listen, accept, connect, resolve";
there are no DNS requests happening anymore.

If you still see DNS requests: Take a look at this file:
YourJDK/jre/lib/security/java.policy
there are some entries with java.net.SocketPermission like:
permission java.net.SocketPermission "localhost:0", "listen";
 Because java first checks this file, you have to remove such lines, to get rid of the DNS requests.

If you do not need to use DNS, you should remove dns in /etc/nsswitch.conf. But, then no domain lookup will succeed  on this machine anymore...

28.09.2018

Linux: journalctl and systemd - better than /var/log/messages?

Nearly 8 years ago systemd was introduced on some Linux distribution (s. here). Last week i discovered some helpful commands, which i share with you.

If you want to take a look at kernel message (for example system boot), you command is
dmesg
The new equivalent is
journalctl -k
Ok - not really amazing.
But all of you know the message
See "systemctl status nginx.service" and "journalctl -xe" for details.
You can run the "systemctl start/restart/stop" and in case of error open the logs with "journalctl -xe". I would recommend to open a seperate shell and run there
journdalctl -f
This is something like "tail -f" to the systemd-journal.
If you do a "systemctl restart network" the shell with journalcctl -f shows the DHCP waiting for a answer from the server and you know why its so slow. You especially know, that your fifth interface has DHCP enabled and there is no DHCP, which slows down every "systemctl restart network".

journalctl has some nice filters like
journalctl -p 0..4
This just shows the message with
  • "emerg" (0), 
  • "alert" (1), 
  • "crit" (2), 
  • "err" (3), 
  • "warning" (4), 
  • "notice" (5),
  • "info" (6), "debug" (7)
Or filter for something like network messages:
journalctl -u NetworkManager

And my favourite: Pipe your own log messages into the systemd-journal:
echo This is important | systemd-cat -t MightyJournal -p notice
Which result in this entry:
Sep 28 20:48:55 zerberus MightyJournal[28520]: This is important

19.09.2018

Missing directory in /var/run or /run - tmpfiles.d

Sometimes is happens, that an application/demon refuses to start because of missing files/directories in /var/run.
The first solution is:
  • Create the directory in /var/run
  • Change the permissions
and everything is fine.

Not really.

After the next reboot, the directory is missing again and you have to go for the "first" solution again.

The right solution works like this:
Inside /usr/lib/tmpfiles.d create a myexample.conf file with this content:
        d /var/run/myexample 0755 schroff schroff -
To check if everything is ok run the following command:
        systemd-tmpfiles --create myexample.conf
and you will see:
# ls -l /var/run/ |grep mxexample
drwxr-xr-x  2 schroff schroff   40 19. Sep 22:45 myexample
And this directory will be created with each reboot...