2

We have a XYZ batch process that kicks of 2:00 AM every day. This XYZ is configured to starts on port 59070. Once it finishes this port is a open port. But recently we had a problem where, another process was using 59070 and when this XYZ process started, it failed to run.

As a workaround,we have updated the configuration to different port 59071 and ran the process OK. My query is that, is there anyway,we can block this port 59070 & ensure no other process uses it? we are using Solaris 10.

| improve this question | | | | |
  • That's a really random port for a different process to use; are you that it wasn't being held by the previous batch run? My best suggestion off the cuff would be to write/use another program that grabs that port when the batch process ends and releases it as batch processing starts. – Jeff Schaller Oct 24 '16 at 0:18
  • If any of the existing answers solves your problem, please consider accepting it via the checkmark. Thank you! – Jeff Schaller Apr 23 '17 at 12:58
1

Port 59070 is an ephemeral port - one that can be used for outbound TCP connections by any process. (As is port 59071, so that's not really a good workaround...)

On Solaris, the ephemeral port range is set by the tcp_smallest_anon_port and the tcp_largest_anon_port tunable parameters. The default range is 32,768 to 65,535. Any port in that range may be in use at any time by an outgoing TCP connection.

As stated in @Jeff Schaller's answer, ports are used on a first-come, first-served basis, so the only way to "reserve" a port is to have something bound to it at all times. Note that in that answer, it's possible that another process could grab the port in question in the time between killing a "port saver" script and the "normal" process that uses the port actually bind()ing to it. It's not likely, admittedly, but it could happen. And if your processing is critical, I'd think you need to worry about that.

I'd recommend not using an ephemeral port and/or configuring your process to run all the time, or use inetadm to configure a service that runs your process automatically. That will cause the inetd process to bind to "your" port all the time, effectively reserving it for your use.

| improve this answer | | | | |
0

I'm not aware of a way to block a port from use, other than proactively using it yourself. The general idea I would put forth would be to change your batch processing to:

  1. kill off the "port saver" script

  2. run the normal batch processing

  3. start up a new "port saver" script

This work-around will help prevent a rogue process from binding to the port you want (a process could grab the port between steps 1 & 2 or between steps 2 & 3), but it will not prevent a mishap with the batch process where that batch process appears to end but does not release the port (by exiting all of its processes).

A sample "port saver" script, in perl, is:

#!/usr/bin/env perl
# listens on the given port
use strict;
use IO::Socket;

my $port = shift or die "Usage: $0 <port>";

my $socket = new IO::Socket::INET(
        LocalHost => '0.0.0.0',
        LocalPort => $port,
        Proto => 'tcp',
        Listen => 1,
        Reuse => 1,
        )
  or die "Cannot create socket: $!\n";

while (1) {
  my $c = $socket->accept();
  shutdown($c, 2);
}

You would need to either save the script's PID or find and kill it, as it runs an infinite loop while holding the given port open.

| improve this answer | | | | |
  • I have implemented this perl solution in our dev environment. Just a thought, is there a feasibility for us to block this port 59070 for our batch process by modifying /etc/services configuration ? I learnt today that ports for a service can be configured here... link so process port vs service ports is the doubt. – GurMan Oct 27 '16 at 2:05
  • No. that's just a name to port translation table. – Jeff Schaller Oct 27 '16 at 2:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.