Cron installed but not enabled

Issues & Assistance Unsupported Software (AUR & Other)
1

Hi,

Bare with me, i am not the person to post on forms and i am not exactly sure if this is even the right place to post

The Problem i found:

Cronie was installed by something in the welcome screens when i first installed my systems (my guess based on logs ) but not enabled or active.

i found this on both of my machines but the info below is from my desktop i use for testing

My System info

Garuda (2.6.14-1):
System install date:     2022-03-21
Last full system update: 2023-01-19 ↻
Is partially upgraded:   No
Relevant software:       snapper NetworkManager mkinitcpio
Windows dual boot:       Probably (Run as root to verify)
Failed units:            shadow.service

# /var/log/pacman.log
[2022-03-21T14:58:42-0600] [PACMAN] Running 'pacman -Su --needed appmenu-gtk-module ark bluedevil brave-bin breeze breeze-gtk
code colord-kde discord discover dolphin-plugins drkonqi evolution ffmpegthumbs filelight garuda-wallpapers-extra gnome-firmwa
re gwenview hypnotix icoutils kaccounts-providers kactivitymanagerd kamera kamoso kate kcalc kcron kde-cli-tools kdeconnect kd
ecoration kdegraphics-thumbnailers kde-gtk-config kdenetwork-filesharing kdeplasma-addons kde-service-menu-reimage kde-service
menus-encfs kde-servicemenus-komparemenu kde-servicemenus-officeconverter kde-servicemenus-pdf kde-servicemenus-pdf-encrypt-de
crypt kde-servicemenus-sendtodesktop kde-servicemenus-setaswallpaper kdf kdialog keditbookmarks kfind kgamma5 khelpcenter khot
keys kimageformats kinfocenter kio-extras kio-fuse kio-gdrive kipi-plugins kleopatra kmenuedit kompare konsole krdc krename kr
fb kscreen ksshaskpass ksystemlog kwalletmanager kwrited milou obs-studio octopi okular packagekit-qt5 partitionmanager plasma
-browser-integration plasma-desktop plasma-disks plasma-firewall plasma-integration plasma-nm plasma-pa plasma-systemmonitor p
lasma-thunderbolt plasma-vault plasma-workspace plasma-workspace-wallpapers polkit-kde-agent powerdevil printer-support print-
manager python-adblock qt5-imageformats quota-tools qutebrowser resvg rootactions-servicemenu ruby samba-mounter-git samba-sup
port scanner-support shortwave signal-desktop skanlite smb4k smplayer smplayer-skins smplayer-themes spectacle streamlink-twit
ch-gui systemsettings torbrowser-launcher vim virt-manager-meta yakuake zoom'
...
...
...
[2022-03-21T15:01:00-0600] [ALPM] installed cronie (1.5.7-2)

Background

i wanted to create a cron script that runs garuda-update updated everyday and if the kernel was updated reboot. so being a good system admin i went to google and stack overflow and got nowhere =D so custom script FTW i went to /etc saw a bunch of cron folders (cron.hourly cron.daily ect...) made my dumb little script put it in cron.daily next to an existing /etc/cron.daily/snapper that was there checked make sure it should reboot my system and waited for cron/anacron to do its thing and nothing happened

so after some banging around on the arch wiki i found how it does cron scheduling and did some packages searching saw that cronie was already installed... WIN!!! ..from there i checked systemctl status cronie and it wasnt active or enabled .. BINGO! a couple of commands later and its enabled and seems to be working ok

So why this post?

so ya my problems fixed moving on with life ...but what about that snapper cron script ...what else was now going to run

# find /etc/cron* -type f

/etc/cron.d/0hourly
/etc/cron.daily/snapper
/etc/cron.daily/z_garuda-update # this one is my lazyness 
/etc/cron.deny
/etc/cron.hourly/0anacron
/etc/cron.hourly/snapper

well the snapper stuff seems fine but the rabbit hole i am not sure is there is some systemd-timer set up for snapper

# systemctl list-timers

NEXT                        LEFT               LAST                        PASSED             UNIT                           >
Fri 2023-01-20 11:54:09 MST 47min left         Thu 2023-01-19 18:53:39 MST 16h ago            updatedb.timer                 >
Fri 2023-01-20 16:33:10 MST 5h 26min left      Thu 2023-01-19 16:33:10 MST 18h ago            snapper-cleanup.timer          >
Fri 2023-01-20 16:38:26 MST 5h 32min left      Thu 2023-01-19 16:38:26 MST 18h ago            systemd-tmpfiles-clean.timer   >
Sat 2023-01-21 00:00:00 MST 12h left           Fri 2023-01-20 00:00:04 MST 11h ago            logrotate.timer                >
Sat 2023-01-21 00:00:00 MST 12h left           Fri 2023-01-20 00:00:04 MST 11h ago            shadow.timer                   >
Sat 2023-01-21 08:28:40 MST 21h left           Fri 2023-01-20 02:16:48 MST 8h ago             man-db.timer                   >
Sun 2023-01-22 09:43:12 MST 1 day 22h left     Tue 2022-12-20 09:41:43 MST 1 month 0 days ago archlinux-keyring-wkd-sync.time>
Wed 2023-02-01 00:00:00 MST 1 week 4 days left Sun 2023-01-01 00:00:29 MST 2 weeks 5 days ago btrfs-balance.timer            >
Wed 2023-02-01 00:00:00 MST 1 week 4 days left Sun 2023-01-01 00:00:29 MST 2 weeks 5 days ago btrfs-defrag.timer             >
Wed 2023-02-01 00:00:00 MST 1 week 4 days left Sun 2023-01-01 00:00:29 MST 2 weeks 5 days ago btrfs-scrub.timer              >
Wed 2023-02-01 00:00:00 MST 1 week 4 days left Sun 2023-01-01 00:00:29 MST 2 weeks 5 days ago btrfs-trim.timer               >

