Re: [systemd-devel] systemd-nspawn and shared private network

[Igor Bukanov]

Lennart Poettering wrote:

>  One option could be to add --same-network= or so to nspawn

It seems it would be better to refer to the service unit that executed
nspawn, not the container running in the namespace created with
nspawn. This way I can refer to that unit using a stable name. Another
alternative that is even more useful is to allow for any service that
specifies PrivateNetwork= also specify how that network should be
initialized and connected to the outside world using the same options
that are available with nspawn.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [ISSUE] network block when it kill teamd service with "Before=network-pre.target"

[Xin Long]

I want teamd.service is stopped after network is stopped when system
shutdown, then I add two line in teamd.service as systemd-devel suggests.

Before=network-pre.target
Wants=network-pre.target

But in /etc/sysconfig/network-scripts/ifdown-Team, it also kills teamd with:

/usr/bin/systemctl stop teamd@${DEVICE}.service || exit 1

network service will call it when system shutdown

So it means network service seems trying to kill the service (teamd) that is
dependent on network service itself when system shutdown, then network
block there until 300s timeout.

I think it's the reason why it blocks.
If it's true, is there a good way to avoid or fix this ?

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

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Simon McVittie]

On 29/07/16 18:56, Simon McVittie wrote:
> So I'm not sure what you're doing, or
> where your dnscrypt-proxy.{socket,service} came from.

It's a bug in the Debian/Ubuntu packaging for dnscrypt-proxy, which have
their own fork of the systemd units, possibly derived from 1.6.0. I've
opened a bug in the Debian bug tracking system.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Simon McVittie]

On 29/07/16 18:46, Chip wrote:
> And I believe, yes, network must be operating before
> dnscrypt-proxy activates.  I'm guessing that some configuration file in
> /etc/systemd/system/ needs tweaking?

My normal advice would be to talk to dnscrypt-proxy upstream or the
supplier of your dnscrypt-proxy package... but if you're running Ubuntu
16.04, then you should have version 1.6.1, and this bug already appears
to have been fixed before 1.6.1. So I'm not sure what you're doing, or
where your dnscrypt-proxy.{socket,service} came from.

The change you need appears to be
,
and maybe

if that isn't in the version you're running.

It's dnscrypt-proxy.{socket,service} in /usr/lib/systemd/system or
/lib/systemd/system depending on distribution, although you can copy
them into /etc/systemd/system to make local modifications (or use
"drop-ins", see systemd.unit(5)).

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Chip]

On 07/29/2016 12:56 PM, Simon McVittie wrote:

On 29/07/16 16:59, Chip wrote:

On 07/29/2016 05:57 AM, Lennart Poettering wrote:

My educated guess is that some cyclic dependency or so caused it to
not be considered for activation at boot.

Lennart's guess was correct:


Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found ordering cycle
on basic.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
sockets.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
dnscrypt-proxy.socket/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
network.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
NetworkManager.service/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
dbus.service/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
basic.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Breaking ordering
cycle by deleting job sockets.target/start

You have asked systemd to do something impossible: basic.target depends
on dnscrypt-proxy.socket, which depends on network.target, which
indirectly depends on basic.target. systemd can't start them all in the
requested order, so it breaks the cycle in an essentially random place.

The bug here is probably that the dnscrypt-proxy.socket *socket* unit
should not depend on anything. You probably intended the corresponding
*service* unit, dnscrypt-proxy.service, to depend on network.target instead?

