Assume I have a one-shot service, *phase1.service*, which runs for a while
and then terminates. I want to have a *phase2.service* start up when phase1
terminates.
I cannot change anything in phase1.service's systemd files or code or
anything, or I would not be asking this question!
A dirty
On Tue, Mar 20, 2018 at 8:47 AM, Andrei Borzenkov <arvidj...@gmail.com>
wrote:
> On Tue, Mar 20, 2018 at 12:52 AM, John Ioannidis <systemd-de...@tla.org>
> wrote:
>
>
> > I can get them to start the first time, but they do not stop when
> > configuration files
I want to have a service with several instances, each of which has a
configuration file; when configuration files appear and disappear, I want
the corresponding instances to be created and started, and die,
respectively, and in particular have the running processes corresponding to
the removed
On Mon, Mar 19, 2018 at 5:52 PM, John Ioannidis <systemd-de...@tla.org>
wrote:
> I want to have a service with several instances, each of which has a
> configuration file; when configuration files appear and disappear, I want
> the corresponding instances to be created and s
I am running systemd v241, the one that comes with debian-10.
Is the following scenario possible natively (that is, without using a
standalone dhcpv6 client)?
- My residential ISP will normally hand me a /64, but will give me a /56
if I ask for it. While technically not a
Is there a document somewhere that details what the
interactions/conflicts/etc are between systemd.{link,netdev,network} and
the ifupdown mechanisms? I have read the manual pages, of course, but I
feel I'm missing something fundamental. I finally got around to moving to
Debian 10, and in the
I'm trying to be a good boy and migrate as much functionality as I can to
networkd.
I'm happy with how networkd manages "internal" and "external" interfaces
and vlans for just setting up IPv4 addresses, but I still find support for
IPv6 to be woefully inadequate, at least for my environment;
I have an instanced service that gets started and stopped by another
service: *alice.service *runs the equivalent of *systemsctl start
alice@foo.service, systemctl start alice@bar.service, systemctl stop
alice@cat.service*, and so on.
Each of the instanced services runs a little http service so
a .socket unit gets activated, and subsequently starts its
corresponding service, when the first connection is made. The primary
purpose of the service is not to serve data over that socket; the socket is
there for scraping metrics.
Thanks though,
/ji
> On Mon, Jun 14, 2021 at 9:17 PM John
ks though,
/ji
> On Tue, Jun 15, 2021, 04:18 John Ioannidis wrote:
>
>> I have an instanced service that gets started and stopped by another
>> service: *alice.service *runs the equivalent of *systemsctl start
>> alice@foo.service, systemctl start alice@bar.service, sy
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
I have the following service file:
[Unit]
Description=D
After=network.target
[Service]
ExecStart=/usr/local/sbin/mktags.py
Type=oneshot
User=root
[Install]
WantedBy=multi-user.target
Occasionally, when the machine reboots, it does not run. Here is the
evidence:
# uptime
05:50:11 up 20 min,
How can I trace what sd_notify(3) calls a program makes?
Obviously, I don't have the source, and running *strings* on it does reveal
a *READY=1* line, but it is unclear whether the code makes it to the point
where that gets sent.
Here is what I am *really* trying to accomplish; maybe I am going
Here are my .path and .service files:
$ *cat /etc/systemd/system/trigg.path *
[Path]
DirectoryNotEmpty=/root/trigger
MakeDirectory=true
$ *cat /etc/systemd/system/trigg.service *
[Unit]
Description=Trigger Service
[Service]
ExecStart=/usr/bin/touch /root/wastriggered
Type=oneshot
Now, after
On Sun, Mar 20, 2022 at 5:26 PM John Ioannidis
wrote:
> Here are my .path and .service files:
>
> $ *cat /etc/systemd/system/trigg.path *
> [Path]
> DirectoryNotEmpty=/root/trigger
> MakeDirectory=true
>
> $ *cat /etc/systemd/system/trigg.service *
> [Unit]
&g
15 matches
Mail list logo
