OpenSuse 13.1/x86_64 kde 4.11.5 systemd 208
So, I wrote a script to do some things anytime there is a software update.
This is just for grins, mostly to get familiar with how systemd works, the script isnt really necessary in daily life.
But what it does is anytime there is a SW update it checks /boot and updates the soft links (config, System.map, initrd, vmlinuz) to point to the latest kernel.
I made a service file that has these attributes (i did run systemctl enable and is enabled ok):
I see on reboot this gets called ok, but it isnt called when i do a software update
My script does not daemonize, i expect that systemd would run it when necessary- Am I correct about this?
The script runs, does its thing then exits in less than a second.
Why isnt this being called after system update? (the T thingy on the kde task bar that installs new kernels and SW etc)
well, i get that odd looking icon (I’m not sure whats its depicting there but it looks like a Y or a T in a circle with little sticks sticking out of the circle) on the task bar in KDE and it shows a list of updates available and when you click install it does the updates. I believe its some kind of gui wrapper for apper - not sure. But what I would like to happen is that after thats finished for systemd to run my service
The crucial thing is of course what system-update.target is defined to be.
When I read through the man pages, a target is to define group of services to be started during e.g. boot (very rough explanation, please read for yourself).
There is indeed a update-system.target:
boven:/usr/lib/systemd/system # cat system-update.target
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=System Update
Documentation=http://freedesktop.org/wiki/Software/systemd/SystemUpdates
Documentation=man:systemd.special(7) man:systemd-system-update-generator(8)
Requires=sysinit.target
Conflicts=shutdown.target systemd-readahead-collect.service systemd-readahead-replay.service
After=sysinit.target
Before=shutdown.target
AllowIsolate=yes
boven:/usr/lib/systemd/system #
I must admit that I can not explain fully from this when it is triggered, but I also do not read from this where your assumption that this should be triggered when some/any package(s) on your system is installed/updated/removed using what (libzypp?), is based on
> I must admit that I can not explain fully from this when it is
> triggered, but I also do not read from this where your assumption that
> this should be triggered when some/any package(s) on your system is
> installed/updated/removed using what (libzypp?), is based on
The wiki link in there explains it. It does some type of off-line
updates. I don’t think it is used on openSUSE.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Here are some guidelines how to implement “offline” OS updates with systemd. By “offline” OS updates we mean package installations and updates that are run with the system booted into a special system update mode, in order to avoid problems related to conflicts of libraries and services that are currently running with those on disk.
For me it is for sure that updating with Apper/Packagekit/YaST/zypper does not fall in the category “offline” OS updates. Thus the whole exercise is useless.
Ok, so, is there a way to trigger this service after a SW update?
Or, another idea I had was to have this run on reboot/shutdown. But I tried it and couldnt get it to work.
Is there an example somewhere of a service running a simple oneshot task right before shutdown/reboot? Maybe I could use that for a model.
For this you first have to define what exactly is a SW update. When you know that you can try to trigger something (like creating a file) when that SW happens.
You might think that I am pedantic (and I am), but the longer I contemplate on what should and what should not be included in the definition of “SW update”, the more I hesitate. Maybe you don’t.
To me it looks that /usr/lib/systemd/system-shutdown has something like that. Thus creating e/tc/systemd/system-shutdown and adding something there might work. But it is you that should study how systemd works and how to add changes in a correct way. I didn’t, so the above is only a wild suggestion.
> And that starts with:
>> Here are some guidelines how to implement “offline” OS updates with
>> systemd. By “offline” OS updates we mean package installations and
>> updates that are run with the system booted into a special system update
>> mode, in order to avoid problems related to conflicts of libraries and
>> services that are currently running with those on disk.
> For me it is for sure that updating with Apper/Packagekit/YaST/zypper
> does not fall in the category “offline” OS updates. Thus the whole
> exercise is useless.
Not exactly. The updates could be prepared with zypper or whatever, if
zypper is modified to support this mode, which currently is not. I think
that this is a feature that systemd people have prepared for the future;
now the ball is on the rpm side of the field, to make use of this and go
ahead.
It is similar to what Windows does routinely: some updates are
downloaded and prepared, but the actual installation happens during
shutdown and reboot.
In openSUSE, some thing like this is done with the DVD, with the system
offline upgrade procedure. Currently you have to boot the DVD, run the
upgrades, then reboot the machine.
With systemd feature, you would prepare the updates/upgrade with the
machine running, and then reboot in an instant to apply.
It is not possible at the moment, it is rather work in progress.
On 2015-06-19 14:46, erbenton wrote:
>
> Ok, so, is there a way to trigger this service after a SW update?
Currently, no.
Maybe you can hook a script called from zypper. I don’t know if it
supports those hooks. Somebody asked about this not many months ago. But
it is not via systemd at all.
> Is there an example somewhere of a service running a simple oneshot task
> right before shutdown/reboot? Maybe I could use that for a model.
First, re using system-update.target, Read the Docs!
hcvv posted the Unitfile, and like all core systemd Unit files, there is an entry that describes a link to the online docs. http://freedesktop.org/wiki/Software/systemd/SystemUpdates/
Seems to describe everything from how it works to comparing it to other methods.
The small part that seems to be skimmed over is your method for obtaining updates which of course will be based on your repo.
Since most distros’ update tools not only manage which files to download but also perform an online install immediately which in most cases won’t require a reboot (unlike system-update.target which will require 2 reboots), although it might be considered a more secure way to apply updates, most Users will balk at the idea of 2 required reboots.
Maybe this might be useful in an Enterprise which might want to test updates first, then serve those updates in a network share instead of a repo, then a client machine could download the specified packages and install using systemd. But, those 2 reboots! Just run zypper against those packages and that might be better…
If it doesn’t already exist, it would be next to trivial to create a “zypper service” to do what the OP requests…
So, for example…
If you’re going to implement something like zypper, here is the general approach you’d probably want to follow…
If you’re going to create an updating app using zypper, you’ll probably first want to disable apper if it’s not already.
Decide how you want to trigger your soon-to-be custom update service. You can trigger off a bootup (multi-user.target? or something else? Depends on your desired timing). Or maybe check periodically (timers.target? Noting that cron is being deprecated)
Create your custom systemd app or service by inspecting, then copying a Unit file which does something similar from /usr/lib/systemd/system/ to /etc/systemd/system/ and rename it for your own. Never modify the original Unit file you’ve only used for a template, only play with the copy in the location I described. This way you never damage your system because if you ever want to revert to what was working, just disable or delete your copy and reboot. If your copy is left the same name as the original, your copy as long as it exists will over-ride the original.
Edit your custom Unit file setting your chosen trigger and setting the Unit file to invoke the functionality you want which can be your custom script, a binary, other Unit files, whatever. In your case, you might be able to design a zypper command (maybe only “zypper up”?) so just invoke that directly. If you want to pull in strange stuff from non-openSUSE type repos, you can do this too (maybe tar files or whatever?). An example might be what one company is currently using appstream, to import updated database data. You have the power to update anything.
Depending on how your custom Unit file is invoked, you may want to “enable” it to run as a service. This won’t make much sense if triggered by a bootup but would make sense if you’ve set to be invoked by timers.target.
Hmmm…
For those who have problems with Apper and want an automated zypper instead, maybe this could be a popular alternative…
You need to “enable” a Unit to daemonize/run as a service. Just declaring in the Unit file is not enough.
I don’t see how you are triggering by a SW update, is this your confusion about using system-update.target which isn’t approriate (read the docs)? Are you confusing with Apper?
Sure, look e.g. at systemd-reboot.service, it runs immediately before reboot
On a more serious note - your service should have DefaultDependency=no, should be WantedBy shutdown.target or similar (shutdown.target is generic enough). If you want this service to be run after everything else is stopped, it should be After=shutdown.target Before=final.target. But please note, that it also means that most of filesystems are unmounted as well (basically, only / and possibly /usr should be present at this point). If you need to ensure filesystems are present, you could make your service to run Before=shutdown.target, but then it will run concurrently with stopping other services.
On 2015-06-19 17:26, tsu2 wrote:
> robin_listas;2715923 Wrote:
> First, re using system-update.target, Read the Docs!
> hcvv posted the Unitfile, and like all core systemd Unit files, there is
> an entry that describes a link to the online docs.
> http://freedesktop.org/wiki/Software/systemd/SystemUpdates/
part that seems to be skimmed over is your method for obtaining updates which of course will be based on your repo.