Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Auto upgrade/notification with systemd timer/service units.

Share your HowTo, Documentation, Tips and Tricks. Not for support questions!.
Locked
Message
Author
Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Auto upgrade/notification with systemd timer/service units.

#1 Post by Deb-fan »

Well ... someone was asking in the forum about automatic upgrades/notification. Had been meaning to dork with it for awhile. Though popping open a terminal periodically and running "sudo apt update" etc isn't much bother. Still computers are meant to make life easier and being a dork why not. Here's what I cooked up ...

Involves 4-5 files, first open your file manager of choice with privileges or otherwise navigate to the following location /usr/local/bin and create two scripts, named mine autoup.sh and am using the terminator terminal emulator in it. Here's the contents.

Code: Select all

#!/bin/bash

CHK=$(apt list --upgradable | wc -l) 

	sudo apt update

if 	[ "$CHK" -gt "1" ]; then # If there's more than 1 line returned by apt list, there are upgrades available.

	terminator -e "bash -c 'sudo /usr/local/bin/autoup2.sh'"
fi
Notes, that sets a variable called CHK with a value of the command, above there wherever $CHK is used in the script it'll have a value of running the apt list --upgradable command and then this part "| wc -l" counts the number of lines returned. Can be whatever someone wants, I used CHK there as short for check and you can set other variables like that in the top of your scripts. Like it says further down if there's more than 1 line, then there's pending updates.

If the value of the CHK variable is -gt (greater than) 1 terminator opens and -e runs bash, which itself runs a command -c (the script.) It runs the other script we need to create here, named the one I used autoup2.sh and here's its contents.

Code: Select all

#!/bin/bash
echo
echo "* SYSTEM UPDATE: The following packages have upgrades available. *"

echo
apt list --upgradable
echo
echo
read -n1 -p " * To proceed with the system upgrade now ... Press 1. " UP 
echo

if [[ $UP =~ ^[1]$ ]]; then

	sudo apt -y upgrade -s

else

exit 0

fi