A socket unit just means systemd is listening on a socket: there's no
reason for it to depend on anything (except perhaps the creation of the
necessary directories, if it's an AF_UNIX socket). If you need the
network to be up before dnscrypt-proxy actually starts, then it's
dnscrypt-proxy.service that needs the dependency.

A wise analysis.  It makes sense.  Now, I'm not a startup maven and 
systemd is certainly very new to me.  How would you suggest I correct 
this?  And I believe, yes, network must be operating before 
dnscrypt-proxy activates.  I'm guessing that some configuration file in 
/etc/systemd/system/ needs tweaking?


/etc/ystemd/system/ contains:

bluetooth.target.wants  hibernate.target.wants
bootdlog.service hybrid-sleep.target.wants
chip-startupdnscryptproxy.service   multi-user.target.wants
dbus-org.bluez.service network-online.target.wants
dbus-org.freedesktop.Avahi.service  paths.target.wants
dbus-org.freedesktop.ModemManager1.service  printer.target.wants
dbus-org.freedesktop.nm-dispatcher.service  shutdown.target.wants
dbus-org.freedesktop.thermald.service   sockets.target.wants
default.target.wantssuspend.target.wants
display-manager.service sysinit.target.wants
display-manager.service.wants   syslog.service
getty.target.wants  timers.target.wants

multi-user.targets.wants contains:

anacron.serviceNetworkManager.service
avahi-daemon.service   openvpn.service
binfmt-support.service php7.0-fpm.service
cron.service   pppd-dns.service
cups-browsed.service   remote-fs.target
cups.path  rsyslog.service
dns-clean.service  snapd.refresh.timer
dnscrypt-proxy-resolvconf.service  snapd.service
dnscrypt-proxy.service systemd-resolved.service
ModemManager.service   thermald.service
networking.service ufw.service



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

Re: [systemd-devel] Where is systemd non-devel list?

[Che]

On Fri, Jul 29, 2016 at 5:52 AM, Lennart Poettering 
wrote:

> On Thu, 28.07.16 17:52, Chip (jeffsch...@gmail.com) wrote:
>
> > I see that my question re: issues with systemd, is more suited for non
> > development list.
> >
> > Is there a non development systemd list?
>
> There is none for now. Just use the -devel list. As long as the noise
> doesn't get too bad we'd like to keep this together, as it ensures the
> user's questions don't end up in nirvana but in the focus of
> developers.
>

Exactly the question I had.

This should definitely be a question in the FAQ for this elist.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Simon McVittie]

On 29/07/16 16:59, Chip wrote:
> On 07/29/2016 05:57 AM, Lennart Poettering wrote:
>> My educated guess is that some cyclic dependency or so caused it to
>> not be considered for activation at boot.

Lennart's guess was correct:

> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found ordering cycle
> on basic.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> sockets.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> dnscrypt-proxy.socket/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> network.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> NetworkManager.service/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> dbus.service/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> basic.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Breaking ordering
> cycle by deleting job sockets.target/start

You have asked systemd to do something impossible: basic.target depends
on dnscrypt-proxy.socket, which depends on network.target, which
indirectly depends on basic.target. systemd can't start them all in the
requested order, so it breaks the cycle in an essentially random place.

The bug here is probably that the dnscrypt-proxy.socket *socket* unit
should not depend on anything. You probably intended the corresponding
*service* unit, dnscrypt-proxy.service, to depend on network.target instead?

A socket unit just means systemd is listening on a socket: there's no
reason for it to depend on anything (except perhaps the creation of the
necessary directories, if it's an AF_UNIX socket). If you need the
network to be up before dnscrypt-proxy actually starts, then it's
dnscrypt-proxy.service that needs the dependency.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Chip]

On 07/29/2016 05:57 AM, Lennart Poettering wrote:

On Thu, 28.07.16 13:44, Chip (jeffsch...@gmail.com) wrote:


Ubuntu 16.04

With no changes to software or anything, on reboot, systemd *sometimes* will
start dnscrypt-proxy.service while other times just ignores it and it fails
to start. There is no rhyme or reason as to why sometimes it starts and
other times fails to start.

All files in /etc/systemd/system/multi-user.target.wants look correct.

I need help troubleshooting this problem.

Following is a successful journalctl -xru dnscrypt-proxy.service, otherwise
when it fails, it simply shows "no results":

