• Where did the day go? Down the rabbit hole of SysAdmin work and so, while not particularly wasted, wasn’t time well spent.

    It started when I decided to upgrade my server to Fedora 30, surprisingly enough, that went smoothly, took a coffee break and a lunch hour and everything came up smelling like a rose. I was due after last summer on the cosmic break board.

    While that was going on was going on I decided to post a blog entry and that was when I went down the rabbit hole. First I updated all the blogs and then turned to the article and started by heading off to download an infographic from a link I was emailed, but as it was a tracker, it was blocked by my Pi-hole. I attempted to temporarily disable the pihole and found I could not login via the web interface. Using SSH, I was able to determine I had run out of storage space…but why?

    I tracked it back to using the version of software, NOOBS that came with it. Lazy and as a result the 8GB card had only 5GB of storage and it was full with the base install. I certainly could have simply deleted a few of the apps (Mathematica and Wolfram Alpha being the largest unused apps I generally pull off) but as it is a rainy day, I optimistically put off gardening to between showers, little sensing how long this was going to take to put a clean copy of Raspbian on it.

    It went very slowly, I forgot why I like to pull of those apps, and that old memory card is left to a slow older standalong Pi duties like Pi-hole, the update took forever but eventually I was rewarded with a reloaded from scratch Pi-Hole with plenty of space.

    Now I was ready to make a blog entry and be quick about it as the update to Fedora 30, which takes at least a coffee break and full lunch to complete was already done. Except the Pi I used for the Pi-Hole to update wasn’t starting the HDMI. Aha I thought, the old HDMI recognition issue I thought, and sure enough the /boot/config.txt file was mangled slightly with a comment that NOOBS had made changes, argh, I might as well reload this one as the rain continued and so I did. It turned out that my new Pi case with a fan and everything has simply been reluctant to let the HDMI cable go all the way in and by the time I solved that I had updates going everywhere.

    So after all of that, I don’t have time to post the entry to the blog, didn’t get any gardening done, didn’t get to read a little, and I am back to where I was at the start of the day although up to date in a maintainable fashion.

    I suppose it is worth it; however, I have found that my view has completely changed. I no longer think it reasonable to spend time on System Administration, life is too short.

    Hmmmm.

  • I solved the problem where after an update tt-rss displayed a red box “Update Deamon not Running” [regrets for not having a screen shot of that].

    What I found, and I am sure it is in the documentation is that in the tt-rss/lock directory, there are two files: update_deamon.lock and update_deamon.stamp and mind had significantly different time stamps [ ls -l * ], one immediately after the update. I deleted them both and restarted my httpd.service and the deamon ran successfully after that.

    I would post this on a support forum or upvote wherever I found it; however, I just took a quick look around for an error log and lock files to warm up my awareness of key issues prior to checking those. Yeah me!

  • There is the theory that the HDMI output of the Raspberry Pi is only initialized if a monitor/television is connected and powered up before a Raspberry Pi 3 is turned on.
    Yet when I connect my Raspberry Pi 3 to a old Panasonic Plasma display the Raspberry Pi actually turns on the device and the screen activates every time.
    Not so with the Vizio P series I just hung on the wall.

    Aside: some of the Panasonic HDMI ports were damaged in a painting disaster…never use a 20lb weight to hold a tarp.

    With the Vizio, whether the monitor is on or off and the correct HDMI port is selected or not, the Raspberry Pi 3 simply never brings up HDMI output.

    Edit the /boot/config.txt file and uncomment these two lines

    #hdmi_force_hotplug=1

    #hdmi_drive=2

    And the device works every time from every state.  The first line is as it appears, the second activates HDMI and enables sound rather than DVI mode which does not.

    I did like that the Vizio takes edits the HDMI connection in its table to Raspberry

  • I am having backup problems, and was troubleshooting other issues earlier in the year, and my resolution at the semester was to export all the classes, create a clean database and reload the classes thereby getting rid of any cruft issues from a not-as-old-as-one-might-think Moodle setup.
    The day started easily but I kept getting a nagging feeling that the classes were to large and found a mdl_log table in the database with entries from years ago and quite a large number of them. Apparently Moodle upgraded and did not remove the old log. So I used TRUNCATE and emptied the table. Of course I had researched the table and implications, backed up the database and so forth.
    I then changed the log retention date to 2 days and ran cron repeatedly and was unable to trim the mdl_logstore_standard_log file at all and it was huge as well. I finally used TRUNCATE on that file as well.
    I am a week along and the log files are running fine, no logs are appearing in the old table and I am hopeful the current logs are being pruned in accordance with the configuration.
    I still haven’t resolved the backup issues and I am sure I have something else in the database and I pass on the obvious lesson that a Moodle site should be completely rebuilt annually, or on some regular schedule, to ensure that old data/tables are pruned or removed effectively.
    If I could just resolve the backup stretching out as well as the backups in some, but not all, classes being retained I would have this system under control. Soon though.

  • I am back to troubleshooting, yet again, the problem of Moodle backups taking forever and a day. An actual day, for very small courses.

    A second problem occurring with the automated backups is that the old backups are not being purged so the file system is filling up with them rather than purging/pruning them. I am solving the problem at present by a weekly manual clean up.

    I could simply pour over the forums for an answer, which has not produced results. I could look at tables/records in the actual database for anomalies and that strikes me as time consuming. Or I could wait until the semester break in two weeks and backup and export each class and all the information and create a brand new instance of Moodle and restore the classes into that and see if that leaves the cruft and problems behind.

    I am going with that alternative in the interests of cleaning up any other problems I am not yet aware of that affect other areas including performance.

    Will post my results.