Starting with NetBackup 9.1, for security reasons, most services no longer run with root/administrative privileges and instead run as the non-privileged SERVICE_USER. A contributing factor is that NetBackup 9.1 no longer runs most services with root/administrative privileges.A contributing factor is that operating systems have always reserved the TCP ports below 512 for root/administrative processes.Windows: netstat -n -a -o, or netstat -n -a -b The root cause is that on some operating systems, the netstat output displays the first process to own a socket, not the current process to own the socket.There are several factors that contribute to this behavior. Notice that the source port and timestamps for the connection match the vnetd log snip above.ġ2/02/21 15:09:03.362 Starting acceptors. The nbpxytnl debug log confirms that the other process was the vnetd -proxy http_api_tunnel which is still alive and listening for connections after connecting to the vnetd -standalone service to have it perform the initial bind/listen. The tasklist and bpps show that several vnetd processes, including the listener PID 2856 and another PID 3340, started at that time.Ĭ:\Program Files\Veritas\NetBackup\bin>bpps | findstr vnetd fd = 960ġ5:09:04.238 ProcessRequests: msg Request VN_REQUEST_LISTEN_BIND(24)ġ5:09:04.238 process_legacy_ listen_request: protocol request_string ġ5:09:04.238 vnet_cached_getaddrinfo_and_update: found via getaddrinfo NAME=NULL SVC=443 IP=:: PORT=443ġ5:09:04.238 vnet_proxy_handoff_send: 0 of 4 PID bytes readġ5:09:05.238 ProcessRequests: status 0 0x0ġ5:09:05.238 ProcessRequests: msg Request VN_REQUEST_DISCONNECT(1) The request originates from another process on this same host, and the child exits after sending the listening socket back to the peer process and receiving a disconnect request.ġ5:09:04.160 vnet_pbxAcceptSocket_ex: Accepted sock from 127.0.0.1:51994ġ5:09:04.207 logparams: D:\Program Files\Veritas\NetBackup\bin\vnetd.exe -standaloneġ5:09:04.238 ProcessRequests: VNETD ACCEPT FROM 127.0.4 TO 127.0. The vnetd -standalone service (PID 2856) created a child (PID 6112), both privileged processes, to handle a listen and bind request for port 443. The missing PID is visible in the vnetd debug log, which confirms the process did exist briefly many hours ago.
#NETSTAT LISTENING PORTS WINDOWS#
Here the netstat command on Windows shows a process with PID 6112 listening on TCP port 443.Ĭ:\> netstat -nao | findstr LISTEN | findstr /C::443īut neither the Task Manager nor the tasklist command show a PID 6112 to be in existence. There is no error, but the situation can be confusing. Similarly (for all versions of NetBackup), netstat shows many other connections owned by pbx_exchange and vnetd, but the NetBackup debug logs show those connections being owned and used by other processes. Other times, the process may not be a NetBackup process or may be a seemingly randomly chosen process.
The displayed PID/process is sometimes not present in the process list (Solaris) or task list (Windows). After upgrading the primary server to NetBackup 9.1, the netstat output for the process listening on TCP port 443 appears to be wrong.
0 kommentar(er)
