Re: [systemd-devel] Question: path-based deactivation or equivalent

[Matthew Giassa]

Additionally, does systemd support assigning an environment variable to an 
internal variable, ie:

Environment=MYPIDFILE=/var/run/mine.pid
PIDFILE=$MYPIDFILE

I know there are workarounds for ExecStart for example, using /bin/bash to 
evaluate environment variables, but I think that special case only applies to 
ExecStart, ExecStartPre, and Executor, as they actually get executed rather 
than just assigned, allowing for some degree of variable expansion.

There are a few systemd options I would like to set like this so that I don't 
have to type the same string literals twice (reduce chances of a typo causing a 
bug), and for the process to know certain systemd-related values without having 
to hard code them in systemd scripts and the project source (write once, use 
everywhere).

Thank you.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: matt...@giassa.net
Sent: Tuesday, September 26, 2017 4:15 PM
To: systemd-devel@lists.freedesktop.org
Subject: Question: path-based deactivation or equivalent

I have a project where I'm adding some services to a Raspberry Pi 3,
and have decided to go with systemd being (mostly) responsible for
launching all of the services. All of the server processes use a common
API to do some initial setup (argument parsing, init, etc), drop root
permissions, and then carry out their normal duties. One of these
services is the "master" service, which I want to use to
activate/deactivate other services on-demand.

I started out with path-based activation via systemd, and that
worked fine for bringing up the services as I requested them. However,
it seems there is no equivalent path-based deactivation functionality at
this time [1], so it's definitely not an option on the older OS deployed
on my dev board.

I've looked into finding a suitable workaround, but the only viable
option so far is a hack that involves creating two separate systemd
scripts for a single service [2]. Is there some other functionality to
systemd that would permit me to:
-Activate and deactivate a service on demand (i.e. start it; stop it via
SIGNIT and after a timeout send it SIGKILL).
-Only have a single systemd script per service rather than the
two-scripts-per-service hack noted in [2].
-Allow a non-root (unprivileged) user to invoke my API/wrapper to
start/stop the services/daemons I maintain.
-Provide similar activation logic to path-based activation (i.e. only
start the service if both its dependencies on other services has been
met, AND the path/socket/etc exists).

Some of these services are provided to me in binary-only form, so I
can't necessarily modify all of them from source. Also, I'm not allowed
to use the LD_PRELOAD approach to injecting features. For all intents
and purposes, let's assume I can only modify my "manager" service, and
the systemd scripts for all services.

Thank you for your time and assistance.

Addendum:

I'm doing this to automate a test suite that evaulates how the
various services handle failure cases when one or more random services
goes up and down. The test suite, like the services/daemons themselves,
is not permitted root access, and has to be able to run as an
unprivileged user (i.e. no "systemctl $SERVICENAME start|stop" is
permitted via the command line). If there's an equivalent to the
path-based activation/deactivation as noted in [2], it makes my life a
lot easier.

Eventually, some services may be able to sidestep the "master"
service, and kill off other services (i.e. dependencies), so having the
"master" service just kill() the other services is not viable long-term.

References:

1. "RFE: systemd.path should support deactivation #3642",
, Last accessed 2017-09-26.

2. "Can I use systemd to start and stop a service based on the presence
of a file?",
,
Last accessed 2017-09-26.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Dedup timers?

[Peter Hoeg]

Hi,


I have a number of timers that all look something like the following:



The boilerplate for such small things is killing me. Is there a good
technique to replace them with something simpler?
Maybe transient timers? What will be the drawbacks of transient timers
comparing to regular timers?


From man systemd.time:

  The following special expressions may be used as shorthands for longer 
normalized forms:

  minutely → *-*-* *:*:00
hourly → *-*-* *:00:00
 daily → *-*-* 00:00:00
   monthly → *-*-01 00:00:00
weekly → Mon *-*-* 00:00:00
yearly → *-01-01 00:00:00
 quarterly → *-01,04,07,10-01 00:00:00
  semiannually → *-01,07-01 00:00:00


--
Regards,
Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to generate core file in system service

[Kai Krakow]

Am Mon, 25 Sep 2017 10:26:48 +0200
schrieb Miroslav Suchý :

> Dne 25.9.2017 v 08:47 Mantas Mikulėnas napsal(a):
> > But when I start the deamon by "teamd" directly, I could get core
> > file. When I start it by systemctl start teamd@team0.service, no
> > core file was generate when it crashed, but only get:
> >    "systemd: teamd@team0.service: main process exited, code=killed,
> > status=6/ABRT"
> > in /var/log/messages.  
> 
> I guess this crash has been caught by ABRT.
> 
> Try:
>   abrt-cli list

Also try "coredumpctl list". Maybe systemd-coredump did catch the dump.

This is the case if sysctl kernel.core_pattern pipes to
/lib/systemd/systemd-coredump.


-- 
Regards,
Kai

Replies to list-only preferred.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Question: path-based deactivation or equivalent

[matthew]

  I have a project where I'm adding some services to a Raspberry Pi 3,
and have decided to go with systemd being (mostly) responsible for
launching all of the services. All of the server processes use a common
API to do some initial setup (argument parsing, init, etc), drop root
permissions, and then carry out their normal duties. One of these
services is the "master" service, which I want to use to
activate/deactivate other services on-demand.

  I started out with path-based activation via systemd, and that
worked fine for bringing up the services as I requested them.  However,
it seems there is no equivalent path-based deactivation functionality at
this time [1], so it's definitely not an option on the older OS deployed
on my dev board.

  I've looked into finding a suitable workaround, but the only viable
option so far is a hack that involves creating two separate systemd
scripts for a single service [2]. Is there some other functionality to
systemd that would permit me to:
-Activate and deactivate a service on demand (i.e. start it; stop it via
SIGNIT and after a timeout send it SIGKILL).
-Only have a single systemd script per service rather than the
two-scripts-per-service hack noted in [2].
-Allow a non-root (unprivileged) user to invoke my API/wrapper to
start/stop the services/daemons I maintain.
-Provide similar activation logic to path-based activation (i.e. only
start the service if both its dependencies on other services has been
met, AND the path/socket/etc exists).

  Some of these services are provided to me in binary-only form, so I
can't necessarily modify all of them from source. Also, I'm not allowed
to use the LD_PRELOAD approach to injecting features. For all intents
and purposes, let's assume I can only modify my "manager" service, and
the systemd scripts for all services.

Thank you for your time and assistance.

Addendum:

  I'm doing this to automate a test suite that evaulates how the
various services handle failure cases when one or more random services
goes up and down. The test suite, like the services/daemons themselves,
is not permitted root access, and has to be able to run as an
unprivileged user (i.e. no "systemctl $SERVICENAME start|stop" is
permitted via the command line). If there's an equivalent to the
path-based activation/deactivation as noted in [2], it makes my life a
lot easier.

  Eventually, some services may be able to sidestep the "master"
service, and kill off other services (i.e. dependencies), so having the
"master" service just kill() the other services is not viable long-term.

References:

1. "RFE: systemd.path should support deactivation #3642",
 , Last accessed 2017-09-26.

2. "Can I use systemd to start and stop a service based on the presence
 of a file?",
 
,
 Last accessed 2017-09-26.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Dedup timers?

[Kai Krakow]

Am Mon, 25 Sep 2017 22:45:23 -0700
schrieb Daniel Wang :

> I have a number of timers that all look something like the following:
> 
> cat /etc/systemd/system/foo.timer
> [Unit]
> Description=Run foo every hour
> 
> [Timer]
> OnCalendar=hourly
> 
> cat /etc/systemd/system/bar.timer
> [Unit]
> Description=Run bar every minute
> 
> [Timer]
> OnCalendar=minutely
> 
> ... (this list goes on and on)
> 
> The boilerplate for such small things is killing me. Is there a good
> technique to replace them with something simpler?
> Maybe transient timers? What will be the drawbacks of transient timers
> comparing to regular timers?

Make them into targets:

$ systemctl cat timer-{daily,hourly}.{target,timer}
# /etc/systemd/system/timer-daily.target
[Unit]
Description=Daily Timer Target
StopWhenUnneeded=yes

# /etc/systemd/system/timer-daily.timer
[Unit]
Description=Daily Timer

[Timer]
OnBootSec=10min
OnUnitActiveSec=1d
Unit=timer-daily.target
AccuracySec=12h
Persistent=yes

[Install]
WantedBy=timers.target

# /etc/systemd/system/timer-hourly.target
[Unit]
Description=Hourly Timer Target
StopWhenUnneeded=yes

# /etc/systemd/system/timer-hourly.timer
[Unit]
Description=Hourly Timer

[Timer]
OnBootSec=5min
OnUnitActiveSec=1h
Unit=timer-hourly.target
AccuracySec=30min
Persistent=yes

[Install]
WantedBy=timers.target



Then install your services into the target:

$ systemctl cat porticron.service
# /etc/systemd/system/porticron.service
[Unit]
Description=Check for upgrades and security updates

[Service]
Type=oneshot
IOSchedulingClass=idle
IOSchedulingPriority=7
CPUSchedulingPolicy=batch
Nice=7
ExecStart=/usr/sbin/porticron

[Install]
WantedBy=timer-daily.target


Enable timer targets:

$ systemctl enable timer-{daily,hourly}.timer
Created symlink /etc/systemd/system/timers.target.wants/timer-daily.timer → 
/etc/systemd/system/timer-daily.timer.
Created symlink /etc/systemd/system/timers.target.wants/timer-hourly.timer → 
/etc/systemd/system/timer-hourly.timer.


There's no need to enable the services then as they are triggered by
the timer targets:

$ systemctl list-timers
NEXT  LEFTLAST  
PASSEDUNIT ACTIVATES
Tue 2017-09-26 22:07:50 CEST  58min left  Tue 2017-09-26 21:07:50 CEST  
1min 29s ago  timer-hourly.timer   timer-hourly.target
Wed 2017-09-27 01:22:26 CEST  4h 13min left   Tue 2017-09-26 01:16:59 CEST  
19h ago   timer-daily.timertimer-daily.target


As the targets are stopped when unneeded (thus each triggered service
stopped), they will be fired again next time. Just make sure your
triggered services actually stop: They should be Type=oneshot.


-- 
Regards,
Kai

Replies to list-only preferred.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Dedup timers?

[Auke Kok]

On 09/25/2017 10:45 PM, Daniel Wang wrote:
> I have a number of timers that all look something like the following:

> The boilerplate for such small things is killing me. Is there a good
> technique to replace them with something simpler?
> Maybe transient timers? What will be the drawbacks of transient timers
> comparing to regular timers?


I assume timers can be instanced as well:

hourly@.timer:

>>>

[Unit]
Description=Runs a unit every hour

[Timer]
OnCalendar=hourly
Unit=%I

<<<

But, this is totally hypothetical, I have not tested if this actually works.

Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel