Re: [systemd-devel] systemd user sessions?

[Kai Krakow]

Am Wed, 24 Feb 2016 17:41:57 +0100
schrieb Krzysztof Kotlenga :

> Jon Stanley wrote:
> 
> > I'd like a systemd unit (and only that unit) to be controlled by a
> > specific user. The unit runs as this user, so I thought about user
> > instances of systemd. This service should be started when the system
> > starts, so you'd have to enable linger in systemd-logind for that to
> > work.
> >
> > The question is how to make the systemd user *service* start at
> > boot?
> 
> [Install]
> WantedBy=default.target
> 
> $ systemctl --user enable foo.service
> Created symlink
> from /home/user/.config/systemd/user/default.target.wants/foo.service
> to /home/user/.config/systemd/user/foo.service.
> $
> 
> That's pretty much it.

I don't think this is how it works... User services do not start at
system boot but at user session start. So without starting the user
session on boot, the user service won't start.

I think it needs to be a system service, then use polkit rules to
enable a user to control this system service.

-- 
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] socket activation systemd holding a reference to an accepted socket

[Pathangi Janardhanan]

Hi,
 Please see this thread
http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/35437, and for
that usecase,  the suggestion to do shutdown did work fine, and with that I
was able to handle this case.

 At that time, the other request I had was if sd_pid_notify_with_fds or
equivalent could be enhanced to explictly ask systemd to forgot some FDs,
as I felt that would be useful in situations where systemd is being used as
FD store, and the FDs that are being stored may not always support shutdown
type of activity.


>
>> Normally one would solve this by inserting shutdown(fd, SHUT_RDWR) at
>> the right place, since that *really* terminates the connection,
>> regardless if anyone else has an fd open still. Is that an option
>> here?
>>
>
> I didn't actually try that myself but that was the 2nd thing that I
> suggested when I got the original problem report and the developer who
> reported the problem told me that it didn't work.
>
>>
>> Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
 wrote:
> On Thu, 18.02.16 20:33, Mike Gilbert (flop...@gentoo.org) wrote:
>
>> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
>>  wrote:
>> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>> >time Debian was still using that, maybe this changed now?
>>
>> Gentoo allows switching between systemd and openrc (sysvinit) at boot
>> time, and will continue to do so for the foreseeable future.
>>
>> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
>> swap these to symlinks to systemd and systemctl by setting a USE flag,
>> but if they do so they knowingly lose the ability to switch back to
>> openrc without a rebuild of the affected packages.
>>
>> I would like to selfishly request that you keep this interface around
>> as long as possible; if you remove it I will have to come up with some
>> replacement.
>
> So here's probably what is going to happen.
>
> The initctl support in systemctl will be dropped and replaced by some
> callout script support. i.e. when you want to use systemctl to reboot
> a sysvinit system, then systemctl won't do that anymore, but it will
> invoke some shell script as a fallback, where distros can place the
> necessary commands if they care about this. This follows how we do
> sysv script enable/disable handling (i.e. the chkconfig hookup).
>
> We'll eventually kill /dev/initctl support. Distros should really find
> their own replacement for this. They can either take the current code,
> build it externally, or write some new code. You might be able to
> implement this in a carefully prepared shell script that invokes
> busctl to do the reboot. You could use "dd" to read the initreq
> structure from STDIN with the precise size, then figure out which kind
> of request it is (again, by using dd to extract the four bytes
> starting at index 4 of that request structure) and then simply execute
> the right busctl command to poweroff/reboot/...
>
> I'll not drop this right-away, but let's say in 6month or so this will
> go away. This should be an ample heads-up to find a replacement and
> prepare for this.

The existing systemd-initctl (/dev/initctl) interface works quite
nicely, so I will probably end up extracting it from systemd when you
drop it, or just building/installing it from an older systemd tarball.
No need to reinvent the wheel.

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

Re: [systemd-devel] socket activation systemd holding a reference to an accepted socket