My educated guess is that some cyclic dependency or so caused it to
not be considered for activation at boot.

To check that, look at the full boot-up process with "journalctl -b",
and see if your service is mentioned there, in particularly by PID 1.

Lennart


This is what a successful startup looks like:

Jul 29 11:33:06 blablabla systemd[1]: systemd 229 running in system mode.
Jul 29 11:33:06 blablabla systemd[1]: Detected architecture x86-64.
Jul 29 11:33:06 blablabla systemd[1]: Set hostname to .
Jul 29 11:33:06 blablabla kernel: random: nonblocking pool is initialized
Jul 29 11:33:06 blablabla kernel: clocksource: Switched to clocksource tsc
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found ordering cycle 
on basic.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
sockets.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
dnscrypt-proxy.socket/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
network.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
NetworkManager.service/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
dbus.service/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
basic.target/start
Jul 29 11:33:06 blablabla systemd[1]: basic.target: Breaking ordering 
cycle by deleting job sockets.target/start
Jul 29 11:33:06 blablabla systemd[1]: sockets.target: Job 
sockets.target/start deleted to break ordering cycle starting with 
basic.target/start

Jul 29 11:33:06 blablabla systemd[1]: Listening on Syslog Socket.
Jul 29 11:33:06 blablabla systemd[1]: Listening on fsck to fsckd 
communication Socket.



And then more specifically for successful startup:

ta@blablabla:~$ journalctl -b | grep dnscrypt

Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on 
dnscrypt-proxy.socket/start
Jul 29 11:33:11 blablabla audit[755]: AVC apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/dnscrypt-proxy" pid=755 comm="apparmor_parser"
Jul 29 11:33:12 blablabla ureadahead[282]: 
ureadahead:/var/lib/apt/lists/ppa.launchpad.net_anton+_dnscrypt_ubuntu_dists_xenial_main_binary-amd64_Packages: 
No such file or directory
Jul 29 11:33:17 blablabla systemd[1]: Listening on dnscrypt-proxy 
listening socket.
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] - [okturtles] 
does not support DNS Security Extensions
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] + Namecoin 
domains can be resolved
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] + Provider 
supposedly doesn't keep logs
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [NOTICE] Starting 
dnscrypt-proxy 1.6.7
Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] Generating a new 
session key pair

Jul 29 11:33:17 blablabla dnscrypt-proxy[1008]: [INFO] Done
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] Server 
certificate #809684433 received
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] This certificate 
is valid
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] Chosen 
certificate #809684433 is valid from [2016-01-24] to [2017-01-23]
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [INFO] Server key 
fingerprint is 
CB51:0B61:88Y2:FCEB:27CE:56B5:3567:978A:04FF:D9E7:42A4:6A6B:0943:0F0F:F084:656C
Jul 29 11:33:22 blablabla dnscrypt-proxy[1008]: [NOTICE] Proxying from 
127.0.2.1:53 to 23.226.215.93:443

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

Re: [systemd-devel] How to securely load a firewall before networking gets up?

[Patrick Schleizer]

Thank you! I forwarded your review in form of bug reports to the
affected projects. [1] [2]

Lennart Poettering:
> On Thu, 28.07.16 17:29, Patrick Schleizer (patrick-mailingli...@whonix.org) 
> wrote:
> 
>> TLDR:
>>
>> How to securely load a firewall before networking gets up?
>>
>> Can you provide a secure, recommended or even canonical example of such
>> a firewall.service?
> 
> See https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

With all due respect, I do not think this is a case of read the manual here.

I did read that also before posting this question. I am sure also
rustybird, the author of the second systemd unit file I posted in this
subject, also read that before. As rustybird (who also once submitted a
systemd patch wrt network-pre.target) pointed out, the author of
netfilter-persistent also got it wrong. [1]

Having explained this, I would like to reiterate my my request...

Can you provide a secure, recommended or even canonical example of such
a firewall.service?

