On 3/27/21 5:38 AM, Lennart Poettering wrote:
On Fr, 26.03.21 23:24, Alan Perry (al...@snowmoose.com) wrote:
I occasionally see a problem where systemd-analyze reports that boot
did not complete and it is suggested that I use systemctl list-jobs
to find out more. That shows a .device service j
> On Mar 27, 2021, at 05:46, Lennart Poettering wrote:
>
> On Fr, 26.03.21 23:24, Alan Perry (al...@snowmoose.com) wrote:
>
>> I occasionally see a problem where systemd-analyze reports that boot
>> did not complete and it is suggested that I use systemctl list-jobs
>> to find out more. That
On Fr, 26.03.21 23:24, Alan Perry (al...@snowmoose.com) wrote:
> I occasionally see a problem where systemd-analyze reports that boot
> did not complete and it is suggested that I use systemctl list-jobs
> to find out more. That shows a .device service job and some sub-jobs
> (associated with udev
On 27.03.2021 10:11, John Ioannidis wrote:
...
>
> *workdir.path *
>
> [Unit]
> Description=Trigger workdir.service when a job starts, creating a directory
> in /opt/circleci/workdir
> After=ccistated.service
> ConditionPathExists=/run/metadata/tags/resource_class
> [Path]
> PathChanged=/opt/circ
tl;dr: a .path unit does not appear to be waiting for the After= unit to
run first.
I am still trying to understand why some services occasionally do not start
at boot time. It is a very intermittent behavior, but I caught another
instance. Everything is running in Google Compute Engine or Amazon