# Of course also remove the -s(simulated switch from the apt cmd above. So it actually does the upgrade.
As mentioned if the return of apt list --upgradable etc command is -gt 1, it runs this above script (autoup2.sh), displays which packages have updates pending and asks someone to press 1 to do the upgrade. Any other key closes the terminal. As noted when someone really gets ready to use this script, they need to remove the -s switch (as long as it's there, the script with only simulate doing the upgrade, not actually do it.) Comes in handy while testing and dorking with terminals until it's ready for prime time. Both these scripts need to be made executable, in terminal ie: "sudo chmod +x /usr/local/bin/*.sh" The -y switch in it just tells it not to bother asking for yes/no confirmation.

Okay next up it's time to add one of those, (the 1st script) to a file in sudoers.d, if you don't have one ... GOOGLE DAMMIT, ... it is a good idea to do a bit of research about sudoers.d for real, I created a file here named myrules it's located in the following directory /etc/sudoers.d and just to be excruciatingly anal ... Here's the contents of it, various stuff and scripts I've added to it, so that I can run sudo commands without having to enter a password. You of course don't need much of that ... Sheesh, some I don't use anymore ... anyway.

Code: Select all

# Adding some sudo commands I don't need passwd for.
your-user-name-here ALL=(ALL) NOPASSWD: /usr/sbin/pm-suspend, /usr/bin/renice, /sbin/iw, /sbin/iwlist, /sbin/iwconfig, /usr/bin/systemd-analyze, /sbin/reboot, /sbin/poweroff, /usr/bin/smem, /usr/local/bin/backup.sh, /usr/local/bin/pgov.sh, /usr/sbin/iftop, /usr/bin/eject, /usr/local/bin/rootfm.sh, /usr/local/bin/logout.sh, /usr/local/bin/autoup.sh 
You can see how the syntax goes, it's whatever scripts/cmds-etc, with a comma, then a space, followed by the next one. No need to (DONT) put a ,(comma) at the end of the last one and you can see that I added the path to the autoup.sh script as the last one above. I didn't need to add the one for autoup2.sh ...


Whew, we're getting there ... Next up ... Time to make more files at the following location /etc/systemd/system. Create two files here, one ending with .timer the other .service and name them the same thing. In my case that ended up being update.timer and here's the contents.

Code: Select all

[Unit]
Description=Timer to help update junk.
Requires=update.service

[Timer]
OnCalendar=*-*-* 18,22:30:00
Persistent=true

[Install]
WantedBy=timers.target 
The other named update.service and it's contents.

Code: Select all

[Unit]
Description=auto updates via script
After=graphical.target 
Wants=network-online.target update.timer

[Service]
Type=simple
User=your-user-name-here
Environment=DISPLAY=:0
Environment=XAUTHORITY=/home/your-user-name-here/.Xauthority
ExecStart=/bin/bash -c 'sudo /usr/local/bin/autoup.sh'

[Install]
WantedBy=graphical.target
Some explanations as to the units above. They don't need to be chmoded, after adding and getting them setup run "sudo systemctl daemon-reload" which an admin has to do after any changes to these/any unit files and enable/start the timer unit. With the following command "sudo systemctl enable update.timer" and likewise for start. Noted I also did add the 1st of the scripts /usr/local/bin/autoup.sh path to my file in /etc/sudoers.d/myfile. So no passwd for sudo required. It's actually a good idea to open a terminal while in /usr/local/bin and check file ownership with ie: "ls -l" .... If needed chown them to user/group root "sudo chown root:root *.sh". Did so and noticed a couple of the scripts here were owned by my user. Just felt better chown'ing them to root user instead. As things stand the timer is set to run at 10:30pm and 6:30pm as per the following line in it. It also runs initially at reboot/boot.

OnCalendar=*-*-* 18,22:30:00

00:00:00 is midnight = otherwise it's just military time, 12:00:00 is noon, 18:30:00hrs = 6:30pm. Clearly you can set them to run more than once by separating in this case, the hour field with comma's.
Clarification: This 18,22:30:00 ... 22:30:00 = 10:30pm, then the next one as shown, add a ,(comma) and 18:30:00 there = 6:30pm
Was pretty weird at first and will help a person to keep fiddling with the timer units time settings, then "systemctl daemon-reload" and checking the changes as to when the timer unit is next going to be run with "systemctl status update.timer" Will use that to track them for awhile and make sure they're functioning properly. Running on schedule and successfully completing. As of yet, it's only ran a couple times but appears to be doing fine.

Another handy command seems to be "systemctl list-timers" will display all timer units active on the system. As will "systemctl status *.timer" Shows the active timer units and when they're sched to run. Also it's good to know you can check your service unit, by running it manually at any time "sudo systemctl start update.service". At some point will get around to setting it to only 2-3dys per wk, as twice daily and at system start is kind of overkill for Debian stable. Plenty of info about what the different time fields in a systemd timer mean and timer units overall. Though am still nowhere near a guru about any of it. Got a helluva headache by this point but shared.

None of this comes with express/implied warranty of course. Took pains here but there you have it. Hopefully helps people out, at least and gives them a good trick or 3. That's a wrap. :D
Last edited by Deb-fan on 2021-06-08 09:52, edited 6 times in total.
Most powerful FREE tech-support tool on the planet * HERE. *

User avatar
dilberts_left_nut
Administrator
Administrator
Posts: 5346
Joined: 2009-10-05 07:54
Location: enzed
Has thanked: 12 times
Been thanked: 66 times

Re: Auto upgrade/notifiction with systemd timer/service unit

#2 Post by dilberts_left_nut »

Or ... 'apt install unattended-upgrades'
AdrianTM wrote:There's no hacker in my grandma...

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Auto upgrade/notifiction with systemd timer/service unit

#3 Post by Deb-fan »

^LMAO ... true. :D As usual with Nix, no shortage of ways to go about just about anything. Thought about a couple/few other routes, could've been all of 5 lines in a script + crontab or several other easy ways. No need of installing anything. Still can't hurt to explore some of the mysteries of systemd and these timer things. I'm suing Redhat for a throbbing headache or would but hey I really like systemd. Technically it's probably not their fault I swilled down 1 1/2gal of coffee either. Will have to let it slide this time I guess. :P Thought there was some interesting stuff involved too though.
Most powerful FREE tech-support tool on the planet * HERE. *

User avatar
Bloom
df -h | grep > 90TiB
df -h | grep > 90TiB
Posts: 504
Joined: 2017-11-11 12:23
Been thanked: 26 times

Re: Auto upgrade/notifiction with systemd timer/service unit

#4 Post by Bloom »

Simply doing "apt list --upgradable" only gives a valid result if you did an "apt update" first.
Then you could get the number of packets to update by this code:

Code: Select all

sudo apt update 2>/dev/null|grep upgradable|cut -d' ' -f1
In a bash variable:

Code: Select all

CHK=$(sudo apt update 2>/dev/null|grep upgradable|cut -d' ' -f1)

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Auto upgrade/notifiction with systemd timer/service unit

#5 Post by Deb-fan »

You'll notice in the first script it does do "sudo apt update" The CHK deal is command substitution as outlined to return the number of lines in the full command and that's set as the value of $CHK. Ah no worries. Hopefully some nuggets and interesting stuff in there.

I like it better than bothering with whichever ready made apps. Though really doesn't matter regardless. Not like any approach is very taxing on even oldish hardware. Personally can't imagine what's wrong with "sudo apt update && sudo apt upgrade" couple times a week but again ... whatever. Actually had to wait a couple days for an upgrade to show up to test on, DAM you Debian !!! :D So stable, no endless flood of stuff coming down the pipe !!! Point was messing with it and thought some cool stuff there.
Most powerful FREE tech-support tool on the planet * HERE. *

User avatar
Bloom
df -h | grep > 90TiB
df -h | grep > 90TiB
Posts: 504
Joined: 2017-11-11 12:23
Been thanked: 26 times

Re: Auto upgrade/notification with systemd timer/service uni

#6 Post by Bloom »

My code gives you in CHK the number of packets that can be upgraded. So if it is at least 1, you have something to upgrade.

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Auto upgrade/notification with systemd timer/service uni

#7 Post by Deb-fan »

^ OMG man, did you not read or are you not capable of grokking what's in the OP ? What does it say, if there's more than 1 friggin line = avail upgrades. Crap wasted a couple hours even posting. Not a hey, cool enough, some interesting stuff. A why not install xyz, that does something I could already do a dozen ways in a couple lines in a script.

No ... alright, some useful bits, instead a use my longer cmd to do what the feck you already painfully outlined to begin with !!! Arghhh, it's beer oclock. Though mostly bother/ed posting for the people who actually know how to use search engines, do google their friggin error msgs etc and don't waste time in Nix forums. :D Beer ... COME TO ME !!! Though chit ... dump some time trying to share some interesting stuff and WHAM, instant bad mood.
Most powerful FREE tech-support tool on the planet * HERE. *

User avatar
Bloom
df -h | grep > 90TiB
df -h | grep > 90TiB
Posts: 504
Joined: 2017-11-11 12:23
Been thanked: 26 times

Re: Auto upgrade/notification with systemd timer/service uni

#8 Post by Bloom »

Your script does the apt update AFTER the apt list --upgradable, that's why it doesn't work properly.

To determine if there is something to upgrade, I showed you and the other readers a method where that can be done with just apt update.

In any case, if you want a list of packages to upgrade, you can get those with apt list --upgradable, but you need to do the apt update first or the result will be invalid.

Deb-fan
Posts: 1047
Joined: 2012-08-14 12:27
Been thanked: 4 times

Re: Auto upgrade/notification with systemd timer/service uni

#9 Post by Deb-fan »

^ Man you're dense ... that is all. It's still beer-thirty. :)
Most powerful FREE tech-support tool on the planet * HERE. *

User avatar
Bloom
df -h | grep > 90TiB
df -h | grep > 90TiB
Posts: 504
Joined: 2017-11-11 12:23
Been thanked: 26 times

Re: Auto upgrade/notification with systemd timer/service uni

#10 Post by Bloom »

And you're impolite. Your first code segment begins with this:

Code: Select all

#!/bin/bash

CHK=$(apt list --upgradable | wc -l)

   sudo apt update
And that is the error. You do 'apt list' first and then 'apt update'. The value of CHK will not be what you expect. Reverse those two commands and it will. Who's dense?

User avatar
4D696B65
Site admin
Site admin
Posts: 2696
Joined: 2009-06-28 06:09
Been thanked: 85 times

Re: Auto upgrade/notification with systemd timer/service uni

#11 Post by 4D696B65 »

Deb-fan, insulting the person who is helping you is never a good idea.

Locked