Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Tue, Apr 09, 2024 at 11:37:39AM +0300, Mikko Rapeli wrote: > Hi, > > On Mon, Feb 19, 2024 at 11:53:14AM +0100, Lennart Poettering wrote: > > For your usecase the new tpm2.target available in git main is what you > > really should focus on: all TPM using services should order themselves > > after that. All stuff needed to make a TPM device appear should be > > placed before that. > > > > The systemd-tpm2-generator that now exists in git main analyzes the > > uefi/acpi firmware situation and automatically adds a dev-tpm0.device > > dependency on tpm2.target if it comes to the conclusion that such a > > device will show up. This generator is not going to cover your > > specific case, but I think it would be a good blueprint for you: > > i.e. write a generator that checks if /dev/teepriv* exists. If not, > > just exit. If yes, generate the required deps to pull in > > tee-supplicatnt@.service, and add the dev-tpmrm0.device dep just like > > systemd-tpm2-generator does. > > Thanks, I've ported the few remaining tpm2.target patches to systemd 255.4 > which we use > from yocto poky. Patches roughly like here but needed some local changes > which I'm > currently trying to test: > https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/merge_requests/82/diffs?commit_id=245086abcd96c24084a741037acc498523e5775b > > I've also added kernel and optee changes which enable RPMB > usage without tee-supplicant userspace daemon but those need more > testing on boards with fTPM and RPMB support. > > https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/merge_requests/82/diffs?commit_id=1a87039f42ad7a6178f47db8558874d98f19b2b2 > https://gitlab.com/mikko.rapeli/meta-ts/-/commit/4d1b8d3885eb5a120d33796462145e9608f2ecfe > > But currently I face a different problem which came from a yocto > update/rebase. > There were a few fTPM related kernel regressions after update from 6.5.y to > 6.6.y > ( https://bugzilla.kernel.org/show_bug.cgi?id=218587 and > https://bugzilla.kernel.org/show_bug.cgi?id=218542 to be exact) > but systemd 254 update to 255.4 seems to also cause isses. > > On 255.4 UEFI secure boot, uki loading and mounting dm-verity protected /usr > work, > and also tpm2 target and creating a writable rootfs / with TPM2 encryption > using > systemd-repart, but then cryptsetup unlocking seems to fail. What could I be > missing? > > Apr 09 07:57:56 trs-qemuarm64 systemd[1]: Reached target Trusted Platform > Module. > sh-5.2# systemctl status systemd-repart.service -l --no-pager > * systemd-repart.service - Repartition Root Disk > Loaded: loaded (/usr/lib/systemd/system/systemd-repart.service; static) > Drop-In: /usr/lib/systemd/system/systemd-repart.service.d > `-override.conf > Active: active (exited) since Tue 2024-04-09 07:23:33 UTC; 1min 58s ago >Docs: man:systemd-repart.service(8) > Process: 209 ExecStart=/bin/sh -c /usr/bin/test -c /dev/tpmrm0 && > /usr/bin/systemd-repart --dry-run=no --definitions=/usr/lib/repart.d/ || > /usr/bin/systemd-repart --dry-run=no --definitions=/usr/lib/repart.d_notpm/ > (code=exited, status=0/SUCCESS) >Main PID: 209 (code=exited, status=0/SUCCESS) > CPU: 6.777s > > Apr 09 07:23:29 trs-qemuarm64 sh[220]: [83B blob data] > Apr 09 07:23:29 trs-qemuarm64 sh[211]: > /dev/mapper/luks-repart-1ec7705a23c053fd successfully formatted as ext4 > (label "root-arm64", uuid 54453b71-30e9-4b29-a593-e4298b2c0770) > Apr 09 07:23:29 trs-qemuarm64 sh[211]: Successfully formatted future > partition 3. > Apr 09 07:23:29 trs-qemuarm64 sh[211]: Populating ext4 filesystem. > Apr 09 07:23:32 trs-qemuarm64 sh[211]: Successfully populated ext4 filesystem. > Apr 09 07:23:33 trs-qemuarm64 sh[211]: Adding new partition 3 to partition > table. > Apr 09 07:23:33 trs-qemuarm64 sh[211]: Writing new partition table. > Apr 09 07:23:33 trs-qemuarm64 sh[211]: Telling kernel to reread partition > table. > Apr 09 07:23:33 trs-qemuarm64 sh[211]: All done. > Apr 09 07:23:33 trs-qemuarm64 systemd[1]: Finished Repartition Root Disk. > sh-5.2# systemctl status systemd-cryptsetup@root.service -l --no-pager > x systemd-cryptsetup@root.service - Cryptography Setup for root > Loaded: loaded > (/run/systemd/generator.late/systemd-cryptsetup@root.service; generated) > Drop-In: /usr/lib/systemd/system/systemd-cryptsetup@.service.d > `-override.conf > Active: failed (Result: exit-code) since Tue 2024-04-09 07:23:35 UTC; > 2min 28s ago >Docs: man:crypttab(5) > man:systemd-cryptsetup-generator(8) > man:systemd-cryptsetup@.service(8) > Process: 234 ExecStart=/usr/bin/systemd-cryptsetup attach root > /dev/gpt-auto-root-luks (code=exited, status=1/FAILURE) >Main PID: 234 (code=exited, status=1/FAILURE) > CPU: 810ms > > Apr 09 07:23:34 trs-qemuarm64 systemd[1]: Starting Cryptography Setup for > root... > Apr 09 07:23:35 trs-qemuarm64 systemd-cryptsetup[234]: No passphrase or >
Re: [systemd-devel] How to debug systemd services failing to start with 11/SEGV?
Hello everone, I thought I knew how to let the kernel create coredumps … (see below). Am Tue, Apr 09, 2024 at 04:21:21PM +0200 schrieb Alexander Dahl: > Hello Lennart, > > thanks for your quick reply, see below. > > Am Tue, Apr 09, 2024 at 03:53:24PM +0200 schrieb Lennart Poettering: > > On Di, 09.04.24 14:42, Alexander Dahl (a...@thorsis.com) wrote: > > > > > Hello everyone, > > > > > > I'm currently trying to build a firmware for an embedded device and > > > running into trouble because systemd seems to crash. The BSP is > > > based on pengutronix DistroKit (master) built with ptxdist and the > > > target is the Microchip SAM9X60-Curiosity board, which is arm v5te > > > architecture (that board is not part of DistroKit, support for that is > > > in an upper layer of mine not public yet (?)). > > > > > > Everything is quite recent, building systemd version 255.2 currently. > > > On startup I get messages like this (this is the first one, later on > > > there are lot more, all with the same status): > > > > > >[ 11.175650] systemd[1]: systemd-journald.service: Main process > > > exited, code=killed, status=11/SEGV > > >[ 11.239679] systemd[1]: systemd-journald.service: Failed with > > > result 'signal'. > > >[ 11.292640] systemd[1]: Failed to start systemd-journald.service. > > >[FAILED] Failed to start systemd-journald.service. > > >See 'systemctl status systemd-journald.service' for details. > > > > > > The system drops me on a shell later, where I can run the above > > > mentioned command, which gives: > > > > > > ~ # systemctl status systemd-journald.service > > > x systemd-journald.service - Journal Service > > > Loaded: loaded > > > (/usr/lib/systemd/system/systemd-journald.service; static) > > > Active: failed (Result: signal) since Tue 2024-04-09 11:44:52 > > > UTC; 11min a> > > > TriggeredBy: x systemd-journald-dev-log.socket > > > * systemd-journald-audit.socket > > > x systemd-journald.socket > > >Docs: man:systemd-journald.service(8) > > > man:journald.conf(5) > > > Process: 197 ExecStart=/usr/lib/systemd/systemd-journald > > > (code=killed, sign> > > >Main PID: 197 (code=killed, signal=SEGV) > > >FD Store: 0 (limit: 4224) > > > CPU: 330ms > > > > > > This does not help me much. Other services crashing: systemd-udevd > > > and systemd-timesyncd, also with status 11/SEGV which is segmentation > > > fault, right? > > > > Yes. > > > > > I had this board running with an older version of systemd, but I can > > > not remember which was the last good version. > > > > > > Could anyone give me a hint please how to debug this? > > > > "coredumpctl gdb" should get open the most recent backtrace for you. > > This gives: > > ~ # coredumpctl gdb > No journal files were found. > No match found. > > > The coredump should also show up in the logs with a backtrace. > > I only have serial console output. journald is crashing. With > `dmesg` I see systemd messages in kernel log, but no backtrace. > gdbserver is installed on target, no gdb currently. Trying to get a > coredump tomorrow. Well I tried for like three hours now, and I could not get a coredump from journald nor udevd. Tried with the systemd way of creating coredumps, which means /usr/lib/systemd/systemd-coredump is registered as kernel.core_pattern with settings from /usr/lib/sysctl.d/50-coredump.conf and I even made sure systemd-coredump.socket is active (started from the maintenance shell): ~ # systemctl status systemd-coredump.socket * systemd-coredump.socket - Process Core Dump Socket Loaded: loaded (/usr/lib/systemd/system/systemd-coredump.socket; static) Active: active (listening) since Tue 2024-04-09 11:46:21 UTC; 2min 44s ago Docs: man:systemd-coredump(8) Listen: /run/systemd/coredump (SequentialPacket) Accepted: 1; Connected: 0; CGroup: /system.slice/systemd-coredump.socket Started a long running process like this: ~ # /usr/lib/systemd/systemd-udevd -d Starting systemd-udevd version 255.2 Killed it like this: ~ # kill -11 269 Got this on serial console (kernel log): [ 329.282462] systemd[1]: Started systemd-coredump@1-271-0.service. [ 329.454739] systemd[1]: Listening on systemd-journald-dev-log.socket. [ 329.552429] systemd[1]: Starting systemd-journald.service... [ 329.953204] systemd[1]: systemd-journald.service: Main process exited, code=killed, status=11/SEGV [ 329.966458] systemd[1]: systemd-journald.service: Failed with result 'signal'. [ 329.977845] systemd[1]: Failed to start systemd-journald.service. [ 330.002231] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1. [ 330.092289] systemd[1]: Starting systemd-journald.service... [ 330.513858] systemd[1]: systemd-journald.service: Main pr
Re: [systemd-devel] How to debug systemd services failing to start with 11/SEGV?
Hello, gave it a try and bisected systemd … see below. Am Wed, Apr 10, 2024 at 12:37:39PM +0200 schrieb Alexander Dahl: > Hello everone, > > I thought I knew how to let the kernel create coredumps … (see below). > > Am Tue, Apr 09, 2024 at 04:21:21PM +0200 schrieb Alexander Dahl: > > Hello Lennart, > > > > thanks for your quick reply, see below. > > > > Am Tue, Apr 09, 2024 at 03:53:24PM +0200 schrieb Lennart Poettering: > > > On Di, 09.04.24 14:42, Alexander Dahl (a...@thorsis.com) wrote: > > > > > > > Hello everyone, > > > > > > > > I'm currently trying to build a firmware for an embedded device and > > > > running into trouble because systemd seems to crash. The BSP is > > > > based on pengutronix DistroKit (master) built with ptxdist and the > > > > target is the Microchip SAM9X60-Curiosity board, which is arm v5te > > > > architecture (that board is not part of DistroKit, support for that is > > > > in an upper layer of mine not public yet (?)). > > > > > > > > Everything is quite recent, building systemd version 255.2 currently. > > > > On startup I get messages like this (this is the first one, later on > > > > there are lot more, all with the same status): > > > > > > > >[ 11.175650] systemd[1]: systemd-journald.service: Main process > > > > exited, code=killed, status=11/SEGV > > > >[ 11.239679] systemd[1]: systemd-journald.service: Failed with > > > > result 'signal'. > > > >[ 11.292640] systemd[1]: Failed to start systemd-journald.service. > > > >[FAILED] Failed to start systemd-journald.service. > > > >See 'systemctl status systemd-journald.service' for details. > > > > > > > > The system drops me on a shell later, where I can run the above > > > > mentioned command, which gives: > > > > > > > > ~ # systemctl status systemd-journald.service > > > > x systemd-journald.service - Journal Service > > > > Loaded: loaded > > > > (/usr/lib/systemd/system/systemd-journald.service; static) > > > > Active: failed (Result: signal) since Tue 2024-04-09 11:44:52 > > > > UTC; 11min a> > > > > TriggeredBy: x systemd-journald-dev-log.socket > > > > * systemd-journald-audit.socket > > > > x systemd-journald.socket > > > >Docs: man:systemd-journald.service(8) > > > > man:journald.conf(5) > > > > Process: 197 ExecStart=/usr/lib/systemd/systemd-journald > > > > (code=killed, sign> > > > >Main PID: 197 (code=killed, signal=SEGV) > > > >FD Store: 0 (limit: 4224) > > > > CPU: 330ms > > > > > > > > This does not help me much. Other services crashing: systemd-udevd > > > > and systemd-timesyncd, also with status 11/SEGV which is segmentation > > > > fault, right? > > > > > > Yes. > > > > > > > I had this board running with an older version of systemd, but I can > > > > not remember which was the last good version. > > > > > > > > Could anyone give me a hint please how to debug this? > > > > > > "coredumpctl gdb" should get open the most recent backtrace for you. > > > > This gives: > > > > ~ # coredumpctl gdb > > No journal files were found. > > No match found. > > > > > The coredump should also show up in the logs with a backtrace. > > > > I only have serial console output. journald is crashing. With > > `dmesg` I see systemd messages in kernel log, but no backtrace. > > gdbserver is installed on target, no gdb currently. Trying to get a > > coredump tomorrow. > > Well I tried for like three hours now, and I could not get a coredump > from journald nor udevd. Tried with the systemd way of creating > coredumps, which means /usr/lib/systemd/systemd-coredump is registered > as kernel.core_pattern with settings from > /usr/lib/sysctl.d/50-coredump.conf and I even made sure > systemd-coredump.socket is active (started from the maintenance > shell): > > ~ # systemctl status systemd-coredump.socket > * systemd-coredump.socket - Process Core Dump Socket > Loaded: loaded (/usr/lib/systemd/system/systemd-coredump.socket; > static) > Active: active (listening) since Tue 2024-04-09 11:46:21 UTC; 2min > 44s ago >Docs: man:systemd-coredump(8) > Listen: /run/systemd/coredump (SequentialPacket) >Accepted: 1; Connected: 0; > CGroup: /system.slice/systemd-coredump.socket > > Started a long running process like this: > > ~ # /usr/lib/systemd/systemd-udevd -d > Starting systemd-udevd version 255.2 > > Killed it like this: > > ~ # kill -11 269 > > Got this on serial console (kernel log): > > [ 329.282462] systemd[1]: Started systemd-coredump@1-271-0.service. > [ 329.454739] systemd[1]: Listening on systemd-journald-dev-log.socket. > [ 329.552429] systemd[1]: Starting systemd-journald.service... > [ 329.953204] systemd[1]: systemd-journald.service: Main process exited, > code=killed, status=11/SEGV > [ 329.966458] systemd[1]: systemd-journal
Re: [systemd-devel] How to debug systemd services failing to start with 11/SEGV?
On Wed, Apr 10, 2024 at 4:08 PM Alexander Dahl wrote: > Note: platform here is 32 bit arm, namely v5te on Microchip SAM9X60 > SoC. Kernel is 6.6, maybe I did not get the kernelconfig right and > some options are not set correctly? Or maybe those crashes are real? > Then I could need some help how to _really_ enable coredumps for > journald, udevd, and timesyncd. Got a hint off-list to pass > 'systemd.dump_core=true' to kernel cmdline, but that had no effect on > coredump creation. > I would just set kernel.core_pattern to a *file* path, e.g. "/var/log/core.%P". Then use the shell's ulimit command to raise the coredump size limit as it defaults to zero (ulimit -c unlimited), and manually start /usr/lib/systemd/systemd-timesyncd from the shell (timesyncd is the simplest one and doesn't do anything system-critical). Alternatively, run the service under the debugger: `gdb /usr/.../timesyncd`. -- Mantas Mikulėnas
Re: [systemd-devel] How to debug systemd services failing to start with 11/SEGV?
Hello Mantas, Am Wed, Apr 10, 2024 at 04:45:58PM +0300 schrieb Mantas Mikulėnas: > On Wed, Apr 10, 2024 at 4:08 PM Alexander Dahl wrote: > > > Note: platform here is 32 bit arm, namely v5te on Microchip SAM9X60 > > SoC. Kernel is 6.6, maybe I did not get the kernelconfig right and > > some options are not set correctly? Or maybe those crashes are real? > > Then I could need some help how to _really_ enable coredumps for > > journald, udevd, and timesyncd. Got a hint off-list to pass > > 'systemd.dump_core=true' to kernel cmdline, but that had no effect on > > coredump creation. > > > > I would just set kernel.core_pattern to a *file* path, e.g. > "/var/log/core.%P". Then use the shell's ulimit command to raise the > coredump size limit as it defaults to zero (ulimit -c unlimited), and > manually start /usr/lib/systemd/systemd-timesyncd from the shell (timesyncd > is the simplest one and doesn't do anything system-critical). Tried that already. The service does not crash in that case. As a workaround for now I added this to /etc/systemd/system/systemd-journald.service.d/override.conf but I'm pretty sure it just hides the underlying issue? [Service] MemoryDenyWriteExecute=no Greets Alex > > Alternatively, run the service under the debugger: `gdb /usr/.../timesyncd`. > > -- > Mantas Mikulėnas
[systemd-devel] How to chain services driven by a timer?
My goal is to implement a service that runs after logrotate.service completes. logrotate.service is triggered by a timer logrotate.timer. I don't want to modify either of logrotate.service or logrotate.timer, as they are provided by the OS vendor (SLES 12 SP5, in my case.) I've tried to apply advice I've seen in misc. forums, e.g.: https://stackoverflow.com/questions/76314129/how-do-i-configure-systemd-timers-to-run-three-separate-tasks-one-after-the-next https://stackoverflow.com/questions/70645559/execute-systemd-service-just-after-another-using-a-timer But I can't seem to get it to be fired. The version of systemd on this distribution: 10-153-68-34:~ # rpm -q systemd systemd-228-157.57.1.x86_64 I'd appreciate any guidance. My current service file: [Unit] Description=Activities after logrotation Requires=logrotate.service Wants=logrotate.service After=logrotate.service [Service] #Type=oneshot Type=simple ExecStart=/usr/bin/logger 'XXX post log rotation' [Install] WantedBy=timers.target -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 5:50 PM Brian Reichert wrote: > My goal is to implement a service that runs after logrotate.service > completes. > > logrotate.service is triggered by a timer logrotate.timer. > > I don't want to modify either of logrotate.service or logrotate.timer, > as they are provided by the OS vendor (SLES 12 SP5, in my case.) > In a sense, you're already modifying units provided by the OS vendor – whenever you use `systemctl enable` to link a service into multi-user.target.wants/, that "modifies" multi-user.target by adding a Wants= dependency, just that that happens in a way that does not get reset during package updates. Systemd has plenty of mechanisms for that; e.g. you can add additional settings to `/etc/systemd/system/logrotate.service.d/*.conf` (using systemctl edit) or you can link some units into logrotate.service.wants/ in the same way as is done with .targets. (You need to do this to the .service, as that's what actually gets activated periodically.) My current service file: > > [Unit] > Description=Activities after logrotation > > Requires=logrotate.service > Wants=logrotate.service > That seems like the complete opposite of what you're trying to achieve – this makes *your* unit trigger the start of logrotate, not the other way around. > After=logrotate.service > After= does not define a trigger. It only defines the execution order when multiple units are triggered at once. > > [Service] > #Type=oneshot > Type=simple > > ExecStart=/usr/bin/logger 'XXX post log rotation' > > [Install] > WantedBy=timers.target > The WantedBy= (or the .wants/ symlink that results from it) is the only trigger being defined in your unit. But since the service was set up to be started by timers.target, and timers.target itself only starts once during boot (when timers get scheduled), that means your service is also started once during boot and that's that. If you want it to be triggered by logrotate.service, then you need WantedBy=logrotate.service. Then each time logrotate.service is started on schedule, it'll cause your service to be started as a dependency, and the After= will actually work to define the order. -- Mantas Mikulėnas
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 8:50 AM Brian Reichert wrote: > > My current service file: > > [Unit] > Description=Activities after logrotation > > Requires=logrotate.service > Wants=logrotate.service > After=logrotate.service > > [Service] > #Type=oneshot > Type=simple > > ExecStart=/usr/bin/logger 'XXX post log rotation' > > [Install] > WantedBy=timers.target The critical part is WantedBy=logrotate.service. In other words, when logrotate.service is activated, you want it to also activate your service. Then After=logrotate.service above will ensure your service starts after it completes. The Requires and Wants above are conflicting. You only want one or the other, but I'd probably put it as Requires=logrotate.service. That way your unit won't start if logrotate.service fails.
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 09:06:09AM -0600, Dan Nicholson wrote: > On Wed, Apr 10, 2024 at 8:50???AM Brian Reichert wrote: > > > > My current service file: > > > > [Unit] > > Description=Activities after logrotation > > > > Requires=logrotate.service > > Wants=logrotate.service > > After=logrotate.service > > > > [Service] > > #Type=oneshot > > Type=simple > > > > ExecStart=/usr/bin/logger 'XXX post log rotation' > > > > [Install] > > WantedBy=timers.target > > The critical part is WantedBy=logrotate.service. In other words, when > logrotate.service is activated, you want it to also activate your > service. Then After=logrotate.service above will ensure your service > starts after it completes. The Requires and Wants above are > conflicting. You only want one or the other, but I'd probably put it > as Requires=logrotate.service. That way your unit won't start if > logrotate.service fails. Thanks to you and for your advice. I think I've correctly incorporated your suggestions, but I still can't seem to get things to work. Perhaps my method of testing is flawed. My current service: [Unit] Description=Activities after logrotation Requires=logrotate.service [Service] Type=simple ExecStart=/usr/bin/logger 'XXX post log rotation' [Install] WantedBy=logrotate.service I tried, variously, to no apparent effect: systemctl restart logrotate.timer systemctl start logrotate.service How should I be testing this? -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] How to chain services driven by a timer?
On 10.04.2024 22:04, Brian Reichert wrote: On Wed, Apr 10, 2024 at 09:06:09AM -0600, Dan Nicholson wrote: On Wed, Apr 10, 2024 at 8:50???AM Brian Reichert wrote: My current service file: [Unit] Description=Activities after logrotation Requires=logrotate.service Wants=logrotate.service After=logrotate.service [Service] #Type=oneshot Type=simple ExecStart=/usr/bin/logger 'XXX post log rotation' [Install] WantedBy=timers.target The critical part is WantedBy=logrotate.service. In other words, when logrotate.service is activated, you want it to also activate your service. Then After=logrotate.service above will ensure your service starts after it completes. The Requires and Wants above are conflicting. You only want one or the other, but I'd probably put it as Requires=logrotate.service. That way your unit won't start if logrotate.service fails. Thanks to you and for your advice. I think I've correctly incorporated your suggestions, but I still can't seem to get things to work. Perhaps my method of testing is flawed. My current service: [Unit] Description=Activities after logrotation Requires=logrotate.service [Service] Type=simple ExecStart=/usr/bin/logger 'XXX post log rotation' [Install] WantedBy=logrotate.service Links in [Install] section are created by "systemctl enable". I tried, variously, to no apparent effect: systemctl restart logrotate.timer systemctl start logrotate.service How should I be testing this?
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 1:21 PM Andrei Borzenkov wrote: > > On 10.04.2024 22:04, Brian Reichert wrote: > > On Wed, Apr 10, 2024 at 09:06:09AM -0600, Dan Nicholson wrote: > >> On Wed, Apr 10, 2024 at 8:50???AM Brian Reichert > >> wrote: > >>> > >>> My current service file: > >>> > >>>[Unit] > >>>Description=Activities after logrotation > >>> > >>>Requires=logrotate.service > >>>Wants=logrotate.service > >>>After=logrotate.service > >>> > >>>[Service] > >>>#Type=oneshot > >>>Type=simple > >>> > >>>ExecStart=/usr/bin/logger 'XXX post log rotation' > >>> > >>>[Install] > >>>WantedBy=timers.target > >> > >> The critical part is WantedBy=logrotate.service. In other words, when > >> logrotate.service is activated, you want it to also activate your > >> service. Then After=logrotate.service above will ensure your service > >> starts after it completes. The Requires and Wants above are > >> conflicting. You only want one or the other, but I'd probably put it > >> as Requires=logrotate.service. That way your unit won't start if > >> logrotate.service fails. > > > > Thanks to you and for your advice. I think I've > > correctly incorporated your suggestions, but I still can't seem to get > > things to work. > > > > Perhaps my method of testing is flawed. > > > > My current service: > > > >[Unit] > >Description=Activities after logrotation > > > >Requires=logrotate.service > > > >[Service] > >Type=simple > > > >ExecStart=/usr/bin/logger 'XXX post log rotation' > > > >[Install] > >WantedBy=logrotate.service > > > > Links in [Install] section are created by "systemctl enable". Just to be complete, your unit won't be triggered until you see it in "systemctl show -p Wants logrotate.service". With WantedBy=logrotate.service, you'll also find a symlink to your service in /etc/systemd/system/logrotate.service.wants/ once it's enabled.
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 10:21:32PM +0300, Andrei Borzenkov wrote: > On 10.04.2024 22:04, Brian Reichert wrote: > > [Install] > > WantedBy=logrotate.service > > > > Links in [Install] section are created by "systemctl enable". I could have sworn I did this, but did so (again) just to be sure: 10-153-68-34:~ # systemctl enable post-logrotate.service Created symlink from /etc/systemd/system/logrotate.service.wants/post-logrotate.service to /etc/systemd/system/post-logrotate.service. 10-153-68-34:~ # systemctl restart logrotate.timer 10-153-68-34:~ # systemctl status logrotate.service ??? logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Active: inactive (dead) since Wed 2024-04-10 14:58:31 EDT; 28min ago Docs: man:logrotate(8) man:logrotate.conf(5) Main PID: 17686 (code=exited, status=0/SUCCESS) Apr 10 14:58:29 10-153-68-34 systemd[1]: Starting Rotate log files... Apr 10 14:58:31 10-153-68-34 systemd[1]: Started Rotate log files. 10-153-68-34:~ # systemctl status post-logrotate.service ??? post-logrotate.service - Activities after logrotation Loaded: loaded (/etc/systemd/system/post-logrotate.service; enabled; vendor preset: disabled) Active: inactive (dead) I don't see post-logrotate.service has having been run. -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 01:29:10PM -0600, Dan Nicholson wrote: > On Wed, Apr 10, 2024 at 1:21???PM Andrei Borzenkov > wrote: > Just to be complete, your unit won't be triggered until you see it in > "systemctl show -p Wants logrotate.service". With > WantedBy=logrotate.service, you'll also find a symlink to your service > in /etc/systemd/system/logrotate.service.wants/ once it's enabled. Ok, double-checking: 10-153-68-34:~ # systemctl show -p Wants logrotate.service Wants=post-logrotate.service 10-153-68-34:~ # ls -ldtr --full-time /etc/systemd/system/logrotate.service.wants/post-logrotate.service lrwxrwxrwx 1 root root 42 2024-04-10 15:26:19.187115411 -0400 /etc/systemd/system/logrotate.service.wants/post-logrotate.service -> /etc/systemd/system/post-logrotate.service -- Brian Reichert BSD admin/developer at large
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 1:32 PM Brian Reichert wrote: > > On Wed, Apr 10, 2024 at 10:21:32PM +0300, Andrei Borzenkov wrote: > > On 10.04.2024 22:04, Brian Reichert wrote: > > > [Install] > > > WantedBy=logrotate.service > > > > > > > Links in [Install] section are created by "systemctl enable". > > I could have sworn I did this, but did so (again) just to be sure: > > 10-153-68-34:~ # systemctl enable post-logrotate.service > Created symlink from > /etc/systemd/system/logrotate.service.wants/post-logrotate.service to > /etc/systemd/system/post-logrotate.service. > > 10-153-68-34:~ # systemctl restart logrotate.timer > > 10-153-68-34:~ # systemctl status logrotate.service Restarting the timer doesn't make the service run immediately. Are you sure logrotate.service has run again since you made this change? Just simulate the timer and start logrotate.service again. All the timer does is activate the service. For testing you don't need to wait for that to happen. -- Dan
Re: [systemd-devel] How to chain services driven by a timer?
On Wed, Apr 10, 2024 at 01:47:47PM -0600, Dan Nicholson wrote: > Restarting the timer doesn't make the service run immediately. Are you > sure logrotate.service has run again since you made this change? Just > simulate the timer and start logrotate.service again. All the timer > does is activate the service. For testing you don't need to wait for > that to happen. Ok, that is a helpful detail. Restarting logrotate.service does now cause my post-logrotate.service to subsequently start. On a lark, I augmented the stock logrotate.service with some instrumentation to show me when 'logrotate' completes, in addition to maintaining a log file: #ExecStart=/usr/sbin/logrotate /etc/logrotate.conf ExecStart=/usr/sbin/logrotate -l /var/log/logrotate.log /etc/logrotate.conf ExecStartPost=/usr/bin/logger 'XXX log rotation completed' My service is being run (yay!), but I'm wary of the out-of-order messaging here: 10-153-68-34:~ # journalctl -o short-precise --no-pager -u logrotate.service -u post-logrotate.service | tail -6 Apr 10 16:57:54.061053 10-153-68-34 systemd[1]: Started Activities after logrotation. Apr 10 16:57:54.061140 10-153-68-34 systemd[1]: Stopped Rotate log files. Apr 10 16:57:54.062219 10-153-68-34 systemd[1]: Starting Rotate log files... Apr 10 16:57:54.104300 10-153-68-34 root[5899]: XXX post log rotation Apr 10 16:57:55.367522 10-153-68-34 root[5903]: XXX log rotation completed Apr 10 16:57:55.368789 10-153-68-34 systemd[1]: Started Rotate log files. And systemctl shows the new post-logrotate.service started slightly before logrotate.service ended: 10-153-68-34:~ # systemctl show logrotate.service --property ExecMainExitTimestamp ExecMainExitTimestamp=Wed 2024-04-10 16:57:55 EDT 10-153-68-34:~ # systemctl show post-logrotate.service --property ExecMainStartTimestamp ExecMainStartTimestamp=Wed 2024-04-10 16:57:54 EDT (I really wish I had higher-resolution timestamps here.) That log file's mtime: 10-153-68-34:~ # ls -ldtr --full-time /var/log/logrotate.log -rw-r--r-- 1 root root 1607975 2024-04-10 16:57:55.094420531 -0400 /var/log/logrotate.log Hopefully someone here can assure me this is just due to an artifact of bookkeeping. I'm specifically trying to avoid doing any work while logrotate is running. That I got even this far is really great, so I appreciate all of the guidance! > -- > Dan -- Brian Reichert BSD admin/developer at large
