search for: pidnum

Daniel, thanks so much for the detailed pointers. So it turns out to be both the evil that is systemd and an overzealous upgrade script. Apollon, should I raise a Debian bug for this? As for reasons, how do 50k proxy session on the proxy servers and 25k imap processes on the mailbox servers sound? Even on a server with just 6k users and 7k imap processes that causes a massive load spike and a

...something else connected to the pipe (antivirus heh?) and loiters there, or something else I could not think of quickly... The next clue could be to look at who is connected to the pipe file, maybe with `fuser`, or look in `ps -ef` if there are other `upssched` processes present, or look in `/proc/PIDNUM/fd/` of the daemonized and looping `upssched`... If anyone decides to track through the code, the potential processing loop goes checkconf -> conf_arg -> parse_at -> sendcmd -> daemon if needed -> start_daemon -> conn_add(pipefd) or sock_read(conn) with short-lived child proc...

...something else connected to the pipe (antivirus heh?) and loiters there, or something else I could not think of quickly... The next clue could be to look at who is connected to the pipe file, maybe with `fuser`, or look in `ps -ef` if there are other `upssched` processes present, or look in `/proc/PIDNUM/fd/` of the daemonized and looping `upssched`... If anyone decides to track through the code, the potential processing loop goes checkconf -> conf_arg -> parse_at -> sendcmd -> daemon if needed -> start_daemon -> conn_add(pipefd) or sock_read(conn) with short-lived child proc...

...to the pipe (antivirus heh?) and loiters there, or something > else I could not think of quickly... > > The next clue could be to look at who is connected to the pipe file, maybe > with `fuser`, or look in `ps -ef` if there are other `upssched` processes > present, or look in `/proc/PIDNUM/fd/` of the daemonized and looping > `upssched`... > > If anyone decides to track through the code, the potential processing loop > goes > checkconf -> conf_arg -> parse_at -> sendcmd -> daemon if needed -> > start_daemon -> conn_add(pipefd) or sock_read(conn...

...to the pipe (antivirus heh?) and loiters there, or something > else I could not think of quickly... > > The next clue could be to look at who is connected to the pipe file, maybe > with `fuser`, or look in `ps -ef` if there are other `upssched` processes > present, or look in `/proc/PIDNUM/fd/` of the daemonized and looping > `upssched`... > > If anyone decides to track through the code, the potential processing loop > goes > checkconf -> conf_arg -> parse_at -> sendcmd -> daemon if needed -> > start_daemon -> conn_add(pipefd) or sock_read(conn...

Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,

Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,