[systemd-devel] Resource ( systemd )
I'm developing a web server in python that is referenced in the path inside a systemd service ( server.service ). In the path that points to the execution of the python file it works without problems but when I make any changes in this file it is necessary to restart the file in order to get the updates. Is there any way to implement a property in (server.service) of the type (autosave) so that you no longer need to use restarting the service when there are changes in the related file in python ? Att, João Aguiar ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?
On Tue, Jul 13, 2021 at 4:06 PM Andrei Borzenkov wrote:
>
> On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither
> wrote:
> >
> > Hi all,
> >
> > when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
> > another.service with After=systemd-udevd.service, can I at system boot rely
> > on my.service to be already run when another.service starts?
> >
>
> No. udevd will queue the start job for my.service. It has no relation
> to systemd-udevd.service. If my.service has any ordering dependencies
> that cause it to be delayed, it will be delayed. If it does not have
> extra ordering dependencies, it is not predictable from practical
> point of view when it will be selected for execution. It depends on
> details of internal implementation.
>
> Even if another.service is explicitly ordered After my.service it does
> not really gurantee anything - another.service may have already
> completed when my.service enters queue.
>
> The only way to ensure another.service is always started after
> my.service is to make my.service Want and After another.service and
I meant Wants and Before of course.
> make sure nothing else can cause start job for another.service to be
> queued.
>
>
> > Here's the background to the question:
> >
> > I'm developing an embedded device with autoupdate functionality. It grabs
> > the new disk image from an usb drive when plugged in. The udev rule and the
> > systemd units + shell scripts run all fine. The only thing complicating all
> > this is that at boot into the new system, the udev rule fires as well.
> >
> > I worked around this in the following way:
> > * udev-triggered start-update.service runs only if
> > /persistent/update-running.stamp doesn't yet exist. When started, it
> > creates this file.
> > * autoscheduled conclude-update.service contains
> > After=systemd-udevd.service and removes /persistent/update-running.stamp.
> >
> > I assumed this would at system boot ensure the start-update.service to be
> > started before conclude-update.service, hence not doing anything. Until
> > recently, this seemed to worked fine, but I have received reports making me
> > believe I was just witnessing a race condition resulting in my favor.
> >
> >
> > Best regards,
> > Manuel
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?
On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither wrote:
>
> Hi all,
>
> when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
> another.service with After=systemd-udevd.service, can I at system boot rely
> on my.service to be already run when another.service starts?
>
No. udevd will queue the start job for my.service. It has no relation
to systemd-udevd.service. If my.service has any ordering dependencies
that cause it to be delayed, it will be delayed. If it does not have
extra ordering dependencies, it is not predictable from practical
point of view when it will be selected for execution. It depends on
details of internal implementation.
Even if another.service is explicitly ordered After my.service it does
not really gurantee anything - another.service may have already
completed when my.service enters queue.
The only way to ensure another.service is always started after
my.service is to make my.service Want and After another.service and
make sure nothing else can cause start job for another.service to be
queued.
> Here's the background to the question:
>
> I'm developing an embedded device with autoupdate functionality. It grabs the
> new disk image from an usb drive when plugged in. The udev rule and the
> systemd units + shell scripts run all fine. The only thing complicating all
> this is that at boot into the new system, the udev rule fires as well.
>
> I worked around this in the following way:
> * udev-triggered start-update.service runs only if
> /persistent/update-running.stamp doesn't yet exist. When started, it creates
> this file.
> * autoscheduled conclude-update.service contains After=systemd-udevd.service
> and removes /persistent/update-running.stamp.
>
> I assumed this would at system boot ensure the start-update.service to be
> started before conclude-update.service, hence not doing anything. Until
> recently, this seemed to worked fine, but I have received reports making me
> believe I was just witnessing a race condition resulting in my favor.
>
>
> Best regards,
> Manuel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?
On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither
wrote:
> Hi all,
>
> when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
> another.service with After=systemd-udevd.service, can I at system boot rely
> on my.service to be already run when another.service starts?
>
No, rule processing is completely separate from udevd's startup. All rules,
even those for devices that are detected "on boot", are run in response to
kernel uevents (either real or faked by systemd-udev-trigger), all of which
happens in udev's main event loop after it has already declared "ready".
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?
Hi all,
when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
another.service with After=systemd-udevd.service, can I at system boot rely on
my.service to be already run when another.service starts?
Here's the background to the question:
I'm developing an embedded device with autoupdate functionality. It grabs the
new disk image from an usb drive when plugged in. The udev rule and the systemd
units + shell scripts run all fine. The only thing complicating all this is
that at boot into the new system, the udev rule fires as well.
I worked around this in the following way:
* udev-triggered start-update.service runs only if
/persistent/update-running.stamp doesn't yet exist. When started, it creates
this file.
* autoscheduled conclude-update.service contains After=systemd-udevd.service
and removes /persistent/update-running.stamp.
I assumed this would at system boot ensure the start-update.service to be
started before conclude-update.service, hence not doing anything. Until
recently, this seemed to worked fine, but I have received reports making me
believe I was just witnessing a race condition resulting in my favor.
Best regards,
Manuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