Cheers,
Patrick

[1] https://github.com/rustybird/corridor/issues/29
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832911
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829640

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

Re: [systemd-devel] enable/disable swap before/after hibernation

[Lukas Pirl]

> If clients ask logind whether hibernation is available or try to 
> initiate hibernation we check whether swap is available and refuse
> if it isn't. This means if you add the swap only after the
> hibernation was already initiated then this will not be able to
> affect the check anymore.

I expected something like that – thanks for the explanation.

> You can bypass this check by setting the 
> SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK env var for the logind
> service (add a drop-in using Environment= for it).
> 
> See https://github.com/systemd/systemd/pull/3064 and related.

Excellent pointer! Thanks Lennart!

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

Re: [systemd-devel] systemd-nspawn and shared private network

[Lennart Poettering]

On Thu, 28.07.16 20:19, Igor Bukanov (i...@mir2.org) wrote:

> Hello,
> 
> I am trying to see how to implement with systemd-nspawn a version of
> docker's pod when a group of very lightweight containers use a
> loopback interface or unix sockets to communicate with each other and
> a shared network interface to communicate with the outside world.
> Otherwise the containers are isolated and do not share process and
> other namespaces.
> 
> My impression from the documentation is that I should create a version
> of systemd-nspawn@.service that uses JoinsNamespaceOf to join the
> namespace of the main service for the pod. That main service should
> configures container networking, expose ports to host etc. For that I
> plan to use systemd-nspawn --network-veth  ...

This won't work. JoinsNamespaceOf= only has an effect on networking if
you set PrivateNetwork= too. But if you use --network-veth (or the
related options) in nspawn then this means that nspawn will open its
own network namespace anyway, independent from the network namespace
it was invoked from. Hence, if you set PrivateNetwork=1 in your
service, you detach nspawn one level from the host's network
namespace, and then with nspawn's --network-veth your detach the stuf
running inside of the container one level further from the host. You
hence end up with three network namespaces in total: one for host, one
for the nspawn process itself, and a thrid one for the stuff running
inside of the container.

> The problem I do not see how to pass the name of the main service
> created with systemd-nspawn to that template. Obviously I can create
> own unit for the main service that contains PrivateNetwork=true, but
> then I cannot use --network-veth with nspawn as that configures the
> namespace that nspawn creates, not the one from the unit.
> 
> Any suggestions?

The only way you can do this right now is by not using any of nspawn's
own network namespacing features, but instead use JoinsNamespaceOf= +
PrivateNetwork=1 to let the service set up things, and then use the
"ip" tool to set up what you need before that. But YMMV...

Long story short: we do not cover this nicely at the moment. And I am
not entirely how we should cover it. One option could be to add
--same-network= or so to nspawn which takes another container name and
then runs the container in the exact same network namespace as that
other container. 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hardware clock

[Lennart Poettering]

On Wed, 27.07.16 19:54, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> Hello.
> 
> There is, it seems, a problem with the hardware clock. That is, the
> systemd does not care about it. Neither systemd nor udev rules set the
> system time using the hardware clock.
> From what I know, if the clock is a cmos rtc, the kernel always sets
> time during bootup. In any other case, it should do this anyway if it is
> configured to do so during compilation, but only when appropriate rtc
> support is compiled into the kernel. So, userspace does not have to.
> The problem is that there are cases when the rtc is not a cmos one, and
> the driver is compiled as a module. This is a specific case because the
> kernel will not restore the time, and systemd does not do this either.
> The thing that restores the time is ntp synchronization and that is not
> related to the hardware clock.
> This issue is visible in case of arm boards with external realtime
> clocks, as those clocks are bought separately and not part of the
> platform. It would be nice if systemd would set the time, or if udev had
> a rule to do this, or both (in case the module was loaded earlier during
> initramfs phase). Or any other solution for that would be nice.

