[systemd-devel] resolved and persistent routing domains

[Igor Bukanov]

Hi,

I have OpenVPN setup to connect to an intranet. The setup scripts push
to systemd-resolved a DNS configuration for the intranet including the
list of routing domains. This makes sure that the names from those
domains are only resolved  using nameservers from the intranet.

But when VPN is switched off, the rules are reset. So internal names
are leaked to external nameservers if I use them accidentally in a
web-browser. Is it possible to prevent that? For example, like keeping
the domains and nameservers even when the link is down or disaapeares
until the new settings for the link are pushed to the resolved?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

On 7 June 2018 at 10:35, Lennart Poettering  wrote:
> Nah, daemon() does not write PID files, you have to do that in your
> own code.

As daemon() calls _exit() (not even exit()) in the parent after the
fork, the only way to synchronize the pid writing is not to use the
daemon() at all and inline daemon() functionality. I doubt that it
will ever be done for the wast majority of sources using the function.
And under systemd there are zero incentives to do that as the
workaround with waiting for the pid file to appear is good enough to
make things reliable. So as such the warning that currently systemd
produces is just a distraction that a user cannot do nothing about.

As a side note the usage of daemon() in 3 from 4 sources I randomly
picked up on github is wrong as the code calls the function and then
writes the pid file right after parsing the config before any
initialization of sockets, but that just pointed out how lack of
simple service initialization API lead to everybody inventing own
buggy code...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

On 18 May 2018 at 19:37, Lennart Poettering  wrote:
> On Do, 17.05.18 22:54, Igor Bukanov (i...@mir2.org) wrote:
> Well, no. The protocol is clear, and what we do is pretty close to
> black magic, and still racy in many ways.
>
> I mean, broken behaviour is still broken behaviour, even if we
> nowadays handle it pretty nicely. Really, nginx should be fixed,
> everybody benefits, sysvinit as much as we do.

It turned out it is not only nginx that behaves this way. Any program
that is using the daemon(3) call available both in Linux and BSD
writes the pid from the child without the parent waiting. So this
behaviour must be widespread and as such I think must be accepted as a
de-facto standard (even if it is unfortunate) and systemd should not
even warn about it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] logging to a fifo pipe

[Igor Bukanov]

Hi,

I need to log to the journal with custom tags from a service that only
supports logging to syslog without any customization or logging to a
file. I cannot use /dev/stderr as the logging is done from a child
process that the main service process starts with /dev/stderr
redirected. I worked around that by having a named pipe connected to
the logger utility. But that required an extra two units (one for the
socket with the named pipe and another for the logger process) and an
extra process.

Is there any better way to do that?

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