[Ben Woodard]

On Wed, Feb 24, 2016 at 4:29 AM, Lennart Poettering 
wrote:

> On Tue, 23.02.16 14:58, Ben Woodard (wood...@redhat.com) wrote:
>
> > On Thu, Feb 18, 2016 at 9:08 AM, Lennart Poettering <
> lenn...@poettering.net>
> > wrote:
> >
> > > On Wed, 17.02.16 17:44, Ben Woodard (wood...@redhat.com) wrote:
> > >
> > > > Is it intentional that systemd holds a reference to a socket it has
> > > > just accepted even though it just handed the open socket over to a
> > > > socket.activated service that it has just started.
> > >
> > > Yes, we do that currently. While there's currently no strict reason to
> > > do this, I think we should continue to do so, as there was always the
> > > plan to provide a bus interface so that services can rerequest their
> > > activation and fdstore fds at any time. Also, for the listening socket
> > > case (i.e. Accept=no case) we do the same and have to, hence it kinda
> > > is makes sure we expose the same behaviour here on all kinds of
> > > sockets.
> > >
> >
> > I'm having trouble believing that consistency of behavior is an ideal to
> > strive for in this case. Consistency with xinetd's behavior would seem to
> > be a better benchmark in this case.
>
> Well, we are implementing our own socket passing protocol anyway, and
> support the inetd style one only for completeness.
>

Which I believe supports my assertion that for the legacy inetd style
socket activation, we reproduce its semantics so that people porting
systemd have a measure of backwards compatibility. Then for those services
which are updated to the new socket passing protocol they can have whatever
semantics are needed to support that new kind of interaction.

It should be pretty obvious from the unit file when the service is
expecting simple inetd semantics vs implementing the socket passing
interface.

>
> > And I'm not sure that I understand the value being able to rerequest a
> > fdstore of fds. To me this sounds like it would be a very rarely used
> > feature. Could this be made an option that could be enabled when you add
> > the bus service that allows a service to rerequest their activation and
> > fdstore fds?
>
> Apple's launchd does activation that way. They have a "check-in"
> protocol, where instead of passing fds through exec() the activated
> process ask for them via an IPC call. This has quite some benefits as
> it allows the service manager to update the set of sockets
> dynamically, and the service can query them at any time to acquire the
> newest set.
>
>
I think it is good that you are patterning this off of apple's prior art.
However, I'm still moderately skeptical about the utility of this. It is
interesting; it sounds cool; I have no idea when I would ever want to use
it and can't think of any cases where a service that I'm familiar with
needs that feature. I'm not in anyway trying to lobby against it. I just
feel like these future plans shouldn't prevent a slightly more complete
backwards compatibility mode for inetd socket activation services.


> Another reason btw to keep the fd open in systemd is that we allow a
> series of programs to be invoked via multiple ExecStartPre=,
> ExecStart=, ExecStartPost=, ExecStop=, ExecStopPost= lines, and we
> have to keep things open at least for all but the last one hence, so
> that we have something to pass to the last invocation.
>

I think that is the most convincing argument thus far. I'd still argue for
special case logic that with simple socket activation accept=yes when the
last invocation is made, systemd closes its reference to the socket.

>
> > > Did you run into problems with this behaviour?
> > >
> >
> > Oh yes. It breaks a large number of management tools that we have on to
> do
> > various things on clusters. It is a kind of pseudoconcurrency. Think of
> > like this:
> >
> > foreach compute-node;
> >rsh node daemonize quick-but-not-instant-task
> >
> > With xinetd the demonization would close the accepted socket.  Then the
> > foreach loop would nearly instantly move onto the next node. We could zip
> > through 8000 nodes in a couple of seconds.
> >
> > With systemd holding onto the socket the "rsh" hangs until the
> > quick-but-not-instant-task completes. This causes the foreach loop to
> take
> > anywhere from between 45min and several hours. Because it isn't really
> rsh
> > and demonize and I just used that to make it easy to understand what is
> > going on, rewriting several of our tools is non-trivial and would end up
> > violating all sorts of implicit logical layering within the tools and
> > libraries that we use to build them.
>
> Hmm, let me get this right: the activated service closes its fd much
> earlier than it calls exit() and you want that this is propagated back
> to the client instead of having that delayed until the service
> actually calls exit()?
>

sort of but not quite.
More like this:

systemd
  accept
  ...
  fork
  if child
ExecStart service-process
service-process
  # this is what I 

Re: [systemd-devel] Moving systemd-bootchart to a standalone repository

[Simon Peeters]

2016-02-18 19:16 GMT+01:00 Lennart Poettering :
> On Thu, 18.02.16 11:32, Daniel Mack (dan...@zonque.org) wrote:
>
>> On 02/17/2016 08:02 PM, Umut Tezduyar Lindskog wrote:
>> > Hi,
>> >
>> > src/shared & src/basic have very useful code that upstream have been
>> > static linking to most binaries. My understanding is that we haven’t
>> > been feeling comfortable about the API to make these paths a
>> > standalone library (or include them in libsystemd).
>>
>> That's correct.
>>
>> > Now that we started duplicating the code outside of systemd main
>> > repo, wouldn’t it be wise to make it a library even if it was
>> > something like libsystemd_onlyandonlyinternal.so.
>> >
>> > For people who can follow upstream’s speed and catch up with API
>> > changes we would gain:
>>
>> I see your point, and that's one reason why we are not splitting out
>> more packages. Downstream deviation would be cumbersome to handle, and
>> providing API/ABI stability for a library is considered outside of the
>> scope of the systemd project. And without this guarantee, things will
>> break all the time, so that's not a win.
>>
>> In the case of bootchart, however, I believe amount of code this small
>> tool shares with the rest of systemd (from src/shared and src/basic) is
>> small enough to justify an exception. And things like lists, hashmaps
>> and trivial file parses could eventually even be solved differently,
>> with other libraries or whatever, if the maintainer decides so.
>>
>> Auke, did you have a look at the current code base of the standalone
>> repo? Does it look feasible to you?
>
> I'd be willing to explore the idea where we make src/basic a somewhat
> self-contained dir that could be imported as git submodule like gnulib
> (as suggested by Armin) by other packages. Key would be that they
> pinpoint a specific revision though, as we'd not provide API compat
> for this.
>
> Of course, we should do so only if there are actually projects IRL
> that are interested in this.

definitely, even though most of the C code I write nowadays is are toy
projects,I almost always start of by copying the shared stuff from
systemd.

I also think having these tools easily available will in general make
it more easy to write quality C code. (and reduce NIH)

> I am fine with making the code in src/basic more reusable, I am not
> very keen on establishing a fixed API for it though.
>
> Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Lennart Poettering]

On Wed, 24.02.16 17:40, Francis Moreau (francis.m...@gmail.com) wrote:

> Hello,
> 
> It seems that the unit generator for sysv init scripts translate
> "Required-Start: X" into "After=X" native ordering deps only.
> 
> I would also have expected it to add the following dependency "Requires=X" 
> too.
> 
> What am I missing ?

Well, on SysV the requirement in the "Required-Start:" concept is
actually a request to the tool that enables/disables a service
(i.e. the chkconfig or update-rcd tool, depending on the distro). It
means that it shall enable another service "b" if "a" is to be
enabled.

Requires= in systemd otoh is something that applies to the actual
activation time of a service. The counterpart of "Required-Start:" in
systemd concepts would actually be the Also= line in [Install], if you
follow what I mean.

systemd leaves enabling/disabling of sysv services to
chkconfig/update-rcd hence it will not act on that line regarding
requirement. It will however act on the ordering, since that's
inherently something systemd itself cares about.

Hope that makes sense?

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] systemd user sessions?

[Krzysztof Kotlenga]

Jon Stanley wrote:

> I'd like a systemd unit (and only that unit) to be controlled by a
> specific user. The unit runs as this user, so I thought about user
> instances of systemd. This service should be started when the system
> starts, so you'd have to enable linger in systemd-logind for that to
> work.
>
> The question is how to make the systemd user *service* start at boot?

[Install]
WantedBy=default.target

$ systemctl --user enable foo.service
Created symlink
from /home/user/.config/systemd/user/default.target.wants/foo.service
to /home/user/.config/systemd/user/foo.service.
$

That's pretty much it.

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

[systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

Hello,

It seems that the unit generator for sysv init scripts translate
"Required-Start: X" into "After=X" native ordering deps only.

I would also have expected it to add the following dependency "Requires=X" too.

What am I missing ?

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

Re: [systemd-devel] [HEADS-UP] resolved APIs fully documented

[Stefan Tatschner]

On 23.02.2016 14:29, Lennart Poettering wrote:
> Heya,
> 
> just wanted to let you know that I finished documenting resolved's bus
> APIs:
> 
> https://wiki.freedesktop.org/www/Software/systemd/resolved/
> https://wiki.freedesktop.org/www/Software/systemd/writing-network-configuration-managers/
> https://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients/

The Wiki seems to be down:

  stefan@kronos ~> ping wiki.freedesktop.org
  PING annarchy.freedesktop.org (131.252.210.176) 56(84) bytes of data.

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

[systemd-devel] systemd user sessions?

[Jon Stanley]

I'd like a systemd unit (and only that unit) to be controlled by a
specific user. The unit runs as this user, so I thought about user
instances of systemd. This service should be started when the system
starts, so you'd have to enable linger in systemd-logind for that to
work.

The question is how to make the systemd user *service* start at boot?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev rules for MCS7715 USB-attached parallel port

[Lennart Poettering]

On Tue, 23.02.16 17:12, Alex Henrie (alexhenri...@gmail.com) wrote:

> 2016-02-22 7:15 GMT-07:00 Lennart Poettering :
> > On Sun, 21.02.16 15:26, Alex Henrie (alexhenri...@gmail.com) wrote:
> >
> >> Hi,
> >>
> >> I recently bought an MCS7715 USB-attached parallel port,[1] but there
> >> seem to be a couple of problems using it with Linux:
> >>
> >> 1. The lp, parport, and parport_pc kernel modules are not loaded when
> >> the device is plugged in.
> >
> > AFAIK parport_pc is the driver for old built-in parallel ports, it
> > it not used f you have a USB paralell port adapter.
> 
> OK. Still, at minimum lp needs to be loaded when the USB parallel port
> adapter is plugged in.
> 
> >> 2. After manually loading the kernel modules, /dev/lp0 is not deleted
> >> when the device is unplugged.
> >
> > /dev/lp0 is also the old built-in parallel port. USB printers and
> > parallel ports show up as /dev/usb/lp0 or so..
> 
> When I plug in the device, /dev/lp0 appears; /dev/usb/lp0 does not.
> Furthermore, when I unplug and plug it back in, /dev/lp1 appears
> alongside /dev/lp0. A third time and I have /dev/lp0, /dev/lp1, and
> /dev/lp2.
> 
> Are you sure that this is not a udev rules bug? If it isn't, where
> should I report it?

Well, parallel ports are somewhat legacy, it'll be hard to find
somebody to fix this for you...

Generally, the lp hookup in udev rules is pretty minimal, the primary
work has to be done in the kernel modules to expose in the modalias
metadata when they want to be loaded, and via the kernel driver model
which device nodes they want.

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] Moving systemd-bootchart to a standalone repository

[Oliver Henshaw]

On 17 February 2016 at 17:17, Lennart Poettering  wrote:
> On Wed, 17.02.16 17:03, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
>>
>>
>> On 02/17/2016 04:51 PM, Daniel Mack wrote:
>> >Hey,
>> >
>> >[I've put all people in Cc who have had more than one commit related to
>> >systemd-bootchart in the past]
>> >
>> >As part of our spring cleaning, we've been thinking about giving
>> >systemd-bootchart a new home, in a new repository of its own. I've been
>> >working on this and put the result here:
>>
>> What's the reason for splitting it out into it's own repository as what's
>> the criteria you used to determine that which may or may not be applicable
>> to other bits of systemd?+
>
> Also, on of the major
> issues was that we trouble testing this, simply because distro kernels
> usually don't turn on the necessary kernel features to make it work
> (Fedora for example turns this off, because of the performance
> penalty).

If you're talking about CONFIG_SCHEDSTATS, I can see that it has been
enabled (with little fanfare) in kernel updates for Fedora 22 and
later. Or are you referring to other kernel features? There might
still be missing features in Fedora kernels, but nothing that prevents
the bootcharts from being created.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] socket activation systemd holding a reference to an accepted socket

[Lennart Poettering]

On Tue, 23.02.16 14:58, Ben Woodard (wood...@redhat.com) wrote:

> On Thu, Feb 18, 2016 at 9:08 AM, Lennart Poettering 
> wrote:
> 
> > On Wed, 17.02.16 17:44, Ben Woodard (wood...@redhat.com) wrote:
> >
> > > Is it intentional that systemd holds a reference to a socket it has
> > > just accepted even though it just handed the open socket over to a
> > > socket.activated service that it has just started.
> >
> > Yes, we do that currently. While there's currently no strict reason to
> > do this, I think we should continue to do so, as there was always the
> > plan to provide a bus interface so that services can rerequest their
> > activation and fdstore fds at any time. Also, for the listening socket
> > case (i.e. Accept=no case) we do the same and have to, hence it kinda
> > is makes sure we expose the same behaviour here on all kinds of
> > sockets.
> >
> 
> I'm having trouble believing that consistency of behavior is an ideal to
> strive for in this case. Consistency with xinetd's behavior would seem to
> be a better benchmark in this case.

Well, we are implementing our own socket passing protocol anyway, and
support the inetd style one only for completeness.

> And I'm not sure that I understand the value being able to rerequest a
> fdstore of fds. To me this sounds like it would be a very rarely used
> feature. Could this be made an option that could be enabled when you add
> the bus service that allows a service to rerequest their activation and
> fdstore fds?

Apple's launchd does activation that way. They have a "check-in"
protocol, where instead of passing fds through exec() the activated
process ask for them via an IPC call. This has quite some benefits as
it allows the service manager to update the set of sockets
dynamically, and the service can query them at any time to acquire the
newest set.

Another reason btw to keep the fd open in systemd is that we allow a
series of programs to be invoked via multiple ExecStartPre=,
ExecStart=, ExecStartPost=, ExecStop=, ExecStopPost= lines, and we
have to keep things open at least for all but the last one hence, so
that we have something to pass to the last invocation.

> > Did you run into problems with this behaviour?
> >
> 
> Oh yes. It breaks a large number of management tools that we have on to do
> various things on clusters. It is a kind of pseudoconcurrency. Think of
> like this:
> 
> foreach compute-node;
>rsh node daemonize quick-but-not-instant-task
> 
> With xinetd the demonization would close the accepted socket.  Then the
> foreach loop would nearly instantly move onto the next node. We could zip
> through 8000 nodes in a couple of seconds.
> 
> With systemd holding onto the socket the "rsh" hangs until the
> quick-but-not-instant-task completes. This causes the foreach loop to take
> anywhere from between 45min and several hours. Because it isn't really rsh
> and demonize and I just used that to make it easy to understand what is
> going on, rewriting several of our tools is non-trivial and would end up
> violating all sorts of implicit logical layering within the tools and
> libraries that we use to build them.

Hmm, let me get this right: the activated service closes its fd much
earlier than it calls exit() and you want that this is propagated back
to the client instead of having that delayed until the service
actually calls exit()?

Normally one would solve this by inserting shutdown(fd, SHUT_RDWR) at
the right place, since that *really* terminates the connection,
regardless if anyone else has an fd open still. Is that an option
here?

I figure I'd be open to adding an option that makes sure the
connection socket is closed as soon as the last ExecXYZ= process we
need is forked off.

> Where is this in the source code? I've been planning to send you a patch to
> change the behavior but I have't quite connected the dots from where a job
> within a transaction is inserted on the run queue to where the fork for the
> "ExecStart" actually happens.

it's in src/core/service.

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] Regression in ipv6 resolutions in systemd-resolved with AF_UNSPEC

[Mantas Mikulėnas]

On Wed, Feb 24, 2016 at 2:04 PM, Yuriy M. Kaminskiy 
wrote:

> On 19.02.2016 18:26, Lennart Poettering wrote:
>
>> Note that resolved will not look up IPv6 addresses if this isn't
>> explicitly requested if there are no local routable IPv6 addresses
>> configured. And vice versa, it won't look for IPv4 addresses if this
>>
>
> Maybe I'm missing something, but That looks ...problematic. To extreme.
> So, I cannot
>
> getent ahosts www.freedesktop.org | while read a rest; do
>case $a in
>*:*) ip6tables -A OUTPUT -d $a -j REJECT;;
>*.*) iptables -A OUTPUT -d $a -j REJECT;;
>esac
> done
>
> *before* I've got my ipv6 connectivity up and running?


getent ahostsv4 www.freedesktop.org | while read a rest; do
iptables -A OUTPUT -d $a -j REJECT
done
getent ahostsv6 www.freedesktop.org | while read a rest; do
ip6tables -A OUTPUT -d $a -j REJECT
done


I'm not sure I like the feature myself – the last time I had to deal with
libc's equivalent, AI_ADDRCONF, it would even prevent programs from
resolving _localhost_ when the system wasn't online... But, I guess it can
improve things in certain situations.

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

Re: [systemd-devel] Regression in ipv6 resolutions in systemd-resolved with AF_UNSPEC

[Yuriy M. Kaminskiy]

On 19.02.2016 18:26, Lennart Poettering wrote:

On Fri, 19.02.16 15:43, Sébastien Luttringer (se...@seblu.net) wrote:


Hello,

Since systemd v229, I have one server which no more resolve ipv6 adresses when
it use nss-resolve and AF_UNSPEC.

This issue seems to be linked with the DNS resolver used on its network. This
resolved is provided by a french FAI box (SFR).

I'm currently not able to understand precisely where is the issue, but opening
the socket with AF_UNSPEC does not resolve ipv6 and with AF_INET6
does.


Note that resolved will not look up IPv6 addresses if this isn't
explicitly requested if there are no local routable IPv6 addresses
configured. And vice versa, it won't look for IPv4 addresses if this


Maybe I'm missing something, but That looks ...problematic. To extreme.
So, I cannot

getent ahosts www.freedesktop.org | while read a rest; do
   case $a in
   *:*) ip6tables -A OUTPUT -d $a -j REJECT;;
   *.*) iptables -A OUTPUT -d $a -j REJECT;;
   esac
done

*before* I've got my ipv6 connectivity up and running?


isn't explicitly requested and there are no local routable Ipv4
addresses configured. Basically, when doing lookups without specifying


Same, but if I have ipv6-only native connectivity and my ipv4 tunnel is 
not up yet?



what you want, we'll return something that you can actually talk
to. If during resolving you however specify what you want, then we'll
actually return that.

How precisely does your IP configuration look like? Do you use
per-interface DNS servers (i.e. configured via networkd), or do you
have global DNS servers configured via /etc/resolv.conf or via DNS= in
/etc/systemd/resolved.conf?

If you use per-interface DNS servers, do you have a routable IPv6
address on that interface? If you use global DNS servers instead, do
you have any routable Ipv6 address on any interface?



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