Re: [systemd-devel] run only a single service at a time
Am 29.10.21 um 07:47 schrieb Andrei Borzenkov: On 28.10.2021 16:04, Olaf Hering wrote: There is A.timer and its A.service, and B.timer and B.service. Both A and B do not know about each other per default. Both timers fire in their own cadence. Both services have their unpredictable time until they finish. So it may happen that A.service is started while B.service is still active. But, unfortunately both services may touch the same files while they run. Does systemd have a way to serialize execution of such units, so that starting of A.service is delayed until B.service is done, and via versa? Not that I am aware of. Similar questions (or requests) came up in the past. Maybe ExecCondition= can be used with a customscript (or ExecStartPre=)? $ man systemd.service -- Leon
Re: [systemd-devel] run only a single service at a time
On Fri, Oct 29, 2021 at 12:52:06PM +0200, Leon Fauster wrote: > Am 29.10.21 um 07:47 schrieb Andrei Borzenkov: > > On 28.10.2021 16:04, Olaf Hering wrote: > > > There is A.timer and its A.service, and B.timer and B.service. > > > Both A and B do not know about each other per default. > > > Both timers fire in their own cadence. > > > Both services have their unpredictable time until they finish. > > > So it may happen that A.service is started while B.service is still > > > active. > > > > > > But, unfortunately both services may touch the same files while they run. > > > > > > Does systemd have a way to serialize execution of such units, so that > > > starting of A.service is delayed until B.service is done, and via versa? > > > > > > > Not that I am aware of. Similar questions (or requests) came up in the past. > > > > Maybe ExecCondition= can be used with a customscript (or ExecStartPre=)? > If one still wants both executions to occur in the collision case, just serialized, it seems like a simple `flock` wrapper scenario. i.e. define a lock file path somewhere for serializing access to the shared files, and pass that lock file to both service executions: `flock /path/to/lockfile -c service-command-to-serialize-on-lockfile` This way when they collide they just wait for eachother unbeknownst to systemd, and will run serially in quick succession. One could argue that if the underlying service is sharing these files, it should probably be serializing access itself to prevent stepping on its own toes. That would likely be done the same way using an advisory lock on a shared file, maybe in a simple startup script using flock as well. Regards, Vito Caputo
Re: [systemd-devel] systemd --user fails to start a user service at the first time
I have a follow-up question inline. Thanks. On Thu, Oct 28, 2021 at 10:47 PM Han wrote: > > On Thu, Oct 28, 2021 at 10:25 PM Andrei Borzenkov > wrote: > >> On 29.10.2021 04:54, Han wrote: >> > Hi, >> > >> > I'm a newbie to systemd. I encountered a strange problem when using >> > systemd user >> > service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241. >> > >> > I posted this question on stackoverflow but didn't get answers yet. >> Hence >> > trying to ask here. My apologies if this is too basic. >> > >> >1. I created a new service unit file at here: >> >/home/pi/.config/systemd/user/foo.service >> > >> > its content looks like this: >> > >> > [Service] >> > ExecStart=/home/pi/test/foo >> > WorkingDirectory=/home/pi/test >> > >> > >> >1. I tried to start this service, but it failed: >> > >> > $ systemctl --user start foo >> > Failed to start foo.service: Unit foo.se >> >> Does it work after >> >> systemctl --user daemon-reload >> >> ? >> > > Yes, it worked after `daemon-reload`. Thank you so much! > "daemon-reload" reloads all unit files in the system. It seems to me such a big remedy for starting a single service. Is this the expected workflow or a workaround? Also I tried to add a 2nd service "foo2.service" in the same way, now I don't have to run "daemon-reload" and it can start. I'm wondering why. Thanks Han > > Han > > > >> >> rvice not found. >> > >> > However, systemd can list this unit file when doing this: >> > >> > $systemctl --user list-unit-files --type service | grep foo >> > foo.service static >> > >> > Moreover, when I added [Install] section in the unit file: >> > >> > [Install] >> > WantedBy=multi-user.target >> > >> >> User instance does not have this target. >> >> > and run $systemctl --user enable foo , it worked. >> > >> > Even more, after that I removed the unit file, and recreated the unit >> file >> > without the [Install] section, now I start the service and the original >> > problem is no longer seen. >> > >> > So it seems like only when I try to create a new user service for the >> first >> > time on the system, without using [Install], it will fail to start. >> > >> > Any ideas why this is happening? (btw, I don't want to have [Install] >> for >> > this service.) >> > >> > Or is this a known issue fixed in a later release? >> > >> > Thanks >> > >> > Han >> > >> >>
Re: [systemd-devel] systemd --user fails to start a user service at the first time
On 29.10.2021 19:24, Han wrote: > I have a follow-up question inline. Thanks. > > On Thu, Oct 28, 2021 at 10:47 PM Han wrote: > >> >> On Thu, Oct 28, 2021 at 10:25 PM Andrei Borzenkov >> wrote: >> >>> On 29.10.2021 04:54, Han wrote: Hi, I'm a newbie to systemd. I encountered a strange problem when using systemd user service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241. I posted this question on stackoverflow but didn't get answers yet. >>> Hence trying to ask here. My apologies if this is too basic. 1. I created a new service unit file at here: /home/pi/.config/systemd/user/foo.service its content looks like this: [Service] ExecStart=/home/pi/test/foo WorkingDirectory=/home/pi/test 1. I tried to start this service, but it failed: $ systemctl --user start foo Failed to start foo.service: Unit foo.se >>> >>> Does it work after >>> >>> systemctl --user daemon-reload >>> >>> ? >>> >> >> Yes, it worked after `daemon-reload`. Thank you so much! >> > > > "daemon-reload" reloads all unit files in the system. It seems to me such > a big remedy for starting a single service. Is this the expected workflow > or a workaround? > Normally systemd should load new unit definition that is not yet present in memory automatically on first reference. Daemon-reload is needed when unit definition changed since it has been cached. > Also I tried to add a 2nd service "foo2.service" in the same way, now I > don't have to run "daemon-reload" and it can start. I'm wondering why. > That is expected behavior.