Re: [systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

On 17 May 2018 at 19:23, Lennart Poettering  wrote:

> So yes, this is a bug in nginx. They really should fix that. And this
> is not only broken when you use systemd, but on sysvinit too, as a
> command like this would likely fail there too: "service nginx start
> service nginx status", as the start would return before the PID file
> is written, and then status would claim the service to be down...

Given that systemd deals with this situation in a very reasonable way,
nginx must not be alone in doing this. And if this a common way to
write such code, perhaps it should not be considered a bug but rather
one more peculiarity of application services the service manager
should deal
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

On 17 May 2018 at 11:58, Mantas Mikulėnas  wrote:
> this would be anyways broken because systemd reads the PIDFile once at
> start to dtermine MAINPID and if MAINPID goes away the service fails

This is not true as with PIDFile systemd does pick up the new process
as a new main without restarting the unit. This is an example from my
development VM:

systemctl status nginx
...
   Active: active (running) since Thu 2018-05-17 11:02:57 UTC; 3min 18s ago
 Docs: man:nginx(8)
  Process: 2407 ExecStart=/usr/sbin/nginx ...
 Main PID: 2408 (nginx)
   CGroup: /system.slice/nginx.service
   ├─2408 nginx: master process ...
   ├─2409 nginx: worker process
   └─2410 nginx: worker process

Initiate a graceful restart of nginx:

kill -s USR2 2408
systemctl status nginx
...
   Active: active (running) since Thu 2018-05-17 11:02:57 UTC; 5min ago
 Docs: man:nginx(8)
  Process: 2407 ExecStart=/usr/sbin/nginx ...
 Main PID: 2408 (nginx)
   CGroup: /system.slice/nginx.service
   ├─2408 nginx: master process /usr/sbin/nginx ...
   ├─2409 nginx: worker process
   ├─2410 nginx: worker process
   ├─2418 nginx: master process /usr/sbin/nginx ...
   ├─2419 nginx: worker process
   └─2420 nginx: worker process

Notice that there are 2 master processes, the old one with pid 2408
and the one 2418. Initiate the shutdown of the initial master:

kill -s QUIT 2408
systemctl status nginx
   Active: active (running) since Thu 2018-05-17 11:02:57 UTC; 7min ago
 Docs: man:nginx(8)
  Process: 2407 ExecStart=/usr/sbin/nginx -c
/vol/opt/act/webapp/nginx/nginx.conf -g daemon on; master_process on;
worker_processes auto; pid /run/nginx/nginx.pid; error_log sys
 Main PID: 2418 (nginx)
   CGroup: /system.slice/nginx.service
   ├─2418 nginx: master process /usr/sbin/nginx -c
/vol/opt/act/webapp/nginx/nginx.conf -g daemon on; master_process on;
worker_processes auto; pid /run/nginx/nginx.pid;
   ├─2419 nginx: worker process
   └─2420 nginx: worker process

Here systemd correctly recognized 2418 as the new master without
restarting the unit as seen by active time.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

On 17 May 2018 at 12:07, Michael Chapman  wrote:
> It _is_ better for the PID file to be written out before the initial
> process exits, but systemd will handle things correctly even if they
> happen the other way around. Essentially the service won't be considered
> to have completed activation until both events occur. If one or the other
> takes too long (i.e. longer than the TimeoutStartSec= setting), the unit
> will fail.

Does it means that even ExecStartPost and especially ExecReload can
always safely use $MAINPID? I.e. does systemd call these Execs only
after it managed to read the the pid file even when the file is
written after the initial ExecStart process exited?

And yes, Type=pid-file will be very useful. I have exactly a shell
script that will benefit from it nicely.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

On 17 May 2018 at 11:58, Mantas Mikulėnas  wrote:
> Have you tried without the PIDFile= setting at all?

As far as I can see that breaks live updates that nginx supports where
it starts a new process and workers and then gracefully terminates the
old main.

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

[systemd-devel] option to wait for pid file to appear

[Igor Bukanov]

Hi,

I have a service unit for nginx that uses Type=forking and PIDFile.
That works, but occasionally I see in the log a message like

nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
start: No such file or directory

After investigating this father I see the reason for this is that
nginx creates the pid file in a child process, not in the parent (at
least this is how I interpret their code). As the parent may exit and
systemd may respond to it before the child writes the pid, that leads
to the above message.

I can workaround that via replacing ExecStart=/usr/sbin/nginx with
something like:

ExecStart=/bin/sh -c "set -e; /usr/sbin/nginx; while ! test -s
/run/nginx/nginx.pid; do sleep 0.1; done'

but that busy waits. Is there any option to replace this hack via a
native systemd solution, like explicitly waiting for the pid file to
appear before considering the unit ready?

Regards, Igor Bukanov
___
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

[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] systemd-nspawn and shared private network

[Igor Bukanov]

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  ...

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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] resolved and bind-mount of /etc/resolv.conf

[Igor Bukanov]

Hi,

currently if one runs systemd-resolved, then  /etc/resolv.conf should
be symlinked to /run/systemd/resolve/resolv.conf . Is  it possible
instead to add an option for resolved to bind-mount /etc/resolv.conf
into the real file when it starts?

This way stopping or disabling resolved will not require to update the
symlink and parallel installation of 2 resolvers is possible when the
decision to use a particular one can be done at runtime with no
changes in /etc.

I suppose I already can do with service ExecStartPost, ExecStart hooks
for resolved, but this is rather hackish as I do not know if resolved
updates the file in place (which is compatible with bind-mount) or via
rename of a temporary (which is not).

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

[systemd-devel] process hangs on mount with automount unit with TimeoutIdleSec

[Igor Bukanov]

Hi,

I have an automount unit that mounts sshfs filesystem via
corresponding mount unit. Without recently introduced TimeoutIdleSec
in [Automount] this works as expected even when ssh cannot connect to
the host.

For example, if I disconnect the network and try to `ls mount-point`,
I get expected:

ls: cannot open directory /set/kino: No such device

If I restore the network, the directory is mounted and ls shows its context.

However, if under systemd 222 under Fedora 23 I add TimeoutIdleSec=30
to the automount unit, reboot the system and disconnect network, then
as before `ls mount-point` shows the same error. But when I restore
network and try `ls mount-point`, the `ls` process just hangs. It
cannot be killed even with kill -9. Running `systemctl restart
mount-pint-unit-file.mount` makes ls to terminate.

Is it a known bug? During that hang  `systemctl status
mount-pint-unit-file.mount` shows:

  Active: failed (Result: exit-code) since Tue 2015-12-01 11:56:09
CET; 21min ago
  Process: 1483 ExecMount=/usr/bin/mount ...  (code=exited, status=1/FAILURE)

Dec 01 11:56:09 untrusted mount[1483]: read: Connection reset by peer
Dec 01 11:56:09 untrusted systemd[1]: xyz.mount: Mount proc...=1
Dec 01 11:56:09 untrusted systemd[1]: xyz.mount: Unit enter...e.
Dec 01 11:56:42 untrusted systemd[1]: Unmounted /xyz.

systemctl status mount-pint-unit-file.automount gives active (running)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] automount and user

[Igor Bukanov]

Hello,

I am trying to translate an autofs map into systemd unit files, but I
could not see how to pass to the mount command an option refering to
the user who accessed the mount dir. For example, the automap
contains:

/mount/dir -fstype=fuse.sshfs,...,id=$UID,gid=$GID remote_user@host:/dir

which mounts /mount/dir as the user whose process accessed /mount/dir
first. How do I simulate this with systemd mount/automount units?


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

Re: [systemd-devel] automount and user

[Igor Bukanov]

On 18 November 2015 at 13:23, Lennart Poettering  wrote:
> The problem is with actually invoking processes such as the fuse.sshfs
> one as a non-root user.

But in my case there are no non-root processes! uid/gid options is
used just for *ownership of files and directories* under the mount
point, the fuse.sshfs process itself is run as a root. Moreover, it
uses an ssh private key that only the root can read to avoid exposing
the key to the user to minimize harm that a malware can do if the user
is infected.

In any case, I thought that I missed something, but I just need to
accept that systemd indeed does not support exposing uid/gid of the
first process that accessed the automount dir to the mount process
even if the latter runs as a root.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] automount and user

[Igor Bukanov]

On 18 November 2015 at 12:28, Lennart Poettering  wrote:
> We don't support that. Invoking user processes from a system context
> is something we generally avoid.

Could you clarify how this is related to an ability to invoke a user
process? For example, I can explicitly pass uid=1000,gid=1000 as a
mount option to fuse.sshfs and that makes the mounted tree owned by
that user also with systemd mount/automount.

What I see is that systemd lacks an ability to pass to the mount
command an automount context like UID/GID of the process that accessed
the mount point first. But I do not see how that can harm security
besides an extra code complexity.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-detect-virt and virtualbox 5.0

[Igor Bukanov]

Hello,

forthcoming VirtualBox 5.0 hypervisor (currently at RC1) supports
paravirtualization using Hyper-V or KVM interfaces. When the latter is
used with a linux guest then systemd-detect-virt prints kvm. I suppose
at least the manual page for systemd-detect-virt should be updated to
indicate that  the command output does not reflect a particular
implementation but names hupervisor technology.

However, the issue then is what to do with ConditionVirtualization=
testing for oracle in unit files. Under kvm mode that gives false
preventing in my case mounting a host directory with config files
using vboxsf module. I suppose I should just deal with that and try to
mount vboxsf share both under kvm and oracle, but perhaps
systemd-detect-virt should be updated to still print oracle even when
VirtualBox uses paravirtualization?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-resolved as dnsmasq replacement

[Igor Bukanov]

On 17 June 2015 at 15:27, Lennart Poettering lenn...@poettering.net wrote:
 To hook up local name service
 clients people should use the nss-resolve NSS module, which ensures
 that gethostbyname() and friends use resolved as backend.

I suppose then non-glibc clients should deal with that on its own. I
thought converting LLMNR into DNS would be a reasonable hack, but then
if the translation requires too much insanity, then indeed it is
better not to do that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-resolved as dnsmasq replacement

[Igor Bukanov]

Hello,

perhaps I missed something, but it seems that systemd-resolved cannot
be configured to serve the same role as dnsmasq and be a DNS server
for local machine.  I.e. I cannot just have nameserver 127.0.0.1 in
/ertc/resolv.conf and get LLMNR resolution working for progams that
only use nameservers from /etc/resolv.conf .

Is it really true and this is indeed an unimplemented feature?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is-enabled and generated units

[Igor Bukanov]

On 14 June 2015 at 12:10, Andrei Borzenkov arvidj...@gmail.com wrote:
 Not really. systemctl enable|disable|is-enabled explicitly work on
 links defined by [Install] section only.

This is not true. According to systemctl is-enabled man page for
services without [Install] the command should succeed and print
static, not fail with an error message.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is-enabled and generated units

[Igor Bukanov]

The reason for .d + .conf, not .wants, is that in my case .conf file
contains several Wants directives including one for a service that is
installed but not not enabled by default. As I do not know the
location of that service unit file (depending on OS or installation it
can be under /usr/lib, /usr/lib64, /etc/ /run/), I use the .conf
fragment as there the Wants does not require to specify an absolute
path.

On 14 June 2015 at 11:52, Michael Biebl mbi...@gmail.com wrote:
 2015-06-14 11:17 GMT+02:00 Igor Bukanov i...@mir2.org:
 Hello,

 I noticed that running `systemctl is-enabled foo.service` against a
 service written by a generator fails with a puzzling error message:

 Failed to get unit file state for foo.service: No such file or directory

 when I expected that the command succeeds and prints enabled-runtime
 as the unit was enabled through a target file
 /run/systemd/generator/multi-user.target.d/foo.conf containing:

 [Unit]
 Wants=foo.service

 Just curious: why don't you use

  /run/systemd/generator/multi-user.target.wants/foo.service → symlink
 to the generated file foo.service?

 --
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] is-enabled and generated units

[Igor Bukanov]

Hello,

I noticed that running `systemctl is-enabled foo.service` against a
service written by a generator fails with a puzzling error message:

Failed to get unit file state for foo.service: No such file or directory

when I expected that the command succeeds and prints enabled-runtime
as the unit was enabled through a target file
/run/systemd/generator/multi-user.target.d/foo.conf containing:

[Unit]
Wants=foo.service

Is it a bug?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is-enabled and generated units

[Igor Bukanov]

On 14 June 2015 at 12:22, Andrei Borzenkov arvidj...@gmail.com wrote:
 So it can be discussed what should be returned in this case, but in any
 case systemctl is-enabled is not expected to return enabled-runtime
 here.

Indeed, I see that it should not be `enabled-runtime` as the unit
does not contain [Install].

Still why systemctl does not return `static` in this case but fails
with an error message? I also see that systemctl fails with the same
error message for generated units that are linked via .wants under
/run/systemd/generator when my expectation is that the command should
succeed and print `linked-runtime`.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] clarification on daemon-reload

[Igor Bukanov]

On 19 May 2015 at 12:08, Lennart Poettering lenn...@poettering.net wrote:
 On Tue, 19.05.15 08:22, Igor Bukanov (i...@mir2.org) wrote:
 In any case, I thought that if I add
 a dependency like After=my-config-is-ready.target for most default
 services that can be configured, load a config from a mount or
 network, generate unit files and place them under /run and then call
 systemctl daemon-reload, then it would work. But if daemon-reload does
 not affect what was already scheduled, then I need a better plan.

 One option is to add a target you enqueue after installing the new
 configuration and reloading. Then, add all units that shall start to
 it as dependencies.

Thanks, that is a nice solution that does not sounds like a
workaround! And if a custom-network-loaded config wants to disable a
services that would be otherwise started by default, it could just
mask it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] clarification on daemon-reload

[Igor Bukanov]

On 18 May 2015 at 17:18, Lennart Poettering lenn...@poettering.net wrote:
 Well, my recommendation is to avoid daemon-reloads during the normal
 boot process if possible, since there are some unresolved issues:

What is then a canonical way to implement initialization when the
configuration comes from a drive that is not available during early
boot like virtio mount or uploaded from a network connection? Clearly
I can write a new persistent config and reboot the system for the new
changes to take an affect, but I would prefer to keep all the config
changes under /run so reboot always brings the system into a clean
state. I.e. how one should implement a staged boot when the system
performs a minimal initialization like mounting some paths or
initializing a minimal networking, gets the rest of the config via
that and then run the rest of initialization?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] clarification on daemon-reload

[Igor Bukanov]

Hello,

suppose a unit B runs just because another unit A contains Requires=B and
After=B. When B runs, it changes A like adding new dependencies, altering
Exec command etc and then B calls systemctl daemon-reload. Then the systemd
uses the new definition for A, right?

In particular, if according to the new configuration A should not run at
all because B changed the systemd configuration so A is no longer required
by any units, then systemd does not run A, right?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] clarification on daemon-reload

[Igor Bukanov]

On 18 May 2015 at 05:35, Andrei Borzenkov arvidj...@gmail.com wrote:


 What exactly do you mean? It has RefuseManualStart set?

I meant that, for example, A is enabled and contains Requires=B and
this is the only dependency that causes B to run and then B alters or
even disables A and calls systemctl daemon-reload.

 I'm not entirely sure what systemd can sensibly do in this case though.

What I would like to know is what is the exact behavior of systemctl
daemon-reload. I am writing a service that creates/modifies other
units by placing files under /run and I would like to know what are
the limitations. In my case I cannot use a systemd.generator as the
service depends on a mounted directory.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-run and waiting for initialization

[Igor Bukanov]

As I understand, the systemd-run utility returns immediately even with
--service-type=forking. What is the proper way then to wait using a shell
until the main service process forks the child and exists signaling
initialization?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-run and waiting for initialization

[Igor Bukanov]

It would be really nice to have an utility that waits until a unit is
transitioned from the activating state. My problem is that I wanted to
replace in a shell script a sequence like:

sudo -u some_user ssh -f port_forwarding host
use_forwarded_ports
kill hopefully rightly guessed ssh PID

with something like

sudo systemd-run --uid user --service-type=forking ...  ssh -f
port_forwarding host
use_forwarded_ports
sudo systemctl stop unit_name

as that is easier to make reliable. However, this does not work as I
expected as systemd-run does not wait for the ssh -f unit to transition
from the activating state indicating that port forwarding is established.
So I need to implement own wait or polling.


On 31 March 2015 at 05:51, Andrei Borzenkov arvidj...@gmail.com wrote:

 В Mon, 30 Mar 2015 09:48:25 +0200
 Igor Bukanov i...@mir2.org пишет:

  As I understand, the systemd-run utility returns immediately even with
  --service-type=forking. What is the proper way then to wait using a shell
  until the main service process forks the child and exists signaling
  initialization?

 It is not limited to forking. systemd-run simply queues request to
 start unit, same as systemctl does. It would need to actually wait
 until systemd reports that unit is started.

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

[systemd-devel] full reset of reset network state with networkd

[Igor Bukanov]

If during the boot the network is configured with DHCP but later is
configured with a static address with a new .network file, then
systemctl restart networkd still keeps the old address obtained with
DHCP.  This is expected according to documentation. Is there a way to
force with networkd to fully reset the network configuration so it
matches the one defined by unit files  and avoid manual removal of the
older IP without doing the reboot?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network-online.target is not down when a physical network is down

[Igor Bukanov]

Just for references. With the the following script placed in
/etc/NetworkManager/dispatcher.d/90-online-monitor everything works.
As the service is started explicitly the unit file needs no Install
section.

#!/bin/sh
status=$(nmcli -f STATE -t g)
if [ _$status = _connected -o _$status = _connected (site only) ]; then
systemctl start my-service
else
systemctl stop my-service
fi


On 22 January 2015 at 19:42, Dan Williams d...@redhat.com wrote:
 On Thu, 2015-01-22 at 19:51 +0300, Andrei Borzenkov wrote:
 В Thu, 22 Jan 2015 16:44:52 +0100
 Igor Bukanov i...@mir2.org пишет:

  For a service that should be shutdown when network is not available, I
  tried to use Requires=network-online.target . However, on Fedora 21
  with NetworkManager that does not work. When I switch off WiFi, the
  only connection on my laptop that can configure default IP route and
  setup /etc/resolv.conf, network-online.target still stays active and
  my service continues to run. Is it a bug in Fedora? If not, what is a
  canonical way to implement such dependency?


 No, it is not a bug. network-online was never intended to be used this
 way. It was intended to be used only during startup; when initial
 startup is finished, state of this service is largely irrelevant.

 network-online.target itself does absolutely nothing. It is provided as
 well known name for other services to order itself after; and you need
 to provide implementation that orders itself before.

 For NM implementation would be NetworkManager-wait-online.service that
 basically does nothing more than calling nm-online.

 Note that network down does not cause any change state in systemd.
 NetworkManager still runs. systemd itself does not watch or manages
 network, so it cannot initiate any actions here. I suppose you really
 want to hook systemctl stop/systemctl start in NetworkManager
 dispatcher framework.

 Yeah, a dispatcher script (man NetworkManager has more info) will be
 executed whenever any network interface is deconfigured by
 NetworkManager.  You could use this, in combination with 'nmcli -f STATE
 -t g' (which reports the NM state as a single word, eg connected or
 disconnected or connecting), to determine when no network
 connections are active, and then run 'systemctl stop your-service.

 See also
 http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/dispatcher

 Dan

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

[systemd-devel] service.d/.conf files and multi-valued options

[Igor Bukanov]

It is not clear from the systemd.unit manual page what happens when
foo.service.d/bar.conf sets an option like Service/ExecStartPre that
can be specified multiple times. From experimenting I see that *.conf
files supply additional values to the option and to overwrite or
remove already given values for the option one have to copy the whole
file into /etc and edit it there. Is it so?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] network-online.target is not down when a physical network is down

[Igor Bukanov]

For a service that should be shutdown when network is not available, I
tried to use Requires=network-online.target . However, on Fedora 21
with NetworkManager that does not work. When I switch off WiFi, the
only connection on my laptop that can configure default IP route and
setup /etc/resolv.conf, network-online.target still stays active and
my service continues to run. Is it a bug in Fedora? If not, what is a
canonical way to implement such dependency?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network-online.target is not down when a physical network is down

[Igor Bukanov]

Hm, checking nmcli -f STATE -t g does not work from a Networkmanager
dispatcher script. If I disable WiFi, that gives in the dispatcher
script connected (local only). If I enable WiFi, then in the
dispatcher I have connected (site only). Only some moments later the
state becomes connected, but on that transition from connected
(site only) to connected the dispatcher script is not called.

What is exactly connected (site only) ?

On 22 January 2015 at 19:42, Dan Williams d...@redhat.com wrote:
 On Thu, 2015-01-22 at 19:51 +0300, Andrei Borzenkov wrote:
 В Thu, 22 Jan 2015 16:44:52 +0100
 Igor Bukanov i...@mir2.org пишет:

  For a service that should be shutdown when network is not available, I
  tried to use Requires=network-online.target . However, on Fedora 21
  with NetworkManager that does not work. When I switch off WiFi, the
  only connection on my laptop that can configure default IP route and
  setup /etc/resolv.conf, network-online.target still stays active and
  my service continues to run. Is it a bug in Fedora? If not, what is a
  canonical way to implement such dependency?


 No, it is not a bug. network-online was never intended to be used this
 way. It was intended to be used only during startup; when initial
 startup is finished, state of this service is largely irrelevant.

 network-online.target itself does absolutely nothing. It is provided as
 well known name for other services to order itself after; and you need
 to provide implementation that orders itself before.

 For NM implementation would be NetworkManager-wait-online.service that
 basically does nothing more than calling nm-online.

 Note that network down does not cause any change state in systemd.
 NetworkManager still runs. systemd itself does not watch or manages
 network, so it cannot initiate any actions here. I suppose you really
 want to hook systemctl stop/systemctl start in NetworkManager
 dispatcher framework.

 Yeah, a dispatcher script (man NetworkManager has more info) will be
 executed whenever any network interface is deconfigured by
 NetworkManager.  You could use this, in combination with 'nmcli -f STATE
 -t g' (which reports the NM state as a single word, eg connected or
 disconnected or connecting), to determine when no network
 connections are active, and then run 'systemctl stop your-service.

 See also
 http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/dispatcher

 Dan

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

Re: [systemd-devel] rsync output is not captured in the journal

[Igor Bukanov]

It could be that this is SELinux-related. If I copy the rsync binary
to a new location and change the test service unit to use it, then the
log appeared as it should. However, I have no indications of any
rsync-related issues in any SELinux logs. Another thing is that if I
run under strace the original /usr/bin/rsync binary, the problem also
disappeares.

Any clues?

On 4 January 2015 at 21:06, Igor Bukanov i...@mir2.org wrote:
 Hello,

 I have a strange case when there is no output in the journal from
 rsync when the command is run from a service. This is on Fedora 21
 with systemd 217.

 Consider the following trivial test unit:

 # cat /etc/systemd/system/test.service
 [Service]
 ExecStart=/usr/bin/rsync -vv /etc/hostname /tmp
 StandardError=journal
 StandardOutput=journal
 Type=oneshot

 When I run it via

 systemctl start test

 I have no messages in the journal. journalctl -au test gives an empty output.

 Now, if I capture the rsync ouput into a shell variable like in:
 # cat /etc/systemd/system/test.service
 [Service]
 ExecStart=/usr/bin/bash -c 'a=$(/usr/bin/rsync -vv /etc/hostname
 /tmp); echo $a'
 StandardError=journal
 StandardOutput=journal
 Type=oneshot

 Then rsync stdout is captured and I have after systemctl start test:

 # journalctl -au test
 -- Logs begin at Thu 2015-01-01 20:02:12 CET, end at Sun 2015-01-04
 20:54:54 CET. --
 Jan 04 20:54:02 dserver bash[6284]: delta-transmission disabled for
 local transfer or --whole-file
 Jan 04 20:54:02 dserver bash[6284]: hostname
 Jan 04 20:54:02 dserver bash[6284]: total: matches=0  hash_hits=0
 false_alarms=0 data=8
 Jan 04 20:54:02 dserver bash[6284]: sent 98 bytes  received 102 bytes
 400.00 bytes/sec
 Jan 04 20:54:02 dserver bash[6284]: total size is 8  speedup is 0.04


 What could prevent stdout capturing with rsync?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rsync output is not captured in the journal

[Igor Bukanov]

On 5 January 2015 at 12:21, Mantas Mikulėnas graw...@gmail.com wrote:
 Run it under `strace -D` – the problem may be related to rsync's
 parent being pid1.

Under strace -D the problem disappeared as well. The problem also
disappears if I run rsync like in:

ExecStart=/usr/bin/bash -c 'exec /usr/bin/rsync -vv /etc/hostname /tmp/h3'

So the only way to see the problem is using rsync directly in
ExecStart like inExecStart=/usr/bin/rsync -vv /etc/hostname /tmp/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rsync output is not captured in the journal

[Igor Bukanov]

I attach strace log for systemd. I have in my test unit:

# cat test.service
[Service]
ExecStart=/usr/bin/bash -c 'echo rsync copy'
ExecStart=/var/rsync -vv /etc/hostname /tmp/h6
ExecStart=/usr/bin/bash -c 'echo system rsync'
ExecStart=/usr/bin/rsync -vv /etc/hostname /tmp/h2
ExecStart=/usr/bin/bash -c 'echo
'
StandardError=journal
StandardOutput=journal
Type=oneshot

Here /var/rsync is a copy of /usr/bin/rsync. After systemctl start
test the journal output generated with journalctl -eau test contains:

Jan 05 13:28:36 miranda bash[4982]: rsync copy
Jan 05 13:28:36 miranda rsync[4984]: delta-transmission disabled for
local transfer or --whole-file
Jan 05 13:28:36 miranda rsync[4984]: hostname
Jan 05 13:28:36 miranda rsync[4984]: total: matches=0  hash_hits=0
false_alarms=0 data=8
Jan 05 13:28:36 miranda rsync[4984]: sent 94 bytes  received 102 bytes
 392.00 bytes/sec
Jan 05 13:28:36 miranda rsync[4984]: total size is 8  speedup is 0.04
Jan 05 13:28:36 miranda bash[4988]: system rsync
Jan 05 13:28:36 miranda bash[4994]:


