WebGUI Diagnostics->Command Prompt gets slow in 2.2.4 embedded



  • pfSense 2.2.4 embedded, fresh install
    HP t5740 Intel Atom, 2GB RAM
    Flash: new SanDisk microSD (8GB Class 4) in USB 2.0 card reader
    Packages: Asterisk, cron

    I ran 2.2.2 embedded for nearly two months (different SD card) and never experienced the following problem.

    On 08/08/15 I did a fresh install of 2.2.4 embedded to a new SD card.
    I restored my last saved config from 2.2.2.
    Everything seemed to work fine.
    I did not notice the slowness in things like config saves that many people have mentioned.
    On 08/09/15 SOME functions in Diagnostics->Command Prompt got very slow:

    • upload a file
    • execute an 'ls' command (went from ~5s to 52s)
      While waiting for the 'ls' command, Firefox status says "Waiting for 192.168.1.1"
      Other than that, the webGUI in general seemed to be working normally.
      On 08/10/15 I restarted the webConfigurator from SSH: no effect.
      I then rebooted pfSense: Diagnostics->Command Prompt 'ls' command went back to responding in ~5s.

    Anyone else seen anything like this?
    How would I troubleshoot this?
    Thanks!


  • Rebel Alliance Developer Netgate

    Probably the same issue that affects some flash media on 2.2.3 and later:
    https://doc.pfsense.org/index.php/2.2.4_New_Features_and_Changes#Security.2FErrata_Notices
    (5th main bullet point down)



  • @jimp:

    Probably the same issue that affects some flash media on 2.2.3 and later:
    https://doc.pfsense.org/index.php/2.2.4_New_Features_and_Changes#Security.2FErrata_Notices
    (5th main bullet point down)

    Hmm, I don't understand what an 'ls' command on a ro file system has to do with pending writes when there aren't any writes pending. Am I missing something here?

    If I recall correctly, ssh shell commands were responding normally when Diagnostics->Command Prompt commands were very slow, but I'll have to recheck this to be sure. If that's correct then I think that means it's a webGUI problem, not a flash problem.

    On the other hand, I do seem to recall one particular switch from rw to ro taking a long time.

    The next time this happens I'll try the following:

    • issue 'ls' command from ssh
    • switch nanoBSD from ro (normal) to rw, modify a file, switch to ro

    Please let me know if you have any other suggestions.

    BTW, forgot to mention: this is i386.


  • Rebel Alliance Developer Netgate

    Any command run via Diag > Command does a switch to rw first and then back to ro before returning.



  • @jimp:

    Any command run via Diag > Command does a switch to rw first and then back to ro before returning.

    Thanks, that solves the mystery of why Diagnostics->Command Prompt could be a lot slower than ssh shell running the same command.

    What I still don't understand is why switches from rw to ro can be fast (~5s) for a number of hours after booting and then get slow (52s) and stay slow until the next boot.