Questions?

  • Do i need remove the snapper crons or the snapper systemd-timers?
  • does the cron do the same thing as the timers? (im not a fan of systemd troubleshooting so im hoping someone knows)
  • Am i better off disabling cronie and figure out how to get a systemd-timer to run my script?
  • Should cronie have been enabled by default with snapper ?

Side note: why a update script ?

i am lazy and i forget to update my machine. so far ive used it for the last 3 weeks manually and it seems to work fine. hence my idea about putting it in cron i couldnt find a solid way to do unintended-upgrades or needs-reboot and my trust in the aur is not great so i avoid it when i can.

Sign off

Again sorry for the post. i know its long but im hoping i given enough info of what i see with both of my garuda machines. not 100% sure its a bug or by design. ive only used Garuda for 18 months or so (25+ year desktop linux user) and ive been really happy. it seems stable and other then needing to use the boot repair utility from the iso a couple of times from bad grub updates that didnt seem to be a Garuda isolated issue... totally off subject that boot repair utility is GREAT!!!! dont know if that is a Garuda only thing. but whoever created that, i owe them a beer/coffee)

TM

4 Likes
2

I wouldn’t have both, but an important note is that you will need to remove them permanently some way. A package update will just restore the cron entries for example.

Yes. But in general I personally prefer the systemd timers, cron is just bloat nowadays to be honest.

Absolutely!

No.

You really really should not rely on an update script. garuda-update itself and pacman (which is run by it in addition to its own routines) output terminal text that is intended to be read and understood by the user and may at times, although we try to avoid it as much as possible, require manual intervention.
But if you absolutely have to, use garuda-update --noconfirm, but there is no guarantee that it will be able to successfully update your system and might just exit out in failure if pacman requires user input that garuda-update can’t automatically handle.

7 Likes
3

Don’t forget to reboot after your update. :slight_smile:

2 Likes
4

Hi there, welcome to the community

One of the best formatted posts. Kudos XD

Apart from @ TNE's answer, it's worthy to link an Archwiki article, that you should read once
https://wiki.archlinux.org/title/Systemd/Timers#As_a_cron_replacement

There are not much benifit of using cronie over systemd, except if you need the MAILTO function specifically. So yes, systemd timers should be better in my humble opinion

4 Likes
6

@TNE Thanks , i will fudge with systemd timers and see if i can get it play nice and disable cronie. i guess i should of said my script runs garuda-update and then checks if the kernel is updated but not running and if kicks off a reboot 15min timer(gives me time to cancel it if i need too ) i added the --noconfirm config option in /etc and would just run garuda-update && reboot at least one time a week (ish) for the last 3 months .. normally its 200 ish updates and the output is a blur at that point and just went by the return code echo $?

@FGD hehe yep i was hoping that the cron would of rebooted it at 3am and as i was working on what happened after i had my answer i wanted to write this post with actual screenshots..but no worries it will be rebooted at 5pm today when i finish working :smiley:

@Naman thank you, i realize my written english is not perfect so iim glad the post was ok and ty for the link i will be digging into timers over the weekend to see what it can do ...i set alot cron jobs in my day job so its gonna be a good education for myself

i realize hacking around the update process is not a great idea and i will still need to occasionally check the updates manually. i am just more concerned that im not doing them often enough letting them go a week sometimes 2 or 3. if the Garuda Team ever needs a beta tester for a more supported auto-updating process please reach out.

Note: to anyone else who come across this post, please don't do what i do for updates. please read the outputs and dont just pump it to reboot.. its not a good way to ensure stability of your install. i purposely keep my system stock and any changes i have documented and backed up and updating should be straight forward or if i need to nuke and repave if it goes south...that said i am really happy with garuda-update and my laptop was the first install has been my daily driver for over a year with no major faults minus the grub nonsense (not garuda issue)

Thank you everyone such a quick reply
TM

2 Likes
7

Update: i ended up using systemd-run to get up a initial file templates for the .timer and .service files and i then copied them from /run to /etc and added the [install] section made some other changes and it seems to be working it rebooted the machine and it still working thank you again for the direction and guidance

1 Like
8

In and of itself, this is typically not problematic. Updating every day is not necessary, unless you are installing new packages.

You run the risk of encountering issues by installing new packages while the system is out of date. As long as you bring your system up to date before you install something, you do not need such an aggressive update routine. It’s not a big deal to go a week or a couple weeks between updates if you are not introducing any package changes in between.

3 Likes
9

This is a very poor update strategy, and I implore other users to not follow the way this is implemented.

:-1:

1 Like
14

I 100% agree do not follow this implementation ... This is very dumb and not something ever to be done.

1 Like
15

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.