Re: Activation environment(s)?
On Mon, 08 Jan 2024 at 20:42:54 +0300, Vladimir Kudrya wrote: > On 08/01/2024 19.21, Mantas Mikulėnas wrote: > > The traditional dbus-daemon keeps a separate environment for services it > > spawns directly [...], though that it doesn't apply to services it runs > > via systemd so you need to keep both in sync. Actually, when you call the dbus-daemon's UpdateActivationEnvironment(), dbus-daemon >= 1.10.4 will try to upload the same variables to both dbus-daemon and `systemd --user`, keeping both environments in sync. `dbus-update-activation-environment --systemd` will also try to upload the same variables to `systemd --user` (which is redundant since 1.10.4, but it does it anyway, because it doesn't know whether the message bus it's talking to has this behaviour). I say "try" because in some corner cases, for example non-UTF-8 variable names or values, systemd and/or dbus-daemon will reject particular updates as not being valid. As far as I know, the other way round is not true: `systemctl --user set-environment`, `systemctl --user unset-environment` and their implementation UnsetAndSetEnvironment() will change the systemd activation environment, but will not do anything to the activation environment used by dbus-daemon for traditional D-Bus services (without SystemdService). > Is it possible to unset a variable from native dbus execution environment? It is not possible to unset a variable in the dbus-daemon's activation environment, or with `dbus-update-activation-environment`: that's an API limitation in the org.freedesktop.DBus interface. I've thought about adding an UnsetAndSetActivationEnvironment() that could do this. It *is* possible to unset a variable in the `systemd --user` activation environment, with `systemctl --user unset-environment` or the UnsetEnvironment() and UnsetAndSetEnvironment() D-Bus methods on the systemd manager. If your distribution is using dbus-broker rather than dbus-daemon, and if Mantas was correct to say that dbus-broker does not have its own separate activation environment, then that should be enough to affect all D-Bus session services. It will also affect all other systemd user services. smcv
Re: Activation environment(s)?
So I'm seeing an artifact of dbus-broker. Is it possible to unset a variable from native dbus execution environment? On 08/01/2024 19.21, Mantas Mikulėnas wrote: The traditional dbus-daemon keeps a separate environment for services it spawns directly (i.e. those that don't specify SystemdService= in their D-Bus .service files), though that it doesn't apply to services it runs via systemd so you need to keep both in sync. On the other hand, dbus-broker runs everything via systemd (using transient service units if necessary), and as far as I know it no longer keeps track of a separate activation environment and all changes are just directly forwarded to systemd's environment instead. It depends on which implementation your distribution uses.
Re: How to get service reload timestamp
On Mon, 8 Jan 2024 at 11:49, port19 wrote:
> Hi all,
>
> we currently have a monitoring check that alerts us of a service-specific
> config file having changed more recently than the services last restart.
> We retrieve the restart time via `systemctl show
> --property=ActiveEnterTimestamp`.
> Is there a comparably elegant way to retreive the reload timestamp?
> To avoid confusion, by reload I do not mean `systemctl daemon-reload`, I
> mean `systemctl reload `.
>
> Alternatively, is there a way to let systemd handle the reloading of
> services on change of related config files?
>
You didn't say what systemd version you use (mine is 255)
systemctl show httpd | fgrep -i rel
ReloadResult=success
ReloadSignal=1
ExecReload={ path=/usr/bin/httpd ; argv[]=/usr/bin/httpd -k graceful ;
ignore_errors=no ; start_time=[Mon 2024-01-08 17:08:45 GMT] ;
stop_time=[Mon 2024-01-08 17:08:45 GMT] ; pid=1476187 ; code=exited ;
status=0 }
ExecReloadEx={ path=/usr/bin/httpd ; argv[]=/usr/bin/httpd -k graceful ;
flags= ; start_time=[Mon 2024-01-08 17:08:45 GMT] ; stop_time=[Mon
2024-01-08 17:08:45 GMT] ; pid=1476187 ; code=exited ; status=0 }
ManagedOOMMemoryPressureLimit=0
CanReload=yes
So with a bit of awk you can get at it this way
failing that, every reload is actually done via an ExecReload command in
the service file, so you could intercept this with your own command instead
NeedDaemonReload=no
>
> Best,
> port19
>
Re: Activation environment(s)?
The traditional dbus-daemon keeps a separate environment for services it spawns directly (i.e. those that don't specify SystemdService= in their D-Bus .service files), though that it doesn't apply to services it runs via systemd so you need to keep both in sync. On the other hand, dbus-broker runs everything via systemd (using transient service units if necessary), and as far as I know it no longer keeps track of a separate activation environment and all changes are just directly forwarded to systemd's environment instead. It depends on which implementation your distribution uses. On Mon, Jan 8, 2024, 17:58 Vladimir Kudrya wrote: > Hello. > > In context of a modern systemd-managed user session, is there a separate > dbus activation environment, or is it merged with systemd? If one > intends to manage environment variables, is systemctl (or > org.freedesktop.systemd1.Manager Environment) enough? > > A variable added by dbus-update-activation-environment (even without > --systemd option) shows up in systemd activation environment. I couldn't > find a pure dbus service to check if reverse is true. > > > >
Activation environment(s)?
Hello. In context of a modern systemd-managed user session, is there a separate dbus activation environment, or is it merged with systemd? If one intends to manage environment variables, is systemctl (or org.freedesktop.systemd1.Manager Environment) enough? A variable added by dbus-update-activation-environment (even without --systemd option) shows up in systemd activation environment. I couldn't find a pure dbus service to check if reverse is true.
Re: How to correctly setup the partition table for systemd-sysupdate?
Hi, thank you for the answer. I use the linux-generic partition to put raw images as the [Source] for systemd-sysupdate. For now, I don't want to spawn a http server for this. So you mean I need to have this kind of partition table? +-+--+++--+ | esp | root | empty root | empty root | linux-generic for put raw images | +-+--+++--+ On Mon, Jan 8, 2024 at 8:33 PM Adrian Vovk wrote: > You shouldn't be using a linux-generic partition for updates. You need (at > least) two of the same kind of partition to switch between whenever there's > an update > > On Mon, Jan 8, 2024, 06:46 Renjaya Raga Zenta wrote: > >> Hi, >> >> I've been experimenting with systemd-sysupdate, trying to understand how >> it works. >> >> I created a Fedora 39 image¹ with mkosi from the GitHub repo. It has 3 >> partitions: >> 1) esp >> 2) root >> 3) linux-generic (to put updates) >> >> The root and third partition will be expanded on firstboot via >> systemd-growfs². I also configured the third partition to be automounted >> with udev rules. >> >> I created a configuration file in /usr/lib/sysupdate.d: 10-root.conf >> [Transfer] >> ProtectVersion=%A >> >> [Source] >> Type=regular-file >> Path=/run/media/system/UPDATES >> MatchPattern=de...@v.root-x86-64.raw >> >> [Target] >> Type=partition >> Path=auto >> MatchPartitionType=root >> >> Let's say, first, I created version 0.1.0: demo_0.1.0.raw, then I created >> version 0.1.1 with SplitArtifacts=yes in mkosi.conf. So I had >> demo_0.1.1.esp.raw and demo_0.1.1.root-x86-64.raw. I put >> demo_0.1.1.root-x86-x64.raw to /run/media/system/UPDATES. >> >> I ran /usr/lib/systemd/systemd-sysupdate list, it correctly showed the >> available update candidate. But then I ran >> /usr/lib/systemd/systemd-sysupdate update, it showed an error about the >> partition table. >> >> "Partition table has less than two partition slots of the right type >> 4f68bce3---truncated (root-x86-64), refusing." >> >> I've tried adding more 2 root partition slots, but still got the same >> error. I've also tried adding PaddingMinBytes/PaddingMaxBytes in >> /usr/lib/repart.d/. >> >> Maybe I missed something here. How to correctly setup the partition table >> for systemd-sysupdate? >> >> Thanks. >> >> [1] I'm working on Debian stable based image, but unfortunately >> systemd-sysupdate is not available (not compiled). So I tried Fedora >> instead. >> [2] Before systemd 255, the GrowFileSystem flag did not work as expected, >> but there is a workaround. Hopefully the patches will be backported. >> >
Re: How to correctly setup the partition table for systemd-sysupdate?
You shouldn't be using a linux-generic partition for updates. You need (at least) two of the same kind of partition to switch between whenever there's an update On Mon, Jan 8, 2024, 06:46 Renjaya Raga Zenta wrote: > Hi, > > I've been experimenting with systemd-sysupdate, trying to understand how > it works. > > I created a Fedora 39 image¹ with mkosi from the GitHub repo. It has 3 > partitions: > 1) esp > 2) root > 3) linux-generic (to put updates) > > The root and third partition will be expanded on firstboot via > systemd-growfs². I also configured the third partition to be automounted > with udev rules. > > I created a configuration file in /usr/lib/sysupdate.d: 10-root.conf > [Transfer] > ProtectVersion=%A > > [Source] > Type=regular-file > Path=/run/media/system/UPDATES > MatchPattern=de...@v.root-x86-64.raw > > [Target] > Type=partition > Path=auto > MatchPartitionType=root > > Let's say, first, I created version 0.1.0: demo_0.1.0.raw, then I created > version 0.1.1 with SplitArtifacts=yes in mkosi.conf. So I had > demo_0.1.1.esp.raw and demo_0.1.1.root-x86-64.raw. I put > demo_0.1.1.root-x86-x64.raw to /run/media/system/UPDATES. > > I ran /usr/lib/systemd/systemd-sysupdate list, it correctly showed the > available update candidate. But then I ran > /usr/lib/systemd/systemd-sysupdate update, it showed an error about the > partition table. > > "Partition table has less than two partition slots of the right type > 4f68bce3---truncated (root-x86-64), refusing." > > I've tried adding more 2 root partition slots, but still got the same > error. I've also tried adding PaddingMinBytes/PaddingMaxBytes in > /usr/lib/repart.d/. > > Maybe I missed something here. How to correctly setup the partition table > for systemd-sysupdate? > > Thanks. > > [1] I'm working on Debian stable based image, but unfortunately > systemd-sysupdate is not available (not compiled). So I tried Fedora > instead. > [2] Before systemd 255, the GrowFileSystem flag did not work as expected, > but there is a workaround. Hopefully the patches will be backported. >
How to get service reload timestamp
Hi all, we currently have a monitoring check that alerts us of a service-specific config file having changed more recently than the services last restart. We retrieve the restart time via `systemctl show --property=ActiveEnterTimestamp`. Is there a comparably elegant way to retreive the reload timestamp? To avoid confusion, by reload I do not mean `systemctl daemon-reload`, I mean `systemctl reload `. Alternatively, is there a way to let systemd handle the reloading of services on change of related config files? Best, port19
How to correctly setup the partition table for systemd-sysupdate?
Hi, I've been experimenting with systemd-sysupdate, trying to understand how it works. I created a Fedora 39 image¹ with mkosi from the GitHub repo. It has 3 partitions: 1) esp 2) root 3) linux-generic (to put updates) The root and third partition will be expanded on firstboot via systemd-growfs². I also configured the third partition to be automounted with udev rules. I created a configuration file in /usr/lib/sysupdate.d: 10-root.conf [Transfer] ProtectVersion=%A [Source] Type=regular-file Path=/run/media/system/UPDATES MatchPattern=de...@v.root-x86-64.raw [Target] Type=partition Path=auto MatchPartitionType=root Let's say, first, I created version 0.1.0: demo_0.1.0.raw, then I created version 0.1.1 with SplitArtifacts=yes in mkosi.conf. So I had demo_0.1.1.esp.raw and demo_0.1.1.root-x86-64.raw. I put demo_0.1.1.root-x86-x64.raw to /run/media/system/UPDATES. I ran /usr/lib/systemd/systemd-sysupdate list, it correctly showed the available update candidate. But then I ran /usr/lib/systemd/systemd-sysupdate update, it showed an error about the partition table. "Partition table has less than two partition slots of the right type 4f68bce3---truncated (root-x86-64), refusing." I've tried adding more 2 root partition slots, but still got the same error. I've also tried adding PaddingMinBytes/PaddingMaxBytes in /usr/lib/repart.d/. Maybe I missed something here. How to correctly setup the partition table for systemd-sysupdate? Thanks. [1] I'm working on Debian stable based image, but unfortunately systemd-sysupdate is not available (not compiled). So I tried Fedora instead. [2] Before systemd 255, the GrowFileSystem flag did not work as expected, but there is a workaround. Hopefully the patches will be backported.
