mrjpaxton

  • Posts

    12
  • Joined

  • Last visited

Reputation Activity

  1. Like
    mrjpaxton got a reaction from lanefu in Migrating the cron jobs to systemd timers   
    Hey,
     
    I have uninstalled cron from my system completely, but I just thought I might help contribute, even just a little, by making some services and timer files to replace the ones in these folders:
     
    /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly  
    Now keep in mind that I have not fully tested any of these yet! I would appreciate feedback in testing these, since most of these I won't even use on my system. I barely even use the armbian-config utility at all, so... yeah...
     
    The files in question are these. Let me know if I should add more:
     
    armbian-truncate-logs armbian-updates armbian-ram-logging  
    These are the Armbian specific ones. I know there's ones for like man-db, mdadm, logrotate, fake-hwclock and a bunch more that get installed by default. And I think systemd already has timer files for some of these. In fact, here's the timers in use on my Kobol system right now:
     
    # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sat 2021-09-11 18:43:28 PDT 13min left Fri 2021-09-10 18:43:28 PDT 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago logrotate.timer logrotate.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago man-db.timer man-db.service Sun 2021-09-12 05:57:58 PDT 11h left Sat 2021-09-11 17:25:28 PDT 1h 4min ago apt-daily.timer apt-daily.service Sun 2021-09-12 06:20:19 PDT 11h left Sat 2021-09-11 06:59:08 PDT 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service n/a n/a Sat 2021-09-11 05:57:28 PDT 12h ago update-ddns.timer update-ddns.service 6 timers listed. Pass --all to see loaded but inactive timers, too.  
    The "update-ddns" timer and service is my own custom one. The rest are defaults.
     
    So we'll start in order of shortest to longest activation times:
     
    armbian-truncate-logs (runs every 15 minutes)
     
    /etc/systemd/system/armbian-truncate-logs.timer
    [Unit] Wants=armbian-truncate-logs.service [Timer] OnActiveSec=15m [Install] WantedBy=timers.target  
    /etc/systemd/system/armbian-truncate-logs.service
    [Unit] Description=Truncate the Armbian log files [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-truncate-logs [Install] WantedBy=multi-user.target  
    armbian-updates (runs daily and on boot up)
    Note: We are going to change this to run after the network is brought Online, but still make it run daily.
     
    /etc/systemd/system/armbian-updates.timer
    [Unit] Wants=armbian-updates.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target  
    /etc/systemd/system/armbian-updates.service
    [Unit] Description=Check for updates on the Armbian system After=network-online.target [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-apt-updates [Install] WantedBy=multi-user.target  
    armbian-ram-logging (runs daily)
    Note: It is mentioned that this cron job should only run when logrotate is a cron job. This was confusing wording at first, because it doesn't tell you if it prefers to either have logrotate as a systemd timer, or if logrotate should not run at all.
     
    After looking inside the script "/usr/lib/armbian/armbian-ramlog", which passes "write" as the first argument, I tried to see if there was any problematic code that conflicts with logrotate...
     
    Using the "syncToDisk ()" function, it doesn't seem like it'd conflict with logrotate at first glance.
     
    Just to be safe, I've included the line "Conflicts=logrotate.service" just in case. If this can be safely removed, let me know.
     
    /etc/systemd/system/armbian-ram-logging.timer
    [Unit] Wants=armbian-ram-logging.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target  
    /etc/systemd/system/armbian-ram-logging.service
    [Unit] Description=Perform Armbian RAM logging Conflicts=logrotate.service [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-ramlog write [Install] WantedBy=multi-user.target  
    ---
     
    That's about it. Again, not sure if any of these should be set to "oneshot" or "simple" services, or if they need to be active "RemainOnExit" or whatnot. Just hope I can give a good template for converting cron jobs to systemd timers. It's a lot simpler than I thought to convert them.
     
    Have a wonderful day, Armbian team. And thank you for all you contribute to this project.
  2. Like
    mrjpaxton got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Well, here's my issue. I'd like to explain it.
     
    The problem was I wasn't even doing a full upgrade. I was just using "apt update; apt upgrade", and upgrading the system normally.
    So if even a normal upgrade breaks the system, there's something seriously wrong here...
     
    I don't know much about Debian's policies, but I do know a full distribution upgrade should only be done with "apt dist-upgrade" or "apt full-upgrade", and this policy wasn't respected. It would have been fine if the latest rockchip64 kernel image was held back before the upgrade, so that it had time to get bug fixes.
     
    Also, the version numbering is confusing. The version for "linux-image-current-rockchip64" is set to "21.08.01", but that's not what version the kernel is. Shouldn't it be "5.10.60-rockchip64". That might have helped me avoid this problem altogether, so at least I'd know what version of the kernel I was about to install. In other words, I had no idea "21.08.01" had the broken kernel "5.10.60-rockchip64".
     
    I know Armbian is different than Debian, but it really should play more nicely to what regular Debian users are used to, rather than deviating too much from it. It's one of the reasons why I chose Armbian! It is because I expected it 99% to work like Debian, except maybe for the fact that it uses a different kernel, DTD, maybe a BSP (base support package), U-Boot, and a few necessary patches.
     
    But changing how core OS updates and upgrades work is just wrong to me.
     
    A side note, I know U-Boot isn't GRUB, but it really would be nice to have support for multiple (backup) kernels like I'm used to on x86 with GRUB. It is different code, and a different arch, so I guess that makes sense though...
     
    Still a shame. I will look around and see if the solutions work. Otherwise, I'll try to use my full rsync backup.