Note that there is no output between lines system rsync and =.

From strace output I see that the message  delta-transmission
disabled for  is printed to stdout twice, first from pid 4984 which
is a copy of rsync and the second time from pid 4990 which
/usr/bin/rsync. For some reason the second output is ignored. I see
the difference between pids is that for 4990 that has not produced any
output there was an extra call:

4990  ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS unfinished ...
4991  write(1, \1\0\0\7\0, 5 unfinished ...
4990  ... ioctl resumed , 0x7fff79087a80) = -1 ENOTTY (Inappropriate
ioctl for device)

This ioctl is not present in rsync with PID 4984.



On 5 January 2015 at 13:04, Mantas Mikulėnas graw...@gmail.com wrote:
 On Mon, Jan 5, 2015 at 1:44 PM, Igor Bukanov i...@mir2.org wrote:
 On 5 January 2015 at 12:21, Mantas Mikulėnas graw...@gmail.com wrote:
 Run it under `strace -D` – the problem may be related to rsync's
 parent being pid1.

 Under strace -D the problem disappeared as well. The problem also
 disappears if I run rsync like in:

 ExecStart=/usr/bin/bash -c 'exec /usr/bin/rsync -vv /etc/hostname /tmp/h3'

 So the only way to see the problem is using rsync directly in
 ExecStart like inExecStart=/usr/bin/rsync -vv /etc/hostname /tmp/

 Attach `strace -f -p 1` to systemd then, and have it follow forks.

 Perhaps also trace journald (the receiving end of rsync's stdout).

 --
 Mantas Mikulėnas graw...@gmail.com


trace.log.xz
Description: application/xz
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] rsync output is not captured in the journal

[Igor Bukanov]

Hello,

I have a strange case when there is no output in the journal from
rsync when the command is run from a service. This is on Fedora 21
with systemd 217.

Consider the following trivial test unit:

# cat /etc/systemd/system/test.service
[Service]
ExecStart=/usr/bin/rsync -vv /etc/hostname /tmp
StandardError=journal
StandardOutput=journal
Type=oneshot

When I run it via

systemctl start test

I have no messages in the journal. journalctl -au test gives an empty output.

Now, if I capture the rsync ouput into a shell variable like in:
# cat /etc/systemd/system/test.service
[Service]
ExecStart=/usr/bin/bash -c 'a=$(/usr/bin/rsync -vv /etc/hostname
/tmp); echo $a'
StandardError=journal
StandardOutput=journal
Type=oneshot

Then rsync stdout is captured and I have after systemctl start test:

# journalctl -au test
-- Logs begin at Thu 2015-01-01 20:02:12 CET, end at Sun 2015-01-04
20:54:54 CET. --
Jan 04 20:54:02 dserver bash[6284]: delta-transmission disabled for
local transfer or --whole-file
Jan 04 20:54:02 dserver bash[6284]: hostname
Jan 04 20:54:02 dserver bash[6284]: total: matches=0  hash_hits=0
false_alarms=0 data=8
Jan 04 20:54:02 dserver bash[6284]: sent 98 bytes  received 102 bytes
400.00 bytes/sec
Jan 04 20:54:02 dserver bash[6284]: total size is 8  speedup is 0.04


What could prevent stdout capturing with rsync?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] lazy forwarding of ssh ports

[Igor Bukanov]

Thanks again! I have completely missed this new feature of ssh.

On 2/3/13, Mantas Mikulėnas graw...@gmail.com wrote:
 On Wed, Jan 30, 2013 at 12:52 AM, Igor Bukanov i...@mir2.org wrote:
 On 29 January 2013 00:25, Mantas Mikulėnas graw...@gmail.com wrote:
 systemd only handles accepting connections, but does not copy any
 data – ssh's stdin  stdout are attached directly to the socket.

 Right, how can I missed that socket-stdio bindings happens in kernel
 that know how to transfer packets efficiently...

 So the whole setup is not that bad. I just wish that I could avoid the
 nc command on the server and ssh had an option to connect to a socket
 directly without netcat involvement. But this has nothing to do with
 systemd.

 Apparently, ssh has an option -W host:port to do just that.

 --
 Mantas Mikulėnas

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