pkg-static consuming 100% cpu

Grimson

I'm not sure since I've not confirmed it on multiple machines, but I can't reproduce it under FreeBSD 11.2 (clean install) so I'm not sure if it's a bug in FreeBSD rather than something specific when running pfSense.

Well the FreeBSD servers aren't down.

gonace

@grimson said in Pkg-Static 100% CPU:

@gonace said in Pkg-Static 100% CPU:

I'm not sure since I've not confirmed it on multiple machines, but I can't reproduce it under FreeBSD 11.2 (clean install) so I'm not sure if it's a bug in FreeBSD rather than something specific when running pfSense.

Well the FreeBSD servers aren't down.

Well, I blocked traffic to them and even blocked access to the internet on FreeBSD 11.2 (clean install) and did the same with a clean install of pfSense and the problem only arises on the clean install of pfSense.

Artichost

@p1ter It´s a handshake problem ;-)

veriqster

The BSD servers might be up but blocking access to them upstream would be equivalent to them being down. Can someone try to do just that?
Definitely a very disturbing oversight, makes me wonder what other things received the same level of attention :)

p1ter

@artichost Thank you. I mean can I fix it by myself?

Grimson

@veriqster said in Pkg-Static 100% CPU:

The BSD servers might be up but blocking access to them upstream would be equivalent to them being down.

That would make them completely unreachable, it currently looks like the pfSense servers hang/are very slow during the SSL negotiation which is a different situation. If you want to see the difference do a traffic capture instead of fooling around.

DougM

Hello from Brazil. Same here, pkg-static-update 100% usage cpu but the system looks functional.

mikekoke

Hello everyone,
I have the same problem but also the process /usr/local/sbin/pkg-static search -r to 100%

chance

I'm not an expert, but could one via ssh temporarily replace pkg-static with a shell script that basically does nothing? If so, can someone with more skills than myself show me the way?
-Chance

veriqster

then maybe someone should just pull the Ethernet plug out of them until things are sorted out instead of messing up with some systems that people depend on.
Honestly I would have said "shit happens, maybe they can just fix it going forward" but his attitude of leaving the servers on knowing it causes issues like this makes me wonder what other things are deemed as acceptable by "the man in charge", things that a dumb user like me might not be able grasp even by looking at the code (which I have neither time nor desire to dedicate myself to)

Rico

Guys, just disable the dashboard automatic update check, the process will disappear after some time. No reboot or anything is needed.
Yeah its annoying to eat one core after the update server broke, but not this dramatic.
I'm sure the Devs will fix this issue in future.

-Rico

gmjs

Identical issue with my copy of the community version here (2.4.4-RELEASE-p2, upgraded three times since installation).

I've killed off the pkg-static process with "kill" and disabled the "Dashboard Check" for updates. This seems to bring CPU usage back to normal, provided that I don't open the Update screen.

chance

I've done the following and corrected (temporarily) the 100% CPU.

Via ssh, I moved /usr/local/sbin/pkg-static to /usr/local/sbin/pkg-static.old and created /usr/local/sbin/pkg-static (a shell script) with the following contents.

while :
do
sleep 5000
done;

don't forget to chmod +x /usr/local/sbin/pkg-static

This has corrected my CPU usage until the servers are back up. I am not sure if this survives a reboot, but as such it's easy to implement.

amorphous

I disabled updates in the dashboard in /system_update_settings.php 30 minutes ago, no change. Did some of you guys had any luck with that?

Rico

Can take up to ~1 hour. But it will stop, trust me.

-Rico

amorphous

@rico It just did. I guess I didn't wait long enough. Thanks for the tip.

DougM

@rico Disable automatic update. Nice tip! Thanks from Brazil!

mikekoke

@rico said in pkg-static consuming 100% cpu:

Problem disappeared

chance

Package servers appear to be up now, at least from my location.

Rico

Same here, looks like back in business.

last pid: 92723;  load averages:  0.70,  0.34,  0.14  up 0+00:02:30    19:40:23
153 processes: 3 running, 103 sleeping, 47 waiting

Mem: 51M Active, 45M Inact, 70M Wired, 15M Buf, 286M Free
Swap: 102M Total, 102M Free


  PID USERNAME   PRI NICE   SIZE    RES STATE    TIME    WCPU COMMAND
   11 root       155 ki31     0K    16K RUN      2:01 100.00% [idle]
    0 root       -16    -     0K   224K swapin   0:26   0.00% [kernel{swapper}]
    4 root       -16    -     0K    32K -        0:01   0.00% [cam{scanner}]
   12 root       -60    -     0K   752K WAIT     0:01   0.00% [intr{swi4: clock (0)}]
  338 root        52    0 62804K 31748K accept   0:01   0.00% php-fpm: pool nginx (php-fpm)
  337 root        30    0 62804K 31876K piperd   0:01   0.00% php-fpm: pool nginx (php-fpm)
  339 root        52    0 65112K 33784K accept   0:01   0.00% php-fpm: pool nginx (php-fpm){php-fpm}
    4 root       -16    -     0K    32K -        0:00   0.00% [cam{doneq0}]
43971 root        20    0 23592K  8824K kqread   0:00   0.00% nginx: worker process (nginx)
   25 root        16    -     0K    16K syncer   0:00   0.00% [syncer]
40067 unbound     20    0 23664K 13920K kqread   0:00   0.00% /usr/local/sbin/unbound -c /var/unbound/unb
   15 root       -68    -     0K   160K -        0:00   0.00% [usb{usbus0}]
    0 root       -92    -     0K   224K -        0:00   0.00% [kernel{em0 taskq}]
   12 root       -88    -     0K   752K WAIT     0:00   0.00% [intr{irq17: mpt0 ehci0}]
28768 root        20    0  6900K  2312K nanslp   0:00   0.00% [dpinger{dpinger}]
44956 root        20    0 10352K 10468K select   0:00   0.00% /usr/local/sbin/ntpd -g -c /var/etc/ntpd.co
   15 root       -68    -     0K   160K -        0:00   0.00% [usb{usbus1}]
78824 root        20    0  6400K  2544K select   0:00   0.00% /usr/sbin/syslogd -s -c -c -l /var/dhcpd/va

-Rico