We don't really cover cases where the RTC driver is loaded as kernel
module during later boot. Our general suggestion is to compile the RTC
drivers you need directly into the kernel, and let the kernel
initialize the system clock from it.

If you compile your RTC drivers as kernel modules loaded late then I'd
suggest writing udev rules that sync the clocks as soon as the drivers
are loaded.

Generally it's a good idea though to leave this all to the kernel, so
that userspace comes up with a correctly set system clock already, so
that logging doesn't use broken realtime timestamps.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] enable/disable swap before/after hibernation

[Lennart Poettering]

On Thu, 28.07.16 19:25, Lukas Pirl (syst...@lukas-pirl.de) wrote:

> Dear list,
> 
> I want to enable/disable the swap partition before/after hibernation.
> 
> However, it seems I cannot get the service to run early enough to avoid
> the error:
> 
>   Failed to hibernate system via logind: Sleep verb not supported

If clients ask logind whether hibernation is available or try to
initiate hibernation we check whether swap is available and refuse if
it isn't. This means if you add the swap only after the hibernation
was already initiated then this will not be able to affect the check
anymore.

You can bypass this check by setting the
SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK env var for the logind service
(add a drop-in using Environment= for it).

See https://github.com/systemd/systemd/pull/3064 and related.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

[Lennart Poettering]

On Thu, 28.07.16 13:44, Chip (jeffsch...@gmail.com) wrote:

> Ubuntu 16.04
> 
> With no changes to software or anything, on reboot, systemd *sometimes* will
> start dnscrypt-proxy.service while other times just ignores it and it fails
> to start. There is no rhyme or reason as to why sometimes it starts and
> other times fails to start.
> 
> All files in /etc/systemd/system/multi-user.target.wants look correct.
> 
> I need help troubleshooting this problem.
> 
> Following is a successful journalctl -xru dnscrypt-proxy.service, otherwise
> when it fails, it simply shows "no results":

My educated guess is that some cyclic dependency or so caused it to
not be considered for activation at boot.

To check that, look at the full boot-up process with "journalctl -b",
and see if your service is mentioned there, in particularly by PID 1.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Where is systemd non-devel list?

[Lennart Poettering]

On Thu, 28.07.16 17:52, Chip (jeffsch...@gmail.com) wrote:

> I see that my question re: issues with systemd, is more suited for non
> development list.
> 
> Is there a non development systemd list?

There is none for now. Just use the -devel list. As long as the noise
doesn't get too bad we'd like to keep this together, as it ensures the
user's questions don't end up in nirvana but in the focus of
developers.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to securely load a firewall before networking gets up?

[Lennart Poettering]

On Thu, 28.07.16 17:29, Patrick Schleizer (patrick-mailingli...@whonix.org) 
wrote:

> TLDR:
> 
> How to securely load a firewall before networking gets up?
> 
> Can you provide a secure, recommended or even canonical example of such
> a firewall.service?

See https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

> [Unit]
> Description=firewalld - dynamic firewall daemon
> Before=network.target

This is pointless and really doesn't do what the author of this file
might think it does.

> [Service]
> ExecStart=/usr/sbin/firewalld --nofork --nopid
> ExecReload=/bin/kill -HUP $MAINPID
> # supress to log debug and error output also to /var/log/messages
> StandardOutput=null
> StandardError=null
> Type=dbus
> BusName=org.fedoraproject.FirewallD1
> 
> [Install]
> WantedBy=basic.target

This is actively broken. A unit that hooks into basic.target *must*
set DefaultDependencies=no, otherwise this will result in a cyclic
dependency.

> [Unit]
> Description=corridor's forwarding
> After=iptables.service systemd-sysctl.service
> Before=network-pre.target
> Wants=network-pre.target

This is correct.
> 
> [Service]
> ExecStart=SBIN/corridor-init-forwarding
> ExecStop=SBIN/corridor-stop-forwarding

The "SBIN/" doesn't look right.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel