

However, on WSL this isn't possible, which means that Apt data can be corrupted more easily. On a physical/virtual machine, the unattended-upgrade-shutdown can inhibit shutdown until the unattended upgrade is complete. The host OS, a wsl -shutdown (or -terminate) or any of a number of things could cause the WSL instance to stop while in the middle of a background/unattended upgrade. As such, I'd always be worried about an interrupted upgrade happening in the background. They are more like Docker containers running a distribution. WSL instances aren't designed to be long-running, always-on environments. it sounds like cron isn't running at all, which is to be expected under WSL.īut before I present any possible solutions, let me suggest that you probably shouldn't do this on a WSL instance. It doesn't even log the echo execution entries You'll need to start cron some other way, since it's normally started by Systemd as well on Ubuntu. Unattended-upgrades, which was suggested in the comments and another answer, won't work. I go into detail a bit on this in an Ask Ubuntu answer and another on Super User, so I'm not going to deep into that again here. Or run yum makecache (from the other answers) which seems to remove the cache and pull down fresh copies right then.You're facing a couple of issues, both rooted in the fact that WSL doesn't run Systemd by default (or easily). Or change the metadata_expire parameter of yum.conf to less than the default 90min, I guess.

Because future yum commands refresh the cache, this is in practice the same as apt-get update. Use yum clean expire-cache (or yum clean all) first, then any future yum commands will auto-refresh the cache "when run.". You can see how long it will take before doing the "auto refresh" that all commands do underneath, by running this: yum repolist enabled -v This means that check-update is not performing an update, like apt-get update does. Loading mirror speeds from cached hostfile So if you run yum check-update and get this: $ sudo yum check-update Apparently its purpose is "know if your machine had any updates that needed to be applied without running it interactively" so basically it's "check if any packages are update-able" not "refresh the list of packages that I could update to" as you'd expect. Unfortunately yum check-update by default doesn't pull down changes from remote repositories until yum.conf's metadata_expire parameter has elapsed (default 90m).
