# Sporadic DIS errors in Server\_Log **URL:** \ **Category:** Users/Site Administrators\ **Created:** [January 30, 2025, 12:37am UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077 "2025-01-30T00:37:39Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mgasp](https://avatars.discourse-cdn.com/v4/letter/m/3be4f8/32.png) [@mgasp](https://community.openpbs.org/u/mgasp)\ **Post date:** [January 30, 2025, 12:37am UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/1 "2025-01-30T00:37:39Z")
Seeing some sporadic DIS errors when -W block=True is requested: ./20250103:01/03/2025 14:19:32;0001;Server@sched;Svr;Server@sched;check\_block\_wt, DIS error while replying to client gitrun3 for job 164004.sched The job exits cleaning (status 0), but the submission terminal hangs as it didn’t receive a response from the Scheduler. I see this in the MOM logs: 01/28/2025 11:02:39;0080;pbs\_mom;Job;179807.sched;task 00000001 terminated 01/28/2025 11:02:39;0800;pbs\_mom;n/a;mom\_get\_sample;nprocs: 615, cantstat: 2, nomem: 0, skipped: 492, cached: 0 01/28/2025 11:02:39;0008;pbs\_mom;Job;179807.sched;Terminated 01/28/2025 11:02:39;0100;pbs\_mom;Job;179807.sched;task 00000001 cput=00:13:00 01/28/2025 11:02:39;0008;pbs\_mom;Job;179807.sched;kill\_job 01/28/2025 11:02:39;0100;pbs\_mom;Job;179807.sched;node9 cput=00:13:00 mem=1275332kb 01/28/2025 11:02:39;0100;pbs\_mom;Job;179807.sched;Obit sent 01/28/2025 11:02:39;0100;pbs\_mom;Req;;Type 54 request received from root@10.10.38.18:15001, sock=5 01/28/2025 11:02:39;0080;pbs\_mom;Job;179807.sched;copy file request received 01/28/2025 11:02:39;0800;pbs\_mom;Job;stage\_file;Skipping directly written/absent spool file /var/spool/pbs/spool/179807.sched.OU 01/28/2025 11:02:39;0800;pbs\_mom;Job;stage\_file;Skipping directly written/absent spool file /var/spool/pbs/spool/179807.sched.ER 01/28/2025 11:02:39;0100;pbs\_mom;Job;179807.sched;staged 2 items out over 0:00:00 01/28/2025 11:02:39;0800;pbs\_mom;n/a;mom\_get\_sample;nprocs: 616, cantstat: 2, nomem: 0, skipped: 492, cached: 0 01/28/2025 11:02:39;0008;pbs\_mom;Job;179807.sched;no active tasks 01/28/2025 11:02:39;0100;pbs\_mom;Req;;Type 6 request received from root@10.10.38.18:15001, sock=5 01/28/2025 11:02:39;0080;pbs\_mom;Job;179807.sched;delete job request received 01/28/2025 11:02:39;0008;pbs\_mom;Job;179807.sched;kill\_job ---
**Author:** ![dtalcott](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/dtalcott/32/410_2.png) [@dtalcott](https://community.openpbs.org/u/dtalcott)\ **Post date:** [January 31, 2025, 11:33pm UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/2 "2025-01-31T23:33:43Z")
> [@mgasp](#): > > Seeing some sporadic DIS errors when -W block=True is requested: > > ./20250103:01/03/2025 14:19:32;0001;Server@sched;Svr;Server@sched;check\_block\_wt, DIS error while replying to client gitrun3 for job 164004.sched This reminds me of a problem that used to exist if Security ran a network port scan against the qsub host while qsub was blocked. In testing just now, I was able to reproduce the qsub hang, but not the error message on the server. Can you check logs to see if a port scan was running at the times of the DIS errors? ---
**Author:** ![mgasp](https://avatars.discourse-cdn.com/v4/letter/m/3be4f8/32.png) [@mgasp](https://community.openpbs.org/u/mgasp)\ **Post date:** [February 1, 2025, 3:31pm UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/3 "2025-02-01T15:31:26Z")
Unfortunately i can’t find any evidence of a port scan in the logs. **I did notice server\_logs complaining about a low file limit (1024), and i increased that to 65536 which seems to have resolved the issue.** I tried to reproduce by running a repetitive netcat to the TCP ports used by qsub on the submission host, but wasn’t able to. ---
**Author:** ![adarsh](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@adarsh](https://community.openpbs.org/u/adarsh)\ **Post date:** [February 1, 2025, 7:51pm UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/4 "2025-02-01T19:51:23Z")
Just in case, the pbs\_comm daemons open file limit is dependent on the limits set at the operating system level. Having mentioned this , i have not seen this error regarding DIS , most of it was related to 1) what @dtalcott mentioned 2) different versions of the openpbs client commands in the mix or two incomptiable versions of the daemons. ---
**Author:** ![mgasp](https://avatars.discourse-cdn.com/v4/letter/m/3be4f8/32.png) [@mgasp](https://community.openpbs.org/u/mgasp)\ **Post date:** [February 3, 2025, 2:40pm UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/5 "2025-02-03T14:40:27Z")
Our PBS environment is homogenous at 20.0.1, we don’t have other versions installed. @dtalcott would you mind sharing how you were able to reproduce the DIS error? ---
**Author:** ![dtalcott](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/dtalcott/32/410_2.png) [@dtalcott](https://community.openpbs.org/u/dtalcott)\ **Post date:** [February 5, 2025, 12:52am UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/6 "2025-02-05T00:52:51Z")
I was unable to reproduce the DIS error message, just the qsub hang. And that was by a nc to the port qsub was listening on. Just for curiosity, how did you get more that 1024 active connections to the pbs server? That seems wrong. Can you run an lsof on the server to see why so many file descriptors are tied up? ---
**Author:** ![mgasp](https://avatars.discourse-cdn.com/v4/letter/m/3be4f8/32.png) [@mgasp](https://community.openpbs.org/u/mgasp)\ **Post date:** [March 11, 2026, 6:56pm UTC](https://community.openpbs.org/t/sporadic-dis-errors-in-server-log/4077/7 "2026-03-11T18:56:05Z")
This was due to this bug: [Scheduler server\_dyn\_res leaves trail of zombies depleting host PID space by alexis-cousein · Pull Request #2108 · openpbs/openpbs · GitHub](https://github.com/openpbs/openpbs/pull/2108). I had a script that ran to check a dynamic resource, and all these open procs were also keeping the file descriptors. This is fixed in PBS 23, which we’ve since upgraded to.