Re: [systemd-devel] [PATCH] resolved: don't fail if IPv6 is not available

[Michael Olbrich]

On Wed, Aug 13, 2014 at 03:04:20PM +0200, Lennart Poettering wrote:
> I applied a different patch now that makes sure we either get the full
> IPv6 support or none at all, and doesn't generate a warning.
> 
> Please have a look, if this fixes things for you.

This work now. However I had to revert
5ba73e9b646af4d8109a5a633aa235665858144d (resolved: clarify that LLMNR
scopes must have a link assigned). dns_scope_llmnr_membership() is called
twice with s->protocol = DNS_PROTOCOL_DNS. dns_scope_new() calls it with
the specified link and protocol here:

$ git grep dns_scope_new | grep AF_UNSPEC
src/resolve/resolved-link.c:r = 
dns_scope_new(l->manager, &l->unicast_scope, l, DNS_PROTOCOL_DNS, AF_UNSPEC);
src/resolve/resolved-manager.c:r = dns_scope_new(m, &m->unicast_scope, 
NULL, DNS_PROTOCOL_DNS, AF_UNSPEC);

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Logind error - Failed to abandon session scope: Connection reset

[Roger Qiu]

Hello Lennart,

Thanks for answering.

Is there any way to enforce ordering to make this error not occur?

Or what's the best way to hide that warning?

Or when is the ETA for kdbus?

Thanks,
Roger

On 15/08/2014 8:38 AM, Lennart Poettering wrote:

On Thu, 17.07.14 11:49, Roger Qiu (roger@polycademy.com) wrote:

Hi,

(sorry for the late response)


Are you saying that logind should be terminated first then dbus
should be terminated second?

Yes, dbus should best be stopped after logind.


In what situations would their termination sequence get mixed?

That's a good question. I am a bit puzzled why this race never shows up
for me, but it shows up for you.

I mean, looking at the deps both services are not ordered against each
other, so it kinda should happen frequently, but it never does for me...

Anyway, this is really just cosmetic, the only thing we can fix here I
guess is hide the warning. Or just wait for kdbus at which point the
problem goes away entirely as the bus will survive the entire system
runtime.

Lennart



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

Re: [systemd-devel] [PATCH] core: collapse JOB_RELOAD on an inactive unit into JOB_NOP

[Uoti Urpala]

On Fri, 2014-08-15 at 01:59 +0200, Lennart Poettering wrote:
> On Wed, 16.07.14 04:15, Jon Severinsson (j...@severinsson.net) wrote:
> > Before this commit systemctl reload on an inactive unit with a queued
> > start job would block until the unit had started if the unit supported
> > reload, but return failure immediately if the unit didn't.
> 
> This sounds like correct behaviour to me.
> 
> 1) I think the rule should be to return only after the unit is in the
> desired state, and the desired operation or something equivalent has
> been executed. This is useful, so that callers can rely on the fact that

What is your "desired state" for reload then? To me the obvious natural
meaning is that after reload has completed, it is guaranteed the service
will not process any requests with outdated configuration from before
reload was issued. Do you want to have reload imply that AND "service is
currently running"? If so, I think such a combination is better done
with "systemctl reload && systemctl start"; getting the correct
semantics for the reload part alone is harder if systemctl only
implements the combined operation.


> > Additionally systemctl reload-or-try-restart (and systemctl force-reload)
> > would block until the unit had started if the unit supported reload, but
> > return *success* immediately if the unit didn't.
> 
> This actually also sounds like correct behaviour to me.
> 
> "try-restart" means that we try to restart a service, but only if it is
> already running. If we are not running this is not considered an
> error. If you then add the "reload-or-" to the mix, this means that we
> will try to reload it if the unit supports it, instead of restarting it.
> 
> So, if a start is already queued, we'll wait for it to finish, so that
> the configuration is fully in effect afterwards. But if the thing is not
> running at all, then we will not consider that a problem at all and
> return success.

I don't think this makes sense. Reload is a "softer" alternative; if I
say "reload-or-try-restart", that should be considered as asking less
from systemd - full restart is not necessary, just reload is enough if
that option is available. Asking for less should not be a reason to
block longer!


> This is really what you want actually, because this allows admins (and
> scripts) to change some daemon configuration, and then finish off by
> issuing "reload-or-try-restart" on the daemon, so that the changes take
> effect, and then immediately talk to the daemon, knowing that if it was
> running, then the new configuration is definitely in effect. If it
> wasn't, then of course we can't talk to the service, but that's OK of
> course.

Exactly, this is a common usecase. But note that this case supports the
changed semantics of the patch, and does not support your view!

After an operation that changes configuration,
"reload-or-try-restart" (or just "reload" if we know reload is in fact
supported by the daemon and sufficient for the configuration change in
question) should guarantee that further requests use the new
configuration. It should not unnecessarily block until the daemon is
actually running if it's being started; anything which relies on it
being up should test for that separately, independently of configuration
change handling. And there's no reason why implementing lighter-weight
reloads to replace full restarts should lead to systemd blocking longer.


> > Finaly reload on an inactive unit without a queued start job would
> > reurn failure, but try-restart on the same job would return success.
> 
> Well, the "try-" prefix is supposed to be the thing "apply only if
> already running, but don't consider it an error if it isn't". We could of
> course add "try-reload" to the mix, so that you have a "reload" version
> that will not fail if the daemon is not running, but I think that's not
> particularly interested

I think such "try-reload" semantics are the actually useful use-case,
and what just "reload" should do as the non-try semantics do not seem
that useful.


> > This behaviour is unintuitive and inconsistent, so make reload of inactive
> > units behave just like try-restart.
> 
> Well, it might appear surprising in some ways, but there's a lot of
> sense in it, and I think what matters is really to look at the effect of
> calls, and make guarantees about that.

try-restart: guarantee that no old daemon instance is running at all
reload: guarantee that the daemon is not running with old configuration,
at least to the degree its ExecReload functionality supports


> > Also fixes deadlocks on boot if a unit calls systemctl reload,
> > reload-or-try-restart or force-reload on a unit ordered later
> > in the boot sequence during startup.
> 
> Well, for cases like that, please consider using --no-block, which will
> just queue the job, but not wait for it. Or use
> --job-mode=ignore-dependencies or so, even though that's a horrid
> invention...

That's not safe - with --no-block the daemon may still

Re: [systemd-devel] [PATCH] coredump: display libdw fail string on stack trace fail

[Lennart Poettering]

On Tue, 08.07.14 16:16, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

> - systemd[1]: hello.service: main process exited, code= \
>   dumped, status=3/QUIT
> - systemd-coredump[2541]: Failed to generate stack trac \
>   e: Unwinding not supported for this architecture
> - systemd-coredump[2541]: Process 1024 (hello) of user  \
>   154 dumped core.

Thanks! Applied!

(Had to add in some more #includes for this to work though...)

Thanks,

Lennart

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

Re: [systemd-devel] race conditions after SIGTERM

[Reindl Harald]

Am 14.08.2014 um 19:51 schrieb Lennart Poettering:
> On Thu, 14.08.14 21:38, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>>> Which is what we do. Except when you specify ExecStop= which basically
>>> tells systemd that you want to do it instead. So there you go!
>>
>> Those daemons I have seen are terminated after receiving signal/command
>> to do it. Those sysvinit scripts that "synchronously" terminated
>> services did it by implementing wait for daemon process to exit. What
>> is worse, the only way to do it is busy looping as they cannot normally
>> receive notification about process exit.
> 
> Well, if they don't have such a protocol, then they can use systemd's
> default logic for this, and just tweak the parameters. KillMode=,
> KillSignal=, TimeoutStopSec= are all ways how you can control how
> exactly systemd should terminate your service.
> 
>> Compare this with "send daemon command - signal or whatever - and wait
>> until it exits". This needs to be implemented just once in PID 1 - and
>> PID 1 already does exactly this most of the time anyway. Why is this
>> the wrong thing to do? You never explained this when you rejected my
>> patch.
> 
> Hmm, this is what we do. By specifiying ExecStop= you turn that off
> however can plug in your own logic. If you don't have any better logic,
> then simply don't plug anything in, that's what we recommend anyway.
> 
> Again: systemd does what you want it to do by default, anyway. By
> specifiying ExecStop= you however turn this off, and have to do it on
> your own!

Uhm - i did not have *any* ExecStop / EexecStopPost until it came
to compromised mysqld datafiles - other than the Fedora packages
i just used

Type=simple
ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf 
--pid-file=/run/mysqld/mysqld.pid

after problems i added "ExecStartPost=/usr/bin/sleep 1" which avoided
the problems most of the time but implicates a useless second at
shutdown

*currently* i added "ExecStop=/usr/bin/kill -15 $MAINPID" and upgraded
to Fedora 20 in the hope systemd-208 does that better than systemd-204
on Fedora 19
__

*normally* i would expect

ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf 
--pid-file=/run/mysqld/mysqld.pid
Restart=always
RestartSec=1
TimeoutSec=300

as the only start / stop configuration and be sure after "systemctl stop mysqld"
returns the daemon process is really away and had written what he needs and
starting rsync the datadir is safe

that is not the case, hence the thread and bugreport for systemd on F19



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

[Lennart Poettering]

On Tue, 08.07.14 17:33, David Timothy Strauss (da...@davidstrauss.net) wrote:

> Is there a good way to empirically determine the additional calls
> required for an application, sort of like selinux permissive mode?
> We're often running user code on our servers, and we'd like to perform
> analysis and gradually roll out filtering. We'd like to be as
> non-disruptive as possible.

"strace" should do the job. It should give you a pretty good idea of all
syscalls a process uses. That's what I used when testing SyscallFilters=.

Lennart

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

Re: [systemd-devel] [PATCH] core: don't complain if cgroup property is missing

[Lennart Poettering]

On Fri, 15.08.14 02:42, Lennart Poettering (lenn...@poettering.net) wrote:

> 
> On Tue, 15.07.14 11:53, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:
> 
> Looks Ok, but doesn't apply to currently git anymore...

(In case this wasn't clear, please rebase and I'll commit this. -- Or
actually, could you add a short comment explaining that EACCES is what
the kernel returns if CFS quotas are disabled?)

Lennart

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

Re: [systemd-devel] [PATCH] core: don't complain if cgroup property is missing

[Lennart Poettering]

On Tue, 15.07.14 11:53, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

Looks Ok, but doesn't apply to currently git anymore...

It's really awful though that the kernel returns EACESS on these. I
wished it would return ENOTSUP or so!

> ---
>  src/core/cgroup.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/core/cgroup.c b/src/core/cgroup.c
> index cd67963..ed5687d 100644
> --- a/src/core/cgroup.c
> +++ b/src/core/cgroup.c
> @@ -303,12 +303,12 @@ void cgroup_context_apply(CGroupContext *c, 
> CGroupControllerMask mask, const cha
>  state == MANAGER_STARTING && c->startup_cpu_shares 
> != (unsigned long) -1 ? c->startup_cpu_shares :
>  c->cpu_shares != (unsigned long) -1 ? c->cpu_shares 
> : 1024);
>  r = cg_set_attribute("cpu", path, "cpu.shares", buf);
> -if (r < 0)
> +if (r < 0 && r != -EACCES)
>  log_warning("Failed to set cpu.shares on %s: %s", 
> path, strerror(-r));
>  
>  sprintf(buf, USEC_FMT "\n", CGROUP_CPU_QUOTA_PERIOD_USEC);
>  r = cg_set_attribute("cpu", path, "cpu.cfs_period_us", buf);
> -if (r < 0)
> +if (r < 0 && r != -EACCES)
>  log_warning("Failed to set cpu.cfs_period_us on %s: 
> %s", path, strerror(-r));
>  
>  if (c->cpu_quota_per_sec_usec != (usec_t) -1) {
> @@ -316,7 +316,7 @@ void cgroup_context_apply(CGroupContext *c, 
> CGroupControllerMask mask, const cha
>  r = cg_set_attribute("cpu", path, 
> "cpu.cfs_quota_us", buf);
>  } else
>  r = cg_set_attribute("cpu", path, 
> "cpu.cfs_quota_us", "-1");
> -if (r < 0)
> +if (r < 0 && r != -EACCES)
>  log_warning("Failed to set cpu.cfs_quota_us on %s: 
> %s", path, strerror(-r));
>  }
>  


Lennart

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

Re: [systemd-devel] networkd with radv advertised prefixes

[Lennart Poettering]

On Thu, 10.07.14 08:14, brane2 (bran...@s5tehnika.net) wrote:

> 
> Dne 09. 07. 2014 17:06, piše Tom Gundersen:
> >On Wed, Jul 9, 2014 at 4:19 PM, Vasiliy Tolstov  wrote:
> >>As i see, networkd now able to do dhcpv6, what about configuring
> >>interfaces to accept radv messages and configure it interfaces? What i
> >>need to do on systemd-networkd side?
> >Currently that is not supported, but it is definitely something we
> >want. So if you are interested in extending our libraries to cover
> >this usecase, that would be awesome.
> 
> I don't want to inject noise in signal of your conversation, but
> doesnt kernel itself do client side of ipv6 router
> solicitation/advertisement ?

router advertisment allows passing along DNS server info. The kernel
can't make use of that, but we cetrainly should make use of it in
userspace.

Lennart

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

Re: [systemd-devel] Separate cpu cgroup parameters

[Lennart Poettering]

On Thu, 10.07.14 15:16, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> Hi,
> 
> Even though cpu.shares and cpu.cfs_period_us/cfs_quota_us parameters
> are in the "cpu" cgroup, they can be turned off individually.
> 
> Our kernel only enables cpu.shares property and due to that we see
> error messages.
> 
> systemd[1]: Failed to set cpu.cfs_period_us on
> /system.slice/system-sshd.slice: Permission denied
> systemd[1]: Failed to set cpu.cfs_quota_us on
> /system.slice/system-sshd.slice: Permission denied

Hmm, the cgroup property files do exist, but return EACCESS when they
are not around? That sounds weird...

> 
> Proposed solutions:
> - Should we have separate CGroupControllerMask mask like
> CGROUP_CPU_SHARES & CGROUP_CPU_QUOTA
> OR
> - Should we just ignore the cg_set_attribute() within
> cgroup_context_apply() if setting attribute fails due to missing
> parameter?

Probably, yeah.

Lennart

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

Re: [systemd-devel] [PATCH] [RFC] Add binary password agent protocol

[Lennart Poettering]

On Mon, 14.07.14 15:43, David Härdeman (da...@hardeman.nu) wrote:

> No problem. Getting it right is part of the systemd philosophy...that
> sometime takes longer
> 
> Anyhow, I've looked at the in-kernel keyring stuff before. Basically
> userspace can request a key via a syscall (or in-kernel code can do
> pretty much the same thing via a similar function call).
> 
> If the key is missing, a placeholder gets created and /sbin/request-key
> is invoked to fill that placeholder with a proper key. The current
> request-key uses config files under /etc to determine how to handle the
> key request.
> 
> The key can then be properly constructed by the add_key sysctl (to write
> the payload to the key).
> 
> As far as I can tell, this could replace the sockets that are currently
> used in systemd, but not much more. All the information in the ask.
> files would still need to be conveyed separately (e.g. by still creating
> the ask. file and providing the path to the file as the callout_info
> in request_key).
> 
> I'm guessing you'd like the dbus API to be a higher-level API that
> userspace can use to get systemd to create the ask. file and call
> request_key()? Are there any advantages of that redirection over doing
> it straight away in the app?

I'd really like to drop the ask. files, too, and do that on the bus.

Some bus API, where clients that can't find the password they need in
the kernel keyring can ask for it in a nice way, which is then
dispatched to a number of agents, which will place the key in the
keyring and then notify the client about it.

This piece of infrastructure should probably also be able to persist
specific keys to disk, a bit like gnome-keyring, but much simpler
because it would only be a persistancy frontend for the kernel
keyring. It should then also do both system-level and user-level keyring
handling...

> Also, I guess this means that systemd would have to add a homegrown
> version of /sbin/request-key (external dependencies for early boot does
> not seem to be part of the systemd way of doing things)?

Well, yeah, I figure. I think the API is awful though. In this day and
age we really shouldn't have a kernel callout-to-userspace anymore, but
use something else, like some netlink event or so... But anyway we shuld
be able to hide this away sufficiently. The idea is that we would then
just make this stub binary drop the request on the bus and get nice
interactivity.

Hope this makes some sense.

Lennart

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

Re: [systemd-devel] [PATCH] tmpfiles: only execute chmod()/chown() when needed

[Lennart Poettering]

On Fri, 11.07.14 15:05, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

> This avoids errors like this, when the paths are already there with the
> correct permissions and owner:
> 
> chmod(/var/spool) failed: Read-only file system
> ---
>  src/tmpfiles/tmpfiles.c | 36 +---
>  1 file changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index 68cfa55..4f41f28 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfiles.c
> @@ -453,35 +453,41 @@ finish:
>  }
>  
>  static int item_set_perms(Item *i, const char *path) {
> +struct stat st;
> +mode_t old_m = ~0;
> +uid_t old_uid = -1;
> +gid_t old_gid = -1;

I'd prefer an explicit cast here, to "(uid_t) -1", since uid_t is
actually unsigned, and we should clarify what we are doing here.

> +
>  assert(i);
>  assert(path);
>  
> +if (stat(path, &st) >= 0) {
> +old_m = st.st_mode & 0;
> +old_uid = st.st_uid;
> +old_gid = st.st_gid;
> +}

Hmm, why copy the fields out here? Can't we just initialize them in the
struct directly to something useful, and just always use the structure
directly?

>  /* not using i->path directly because it may be a glob */
>  if (i->mode_set) {
>  mode_t m = i->mode;
>  
> -if (i->mask_perms) {
> -struct stat st;
> -
> -if (stat(path, &st) >= 0) {
> -if (!(st.st_mode & 0111))
> -m &= ~0111;
> -if (!(st.st_mode & 0222))
> -m &= ~0222;
> -if (!(st.st_mode & 0444))
> -m &= ~0444;
> -if (!S_ISDIR(st.st_mode))
> -m &= ~07000; /* remove 
> sticky/sgid/suid bit, unless directory */
> -}
> +if (i->mask_perms && old_m != ~0) {

So you are using "old_m != ~0" as check whether the stat() was
successfuly? I'd really prefer if we could make this explicit. Just add
a bool called "st_valid" or so, and check that here. That's certainly
easier to read.

Otherwise looks good!

Lennart

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

Re: [systemd-devel] [PATCH v3 2/3] cxgb4: use module_long_probe_init()

[Luis R. Rodriguez]

On Thu, Aug 14, 2014 at 09:53:21PM +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 14, 2014 at 09:42:49AM -0700, Casey Leedom wrote:
> >   Part of the problem is that the current 
> > architecture has Device Probe happening out of the Module Initialization 
> > when we call pci_register_driver() with our PCI Device ID Table.
> >
> >   Running the Device Probes asynchronously has been discussed but that has 
> > the problem that it's then impossible to return the Device Probe Status.  
> > This is a problem for Driver Fallback and, if the probe fails, we're not 
> > supposed to call the Device Remove function. To make this work, the 
> > synchronous/asynchronous boundary would really need to be up in the PCI 
> > Infrastructure layer so the Device Probe status could be captured in the 
> > normal logic.  This would be a moderately large change there ...
> 
> Some maintainers consider most of the work to get what you need done
> simple, I've tried to explain it ain't so, so glad you provided a bit
> of details here. To be clear its not just about asynch firmware loading,
> you need a bit more work. Can you evaluate using a bus driver?

<-- snip -->

> >   On the whole, I think that introducing these Module Load Timeouts hasn't 
> > been well thought out with respect to the repercussions and I'd be more 
> > inclined to back that out till a well thought out design is developed.  But 
> > I'm here for the discussion.
> 
> The way that the 30 second timeout was introduced as a new driver
> initialization requirement was certainly not ideal specially since
> the respective systemd patch that intended to trigger the SIGKILL on
> kmod module loading only took effect once kernel commit 786235ee
> went in about a year later, and since the original systemd commit
> was only addressing asynchronous firmware loading as a possible
> issue that drivers may need to fix. The cxgb4 driver is a good
> example that needs quite a bit of more work. Regardless systemd
> folks are right -- but again, having this be introduced as a new
> requirement that otherwise simply kills drivers seems a bit too
> aggressive specially if its killing boot on some systems due to
> delays on storage drivers. What's done is done -- and we need to
> move on. We already reviewed twice now reverting 786235ee and that
> won't happen, as a compromise we're looking for an easy agreeable
> general driver work around that would both circumvent the issue
> and let us easily grep for broken drivers. The deferred probe trick
> was the first approach and this series addresses the more agreeable
> solution. This 2 line patch then is what we are looking as work
> around until your driver gets properly fixed.
> 
> Apart from these kernel changes there are systemd changes we've
> looked at modifying, Hannes' patch 9719859c07a, now merged upstream on
> systemd lets you override the timeout value through the kernel command
> line. This will only help for all systems if you use a high enough
> large timeout value, or on a case by case basis for each system.
> I recently proposed replacing a kill for a warn only for udev
> kmod built in commands, that's unacceptable for systemd's architecture
> though so the last thing I proposed instead to use *for now* is a
> multiplier for each different type of udev built-in command and
> for kmod we'd use a high enough value, the timeout therefore would
> be really large for module loading for now, but we'd still want to
> collect logs of drivers taking long to probe. That's still being
> discussed [0] but my hope is that with this series and that other
> systemd discussion we'll have covered both areas affected and have
> a good strategy to move forward with this new driver requirement.
> 
> [0] http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/21689

Here's another affected driver:

https://bugzilla.kernel.org/show_bug.cgi?id=59581

pata_marvell, and using the work around in this series should work,
just as the deferred probe work around. Alexander however notes that
the pata_marvell driver is just a simple wrapper and other devices
can act the same way. This can surely be fixed perhaps in libata
but its an example of an old driver and folks not being around to
care much over drivers which are affected.

This driver also uses module_pci_driver() so a module_long_probe_driver()
and respective module_long_probe_pci_driver() would need to be considered
if but easily implemented (sent to Alex to test).

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

Re: [systemd-devel] [PATCH] architecture: fix building for big-endian PowerPC with gcc

[Lennart Poettering]

On Fri, 11.07.14 15:04, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

> gcc does not define WORDS_BIGENDIAN for big-endian PowerPC. It defines
> __BIG_ENDIAN__ instead. So also check for __BIG_ENDIAN__ to determine if
> the system is big-endian.

A different patch doing more or less the same has since been applied. 

Thanks anyway!
> ---
>  src/shared/architecture.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/shared/architecture.h b/src/shared/architecture.h
> index 4821d5d..ba42761 100644
> --- a/src/shared/architecture.h
> +++ b/src/shared/architecture.h
> @@ -80,7 +80,7 @@ Architecture uname_architecture(void);
>  #  define native_architecture() ARCHITECTURE_X86
>  #  define LIB_ARCH_TUPLE "i386-linux-gnu"
>  #elif defined(__powerpc64__)
> -#  if defined(WORDS_BIGENDIAN)
> +#  if defined(WORDS_BIGENDIAN) || defined(__BIG_ENDIAN__)
>  #define native_architecture() ARCHITECTURE_PPC64
>  #define LIB_ARCH_TUPLE "ppc64-linux-gnu"
>  #  else
> @@ -88,7 +88,7 @@ Architecture uname_architecture(void);
>  #error "Missing LIB_ARCH_TUPLE for PPC64LE"
>  #  endif
>  #elif defined(__powerpc__)
> -#  if defined(WORDS_BIGENDIAN)
> +#  if defined(WORDS_BIGENDIAN) || defined(__BIG_ENDIAN__)
>  #define native_architecture() ARCHITECTURE_PPC
>  #define LIB_ARCH_TUPLE "powerpc-linux-gnu"
>  #  else


Lennart

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

Re: [systemd-devel] [PATCH 1/3] socket: Add Support for TCP keep alive variables

[Zbigniew Jędrzejewski-Szmek]

Pushed all three, with my typo pointed out by sztapnet fixed.

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

Re: [systemd-devel] [PATCH] core: collapse JOB_RELOAD on an inactive unit into JOB_NOP

[Lennart Poettering]

On Wed, 16.07.14 04:15, Jon Severinsson (j...@severinsson.net) wrote:

Sorry for the late review, but this stuff is a bit harder to grok, so I
needed some time to have a closer look.

> Before this commit systemctl reload on an inactive unit with a queued
> start job would block until the unit had started if the unit supported
> reload, but return failure immediately if the unit didn't.

This sounds like correct behaviour to me.

1) I think the rule should be to return only after the unit is in the
desired state, and the desired operation or something equivalent has
been executed. This is useful, so that callers can rely on the fact that
whatever they wanted is actually in effect after returning. The strict
focus is here on the *effect*, the *resulting state* of things.

2) A second rule should be that the operation should fail if the unit is
not in an appropriate state, and is not in process of being brought into
the right state.

The combination of these rules is that we try to be "positive": unless
there's no way to bring the unit into the state the admin wants, we will
not fail, but wait.

Due to rule 2 "systemctl reload" should fail on inactive units. However
if a start job is already queued, we should try to be "positive", and
wait for it to complete.

> Additionally systemctl reload-or-try-restart (and systemctl force-reload)
> would block until the unit had started if the unit supported reload, but
> return *success* immediately if the unit didn't.

This actually also sounds like correct behaviour to me.

"try-restart" means that we try to restart a service, but only if it is
already running. If we are not running this is not considered an
error. If you then add the "reload-or-" to the mix, this means that we
will try to reload it if the unit supports it, instead of restarting it.

So, if a start is already queued, we'll wait for it to finish, so that
the configuration is fully in effect afterwards. But if the thing is not
running at all, then we will not consider that a problem at all and
return success.

This is really what you want actually, because this allows admins (and
scripts) to change some daemon configuration, and then finish off by
issuing "reload-or-try-restart" on the daemon, so that the changes take
effect, and then immediately talk to the daemon, knowing that if it was
running, then the new configuration is definitely in effect. If it
wasn't, then of course we can't talk to the service, but that's OK of
course.

> Finaly reload on an inactive unit without a queued start job would
> reurn failure, but try-restart on the same job would return success.

Well, the "try-" prefix is supposed to be the thing "apply only if
already running, but don't consider it an error if it isn't". We could of
course add "try-reload" to the mix, so that you have a "reload" version
that will not fail if the daemon is not running, but I think that's not
particularly interested

> This behaviour is unintuitive and inconsistent, so make reload of inactive
> units behave just like try-restart.

Well, it might appear surprising in some ways, but there's a lot of
sense in it, and I think what matters is really to look at the effect of
calls, and make guarantees about that.

> Also fixes deadlocks on boot if a unit calls systemctl reload,
> reload-or-try-restart or force-reload on a unit ordered later
> in the boot sequence during startup.

Well, for cases like that, please consider using --no-block, which will
just queue the job, but not wait for it. Or use
--job-mode=ignore-dependencies or so, even though that's a horrid
invention...

Lennart

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

Re: [systemd-devel] [PATCH v3] Refuse mount on symlink

[Lennart Poettering]

On Fri, 15.08.14 02:17, Timofey Titovets (nefelim...@gmail.com) wrote:

Applied! Thanks!

> Signed-off-by: Timofey 

We don't do Signed-off-by on systemd, so I drop this when I pushed it. 

Thanks!

Lennart

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

Re: [systemd-devel] [RFC][PATCH] socket: show full instance name in services' description

[Lennart Poettering]

On Tue, 15.07.14 16:36, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

> Change the way socket activated services are instantiated so that the
> full instnace name with addresses of both parties and not only the
> counter make it into units' descriptions visible in the journal.

Hmm, what I really don't like about this scheme is the selinux handling,
i.e. previously we just pre-allocated a stream when we had to label the
socket, and then used it much later, when the first actual connection
was coming in. Allocating and then freeing it immediately during
labelling sounds not so attractive to me.

Maybe we can fix this problem differently. I mean we use
unit_choose_id() to make sure the primary name for the unit is the
pretty one. Maybe we can find a way how to make sure that the log
messages you are interested in are only generated after that? 

So, hmm, which log messages are you interested in particular to carry
the final name?

Lennart

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

Re: [systemd-devel] [PATCH v3] Refuse mount on symlink

[Timofey Titovets]

2014-08-15 2:00 GMT+03:00 Lennart Poettering :
> On Fri, 15.08.14 01:43, Timofey Titovets (nefelim...@gmail.com) wrote:
>
>>
>> +int fail_if_symlink(const char *unit, const char* where) {
>> +assert(where);
>> +
>> +if (is_symlink(where) > 0) {
>> +log_struct_unit(LOG_WARNING,
>> +unit,
>> +"MESSAGE=%s: Mount on symlink %s
>> not allowed.",
>> +unit, where,
>> +"WHERE=%s", where,
>> +MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
>> +NULL);
>> +
>> +return -ELOOP;
>> +}
>> +return 0;
>> +}
>
> Looks good, but the patch is line broken, I can't apply it like
> that... Maybe attach the patch?
>
>> diff --git a/src/core/mount.h b/src/core/mount.h
>> index 2dcb663..5fc1fe1 100644
>> --- a/src/core/mount.h
>> +++ b/src/core/mount.h
>> @@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult
>> i) _const_;
>>  MountResult mount_result_from_string(const char *s) _pure_;
>>
>>  void warn_if_dir_nonempty(const char *unit, const char* where);
>> +
>> +int fail_if_symlink(const char *unit, const char* where);
>
> No reason to export this, or am I missing something? Just make the
> function static, and don't include it in the header file, unless some
> other .c file is actually using it.
Fixed in patch
> Otherwise looks good.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat



-- 
Have a nice day,
Timofey.
From 5f4325df1cd8f3c6ee3790e6c9c23b6dd0aaffec Mon Sep 17 00:00:00 2001
From: Timofey 
Date: Fri, 15 Aug 2014 02:05:47 +0300
Subject: [PATCH] Refuse mount on symlink

Signed-off-by: Timofey 
---
 TODO  |  2 --
 src/core/mount.c  | 21 +
 src/shared/util.c | 12 
 src/shared/util.h |  2 ++
 4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/TODO b/TODO
index d58da71..c8e9f27 100644
--- a/TODO
+++ b/TODO
@@ -93,8 +93,6 @@ Features:
 
 * Add a new verb "systemctl top"
 
-* refuse mounting on symlinks
-
 * logind: allow users to kill or lock their own sessions
 
 * add new gpt type for btrfs volumes
diff --git a/src/core/mount.c b/src/core/mount.c
index 39a9aaf..ec90b0a 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -827,6 +827,23 @@ void warn_if_dir_nonempty(const char *unit, const char* where) {
NULL);
 }
 
+static int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (is_symlink(where) > 0) {
+log_struct_unit(LOG_WARNING,
+unit,
+"MESSAGE=%s: Mount on symlink %s not allowed.",
+unit, where,
+"WHERE=%s", where,
+MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
+NULL);
+
+return -ELOOP;
+}
+return 0;
+}
+
 static void mount_enter_unmounting(Mount *m) {
 int r;
 
@@ -877,6 +894,10 @@ static void mount_enter_mounting(Mount *m) {
 if (p && mount_is_bind(p))
 mkdir_p_label(p->what, m->directory_mode);
 
+r = fail_if_symlink(m->meta.id, m->where);
+if (r < 0)
+goto fail;
+
 if (m->from_fragment)
 r = exec_command_set(
 m->control_command,
diff --git a/src/shared/util.c b/src/shared/util.c
index 3d16cd1..0db4bd9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6918,3 +6918,15 @@ int take_password_lock(const char *root) {
 
 return fd;
 }
+
+int is_symlink(const char *path) {
+struct stat info;
+
+if (lstat(path, &info) < 0)
+return -errno;
+
+if (S_ISLNK(info.st_mode))
+return 1;
+
+return 0;
+}
\ No newline at end of file
diff --git a/src/shared/util.h b/src/shared/util.h
index 101d2df..bd8bbb2 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -966,3 +966,5 @@ char *tempfn_random(const char *p);
 bool is_localhost(const char *hostname);
 
 int take_password_lock(const char *root);
+
+int is_symlink(const char *path);
\ No newline at end of file
-- 
2.0.4

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

Re: [systemd-devel] [RFC] Remove warning: may be used uninitialized

[Timofey Titovets]

I just use:
./autogen.sh && ./configure && make

But did not matter, thanks for explanation, i think what this thread
can be closed.

2014-08-15 1:57 GMT+03:00 Lennart Poettering :
> On Fri, 15.08.14 01:11, Timofey Titovets (nefelim...@gmail.com) wrote:
>
>> Good time of day, when i compile systemd i get ton of warning like:
>>  may be used uninitialized in function...
>> May be i can spend some time and create patches with fixes of that warnings?
>> As example declare it by default to 0 or something like that.
>>
>> Or this is not a bug, just feature? %)
>
> Did you compile this with -flto? (which is the default, unless you build
> with "autogen.sh c" or suchlike)
>
> With lto enabled gcc warnings about that are not useful, and should be
> ignored mostly, right now. Turn off lto, and they become more useful,
> but we should be pretty clean with that already.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat

-- 
Have a nice day,
Timofey.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v3] Refuse mount on symlink

[Lennart Poettering]

On Fri, 15.08.14 01:43, Timofey Titovets (nefelim...@gmail.com) wrote:

> 
> +int fail_if_symlink(const char *unit, const char* where) {
> +assert(where);
> +
> +if (is_symlink(where) > 0) {
> +log_struct_unit(LOG_WARNING,
> +unit,
> +"MESSAGE=%s: Mount on symlink %s
> not allowed.",
> +unit, where,
> +"WHERE=%s", where,
> +MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
> +NULL);
> +
> +return -ELOOP;
> +}
> +return 0;
> +}

Looks good, but the patch is line broken, I can't apply it like
that... Maybe attach the patch?

> diff --git a/src/core/mount.h b/src/core/mount.h
> index 2dcb663..5fc1fe1 100644
> --- a/src/core/mount.h
> +++ b/src/core/mount.h
> @@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult
> i) _const_;
>  MountResult mount_result_from_string(const char *s) _pure_;
> 
>  void warn_if_dir_nonempty(const char *unit, const char* where);
> +
> +int fail_if_symlink(const char *unit, const char* where);

No reason to export this, or am I missing something? Just make the
function static, and don't include it in the header file, unless some
other .c file is actually using it.

Otherwise looks good.

Lennart

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

Re: [systemd-devel] [RFC] Remove warning: may be used uninitialized

[Lennart Poettering]

On Fri, 15.08.14 01:11, Timofey Titovets (nefelim...@gmail.com) wrote:

> Good time of day, when i compile systemd i get ton of warning like:
>  may be used uninitialized in function...
> May be i can spend some time and create patches with fixes of that warnings?
> As example declare it by default to 0 or something like that.
> 
> Or this is not a bug, just feature? %)

Did you compile this with -flto? (which is the default, unless you build
with "autogen.sh c" or suchlike) 

With lto enabled gcc warnings about that are not useful, and should be
ignored mostly, right now. Turn off lto, and they become more useful,
but we should be pretty clean with that already.

Lennart

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

Re: [systemd-devel] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init

[Lennart Poettering]

On Wed, 16.07.14 20:45, Jon Severinsson (j...@severinsson.net) wrote:

> 
> onsdagen den 16 juli 2014 16:49:55 skrev  Lennart Poettering:
> > On Wed, 16.07.14 12:09, Jon Severinsson (j...@severinsson.net) wrote:
> > > From: Tollef Fog Heen 
> > 
> > If you really want to support systems without systemd installed, then I'd
> > recommend placing this rules file in the systemd pacakge, so that it is
> > gone if you uninstall systemd.
> > 
> > That said, nothing of what the file does is in any way something that
> > could break things on non-systemd systems, hence the whole excercise
> > sounds pointless...
> 
> The file still contains one RUN+="@rootlibexecdir@/systemd-sysctl ...", which 
> I don't think is desirable when systemd is installed but not running as PID 1 
> (which we also have to support).

The tool actually will work fine if you run it outside of
systemd. There's no dependency on systemd being PID 1 in that tool.

But I do see your point.

Lennart

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

[systemd-devel] [PATCH v3] Refuse mount on symlink

[Timofey Titovets]

Just complete TODO:
* refuse mounting on symlinks

I not add this TODO, but i think what it avoid potential security 
{and/or} bug issues


v2 -> v3:
Rebase on latest git
Add message : Mount on symlink  not allowed.

if systemd try mounting entry from fstab on symlink, user get:
$ systemctl status symlink.mount 


  [1:29:45]
● symlink.mount - /symlink
   Loaded: loaded (/etc/fstab)
   Active: failed (Result: resources)
Where: /symlink
 What: /dev/sda2
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)

Aug 15 01:26:47 beplan.lan systemd[1]: Mounting /symlink...
Aug 15 01:26:47 beplan.lan systemd[1]: symlink.mount: Mount on symlink 
/symlink not allowed.
Aug 15 01:26:47 beplan.lan systemd[1]: symlink.mount failed to run 
'mount' task: Too many levels of symbolic links

Aug 15 01:26:47 beplan.lan systemd[1]: Failed to mount /symlink.
Aug 15 01:26:47 beplan.lan systemd[1]: Unit symlink.mount entered failed 
state.


can be pulled from:
https://github.com/Nefelim4ag/systemd.git


 TODO  |  2 --
 src/core/mount.c  | 21 +
 src/core/mount.h  |  2 ++
 src/shared/util.c | 12 
 src/shared/util.h |  2 ++
 5 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/TODO b/TODO
index d58da71..c8e9f27 100644
--- a/TODO
+++ b/TODO
@@ -93,8 +93,6 @@ Features:

 * Add a new verb "systemctl top"

-* refuse mounting on symlinks
-
 * logind: allow users to kill or lock their own sessions

 * add new gpt type for btrfs volumes
diff --git a/src/core/mount.c b/src/core/mount.c
index 39a9aaf..f51e0f3 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -827,6 +827,23 @@ void warn_if_dir_nonempty(const char *unit, const 
char* where) {

NULL);
 }

+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (is_symlink(where) > 0) {
+log_struct_unit(LOG_WARNING,
+unit,
+"MESSAGE=%s: Mount on symlink %s not 
allowed.",

+unit, where,
+"WHERE=%s", where,
+MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
+NULL);
+
+return -ELOOP;
+}
+return 0;
+}
+
 static void mount_enter_unmounting(Mount *m) {
 int r;

@@ -877,6 +894,10 @@ static void mount_enter_mounting(Mount *m) {
 if (p && mount_is_bind(p))
 mkdir_p_label(p->what, m->directory_mode);

+r = fail_if_symlink(m->meta.id, m->where);
+if (r < 0)
+goto fail;
+
 if (m->from_fragment)
 r = exec_command_set(
 m->control_command,
diff --git a/src/core/mount.h b/src/core/mount.h
index 2dcb663..5fc1fe1 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult i) 
_const_;

 MountResult mount_result_from_string(const char *s) _pure_;

 void warn_if_dir_nonempty(const char *unit, const char* where);
+
+int fail_if_symlink(const char *unit, const char* where);
\ No newline at end of file
diff --git a/src/shared/util.c b/src/shared/util.c
index 3d16cd1..0db4bd9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6918,3 +6918,15 @@ int take_password_lock(const char *root) {

 return fd;
 }
+
+int is_symlink(const char *path) {
+struct stat info;
+
+if (lstat(path, &info) < 0)
+return -errno;
+
+if (S_ISLNK(info.st_mode))
+return 1;
+
+return 0;
+}
\ No newline at end of file
diff --git a/src/shared/util.h b/src/shared/util.h
index 101d2df..bd8bbb2 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -966,3 +966,5 @@ char *tempfn_random(const char *p);
 bool is_localhost(const char *hostname);

 int take_password_lock(const char *root);
+
+int is_symlink(const char *path);
\ No newline at end of file

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

Re: [systemd-devel] Logind error - Failed to abandon session scope: Connection reset

[Lennart Poettering]

On Thu, 17.07.14 11:49, Roger Qiu (roger@polycademy.com) wrote:

Hi,

(sorry for the late response)

> Are you saying that logind should be terminated first then dbus
> should be terminated second?

Yes, dbus should best be stopped after logind.

> In what situations would their termination sequence get mixed?

That's a good question. I am a bit puzzled why this race never shows up
for me, but it shows up for you.

I mean, looking at the deps both services are not ordered against each
other, so it kinda should happen frequently, but it never does for me...

Anyway, this is really just cosmetic, the only thing we can fix here I
guess is hide the warning. Or just wait for kdbus at which point the
problem goes away entirely as the bus will survive the entire system
runtime.

Lennart

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

Re: [systemd-devel] Socket activated SSHD service showing up as a failure when the client connection fReply-To:

[Lennart Poettering]

On Thu, 17.07.14 13:49, Roger Qiu (roger@polycademy.com) wrote:

> I've googled around and saw that 255 error code comes up a lot. But
> most resources talked about "ssh" not necessarily the "sshd". If we
> ignore 255 code, is it possible we're also ignoring some other real
> errors, and not just the client failing the connection? Basically I
> would like sshd to report an error,  if it is indeed an error from
> the host's side, not the client's side.

In general I'd recommend to use ExecStart=-/usr/sbin/sshd...,
i.e. with the "-" between the = and the /. This tells systemd to
completely ignore the exit/failure status of the process.

The reason for this is that if an sshd instance fails it would stay
around in failed state. Since you use per-connection instances this
might be able to give an attacker the chance to create tons of failed
services, until systemd refuses. 

I'd hence recommend to always ignore errors for services that are
instantiated in theoretic unbounded numbers. You'll still get them
reported in the logs, but I'd recommend not making them enter a service
into "failed" mode. 

I hope that makes some sense,

Lennart

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

Re: [systemd-devel] Unit to test if a domain is reachable

[Lennart Poettering]

On Thu, 17.07.14 11:37, Moviuro (movi...@gmail.com) wrote:

> However, everything I tried proved an utter failure: target says reached even 
> though it doesn't even have an IP on any link; wait-online obviously didn't 
> even check if I had a DNS whatsoever.

This sounds like a shortcoming of your network stack? 
network-wait-online.target is
supposed to be filled with meaning by your networking stack,
i.e. NetworkManager or suchlike. 

The implementation that is networkd should get this right really.

Which one are you using?

Lennart

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

Re: [systemd-devel] Networkd dhcp hostname override

[Thomas Suckow]

It's used as a general identifier of the client in any situation, so
that the server can pass back specific options.  Yes, this can be done
by looking at the client MAC address, but that's not sufficient in the
following cases:

1) non-Ethernet hardware addresses
2) dual-stack clients using DHCPv4 and DHCPv6
3) you change the NIC and want the same options
4) the NIC doesn't have a permanent MAC address

The client ID (and on the DHCPv6 side, the DUID) is the
single-identifier solution that should really be used instead of the MAC
address.



Touché

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

[systemd-devel] [RFC] Remove warning: may be used uninitialized

[Timofey Titovets]

Good time of day, when i compile systemd i get ton of warning like:
 may be used uninitialized in function...
May be i can spend some time and create patches with fixes of that warnings?
As example declare it by default to 0 or something like that.

Or this is not a bug, just feature? %)

-- 
Have a nice day,
Timofey.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Networkd dhcp hostname override

[Dan Williams]

On Thu, 2014-08-14 at 14:29 -0700, Thomas Suckow wrote:
> >> Typically the send-hostname thing is actually used for DNS updates,
> >> where you send the hostname to the DHCP server, which then gives you a
> >> lease and sends the hostname + IP to the DNS server, so that your
> >> machine is accessible via DNS automatically.  I've never heard of it
> >> being used as a Client ID, and AFAIK the "send hostname" and client ID
> >> can both be used at the same time.
> Yes. In my network the "Host Name" dhcp option is used to configure dns. I am 
> attempting to use a single machine to operate several instances of the same 
> server. Therefore I need to bind each server to a unique IP. Currently I use 
> macvlan and dhcpcd to have the dns entries created.
> 
> >
> > this means that allowing to provide a custom hostname that is not set via 
> > hostname or hostnamectl makes no sense at all.
> 
> I will agree that conventionally in the linux world the hostname is for the 
> system itself and not per interface.
> I suppose it needs to be decided whether it is tolerable for this convention 
> to be "bent" in networkd. Bridged virtual machines effectively do the same 
> thing, but one could argue it isn't really the same machine.
> 
> > Since you want to send your actual hostname.
> 
> In this case I don't, I want to specify a custom host name for dhcp on a 
> specific interface.
> 
> > So current boolean for SendHostname is the right way to do this. In 
> > addition someone might add a ClientId=foo option.
> 
> I am not very familiar with the Client ID. It appears to only be useful to 
> change if you wanted multiple dhcp leases with the same hardware address, 
> which I have avoided with macvlans.

It's used as a general identifier of the client in any situation, so
that the server can pass back specific options.  Yes, this can be done
by looking at the client MAC address, but that's not sufficient in the
following cases:

1) non-Ethernet hardware addresses
2) dual-stack clients using DHCPv4 and DHCPv6
3) you change the NIC and want the same options
4) the NIC doesn't have a permanent MAC address

The client ID (and on the DHCPv6 side, the DUID) is the
single-identifier solution that should really be used instead of the MAC
address.

Dan

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

Re: [systemd-devel] Networkd dhcp hostname override

[Thomas Suckow]

Typically the send-hostname thing is actually used for DNS updates,
where you send the hostname to the DHCP server, which then gives you a
lease and sends the hostname + IP to the DNS server, so that your
machine is accessible via DNS automatically.  I've never heard of it
being used as a Client ID, and AFAIK the "send hostname" and client ID
can both be used at the same time.

Yes. In my network the "Host Name" dhcp option is used to configure dns. I am 
attempting to use a single machine to operate several instances of the same server. 
Therefore I need to bind each server to a unique IP. Currently I use macvlan and dhcpcd 
to have the dns entries created.



this means that allowing to provide a custom hostname that is not set via 
hostname or hostnamectl makes no sense at all.


I will agree that conventionally in the linux world the hostname is for the 
system itself and not per interface.
I suppose it needs to be decided whether it is tolerable for this convention to be 
"bent" in networkd. Bridged virtual machines effectively do the same thing, but 
one could argue it isn't really the same machine.


Since you want to send your actual hostname.


In this case I don't, I want to specify a custom host name for dhcp on a 
specific interface.


So current boolean for SendHostname is the right way to do this. In addition 
someone might add a ClientId=foo option.


I am not very familiar with the Client ID. It appears to only be useful to 
change if you wanted multiple dhcp leases with the same hardware address, which 
I have avoided with macvlans.


Regards,
Thomas

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

Re: [systemd-devel] Networkd dhcp hostname override

[Marcel Holtmann]

Hi Dan,

 Now that networkd can send the systems hostname to the dhcp server, I 
 would find it useful to have an option to override the hostname that gets 
 sent.
 
 In my use case, I would like to setup a number of macvlans with different 
 hostnames.
 
 Something as simple as
 
 [DHCP]
 SendHostname=true
 Hostname=foo
>>> 
>>> Sounds useful, though this could just be a single option
>>> SendHostname=foobar or so. If not set it sends the system hostname,
>>> otherwise the specified hostname. Or something like that.
>> 
>> what would this be useful for? Either you send the hostname or you don't.
>> 
>> I think what you are looking for is an option to set the Client ID. And when 
>> that is set, then that is used. If it not set and SendHostname=true, the 
>> hostname is used as Client ID. If SendHostname=false and Client ID is not 
>> send, then none of them are send.
> 
> Typically the send-hostname thing is actually used for DNS updates,
> where you send the hostname to the DHCP server, which then gives you a
> lease and sends the hostname + IP to the DNS server, so that your
> machine is accessible via DNS automatically.  I've never heard of it
> being used as a Client ID, and AFAIK the "send hostname" and client ID
> can both be used at the same time.

this means that allowing to provide a custom hostname that is not set via 
hostname or hostnamectl makes no sense at all. Since you want to send your 
actual hostname. So current boolean for SendHostname is the right way to do 
this. In addition someone might add a ClientId=foo option.

Regards

Marcel

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

Re: [systemd-devel] [PATCH v3 2/3] cxgb4: use module_long_probe_init()

[Luis R. Rodriguez]

On Thu, Aug 14, 2014 at 09:42:49AM -0700, Casey Leedom wrote:
>
> On 08/13/2014 04:33 PM, Anish Bhatt wrote:
>> Adding Casey who's actually incharge of this code and missing from the CC 
>> list
>
>   Thanks Anish!
>
>   As I mentioned to Anish, there are fundamentally two problems here in the 
> time being consumed by the cxgb4 PCI probe() function:
>
>  1. When various firmware files aren't present, request_firmware()
> can take a very long time.  This is easily solved by using
> request_firmware_direct() and I certainly have no objection to that.

I sent a patch for this a while ago, since there is no objection if
you'd like to apply the patch:

http://patchwork.ozlabs.org/patch/363756/

Apart from that you also want to use asynch firmware loading but
to use that properly (I also had sent some basic initial patches
for asynch firmware loading but without moving out other logic
yet) you want to also let driver initalization complete
asynchronously later.

>  2. When there are multiple adapters present in a system which
> need firmware downloaded, each one individually may not take
> a ton of time but together they can exceed simple Module Load
> Timeouts.  There's not a simple answer here.

I had originally recommended to write your own platform driver for
this and have each port probe but Greg has provided the last advice
for this on the patch I sent to add deferred probe support from
init, his recommendation was for you to write your own bus code for
the driver:

http://www.spinics.net/lists/linux-scsi/msg76695.html

>   Part of the problem here is that it's a Module Load Timeout instead of a 
> per-device Probe Timeout.

Seems like you can fix this with a bus driver.

>   Part of the problem is that the current 
> architecture has Device Probe happening out of the Module Initialization 
> when we call pci_register_driver() with our PCI Device ID Table.
>
>   Running the Device Probes asynchronously has been discussed but that has 
> the problem that it's then impossible to return the Device Probe Status.  
> This is a problem for Driver Fallback and, if the probe fails, we're not 
> supposed to call the Device Remove function. To make this work, the 
> synchronous/asynchronous boundary would really need to be up in the PCI 
> Infrastructure layer so the Device Probe status could be captured in the 
> normal logic.  This would be a moderately large change there ...

Some maintainers consider most of the work to get what you need done
simple, I've tried to explain it ain't so, so glad you provided a bit
of details here. To be clear its not just about asynch firmware loading,
you need a bit more work. Can you evaluate using a bus driver?

>   Deferring the Device Initialization till the first "ifup" has also been 
> discussed and is certainly possible, though a moderately large 
> architectural change to every driver which needs it.  It also has the 
> unfortunate effect of introducing random large delays directly on user 
> commands.  From a User Experience perspective I would tend to want such 
> large delays in the Device Probe

You should just use asynch firmware loading there and only once your
driver is done loading firmware start exposing the device(s) as you
see fit with your bus driver.

>.  But that's something that really 
> deserves a real User Interaction study rather than throwing a dart.
>
>   On the whole, I think that introducing these Module Load Timeouts hasn't 
> been well thought out with respect to the repercussions and I'd be more 
> inclined to back that out till a well thought out design is developed.  But 
> I'm here for the discussion.

The way that the 30 second timeout was introduced as a new driver
initialization requirement was certainly not ideal specially since
the respective systemd patch that intended to trigger the SIGKILL on
kmod module loading only took effect once kernel commit 786235ee
went in about a year later, and since the original systemd commit
was only addressing asynchronous firmware loading as a possible
issue that drivers may need to fix. The cxgb4 driver is a good
example that needs quite a bit of more work. Regardless systemd
folks are right -- but again, having this be introduced as a new
requirement that otherwise simply kills drivers seems a bit too
aggressive specially if its killing boot on some systems due to
delays on storage drivers. What's done is done -- and we need to
move on. We already reviewed twice now reverting 786235ee and that
won't happen, as a compromise we're looking for an easy agreeable
general driver work around that would both circumvent the issue
and let us easily grep for broken drivers. The deferred probe trick
was the first approach and this series addresses the more agreeable
solution. This 2 line patch then is what we are looking as work
around until your driver gets properly fixed.

Apart from these kernel changes there are systemd changes we've
looked at modifying, Hannes' patch 9719859c07a, now merge

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Timofey Titovets]

>> Just completed TODO:
>> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>> ioctl, with START_IO
>
> Hmm, the patch is line broken...
>
> But this patch only replaces one ioctl with another right? It doesn't
> actually improve anything effectively, does it?
>
> I am not really convinced that we should make this change, maybe we
> should remove readahead from the the package instead...

On my machine it not get my any speed up (btrfs, hdd/ssd, latest arch).
But i already talk with ext4 developers, and one of devs try to port
e4rat functionally to ext progs and mainline kernel.
And as i think on ext4, we can port to readahead functional from ext
progs and defrag files what reading while boot, to one line on hdd.
But it function must be part of systemd?

2014-08-14 20:29 GMT+03:00 Lennart Poettering :
> On Mon, 21.07.14 15:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
>>
>> On Mon, Jul 21, 2014 at 09:38:57AM +0300, Timofey Titovets wrote:
>> > Just completed TODO:
>> > * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>>
>> This is still not an explanation. What is the difference between the
>> two?
>
> The idea really was to just defrag the bits of files that we really
> needed instead of all of them...

On btrfs with compress mount option, we can't determine file
fragmented or not, i'm didn't deep read of btrfs progs while porting
BTRFS_IOC_DEFRAG_RANGE, but as i understand btrfs self defrag files
and BTRFS_IOC_DEFRAG_RANGE just add aditional filters to this
operation, but i can be wrong.

> Lennart
>
> --
> Lennart Poettering, Red Hat



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

Re: [systemd-devel] [PATCH] resolved: fix warnings

[Daniel Buch]

I just hit this assert on my arch system with gcc 4.9,

dbuch-laptop systemd-resolved[457]: Assertion 's->protocol ==
DNS_PROTOCOL_LLMNR' failed at src/resolve/resolved-dns-scope.c:369


2014-08-14 19:58 GMT+02:00 Lennart Poettering :

> On Sat, 19.07.14 10:37, Thomas H.P. Andersen (pho...@gmail.com) wrote:
>
> > --- a/src/resolve/resolved-dns-scope.c
> > +++ b/src/resolve/resolved-dns-scope.c
> > @@ -292,7 +292,7 @@ int dns_scope_llmnr_membership(DnsScope *s, bool b) {
> >  if (s->family == AF_INET) {
> >  struct ip_mreqn mreqn = {
> >  .imr_multiaddr = LLMNR_MULTICAST_IPV4_ADDRESS,
> > -.imr_ifindex = s->link->ifindex,
> > +.imr_ifindex = s->link ? s->link->ifindex : 0,
>
> LLMNR scopes don't exist with a NULL link value, they are strictly bound
> to physical links.
>
> I have now added a couple of assert()s to the function, that should
> clarify that and hopefully tell the compiler that these are necessarily
> initialized.
>
> Does this make things work for you? Please check.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub

[Kay Sievers]

On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie
 wrote:
> I recently opened this Debian bug, for which I attach a
> patch that seems to work. Bug report quoted in full below.
>
> I would appreciate udev maintainers' opinions on whether this is
> likely to break non-USB devices, or whether there is a better way
> to do it.

Maybe replace streq(dsubsys, "usb") with a specific match on " devtype
== usb_device" (sysfs hierarchy is usb_interface -> usb_device) and if
we hit that, we make sure we stop looking at any of the parents?

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

Re: [systemd-devel] Warnings from recent commits

[Lennart Poettering]

On Mon, 21.07.14 16:09, Samuli Suominen (ssuomi...@gentoo.org) wrote:

> 
> 4.6 is the minimum dependency as-is, for eg. _Static_assert,
> DISABLE_WARNING_{DECLARATION_AFTER_STATEMENT,FORMAT_NONLITERAL,MISSING_PROTOTYPES,NONNULL},
> REENABLE_WARNING
> Just to get the udev part of the systemd tree compiled with gcc-4.5 or
> older, you need something like,
> http://510524.bugs.gentoo.org/attachment.cgi?id=380992
> 
> Just saying, that 4.6 minimum wouldn't be a new thing, it's been around
> for several releases now

I am fine with supporting gcc 4.5. This patch really looks like it could
be turned into something upstreamable. I mean, we already have a manual
fallback for assert_cc(), so it shouldn't be too hard to figure
something out that works on gcc 4.5. I mean, i think it would be totally
OK to throw warnings on gcc 4.5, as long as it compiles. And the
DISABLE_WARNING_xyz stuff is really only stuff to make warnings go away,
that is all...

Lennart

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

Re: [systemd-devel] Forcing default route as the one provided by one interface

[Lennart Poettering]

On Thu, 17.07.14 15:44, Mauricio Tavares (raubvo...@gmail.com) wrote:

>   Newbie question: if I have two interfaces (in separate networks)
> with each of them using DHCP, how can I specify that I want the
> default route to be the one being obtained by, say, interface A? I
> read through 
> http://www.freedesktop.org/software/systemd/man/systemd.network.html
> and did not see any option to specify that a given interface is
> providing the default gateway. Am I missing something?
> 
> If such an option does not exist, would it be possible to have a, say,
> SetDefaultGateway/UseDefaultGateway (boolean) option to do so?

networkd should probably gain a way to define a default metric for all
routes defined on a specific .network, and maybe a second one as default
metric for all DHCP acquired routes on a specify network. That way you
could just set two different defaults for your two networks and the IP
stack will always use the right one.

Added to the TODO list.

Lennart

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

Re: [systemd-devel] Start Up services using systemd

[Lennart Poettering]

On Mon, 21.07.14 17:26, Bharath Chandra (ellurubharat...@gmail.com) wrote:

Heya,

> Hi,
> 
> I am trying to analyze what all services that would start during boot up
> process statically, i.e just by looking into the unit files, without
> running the system. I have understood the dependecies of unit files using
> Wants, Requires,After but i do not find all of the services which are
> listed under a specific target.wants directory to be in active state.

Some services actually terminate after they have done their job. Do you
have any services in particular in mind here that do not stay active?
>From which targets are they pulled in?

> 
> Eg: All the services are not loaded which are present under
> multi-user.target.wants directory. I am new to systemd. Kindly help me in
> understanding the dependencies.

This is actually not that easy, as many of the services started at boot
might get pulled in dynamically due to udev rules, or because of
generators and suchlike which can dynamically extend the initial
transaction depending on external configuration.

Lennart

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

Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

[Lennart Poettering]

On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> > Not aware of an C++ code. There's a vala one, and of course the one we
> > ship in systemd itself in C, but c++ i cannot help you with, sorry.
> 
> Is it possible to write a PasswordAgent in shell? Example code please
> ;)

Probably possible, after all bash allows you to talk to unix sockets and
stuff. And you could probably put the protocol together with carefully
crafted echo lines, but I know of nobody who has done that so far...

> > I fear I don#t have an easy suggestion. What kind of device do you
> > actually want to make work here? some smartcard or so?
> 
> That's the vision, yes. At the moment, my keyscript unlocks a small
> LUKS partition on the disk and takes the key for the root fs from
> there. That's just a placeholder for a future more complicated setup.

Not following. You place a key for a LUKS partition on another LUKS
partition? What's the benefit of that? Inception? ;-)

> With Debian's initramfs, unlocking the small LUKS partition works
> transparently even with plymouth. This is real functionality being
> lost in the systemd migration.

Haven't understood your setup yet I must say, before I can agree that
this is "real functionality"...

> > I think in the long run we should somehow work towards the direction to
> > make things like that just work, for common devices like smartcards and
> > other auth tokens...
> 
> First step to do that would be to implement support for the keyscript=
> option in /etc/crypttab as this is the canonical place to hook into on
> non-system systems. At least it's the case on Debian, I don't know
> about Red Hat, Fedora and other distributions.

Well, I am really not convinced that this is a well-defined
interface. Even in your case you have to wait for two devices at least,
right? a synchronous shell callout won't solve that for you since
there's no guarantee that the second LUKS device has already shown up,
or am I missing something?

Shell callouts always appear simply or powerful, but when it comes to
waiting for devices, and executing things as things pop up its often
really not the right tool.

As mentioned we really should redesign the whole thing around the kernel
keyring anyway, I am really conservative in adding support for Debian's
keyscript thingy upstream now. (That of course shouldn't stop Debian
from adding this downstream)

> The PasswordAgent stuff is really neat, but complicated due to the
> socket communication, and it's far from being a drop-in replacement.

Well, it's really easy in C I figure, but admittedly not in shell...

Lennart

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

Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

[Marc Haber]

Hi,

On Thu, Aug 14, 2014 at 08:09:05PM +0200, David Herrmann wrote:
> That is, to solve your problem, I'd recommend to make systemd allow
> external scripts like "keyscript=" before placing *.ask files (or some
> other hookup or configuration, if scripts are not suitable for that).

If systemd would support keyscript=, migration would be painless. I am
absolutely in favor of that ;-)

Greetings
Marc, unfortunately too bad a C programmer to write a patch

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

[Marc Haber]

Hi Lennart,

thanks for your thoughts.

On Thu, Aug 14, 2014 at 07:44:59PM +0200, Lennart Poettering wrote:
> On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> > (4)
> > My PasswordAgent indicates taking responsibility by unlinking the
> > ask.xxx file from /run/systemd/ask-password. The interactive password
> 
> Well, so far it is the querier that removes the file, not the agent...

I see. What would happen if I remove the file myself?

> > To use this to unlock the root fs, an entire python installation would
> > need to go in my initramfs, right? And if I want to keep things
> > simple, the best idea would be to write my PasswordAgent in a compiled
> > language which would only need the binary and its libs in the
> > initramfs, right?
> 
> Yes. Correct. If you want to stick something into the initrd, I'd always
> do things in C (or shell if you must), but nothing else.
> 
> > Is there code for an example PasswordAgent in C++ which I can use as a
> > template? I am quite reluctant to write a program which needs to to
> > complex string processing and is bound to run as root in C because my
> > C experience is somewhat lacking.
> 
> Not aware of an C++ code. There's a vala one, and of course the one we
> ship in systemd itself in C, but c++ i cannot help you with, sorry.

Is it possible to write a PasswordAgent in shell? Example code please ;)

> > Can you please recommend a way to allow me to migrate to systemd?
> > Without keyscript= being supported in /etc/crypttab, I need to replace
> > my 50 line key script written in POSIX shell and would like to keep
> > things simple.
> > 
> > Thank you very much for your consideration.
> 
> I fear I don#t have an easy suggestion. What kind of device do you
> actually want to make work here? some smartcard or so?

That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.

With Debian's initramfs, unlocking the small LUKS partition works
transparently even with plymouth. This is real functionality being
lost in the systemd migration.

> I think in the long run we should somehow work towards the direction to
> make things like that just work, for common devices like smartcards and
> other auth tokens...

First step to do that would be to implement support for the keyscript=
option in /etc/crypttab as this is the canonical place to hook into on
non-system systems. At least it's the case on Debian, I don't know
about Red Hat, Fedora and other distributions.

The PasswordAgent stuff is really neat, but complicated due to the
socket communication, and it's far from being a drop-in replacement.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] machine_kill(): Don't kill the unit when killing the leader

[Lennart Poettering]

On Thu, 14.08.14 19:59, Eelco Dolstra (eelco.dols...@logicblox.com) wrote:

Thanks!

Applied!

> If "machinectl poweroff" or "machinectl reboot" is used on a
> systemd-nspawn container started with --keep-unit and --register, it
> should *only* send the appropriate signal to the leader PID (i.e. the
> container's systemd process). It shouldn't fall through to
> manager_kill_unit() to also send the signal to the unit. The latter
> ends up killing systemd-nspawn, which takes down the container
> prematurely.
> ---
>  src/machine/machine.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/machine/machine.c b/src/machine/machine.c
> index 1c9177e..13d3448 100644
> --- a/src/machine/machine.c
> +++ b/src/machine/machine.c
> @@ -493,6 +493,8 @@ int machine_kill(Machine *m, KillWho who, int signo) {
>  
>  if (kill(m->leader, signo) < 0)
>  return -errno;
> +
> +return 0;
>  }
>  
>  /* Otherwise make PID 1 do it for us, for the entire cgroup */


Lennart

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

Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

[David Herrmann]

Hi

On Thu, Aug 14, 2014 at 7:44 PM, Lennart Poettering
 wrote:
> On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>
> Heya,
>
>> I have read the thread (from 2012?) where those things were discussed
>> here and I understand that I should replace my keyscript with a
>> passwort agent. Things would then work like this:
>
> There's currently no streamlined support for stacking password questions
> really. You currently cannot "take possession" of specific password
> questions.
>
> Also note that we really should redesign the entire scheme around the
> kernel keyring as only transport for the keys (and the bus for
> signalling). I am a bit conservative in changing here too much for now,
> because we really should figure out that bit first.

The hack you describe here should work, however, it's really an ugly
hack. One thing you really need to take care of is to not cause
recursive loops. That is, if your agent places a new *.ask file, it
will be called on it again and *must* ignore it. Otherwise, you end up
with an endless loop.

Anyhow, I don't think we should support stacked agents. Agents are
meant as an API to interact with users. They should not employ any
logic/rules regarding the query itself. They're solely meant as GUI.
That is, to solve your problem, I'd recommend to make systemd allow
external scripts like "keyscript=" before placing *.ask files (or some
other hookup or configuration, if scripts are not suitable for that).
I have never worked with crypttab, though. I have to refer to Lennart
here to tell whether that makes sense. I just want to make clear that
once you query the ask-password tool, you will inevitably end up
forwarding that request unchanged to an UI.

Polkit provides .rule scripts for that. We don't have any equivalent
for ask-password. I'm not sure whether that would make sense.

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

Re: [systemd-devel] compile with clang broken

[Lennart Poettering]

On Fri, 18.07.14 16:02, Thomas H.P. Andersen (pho...@gmail.com) wrote:

> 1716f6dcf54d4c181c2e2558e3d5414f54c8d9ca (resolved: add LLMNR support
> for looking up names) broke the build on clang.
> 
> src/resolve/resolved-manager.c:553:43: error: non-const static data
> member must be initialized out of line
> uint8_t buffer[CMSG_SPACE(MAX(sizeof(struct in_pktinfo), sizeof(struct
> in6_pktinfo)))
> 
> Moving the MAX(...) to a separate line fixes that problem but another
> error then happens:
> 
> src/resolve/resolved-manager.c:554:25: error: fields must have a
> constant size: 'variable length array in structure' extension will
> never be supported
> uint8_t buffer[CMSG_SPACE(size)
> 
> We have encountered the same problem before and Lennart was able to
> write the code in a different way. Would this be possible here too?

My sugegstion here would be to maybe rewrite the MAX() macro to use
__builtin_constant_p() so that it becomes constant if the params are
constant, and only uses code block when it isn't. Or so...

http://lists.freedesktop.org/archives/systemd-devel/2014-August/021912.html

Lennart

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

[systemd-devel] [PATCH] machine_kill(): Don't kill the unit when killing the leader

[Eelco Dolstra]

If "machinectl poweroff" or "machinectl reboot" is used on a
systemd-nspawn container started with --keep-unit and --register, it
should *only* send the appropriate signal to the leader PID (i.e. the
container's systemd process). It shouldn't fall through to
manager_kill_unit() to also send the signal to the unit. The latter
ends up killing systemd-nspawn, which takes down the container
prematurely.
---
 src/machine/machine.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/machine/machine.c b/src/machine/machine.c
index 1c9177e..13d3448 100644
--- a/src/machine/machine.c
+++ b/src/machine/machine.c
@@ -493,6 +493,8 @@ int machine_kill(Machine *m, KillWho who, int signo) {
 
 if (kill(m->leader, signo) < 0)
 return -errno;
+
+return 0;
 }
 
 /* Otherwise make PID 1 do it for us, for the entire cgroup */
-- 
1.9.2

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

Re: [systemd-devel] [PATCH] resolved: fix warnings

[Lennart Poettering]

On Sat, 19.07.14 10:37, Thomas H.P. Andersen (pho...@gmail.com) wrote:

> --- a/src/resolve/resolved-dns-scope.c
> +++ b/src/resolve/resolved-dns-scope.c
> @@ -292,7 +292,7 @@ int dns_scope_llmnr_membership(DnsScope *s, bool b) {
>  if (s->family == AF_INET) {
>  struct ip_mreqn mreqn = {
>  .imr_multiaddr = LLMNR_MULTICAST_IPV4_ADDRESS,
> -.imr_ifindex = s->link->ifindex,
> +.imr_ifindex = s->link ? s->link->ifindex : 0,

LLMNR scopes don't exist with a NULL link value, they are strictly bound
to physical links.

I have now added a couple of assert()s to the function, that should
clarify that and hopefully tell the compiler that these are necessarily
initialized.

Does this make things work for you? Please check.

Lennart

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

Re: [systemd-devel] race conditions after SIGTERM

[Lennart Poettering]

On Thu, 14.08.14 21:38, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> > Which is what we do. Except when you specify ExecStop= which basically
> > tells systemd that you want to do it instead. So there you go!
> 
> Those daemons I have seen are terminated after receiving signal/command
> to do it. Those sysvinit scripts that "synchronously" terminated
> services did it by implementing wait for daemon process to exit. What
> is worse, the only way to do it is busy looping as they cannot normally
> receive notification about process exit.

Well, if they don't have such a protocol, then they can use systemd's
default logic for this, and just tweak the parameters. KillMode=,
KillSignal=, TimeoutStopSec= are all ways how you can control how
exactly systemd should terminate your service.

> Compare this with "send daemon command - signal or whatever - and wait
> until it exits". This needs to be implemented just once in PID 1 - and
> PID 1 already does exactly this most of the time anyway. Why is this
> the wrong thing to do? You never explained this when you rejected my
> patch.

Hmm, this is what we do. By specifiying ExecStop= you turn that off
however can plug in your own logic. If you don't have any better logic,
then simply don't plug anything in, that's what we recommend anyway.

Again: systemd does what you want it to do by default, anyway. By
specifiying ExecStop= you however turn this off, and have to do it on
your own!

Lennart

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

Re: [systemd-devel] [PATCH v2] Refuse mount on symlink

[Lennart Poettering]

On Thu, 14.08.14 20:31, Timofey Titovets (nefelim...@gmail.com) wrote:

> 
> Okay, i will rebase and resend, and add warning
> But what i must do with message:
> "symlink.mount failed to run 'mount' task: Too many levels of symbolic links"?
> Just leave and add additional massage error or replace?

Yeah, I think it's OK to leave both messages in there.

> 
> 2014-08-14 20:05 GMT+03:00 Lennart Poettering :
> > On Mon, 21.07.14 19:24, Timofey Titovets (nefelim...@gmail.com) wrote:
> >
> > Doesn't apply to current git. Could you please rebase on current git?
> >
> >>
> >> +int fail_if_symlink(const char *unit, const char* where) {
> >> +assert(where);
> >> +
> >> +if (!is_symlink(where))
> >> +return 0;
> >
> > This should probably be "if (is_symlink(where) > 0)".
> >
> > Also I think we should print an explicit message here, that tells the
> > admin that mounting symlinks is not supported.
> >
> > Sorry for the long delay in responding.
> >
> > Lennart
> >
> 
> 
> 


Lennart

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

Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

[Lennart Poettering]

On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

Heya,

> I have read the thread (from 2012?) where those things were discussed
> here and I understand that I should replace my keyscript with a
> passwort agent. Things would then work like this:

There's currently no streamlined support for stacking password questions
really. You currently cannot "take possession" of specific password
questions.

Also note that we really should redesign the entire scheme around the
kernel keyring as only transport for the keys (and the bus for
signalling). I am a bit conservative in changing here too much for now,
because we really should figure out that bit first.

> (4)
> My PasswordAgent indicates taking responsibility by unlinking the
> ask.xxx file from /run/systemd/ask-password. The interactive password

Well, so far it is the querier that removes the file, not the agent...

> agents will remove their interactive requests then. The user will
> therefore see the password request popping up for a very short period
> of time, if at all.
> 
> (5)
> Should my PasswordAgent need a password to act itself (like a PIN for
> a hardware device, for example), it would place its own ask.xxx file
> in /run/systemd/ask-password. The interactive PasswordAgents would
> act on that, obtain the password/PIN interactively from the user and
> return it to my PasswordAgent.
> 
> (6)
> My PasswordAgent would then obtain the password for the file system
> itself and return it to systemd which can now proceed to unlock the
> file system.
> 
> Am I understanding things correctly so far?

Yes, this should indeed work.

> If so, this leaves the task to write "my" PasswordAgent. I have found
> some example code in python for a password agent.
> 
> To use this to unlock the root fs, an entire python installation would
> need to go in my initramfs, right? And if I want to keep things
> simple, the best idea would be to write my PasswordAgent in a compiled
> language which would only need the binary and its libs in the
> initramfs, right?

Yes. Correct. If you want to stick something into the initrd, I'd always
do things in C (or shell if you must), but nothing else.

> Is there code for an example PasswordAgent in C++ which I can use as a
> template? I am quite reluctant to write a program which needs to to
> complex string processing and is bound to run as root in C because my
> C experience is somewhat lacking.

Not aware of an C++ code. There's a vala one, and of course the one we
ship in systemd itself in C, but c++ i cannot help you with, sorry.

> Can you please recommend a way to allow me to migrate to systemd?
> Without keyscript= being supported in /etc/crypttab, I need to replace
> my 50 line key script written in POSIX shell and would like to keep
> things simple.
> 
> Thank you very much for your consideration.

I fear I don#t have an easy suggestion. What kind of device do you
actually want to make work here? some smartcard or so?

I think in the long run we should somehow work towards the direction to
make things like that just work, for common devices like smartcards and
other auth tokens...

Lennart

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

Re: [systemd-devel] [PATCH v2] Refuse mount on symlink

[Timofey Titovets]

Okay, i will rebase and resend, and add warning
But what i must do with message:
"symlink.mount failed to run 'mount' task: Too many levels of symbolic links"?
Just leave and add additional massage error or replace?

2014-08-14 20:31 GMT+03:00 Timofey Titovets :
> Okay, i will rebase and resend, and add warning
> But what i must do with message:
> "symlink.mount failed to run 'mount' task: Too many levels of symbolic links"?
> Just leave and add additional massage error or replace?
>
> 2014-08-14 20:05 GMT+03:00 Lennart Poettering :
>> On Mon, 21.07.14 19:24, Timofey Titovets (nefelim...@gmail.com) wrote:
>>
>> Doesn't apply to current git. Could you please rebase on current git?
>>
>>>
>>> +int fail_if_symlink(const char *unit, const char* where) {
>>> +assert(where);
>>> +
>>> +if (!is_symlink(where))
>>> +return 0;
>>
>> This should probably be "if (is_symlink(where) > 0)".
>>
>> Also I think we should print an explicit message here, that tells the
>> admin that mounting symlinks is not supported.
>>
>> Sorry for the long delay in responding.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>
>
>
> --
> Best regards,
> Timofey.



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

Re: [systemd-devel] race conditions after SIGTERM

[Andrei Borzenkov]

В Thu, 14 Aug 2014 19:24:54 +0200
Lennart Poettering  пишет:

> On Thu, 14.08.14 21:16, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
> > 
> > В Thu, 14 Aug 2014 14:24:49 +0200
> > Lennart Poettering  пишет:
> > 
> > > On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote:
> > > 
> > > > but that still don't explain why "ExecStopPost=/sur/bin/true" or
> > > > whatever "ExecStopPost" solves that and if it is not supported
> > > > why "systemctl" don't return after the one and only process
> > > > exited
> > > 
> > > Well, this is a misunderstanding how ExecStop= and friends are supposed
> > > to work. They are supposed to do what they did on sysvinit:
> > > synchronously terminate a service. And not asynchronously do that.
> > 
> > I have to ask again - why is forcing every package to re-implement busy
> > loop waiting for process to exit better than doing this wait in one
> > place - PID 1 - which is the most natural place to do it?
> 
> Which is what we do. Except when you specify ExecStop= which basically
> tells systemd that you want to do it instead. So there you go!
> 

Those daemons I have seen are terminated after receiving signal/command
to do it. Those sysvinit scripts that "synchronously" terminated
services did it by implementing wait for daemon process to exit. What
is worse, the only way to do it is busy looping as they cannot normally
receive notification about process exit.

So currently package author who needs to be sure daemon have enough
time to finish housekeeping have choice between

a) implement custom busy looping a la sysvinit script
b) implement custom synchronous protocol between daemon and external
program that somehow connects to daemon and blocks until daemon is
terminated

Compare this with "send daemon command - signal or whatever - and wait
until it exits". This needs to be implemented just once in PID 1 - and
PID 1 already does exactly this most of the time anyway. Why is this
the wrong thing to do? You never explained this when you rejected my
patch.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 3/3] socket: add bus property for bus property NoDelay

[Susant Sahani]

Missed to add the SD_BUS_PROPERTY for no_delay.
---
 src/core/dbus-socket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index cc55b8d..e9e2430 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -101,6 +101,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
 SD_BUS_PROPERTY("KeepAliveInterval", "t", bus_property_get_usec, 
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("KeepAliveProbes", "u", bus_property_get_unsigned, 
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("DeferAccept" , "t", bus_property_get_usec, 
offsetof(Socket, defer_accept), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("NoDelay", "b", bus_property_get_bool, 
offsetof(Socket, no_delay), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("Priority", "i", bus_property_get_int, 
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("ReceiveBuffer", "t", bus_property_get_size, 
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("SendBuffer", "t", bus_property_get_size, 
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
-- 
1.9.3

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

[systemd-devel] [PATCH 2/3] socket: Add support for TCP defer accept

[Susant Sahani]

TCP_DEFER_ACCEPT Allow a listener to be awakened only when data
arrives on the socket. If TCP_DEFER_ACCEPT set on a server-side
listening socket, the TCP/IP stack will not to wait for the final
ACK packet and not to initiate the process until the first packet
of real data has arrived. After sending the SYN/ACK, the server will
then wait for a data packet from a client. Now, only three packets
will be sent over the network, and the connection establishment delay
will be significantly reduced.
---
 man/systemd.socket.xml| 24 
 src/core/dbus-socket.c|  1 +
 src/core/load-fragment-gperf.gperf.m4 |  1 +
 src/core/socket.c | 12 
 src/core/socket.h |  1 +
 5 files changed, 39 insertions(+)

diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 5efb398..38f16e5 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -546,6 +546,30 @@
 
 
 
+DeferAccept=
+Takes time (in seconds) as 
argument. If set, the listening process
+will be awakened only when data arrives on the 
socket, and not immediately
+when connection is established. When this 
option is set, the
+TCP_DEFER_ACCEPT socket 
option will be used
+(see
+
tcp7),
+and the kernel will ignore initial ACK packets 
without any data.
+The argument specifies the approximate amount
+of time the kernel should wait for incoming 
data before falling
+back to the normal behaviour of honouring 
empty ACK packets.
+This option beneficial for protocols where the 
client sends the data
+first (e.g. HTTP, in contrast to SMTP), 
because the server
+process will not be woken up unnecessarily 
before it can take any action.
+
+If the client also uses the 
TCP_DEFER_ACCEPT
+option, the latency of the initial connection 
may be
+reduced, because the kernel will send data in 
the
+final packet establishing the connection (the 
third packet in the
+"three-way handshake").
+Disabled by default.
+
+
+
 ReceiveBuffer=
 SendBuffer=
 Takes an integer
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index bdf111c..cc55b8d 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -100,6 +100,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
 SD_BUS_PROPERTY("KeepAliveTime", "t", bus_property_get_usec, 
offsetof(Socket, keep_alive_time), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("KeepAliveInterval", "t", bus_property_get_usec, 
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("KeepAliveProbes", "u", bus_property_get_unsigned, 
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("DeferAccept" , "t", bus_property_get_usec, 
offsetof(Socket, defer_accept), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("Priority", "i", bus_property_get_int, 
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("ReceiveBuffer", "t", bus_property_get_size, 
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("SendBuffer", "t", bus_property_get_size, 
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index 67bd0e5..b4e2b25 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -234,6 +234,7 @@ Socket.KeepAlive,config_parse_bool, 
 0,
 Socket.KeepAliveTime,config_parse_sec,   0,
 offsetof(Socket, keep_alive_time)
 Socket.KeepAliveInterval,config_parse_sec,   0,
 offsetof(Socket, keep_alive_interval)
 Socket.KeepAliveProbes,  config_parse_unsigned,  0,
 offsetof(Socket, keep_alive_cnt)
+Socket.DeferAccept,  config_parse_sec,   0,
 offsetof(Socket, defer_accept)
 Socket.NoDelay,  config_parse_bool,  0,
   

[systemd-devel] [PATCH 1/3] socket: Add Support for TCP keep alive variables

[Susant Sahani]

The tcp keep alive variables now can be configured via conf
parameter. Follwing variables are now supported by this patch.

tcp_keepalive_intvl: The number of seconds between TCP keep-alive probes

tcp_keepalive_probes: The maximum number of TCP keep-alive probes to
send before giving up and killing the connection if no response is
obtained from the other end.

tcp_keepalive_time: The number of seconds a connection needs to be
idle before TCP begins sending out keep-alive probes.
---
 man/systemd.socket.xml| 36 +++
 src/core/dbus-socket.c|  3 +++
 src/core/load-fragment-gperf.gperf.m4 |  3 +++
 src/core/socket.c | 36 +++
 src/core/socket.h |  3 +++
 5 files changed, 81 insertions(+)

diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 352825f..5efb398 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -488,6 +488,42 @@
 
 
 
+KeepAliveTime=
+Takes time (in seconds) as 
argument . The connection needs to remain
+idle before TCP starts sending keepalive 
probes. This controls the TCP_KEEPIDLE
+socket option (see
+
socket7
+and the http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/";>TCP
+Keepalive HOWTO for details.)
+Defaults value is 7200 seconds (2 
hours).
+
+
+
+
KeepAliveInterval=
+Takes time (in seconds) as 
argument between individual keepalive probes,
+if the socket option SO_KEEPALIVE has  been 
set on this socket seconds as argument.
+This controls the TCP_KEEPINTVL socket option 
(see
+
socket7
+and the http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/";>TCP
+Keepalive HOWTO for details.)
+Defaults value is 75 seconds.
+
+
+
+
KeepAliveProbes=
+Takes interger as argument. 
It's the number of unacknowledged probes to
+send before considering the connection dead 
and notifying the application layer.
+This controls the TCP_KEEPCNT socket option 
(see
+
socket7
+and the http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/";>TCP
+Keepalive HOWTO for details.)
+Defaults value is 9.
+
+
+
 NoDelay=
 Takes a boolean
 argument. TCP Nagle's algorithm works by 
combining a number of
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index ad135a1..bdf111c 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -97,6 +97,9 @@ const sd_bus_vtable bus_socket_vtable[] = {
 SD_BUS_PROPERTY("DirectoryMode", "u", bus_property_get_mode, 
offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("Accept", "b", bus_property_get_bool, offsetof(Socket, 
accept), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("KeepAlive", "b", bus_property_get_bool, 
offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("KeepAliveTime", "t", bus_property_get_usec, 
offsetof(Socket, keep_alive_time), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("KeepAliveInterval", "t", bus_property_get_usec, 
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("KeepAliveProbes", "u", bus_property_get_unsigned, 
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("Priority", "i", bus_property_get_int, 
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("ReceiveBuffer", "t", bus_property_get_size, 
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY("SendBuffer", "t", bus_property_get_size, 
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index f4acdda..67bd0e5 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -231,6 +231,9 @@ Socket.DirectoryMode,config_parse_mode, 
 0,
 Socket.Accept,   

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Lennart Poettering]

On Mon, 21.07.14 15:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> 
> On Mon, Jul 21, 2014 at 09:38:57AM +0300, Timofey Titovets wrote:
> > Just completed TODO:
> > * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
> 
> This is still not an explanation. What is the difference between the
> two?

The idea really was to just defrag the bits of files that we really
needed instead of all of them...

Lennart

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

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Lennart Poettering]

On Tue, 22.07.14 06:29, Andrey Borzenkov (arvidj...@gmail.com) wrote:

> В Mon, 21 Jul 2014 18:15:37 +0300
> Timofey Titovets  пишет:
> 
> > Zbyszek, i research problem and i found what in btrfs.h
> > struct btrfs_ioctl_defrag_range_args  not defined
> > This acceptable if i add it in missing.h like:
> > /* btrfs_ioctl_defrag_range_args now 21.07.2014
> >  * not defined in btrfs.h and duplicated from /fs/btrfs/ctree.h
> >  */
> > #ifdef HAVE_LINUX_BTRFS_H
> > struct btrfs_ioctl_defrag_range_args {
> > uint64_t start; /* start byte = 0 */
> > uint64_t len;   /* whole file uint64_t-1 */
> > uint64_t flags; /* start_io 2 */
> > uint32_t extent_thresh; /* 0 */
> > uint32_t compress_type;
> > uint32_t unused[4];
> > };
> > #endif
> > 
> 
> I think it should really be discussed on btrfs list. It must be
> properly exported to user space if user space is going to use it.

Well, the ioctls of btrfs seldom come with proper userpace headers
unfortunately...

Lennart

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Marco d'Itri]

On Aug 14, Lennart Poettering  wrote:

> Hmm, Debian still generates persistent rules at boot? Yuck!
Experience shows that it worked better than the alternatives for our 
users, so I think that we will just keep it around for a while, probably
until most hardware will provide persistent names via BIOS tables.

-- 
ciao,
Marco


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

Re: [systemd-devel] race conditions after SIGTERM

[Lennart Poettering]

On Thu, 14.08.14 21:16, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 
> В Thu, 14 Aug 2014 14:24:49 +0200
> Lennart Poettering  пишет:
> 
> > On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote:
> > 
> > > but that still don't explain why "ExecStopPost=/sur/bin/true" or
> > > whatever "ExecStopPost" solves that and if it is not supported
> > > why "systemctl" don't return after the one and only process
> > > exited
> > 
> > Well, this is a misunderstanding how ExecStop= and friends are supposed
> > to work. They are supposed to do what they did on sysvinit:
> > synchronously terminate a service. And not asynchronously do that.
> 
> I have to ask again - why is forcing every package to re-implement busy
> loop waiting for process to exit better than doing this wait in one
> place - PID 1 - which is the most natural place to do it?

Which is what we do. Except when you specify ExecStop= which basically
tells systemd that you want to do it instead. So there you go!

Lennart

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

Re: [systemd-devel] eye of cylon / timeout timer is cut off

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 14, 2014 at 06:44:03PM +0200, Michael Biebl wrote:
> 2014-08-14 18:36 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> > It would be more useful to remove the "/ 1min 30s" part. Maybe the cylon
> > code could be smart enough for that.
> 
> I think it's useful information to know that the timeout is 90s.
> An alternative could be, to simply use seconds and not convert that
> into h:m:s values.
> A "77s / 90s" display would be ok to me.

What I meant is to skip the limit only where there is a shortage of space.
But thinking about it again, it is hard to say which is more important. So
maybe it is better to instead display the time remaining, like -33s, -32s, 
-31s...
when columns() <= 80.

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

Re: [systemd-devel] race conditions after SIGTERM

[Andrei Borzenkov]

В Thu, 14 Aug 2014 14:24:49 +0200
Lennart Poettering  пишет:

> On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
> > but that still don't explain why "ExecStopPost=/sur/bin/true" or
> > whatever "ExecStopPost" solves that and if it is not supported
> > why "systemctl" don't return after the one and only process
> > exited
> 
> Well, this is a misunderstanding how ExecStop= and friends are supposed
> to work. They are supposed to do what they did on sysvinit:
> synchronously terminate a service. And not asynchronously do that.

I have to ask again - why is forcing every package to re-implement busy
loop waiting for process to exit better than doing this wait in one
place - PID 1 - which is the most natural place to do it?

>We
> hence don't wait for anything else then, because what is left afterwards
> must be left-over processes that ExecStop= and friends couldn't clean up
> properly...
> 
> Lennart
> 

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

[systemd-devel] [HEADS-UP] Intent to remove readahead from systemd

[Lennart Poettering]

Heya,

Since its early days systemd contained the systemd-readahead tool, whose
job was to improve boot times by reading files in their order on disk,
before they would actually be needed by applications. In times of SSD
the benefit of systemd-readahead is much less convincing, in many case
it actually slows things down.

The fact is now that nobody really cares about systemd-readahead much
anymore. Nobody in the systemd team still works on a laptop with
rotating media, hence nobody tries to optimize it in any way. And it
probably needs a lot of looking after and love to still be useful as
general purpose systems, instead of just slowing them down...

So, I think with the release after the upcoming one we should just
remove it from the systemd package and just throw it on the pile of
historic cruft. So, yeah, here's the advance warning that this will be
happening...

(Well, unless somebody from the community who cares and wants to invest
the necessary time in it steps up and gives it the love it really
needs. If nobody does until that release, I will delete the component
from systemd).

I fully understand that not everybody uses SSDs yet, and also that
theoretically doign systemd-readahead on SSD could be beneficial still
(since RAM is still orders of magnitude faster than SSDs), but it's
really not about that, it's about maintainership and giving the tool the
love it needs.

Lennart

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

Re: [systemd-devel] [PATCH v3] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Lennart Poettering]

On Mon, 21.07.14 20:23, Timofey Titovets (nefelim...@gmail.com) wrote:

> Just completed TODO:
> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
> ioctl, with START_IO

Hmm, the patch is line broken...

But this patch only replaces one ioctl with another right? It doesn't
actually improve anything effectively, does it?

I am not really convinced that we should make this change, maybe we
should remove readahead from the the package instead...

> 
> commit d3fc81bd6a5a046b22600ac1204df220c93d2c15 refs/tags/v30
> Author: Lennart Poettering 
> Date:   Wed Jun 15 15:39:10 2011 +0200
> 
> update TODO
> 
> i no add this todo in TODO list (recursively todo %), and as this my
> opinion may be not relevant with author.
> 
> As i understand start_io option force write data after defragment,
> without buffering it in memory.
> 
> 
> v1 -> v2
> Fixed spelling in TODO
> 
> v2 -> v3
> Deleted todo from code
> Fix compilation issues
> Delete fallback code, because BTRFS_IOC_DEFRAG_RANGE supported as
> 2.6.29 oldest longterm 2.6.32.63
> 

Lennart

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

Re: [systemd-devel] [PATCH v2] Refuse mount on symlink

[Lennart Poettering]

On Mon, 21.07.14 19:24, Timofey Titovets (nefelim...@gmail.com) wrote:

Doesn't apply to current git. Could you please rebase on current git?

> 
> +int fail_if_symlink(const char *unit, const char* where) {
> +assert(where);
> +
> +if (!is_symlink(where))
> +return 0;

This should probably be "if (is_symlink(where) > 0)".

Also I think we should print an explicit message here, that tells the
admin that mounting symlinks is not supported.

Sorry for the long delay in responding.

Lennart

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

Re: [systemd-devel] [PATCH 2/2] units: add RequiresMountsFor=/usr/… to various systemd service files

[Lennart Poettering]

On Tue, 22.07.14 14:45, Jon Severinsson (j...@severinsson.net) wrote:

> 
> At Tuesday 22 July 2014 13:01:24 Lennart Poettering wrote:
> > I am totally not convinced this would be a good idea. You cannot fix
> > this anyway... Think about udevd: if you start it without /usr is
> > around, then it won't find the rules files below /usr. So by your logic
> > you'd add a RequiresMountsFor=/usr to udev's service file. But that
> > would totally break things, as the backing device for /usr will not
> > become available without udev.
> 
> The difference being that systemd units and udev rules goes to $(rootlibdir) 
> by 
> default, but these goes to $(libdir) by default.
> 
> Also, systemd units and udev rules might be required to mount local file 
> systems, these are not.
> 
> > systemd currently doesn't totally fail if /usr is found to be empty when
> > it initializes, but it will set a "taint" flag, since that really is an
> > unsupported setup.
> 
> I'm well aware that a separate /usr not mounted in the initrd is an 
> unsupported setup, but a separate /usr/local *is* supposed to work, and 
> making 
> a separate /usr slightly less broken when it comes at virtually no extra cost 
> (on top of getting a separate /usr/local working) is imho a good thing.

I am tempted to say that stuff that runs in early-boot (i.e. before
basic.target) cannot be split off into external partitions. And the ones
you list in your patch are all things that run in early boot...

(Also tmpfiles is ordered after local-fs.target anyway, so it is
actually ordered after /usr/local anyway, indirectly)

(And /usr/share/zoneinfo is something that is never Ok to split off. We
are not playing games of trying to come up with more exciting schemes
how people split up /usr. Really, /usr should be one thing, and maybe
/usr/local split off, but then it shouldn't expect to install anything
into early boot really...)  

Lennart

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

Re: [systemd-devel] [PATCH 1/2] core: do not add default dependencies to /usr mount unit

[Lennart Poettering]

On Tue, 22.07.14 00:39, Jon Severinsson (j...@severinsson.net) wrote:

> This makes no difference if /usr was mounted in the initrd,
> and brings the behaviour of legacy systems closer to those
> with a propper initrd.

I applied this one now, as /usr is probably indeed mostly like /, and we
shouldn't handle it at all with default dependencies.

Lennart

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

Re: [systemd-devel] Networkd dhcp hostname override

[Dan Williams]

On Wed, 2014-08-13 at 18:55 -0700, Marcel Holtmann wrote:
> Hi Lennart,
> 
> >> Now that networkd can send the systems hostname to the dhcp server, I 
> >> would find it useful to have an option to override the hostname that gets 
> >> sent.
> >> 
> >> In my use case, I would like to setup a number of macvlans with different 
> >> hostnames.
> >> 
> >> Something as simple as
> >> 
> >> [DHCP]
> >> SendHostname=true
> >> Hostname=foo
> > 
> > Sounds useful, though this could just be a single option
> > SendHostname=foobar or so. If not set it sends the system hostname,
> > otherwise the specified hostname. Or something like that.
> 
> what would this be useful for? Either you send the hostname or you don't.
> 
> I think what you are looking for is an option to set the Client ID. And when 
> that is set, then that is used. If it not set and SendHostname=true, the 
> hostname is used as Client ID. If SendHostname=false and Client ID is not 
> send, then none of them are send.

Typically the send-hostname thing is actually used for DNS updates,
where you send the hostname to the DHCP server, which then gives you a
lease and sends the hostname + IP to the DNS server, so that your
machine is accessible via DNS automatically.  I've never heard of it
being used as a Client ID, and AFAIK the "send hostname" and client ID
can both be used at the same time.

Dan

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Michael Biebl]

2014-08-14 17:04 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> On Thu, Aug 14, 2014 at 02:31:00PM +0100, Simon McVittie wrote:
>> On 14/08/14 13:27, Vlad Orlov wrote:
>> > ### BEGIN INIT INFO
>> > # Provides:  mintsystem
>> > # Required-Start:$local_fs $syslog $remote_fs dbus
>> > # Required-Stop: $local_fs $syslog $remote_fs
>> > # Default-Start: S
>> > # Default-Stop:
>> > ### END INIT INFO
>>
>> As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream
>> systemd does not support sysvinit services during early boot, i.e. rcS.
>>
>> In Debian, support for sysvinit scripts in rcS was patched back in to
>> avoid breaking existing software, because it's unlikely that all of the
>> packages listed in
>>  will get a
>> native systemd unit any time soon. Most of them probably doesn't
>> actually need to run in rcS - nvi? seriously? - but if fixing them all
>> was on the critical path for adopting systemd, we'd probably still be
>> using sysvinit for years to come.
> Actually, most of them probably don't need to run at all:

Yeah, this is correct. Those init scripts are only necessary if you
actually still use sysvinit as PID 1.

See 
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.links




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

Re: [systemd-devel] eye of cylon / timeout timer is cut off

[Michael Biebl]

2014-08-14 18:36 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> It would be more useful to remove the "/ 1min 30s" part. Maybe the cylon
> code could be smart enough for that.

I think it's useful information to know that the timeout is 90s.
An alternative could be, to simply use seconds and not convert that
into h:m:s values.
A "77s / 90s" display would be ok to me.


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

Re: [systemd-devel] eye of cylon / timeout timer is cut off

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 14, 2014 at 06:13:47PM +0200, Michael Biebl wrote:
> 2014-08-14 17:17 GMT+02:00 Lennart Poettering :
> > On Sun, 27.07.14 21:47, Michael Biebl (mbi...@gmail.com) wrote:
> >
> >> Hi,
> >>
> >> as you can see at the attached diff, there is a small issue with the
> >> timer that is disabled, when systemd is waiting for a job.
> >>
> >> In this case, the job is already running 1min 17secs, but only 17 secs
> >> is displayed, the other part is cut off.
> >
> > Hmm, well, we currently ellipsize at 75% of the line width. I have now
> > moved that to 50%, so that there's a chance that the time is still shown
> > on tiny displays.
> 
> Well, that's the standard resolution on non-KMS enabled systems, like
> in a virtualized environment (the screenshot was made using vbox).
> So it's pretty common, I'd say.
> 
>  But it's a stupid game. We will have to cut out
> > something...
> >
> > Anyway, let's see if people complain about this new setting too...
> 
> With 50% being the cut-off, you'll only be able to see "A stop job is
> running..." afaics without showing the actual unit which is being
> waited for.
> That doesn't sound great either.
It would be more useful to remove the "/ 1min 30s" part. Maybe the cylon
code could be smart enough for that.

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

Re: [systemd-devel] [PATCH 3/3] socket: Add support for TCP defer accept

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 29, 2014 at 11:10:09PM +0530, Susant Sahani wrote:
> TCP_DEFER_ACCEPT Allow a listener to be awakened only when data
> arrives on the socket. If TCP_DEFER_ACCEPT set on a server-side
> listening socket, the TCP/IP stack will not to wait for the final
> ACK packet and not to initiate the process until the first packet
> of real data has arrived. After sending the SYN/ACK, the server will
> then wait for a data packet from a client. Now, only three packets
> will be sent over the network, and the connection establishment delay
> will be significantly reduced.
> ---
>  man/systemd.socket.xml | 16 
>  src/core/dbus-socket.c |  1 +
>  src/core/socket.c  | 11 +++
>  src/core/socket.h  |  1 +
>  4 files changed, 29 insertions(+)
> 
> diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
> index e6bbb2e..9ce94aa 100644
> --- a/man/systemd.socket.xml
> +++ b/man/systemd.socket.xml
> @@ -539,6 +539,22 @@
>  
>  
>  
> +DeferAccept=
> +Takes time (in seconds) as 
> argument
> +Allow a listener to be awakened only when 
> data arrives on the socket.
> +If TCP_DEFER_ACCEPT set on a server-side 
> listening socket,
> +the TCP/IP stack will not to wait for the 
> final ACK packet and not to
> +initiate the process until the first packet 
> of real data has arrived.
> +After sending the SYN/ACK, the server will 
> then wait for a data packet
> +from a client. Now, only three packets will 
> be sent over the network,
> +and the connection establishment delay will 
> be significantly reduced.
> +This controls the TCP_DEFER_ACCEPT socket 
> option (see
> +
> socket7
> +Defaults to
> +disabled.
I think this needs to be cleaned up to be gramatically correct. Right now
some guesswork is required to gather the true meaning.

Maybe something like this:

---

Takes time (in seconds) as argument. If set, the listening process
will be awakened only when data arrives on the socket, and not immediately
when connection is established. When this option is set, the
TCP_DEFER_ACCEPT socket option will be used
(see
tcp7),
and the kernel will ignore initial ACK packets without any data.
The argument specifies the approximate amount
of time the kernel should wait for incoming data before falling
back to the normal behaviour of honouring empty ACK packets.
This option beneficial for protocols where the client sends the data
first (e.g. HTTP, in contrast to SMTP), because the server
process will not be woken up unnecessarily before it can take any action.


If the client also uses the TCP_DEFER_ACCEPT
option, the latency of the initial connection may be
reduced, because the kernel will send data in the
final packet establishing the connection (the third packet in the
"three-way handshake").

Disabled by default.

---

(Note that TCP_DEFER_ACCEPT is described in tcp(7), not socket(7), and this
description is so terse that it is nearly useless anyway.)

Zbyszek

> +
> +
> +
>  Priority=
>  Takes an integer
>  argument controlling the priority for
> diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
> index f9ef7ef..1142ca5 100644
> --- a/src/core/dbus-socket.c
> +++ b/src/core/dbus-socket.c
> @@ -101,6 +101,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
>  SD_BUS_PROPERTY("KeepAliveInterval", "t", bus_property_get_usec, 
> offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("KeepAliveProbes", "i", bus_property_get_int, 
> offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("FastOpen" , "b", bus_property_get_bool, 
> offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
> +SD_BUS_PROPERTY("DeferAccept" , "t", bus_property_get_usec, 
> offsetof(Socket, defer_accept), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("Priority", "i", bus_property_get_int, 
> offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("ReceiveBuffer", "t", bus_property_get_size, 
> offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("SendBuffer", "t", bus_property_get_size, 
> offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
> diff --git a/src/core/socket.c b/src/core/socket.c
> index b798d4e..32cadf9 100644
> --- a/src/core/socket.c
> +++ b/src/core/socket.c
> @@ -610,6 +610,11 @@ static void socket_dump(Unit *u, FIL

Re: [systemd-devel] How to get rid of this ordering cycle?

[Michael Biebl]

2014-08-14 17:57 GMT+02:00 Lennart Poettering :
> Hmm, Debian still generates persistent rules at boot? Yuck!

Correct. We still use the old persistent network naming scheme and
have not transitioned to the new scheme [1] yet.
We might in the future or not. This needs further investigation and a
proper transition plan.
At least for jessie we don't want to deal with yet another transition
which has the potential to break a lot of existing installations.

Cheers,
Michael

[1] 
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
-- 
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

Re: [systemd-devel] eye of cylon / timeout timer is cut off

[Michael Biebl]

2014-08-14 17:17 GMT+02:00 Lennart Poettering :
> On Sun, 27.07.14 21:47, Michael Biebl (mbi...@gmail.com) wrote:
>
>> Hi,
>>
>> as you can see at the attached diff, there is a small issue with the
>> timer that is disabled, when systemd is waiting for a job.
>>
>> In this case, the job is already running 1min 17secs, but only 17 secs
>> is displayed, the other part is cut off.
>
> Hmm, well, we currently ellipsize at 75% of the line width. I have now
> moved that to 50%, so that there's a chance that the time is still shown
> on tiny displays.

Well, that's the standard resolution on non-KMS enabled systems, like
in a virtualized environment (the screenshot was made using vbox).
So it's pretty common, I'd say.

 But it's a stupid game. We will have to cut out
> something...
>
> Anyway, let's see if people complain about this new setting too...

With 50% being the cut-off, you'll only be able to see "A stop job is
running..." afaics without showing the actual unit which is being
waited for.
That doesn't sound great either.




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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Lennart Poettering]

On Thu, 14.08.14 16:41, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

> On 14/08/14 16:29, Lennart Poettering wrote:
> > On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > wrote:
> > 
> >> systemd: "Copy rules generated while the root was ro"
> > 
> > Hmm, wut? What's that supposed to be?
> 
> I think it's glue for running udev when pid 1 != systemd and there was
> no initramfs. (All the rcS scripts in systemd are either masked or
> hidden by a corresponding whatever.service on systemd systems anyway, so
> that particular script is not relevant here.)

Hmm, Debian still generates persistent rules at boot? Yuck!

Lennart

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

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Thu, 24.07.14 13:32, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> I guess my main concern still remains that uid range settings for system
> users would now be in two places - one used by sysusers and another by
> adduser (I now accept your argument that the other two places are
> different configuration data even if it's conceptually similar). I want
> to be able to tell a user that the configuration is in one place not
> explain that package "system users ranges" are in one place and
> adduser's "system user range" is in another.

Well, here's the thing: I reall don't think the boundary should be a user
configuration thing. It should be a vendor configuration thing. And thus
you shouldn't tell your users about how to configure it at all.

I think communicating how to select the users that get split up journals
makes a lot of sense, but not how to shift the boundary in general. And
that's kinda the key of the issue here... 

I am still convinced that adding a range command to sysusers and a
SplitUserRange= setting to journald is the right way to go...

Lennart

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Simon McVittie]

On 14/08/14 16:29, Lennart Poettering wrote:
> On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
>> systemd: "Copy rules generated while the root was ro"
> 
> Hmm, wut? What's that supposed to be?

I think it's glue for running udev when pid 1 != systemd and there was
no initramfs. (All the rcS scripts in systemd are either masked or
hidden by a corresponding whatever.service on systemd systems anyway, so
that particular script is not relevant here.)

S

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

Re: [systemd-devel] Changing configurations with networkd

[Lennart Poettering]

On Fri, 25.07.14 09:48, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

> What I'm _not_ seeing, and what usually comes when anything else changes in
> the network configuration is:
> systemd-timesyncd[348]: Network configuration changed, trying to establish 
> connection.
> 
> I would expect, that systemd-timesyncd should be notified in this case as
> well, right?

This should be fixed with current git. Could you please recheck?

Lennart

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

Re: [systemd-devel] Changing configurations with networkd

[Lennart Poettering]

On Thu, 24.07.14 10:49, Tom Gundersen (t...@jklm.no) wrote:

> > I think there was some misunderstanding here. I don't want to keep the
> > lease across reboots. I don't care about that. I think networkd should
> > remember the lease when restarting networkd only and not send a new dhcp
> > discover.
> 
> Right, I spoke too quickly. What I don't want is to preserve state
> between reboots, preserving it between restarts of networkd would
> indeed be fine. We already serialize the dhcp leases to /run, so I'd
> be happy to take a patch to deserialize these again when networkd
> starts.

Yeah, this would be great. This is what we are doing for machined and
logind too now, where we store everything in /run all the time, and can
then stop and start at any time without losing any information. I think
we should follow this scheme wherever we can. This would be particularly
useful when transitioning from the initrd to the main system, since the
initrd's networkd could simply be terminated and be replaced by the
host's version and still find everything.

Lennart

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Lennart Poettering]

On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> systemd: "Copy rules generated while the root was ro"

Hmm, wut? What's that supposed to be?

Lennart

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

Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units

[Lennart Poettering]

On Thu, 14.08.14 17:10, Harald Hoyer (harald.ho...@gmail.com) wrote:

> 
> On 14.08.2014 13:00, Lennart Poettering wrote:
> > On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> > 
> >> The only thing: PROGRAM="...", ENV{SYSTEMD_WANTS}+="...%c..." idiom seems a
> >> pretty ugly way to invoke systemd-escape. This looks like a pretty common
> >> thing to do; shouldn't there be a shorthand or something? (just a 
> >> suggestion)
> > 
> > Yeah, I agree, but I not entirely sure how this could look like in a
> > nice way?
> > 
> > Maybe add:
> > 
> > ENV{SYSTEMD_WANTS_INSTANCE}="bar"
> > ENV{SYSTEMD_WANTS_TEMPLATE}="foo@.service"
> > 
> > or so, would escape "bar" and add it into foo@.service... But that's not
> > particularly generic but focusses only on the instance/template case...
> > 
> > Ideas?
> > 
> > Lennart
> > 
> 
> Why not extend udev with new % specifiers for the systemd escaped name?

What syntax would you propose? Note that there are probably a couple of
different strings people might want to have escaped?

Lennart

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Simon McVittie]

On 14/08/14 16:04, Zbigniew Jędrzejewski-Szmek wrote:
> Actually, most of them probably don't need to run at all:

Many of the ones you quoted indeed don't make sense with systemd and are
either explicitly masked by a symlink to /dev/null, or have a
corresponding native systemd service that overrides them - notably,
everything in systemd, sysvinit, util-linux and procps - but you might
have missed the "next page" link at the bottom? There are about 4 pages
of results at the moment.

That search is among source packages, not binaries, so it'll match
anything that ships a rcS script, whether we would actually execute that
script under systemd or not. (The ones in the systemd source package are
for udev on a non-systemd init system, FWIW.)

At some point a mass-bug-filing on packages that ship an rcS script
without a corresponding systemd service would make sense, yes. Hopefully
many of them could be dealt with by masking the sysvinit script and
shipping a tmpfiles.d fragment.

S

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

Re: [systemd-devel] Reason for IgnoreSIGPIPE=true by default

[Lennart Poettering]

On Fri, 25.07.14 20:22, Ansgar Burchardt (ans...@debian.org) wrote:

Heya!

I think I replied to this since on IRC, but just for the sake of
completeness of the ML archives:

> I'm wondering what the reason for IgnoreSIGPIPE to default to true is.
> The documentation just states that

SIGPIPE is primarily something to ripple up shell pipelines right to
left, if something dies. EOF is usually used from left-to-right. That's
not really useful for normal daemons though, and as we try to provide a
good, useful execution environment for daemons, we turn this off. Of
course, shells should and suchlike should turn this on again.

> Defaults to true because SIGPIPE generally is useful only in shell
> pipelines.
> 
> But I don't think that this alone is a good reason to change the default.
> 
> It can confuse programs which use pipes and do not expect their signal
> handlers to be messed with, see [1] for the same issue in Python. As
> another example, "tar xf *.tar.gz" will fail on some archives if SIGPIPE
> is ignored[2].
> 
> Another problem is that this not only affects the program started by
> systemd itself, but leaks into all child processes as well. See [3] for
> a bug report against cron due to this (yes, can be worked around by
> setting IgnoreSIGPIPE=false for cron.service, but I believe systemd is
> wrong here).
> 
> Ansgar
> 
>   [1] 

I think the Python guys did the right thing here, and reset the SIG_IGN
again before execing something else...

Also, to my knowledge bash is actually smart enough to reset this on its
own when it is invoked. Which sounds like the right thing to do. Maybe
this bug is specific to Debian's bash replacement, and should be fixed there.

In addition, note that for gettys/user shells and stuff we actually
explicitly set IgnoreSIGPIPE=no currently. Same for all sysv init
scripts, to provide compatible behaviour.

Lennart

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

Re: [systemd-devel] eye of cylon / timeout timer is cut off

[Lennart Poettering]

On Sun, 27.07.14 21:47, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
> 
> as you can see at the attached diff, there is a small issue with the
> timer that is disabled, when systemd is waiting for a job.
> 
> In this case, the job is already running 1min 17secs, but only 17 secs
> is displayed, the other part is cut off.

Hmm, well, we currently ellipsize at 75% of the line width. I have now
moved that to 50%, so that there's a chance that the time is still shown
on tiny displays. But it's a stupid game. We will have to cut out
something...

Anyway, let's see if people complain about this new setting too... 

Lennart

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 14, 2014 at 02:31:00PM +0100, Simon McVittie wrote:
> On 14/08/14 13:27, Vlad Orlov wrote:
> > ### BEGIN INIT INFO
> > # Provides:  mintsystem
> > # Required-Start:$local_fs $syslog $remote_fs dbus
> > # Required-Stop: $local_fs $syslog $remote_fs
> > # Default-Start: S
> > # Default-Stop:  
> > ### END INIT INFO
> 
> As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream
> systemd does not support sysvinit services during early boot, i.e. rcS.
> 
> In Debian, support for sysvinit scripts in rcS was patched back in to
> avoid breaking existing software, because it's unlikely that all of the
> packages listed in
>  will get a
> native systemd unit any time soon. Most of them probably doesn't
> actually need to run in rcS - nvi? seriously? - but if fixing them all
> was on the critical path for adopting systemd, we'd probably still be
> using sysvinit for years to come.
Actually, most of them probably don't need to run at all:

util-linux: hwclock.sh   - not necessary with systemd
systemd: "Copy rules generated while the root was ro"
 - argh, installing a sysv script as part 
of systemd?
udev: "Start udevd, populate /dev and load drivers"
 - ?? 
procps: "Configure kernel parameters at boottime"
 - not necessary with systemd, probably
   downright harmful
sysvinit:- n/a
kmod: "Load the modules listed in /etc/modules"
 - not necessary with systemd
console-setup:   - not necessary with systemd, probably
   will cause a mess by duplicating 
functionality
xorg:- I doubt that this has to run in early 
boot
insserv: - n/a, seems to be some tests
fuse:- Not sure what this does, but it proably
   should be started on demand only

and then there's

lvm2:
ifupdown:

So there's two scripts to convert, and a bunch to disable. Those that
should be disabled are either already disabled with systemd, or will have
to be for correctness anyway. And that leaves two scripts to take care of.
At least for lvm2, converting it to properly support systemd seems to be
a prerequisite for proper shutdown, and is something that it worth doing
anyway.

For some of those scripts, support in systemd might be inadequate. But
fixing/enhancing systemd is imho a much better approach than adding
workarounds in obsolete init scripts.

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

Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units

[Harald Hoyer]

On 14.08.2014 13:00, Lennart Poettering wrote:
> On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> 
>> The only thing: PROGRAM="...", ENV{SYSTEMD_WANTS}+="...%c..." idiom seems a
>> pretty ugly way to invoke systemd-escape. This looks like a pretty common
>> thing to do; shouldn't there be a shorthand or something? (just a suggestion)
> 
> Yeah, I agree, but I not entirely sure how this could look like in a
> nice way?
> 
> Maybe add:
> 
> ENV{SYSTEMD_WANTS_INSTANCE}="bar"
> ENV{SYSTEMD_WANTS_TEMPLATE}="foo@.service"
> 
> or so, would escape "bar" and add it into foo@.service... But that's not
> particularly generic but focusses only on the instance/template case...
> 
> Ideas?
> 
> Lennart
> 

Why not extend udev with new % specifiers for the systemd escaped name?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd Promiscuous mode

[Tom Gundersen]

On Thu, Aug 14, 2014 at 3:53 AM, Marcel Holtmann  wrote:
> Hi Lennart,
>
>>> There seems to be no way in systemd-networkd to put a link in
>>> Promiscuous mode. This is needed to make macvlan work correctly
>>> (Otherwise it receives no traffic with its mac address as the
>>> destination). If I am not mistaken this could be a boolean in *.link
>>> files.
>>
>> Sounds useful. Added to the todo list.
>
> actually this sounds like a design mistake. If macvlan requires the network 
> interface in promiscuous mode, then it should do that internally.
>
> Inside the kernel the promiscuous mode is actually reference counted. This 
> can for example be utilized from packet(7) sockets. That way you do not 
> accidentally leave a device in promiscuous mode if all users are gone.
>
> So why not fix macvlan to put the parent into promiscuous mode.


Yeah, this sounds like a kernel bug. If there is some independent
reason to unconditionally enable promiscuous mode, we could consider
it. Otherwise, I'd let it be.

Cheers,

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

Re: [systemd-devel] networkd Promiscuous mode

[Lennart Poettering]

On Wed, 13.08.14 18:53, Marcel Holtmann (mar...@holtmann.org) wrote:

> 
> Hi Lennart,
> 
> >> There seems to be no way in systemd-networkd to put a link in
> >> Promiscuous mode. This is needed to make macvlan work correctly
> >> (Otherwise it receives no traffic with its mac address as the
> >> destination). If I am not mistaken this could be a boolean in *.link
> >> files.
> > 
> > Sounds useful. Added to the todo list.
> 
> actually this sounds like a design mistake. If macvlan requires the network 
> interface in promiscuous mode, then it should do that internally.
> 
> Inside the kernel the promiscuous mode is actually reference counted. This 
> can for example be utilized from packet(7) sockets. That way you do not 
> accidentally leave a device in promiscuous mode if all users are gone.
> 
> So why not fix macvlan to put the parent into promiscuous mode.

Makes sense.

Removed the thing from the TODO list again...

Lennart

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

Re: [systemd-devel] [PATCH] socket: add support for TCP fast Open

[Lennart Poettering]

On Thu, 14.08.14 09:54, Dave Reisner (d...@falconindy.com) wrote:

> 
> On Thu, Aug 14, 2014 at 02:31:47PM +0530, Susant Sahani wrote:
> > TCP Fast Open (TFO) speeds up the opening of successiveTCP)
> > connections between two endpoints.It works by using a TFO cookie
> > in the initial SYN packet to authenticate a previously connected
> > client. It starts sending data to the client before the receipt
> > of the final ACK packet of the three way handshake is received,
> > skipping a round trip and lowering the latency in the start of
> > transmission of data.
> > ---
> 
> Why does this default to false? The kernel enables this by default as of
> 3.13 and exposes /proc/sys/net/ipv4/tcp_fastopen. Are there really
> cases where one might want this conditionally enabled/disabled?

Oh, indeed. Also the setsockopt actually doesn't take a bool but a qlen
integer, according to the LWN story.

The sysctl is actually a bit field, and by default turns on the server
side of TCP fastopen, but not the client side. However, we only do the
server side in systemd anyway, so it's always on anyway...

I reverted this for now hence, this needs more discussion. 

Lennart

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

Re: [systemd-devel] [PATCH] Removed PPC 32 bit LE architecture

[Samuli Suominen]

On 11/08/14 17:14, Lennart Poettering wrote:
> On Mon, 11.08.14 15:57, Lennart Poettering (lenn...@poettering.net) wrote:
>
>> On Fri, 08.08.14 17:00, har...@redhat.com (har...@redhat.com) wrote:
>>
>>> From: Harald Hoyer 
>>>
>>> According to Brent Baude , who provided the patch,
>>> IBM doesn't want to support the PPC 32 bit LE architecture at all.
>> What is "support" supposed to mean? Does that mean that the silicon for
>> PPC32LE has and will never exist? Or does this mean that they are simply
>> not interested in supporting Linux on ppc32le like this with support
>> employees and stuff?
>>
>> I think if the silicon exists and people play around with it, we should
>> keep the thing probably. However, if this is a theoretic architecture
>> only, then let's kill it.
> Judging by this it's something that actually exists:
>
> http://lwn.net/Articles/408051/
>
> Hence I think we should leave the arch in... 
>
> Lennart
>

Thanks.

(As in, it's supported arch in Gentoo)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to get rid of this ordering cycle?

[Lennart Poettering]

On Thu, 14.08.14 14:31, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

> In Debian, support for sysvinit scripts in rcS was patched back in to
> avoid breaking existing software, because it's unlikely that all of the
> packages listed in
>  will get a
> native systemd unit any time soon. Most of them probably doesn't
> actually need to run in rcS - nvi? seriously? - but if fixing them all
> was on the critical path for adopting systemd, we'd probably still be
> using sysvinit for years to come.

I have the suspicion that this creates as many problems as it
solves... That's why we removed support for that, especially since
there's no realy standard about this anyway...

Lennart

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

Re: [systemd-devel] [PATCH] socket: add support for TCP fast Open

[Dave Reisner]

On Thu, Aug 14, 2014 at 02:31:47PM +0530, Susant Sahani wrote:
> TCP Fast Open (TFO) speeds up the opening of successiveTCP)
> connections between two endpoints.It works by using a TFO cookie
> in the initial SYN packet to authenticate a previously connected
> client. It starts sending data to the client before the receipt
> of the final ACK packet of the three way handshake is received,
> skipping a round trip and lowering the latency in the start of
> transmission of data.
> ---

Why does this default to false? The kernel enables this by default as of
3.13 and exposes /proc/sys/net/ipv4/tcp_fastopen. Are there really
cases where one might want this conditionally enabled/disabled?

>  man/systemd.socket.xml| 15 +++
>  src/core/dbus-socket.c|  1 +
>  src/core/load-fragment-gperf.gperf.m4 |  1 +
>  src/core/socket.c |  8 
>  src/core/socket.h |  1 +
>  5 files changed, 26 insertions(+)
> 
> diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
> index 352825f..170d010 100644
> --- a/man/systemd.socket.xml
> +++ b/man/systemd.socket.xml
> @@ -499,6 +499,21 @@
>  
>  
>  
> +FastOpen=
> +Takes a boolean
> +argument. It works by using a TFO cookie (a 
> TCP option) in the initial
> +SYN packet to authenticate a previously 
> connected client. If successful,
> +it may start sending data to the client 
> before the receipt of the final
> +ACK packet of the three way handshake is 
> received, skipping a round trip
> +and lowering the latency in the start of 
> transmission of data.
> +This controls the TCP_FASTOPEN socket option 
> (see
> +the  url="http://lwn.net/Articles/508865/";>TCP
> +Fast Open: expediting web services 
> for details.)
> +Defaults to
> +false.
> +
> +
> +
>  Priority=
>  Takes an integer
>  argument controlling the priority for
> diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
> index ad135a1..71c0115 100644
> --- a/src/core/dbus-socket.c
> +++ b/src/core/dbus-socket.c
> @@ -97,6 +97,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
>  SD_BUS_PROPERTY("DirectoryMode", "u", bus_property_get_mode, 
> offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("Accept", "b", bus_property_get_bool, 
> offsetof(Socket, accept), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("KeepAlive", "b", bus_property_get_bool, 
> offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
> +SD_BUS_PROPERTY("FastOpen" , "b", bus_property_get_bool, 
> offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("Priority", "i", bus_property_get_int, 
> offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("ReceiveBuffer", "t", bus_property_get_size, 
> offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
>  SD_BUS_PROPERTY("SendBuffer", "t", bus_property_get_size, 
> offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
> diff --git a/src/core/load-fragment-gperf.gperf.m4 
> b/src/core/load-fragment-gperf.gperf.m4
> index f4acdda..08d0593 100644
> --- a/src/core/load-fragment-gperf.gperf.m4
> +++ b/src/core/load-fragment-gperf.gperf.m4
> @@ -232,6 +232,7 @@ Socket.Accept,   config_parse_bool,   
>0,
>  Socket.MaxConnections,   config_parse_unsigned,  0,  
>offsetof(Socket, max_connections)
>  Socket.KeepAlive,config_parse_bool,  0,  
>offsetof(Socket, keep_alive)
>  Socket.NoDelay,  config_parse_bool,  0,  
>offsetof(Socket, no_delay)
> +Socket.FastOpen, config_parse_bool,  0,  
>offsetof(Socket, fast_open)
>  Socket.Priority, config_parse_int,   0,  
>offsetof(Socket, priority)
>  Socket.ReceiveBuffer,config_parse_iec_size,  0,  
>offsetof(Socket, receive_buffer)
>  Socket.SendBuffer,   config_parse_iec_size,  0,  
>offsetof(Socket, send_buffer)
> diff --git a/src/core/socket.c b/src/core/socket.c
> index 5af1596..44827ad 100644
> --- a/src/core/socket.c
> +++ b/src/core/socke

Re: [systemd-devel] How to get rid of this ordering cycle?

[Simon McVittie]

On 14/08/14 14:31, Simon McVittie wrote:
> Default-Start: S means basic-target.target depends on
> mintsystem.service, which depends on dbus.service, which does not have
> DefaultDependencies=no, so it implicitly depends on sysinit.target, so
> you lose.

Sorry, that's not quite right. Default-Start: S translates into making
sysinit.target depend on mintsystem.service, and mintsystem.service
depends on dbus.service, which implicitly depends on basic.target as a
result of default dependencies, and basic.target depends on
sysinit.target. So, again, a cycle.

S

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Simon McVittie]

On 14/08/14 13:27, Vlad Orlov wrote:
> ### BEGIN INIT INFO
> # Provides:  mintsystem
> # Required-Start:$local_fs $syslog $remote_fs dbus
> # Required-Stop: $local_fs $syslog $remote_fs
> # Default-Start: S
> # Default-Stop:  
> ### END INIT INFO

As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream
systemd does not support sysvinit services during early boot, i.e. rcS.

In Debian, support for sysvinit scripts in rcS was patched back in to
avoid breaking existing software, because it's unlikely that all of the
packages listed in
 will get a
native systemd unit any time soon. Most of them probably doesn't
actually need to run in rcS - nvi? seriously? - but if fixing them all
was on the critical path for adopting systemd, we'd probably still be
using sysvinit for years to come.

Default-Start: S means basic-target.target depends on
mintsystem.service, which depends on dbus.service, which does not have
DefaultDependencies=no, so it implicitly depends on sysinit.target, so
you lose.

Or to put it in sysvinit terms, this is still incorrect: a service
started in rcS should not depend on dbus, which is started in rc2.

(Perhaps dbus should use DefaultDependencies=no - I think all it
actually needs are syslog.socket and /usr - but it has traditionally
been run in rc2.)

> I'd like to know: what can I change in this script to get rid of the ordering 
> cycle?

You can start it later, in rc2 (so it can start after dbus.service); or
you can make it not depend on dbus if it doesn't actually need
dbus-daemon; or you can modify dbus.service to use
DefaultDependencies=no and declare its dependencies explicitly; or you
can delete it.

If mint-adjust.py is

then, ugh, this is the sort of thing that should not be done (and Debian
Policy specifically forbids it). Linux Mint should ship a patched
version of Debian's base-files package instead, like Ubuntu, SteamOS and
other Debian derivatives do: that's the correct place to declare your OS
to be a fork of Debian.

S

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

Re: [systemd-devel] How to get rid of this ordering cycle?

[Lennart Poettering]

On Thu, 14.08.14 16:27, Vlad Orlov (mon...@inbox.ru) wrote:

> Hi,
> 
> I have Debian Testing running with some additional packages from Linux
> Mint which are installed for testing purposes.
>
> One of them is mintsystem, which causes an ordering cycle during the boot:
> 
> авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start
> авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start
> авг 14 13:51:06 jessica systemd[1]: Found dependency on 
> mintsystem.service/start
> авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start
> авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start
> авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job 
> mintsystem.service/start
> авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to 
> break ordering cycle starting with basic.target/start
> 
> 
> The init script in mintsystem package is /etc/init.d/mintsystem. Here's its 
> contents:
> 
> #! /bin/sh
> 
> ### BEGIN INIT INFO
> # Provides:  mintsystem
> # Required-Start:$local_fs $syslog $remote_fs dbus
> # Required-Stop: $local_fs $syslog $remote_fs
> # Default-Start: S
> # Default-Stop:  
> ### END INIT INFO
> 
> /usr/lib/linuxmint/mintSystem/mint-adjust.py
> 
> 
> I'd like to know: what can I change in this script to get rid of the ordering 
> cycle?

This must be a really old systemd version?

So the problem here is that you want this to be started in the "S"
runlevel, i.e. during early boot. But you also want this to run after
dbus. dbus however is only started in late boot. 

You have to make a decision here: run the thing in early boot (and hence
not in "S"), or run it after dbus. Both you cannot do, that's not
possible...

That said, we removed support for sysv init scripts as part of
early-boot a long time ago. Your distro's systemd must be really old or
somebody must have patched that it added that back in.

Lennart

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

Re: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub

[Simon McVittie]

I recently opened this Debian bug, for which I attach a
patch that seems to work. Bug report quoted in full below.

I would appreciate udev maintainers' opinions on whether this is
likely to break non-USB devices, or whether there is a better way
to do it.

S

> Steps to reproduce: plug in a USB device which isn't in the udev
> hwdb, like this one: 
> 
> Bus 003 Device 017: ID 21b4:0081  
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   1.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize0 8
>   idVendor   0x21b4 
>   idProduct  0x0081 
>   bcdDevice1.20
>   iManufacturer   1 AudioQuest inc.
>   iProduct2 AudioQuest DragonFly
>   iSerial 3 (C) 2013 Wavelength Audio, ltd.
> 
> (Yes I know that's a weird serial number, I didn't design the device.)
> 
> Expected result:
> 
> * ID_MODEL_FROM_DATABASE and ID_VENDOR_FROM_DATABASE are missing
> * Interested applications can look up those properties using
>   idVendor and idProduct if they want to
> 
> Actual result: those strings are taken from the parent device,
> an Intel Corp. Integrated Rate Matching Hub (vendor 8087, product 0024):
> 
> P: /devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/sound/card1
> E: 
> DEVPATH=/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/sound/card1
> E: ID_BUS=usb
> E: ID_FOR_SEAT=sound-pci-_00_1a_0-usb-0_1_2_1_0
> E: ID_ID=usb-AudioQuest_inc._AudioQuest_DragonFly-00-DragonFly
> E: ID_MODEL=AudioQuest_DragonFly
> E: ID_MODEL_ENC=AudioQuest\x20DragonFly
> E: ID_MODEL_FROM_DATABASE=Integrated Rate Matching Hub
> E: ID_MODEL_ID=0081
> E: ID_PATH=pci-:00:1a.0-usb-0:1.2:1.0
> E: ID_PATH_TAG=pci-_00_1a_0-usb-0_1_2_1_0
> E: ID_REVISION=0120
> E: ID_SERIAL=AudioQuest_inc._AudioQuest_DragonFly
> E: ID_TYPE=audio
> E: ID_USB_DRIVER=snd-usb-audio
> E: ID_USB_INTERFACES=:010100:010200:
> E: ID_USB_INTERFACE_NUM=00
> E: ID_VENDOR=AudioQuest_inc.
> E: ID_VENDOR_ENC=AudioQuest\x20inc.
> E: ID_VENDOR_FROM_DATABASE=Intel Corp.
> E: ID_VENDOR_ID=21b4
> E: SOUND_INITIALIZED=1
> E: SUBSYSTEM=sound
> E: SYSTEMD_WANTS=sound.target
> E: TAGS=:seat:systemd:
> E: USEC_INITIALIZED=6479525776
> 
> This makes PulseAudio assign a silly name to this device, which shows
> up in control UIs (e.g. "Integrated Rate Matching Hub Analog Stereo" in
> pavucontrol and "Analog Stereo - Integrated Rate Matching Hub" in
> gnome-control-center):
> 
> index: 1
>   name: 
> 
>   ...
>   card: 1 
> 
>   ...
>   properties:
>   ...
>   alsa.card_name = "AudioQuest DragonFly"
>   alsa.long_card_name = "AudioQuest inc. AudioQuest DragonFly at 
> usb-:00:1a.0-1.2, full speed"
>   ...
>   udev.id = 
> "usb-AudioQuest_inc._AudioQuest_DragonFly-00-DragonFly"
>   device.bus = "usb"
>   device.vendor.id = "21b4"
>   device.vendor.name = "Intel Corp."
>   device.product.id = "0081"
>   device.product.name = "Integrated Rate Matching Hub"
>   device.serial = "AudioQuest_inc._AudioQuest_DragonFly"
>   ...
>   device.profile.name = "analog-stereo"
>   device.profile.description = "Analog Stereo"
>   device.description = "Integrated Rate Matching Hub Analog 
> Stereo"
>From e0bb1d9cf82e397b08335e5d7107a8506849e823 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 14 Aug 2014 14:05:45 +0100
Subject: [PATCH] hwdb: stop looking at parent devices if the modalias changes

This avoids claiming that an unrecognised USB device is an Intel USB
hub, just because it happens to be plugged into an Intel USB hub.

Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758050
---
 src/udev/udev-builtin-hwdb.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/udev/udev-builtin-hwdb.c b/src/udev/udev-builtin-hwdb.c
index cac97e7..ac8d2e3 100644
--- a/src/udev/udev-builtin-hwdb.c
+++ b/src/udev/udev-builtin-hwdb.c
@@ -89,6 +89,7 @@ static int udev_builtin_hwdb_search(struct udev_device *dev, struct udev_device
 struct udev_device *d;
 char s[16];
 int n = 0;
+char found_modalias[16] = { 0 };
 
 for (d = srcdev; d; d = udev_device_get_parent(d)) {
 const char *dsubsys;
@@ -111,6 +112,16 @@ static int udev_builtin_hwdb_search(struct udev_device *dev, struct udev_device
 if (!modalias)
 continue;
 
+/* if we already found a device with a vendor:product
+ * and this device has a different vendor:product, stop -
+ * this avoids matching the hub to which a USB device is
+ * attached */
+if (found_modalias[0] && !streq(modalias, found_modalias))
+brea

Re: [systemd-devel] race conditions after SIGTERM

[Reindl Harald]

Am 14.08.2014 um 14:24 schrieb Lennart Poettering:
> On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> but that still don't explain why "ExecStopPost=/usr/bin/true" or
>> whatever "ExecStopPost" solves that and if it is not supported
>> why "systemctl" don't return after the one and only process
>> exited
> 
> Well, this is a misunderstanding how ExecStop= and friends are supposed
> to work. They are supposed to do what they did on sysvinit:
> synchronously terminate a service. And not asynchronously do that. We
> hence don't wait for anything else then, because what is left afterwards
> must be left-over processes that ExecStop= and friends couldn't clean up
> properly...

no - the point was why was mysqld not finished with write down
his ariadb-logs while systemctl returns and hence the corruption
by start rsysnc the datadir

in case of Type=simple and mysqld directly called in ExecStart
without the mysqld_safe script there are not much processes
to "left over"



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] race conditions after SIGTERM

[Reindl Harald]

Am 14.08.2014 um 14:22 schrieb Lennart Poettering:
> On Sun, 27.07.14 19:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>>
>> On Sat, Jul 26, 2014 at 02:46:05PM +0200, Reindl Harald wrote:
>>> after that happend a few minutes ago systemd on F19:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1123557
>>>
>>> since the "sleep 1" was enough over months and now "sleep 6"
>>> between "systemctl stop" and rsync is also not relieable my
>>> only conclusion is that systemd don't care about the still
>>> running MAINPID of "type=simple" and in case of a existing
>>> "ExecStopPost" the logic is correct
>> Hi,
>>
>> PIDFile with Type=simple is not supported. Adding support
>> would be tricky, because with Type=simple there's no obvious
>> mechanism to notify systemd *when* to read the file. With
>> Type=forking, when the first process exits, systemd knows
>> it can read the file. It could be done with inotify maybe.
> 
> A long-standing item on the TODO list is to add a new Type=pid-file or
> so that waits for a PID file to appear and uses that as indication when
> a daemon is up, or dies. I figure the example above would be a good case
> for this

yes, but the problem is somewhere else
look at the bugreport, it happened also witout the PIDFile line

well, yesterday i upgraded production to Fedora 20
maybe that is now solved anyways

i will report in both cases in the RH bugzilla

* if it did not happen again for 3 weeks
* if it happens again

pretty sure a regression in the last F19 systemd update only
in rare situations triggered or at least it got bader with
that version since the "/usr/bin/sleep 1" workaround did
no longer help relieable





signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to get rid of this ordering cycle?

[Vlad Orlov]

Hi,

I have Debian Testing running with some additional packages from Linux Mint 
which are installed for testing purposes.
One of them is mintsystem, which causes an ordering cycle during the boot:

авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start
авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start
авг 14 13:51:06 jessica systemd[1]: Found dependency on mintsystem.service/start
авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start
авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start
авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job 
mintsystem.service/start
авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to 
break ordering cycle starting with basic.target/start


The init script in mintsystem package is /etc/init.d/mintsystem. Here's its 
contents:

#! /bin/sh

### BEGIN INIT INFO
# Provides:  mintsystem
# Required-Start:$local_fs $syslog $remote_fs dbus
# Required-Stop: $local_fs $syslog $remote_fs
# Default-Start: S
# Default-Stop:  
### END INIT INFO

/usr/lib/linuxmint/mintSystem/mint-adjust.py


I'd like to know: what can I change in this script to get rid of the ordering 
cycle?

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

Re: [systemd-devel] [PATCH] resolved: re-add support for getting local domain from DHCP

[Tom Gundersen]

On Thu, Aug 14, 2014 at 1:47 PM, Lennart Poettering
 wrote:
> On Thu, 14.08.14 13:27, Tom Gundersen (t...@jklm.no) wrote:
>
>>
>> On Thu, Aug 14, 2014 at 1:11 PM, Lennart Poettering
>>  wrote:
>> >
>> > UseDomain= should have the effect of adding the domains from dhcp option
>> > 15 and 119 to the list of domains for the interface. And
>> > sd_network_get_link_domains() should then return a single list, of
>> > deduplicated entries, with the domains specified in Domains= first, and
>> > then the dhcp domains possible added in at the end.
>> >
>> > Zbigniew, I think this simplification would be beneficial, as I really
>> > don't see the need to make the search vs. route domain thing
>> > configurable
>> >
>> > Tom, what's your take on all of this?
>>
>>
>> Sorry for taking forever to answer to this thread. I have been going
>> back and forth in my mind about how this should look.
>>
>> I think in the end I essentially agree with Lennart's last suggestion.
>> Let's make this dead-simple and collapse the search/route domains for
>> each link into a single list. I think this is fine given that we
>> restrict the search behaviour to single-labels.
>>
>> My only hesitation has been that I can imagine someone wanting to add
>> search domains that do not imply anything about routing. However, I
>> think in this case it does not make much sense to make this per-link,
>> but it should rather be a global SearchDomains= option (in
>> resolved.conf) or something to that effect.
>>
>> Zbigniew, Michael, what do you think?
>
> Tom reminded me of the fact now, that at the systemd hackfest in Brno
> last week (which really was more a "talkfest") people suggested we
> should actually make it possible that if you go to lets say
> "xhamster.com" you never ever want this to be resolved via the redhat
> VPN. That probably makes a lot of sense.
>
> Hence, I would suggest adding a syntax of:
>
>[Network]
>Domains=*
>
> which would have the effect to route all DNS traffic that is not
> explicitly routed somewhereelse to this interface.
>
> Internally, this would just set a boolean, which could be queried with:
>
>int sd_network_link_get_wildcard_domain(int ifindex);
>
> or so, which would return 0 or 1 or negative -errno...
>
> But then again, this doesn't have to be there from day one, we can add
> that later... But of course, I'd love to see this done early on, too,
> after all the porn usecase is a major one.


As discussed off-list, I agree with adding this API / behaviour.

Cheers,

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

Re: [systemd-devel] race conditions after SIGTERM

[Lennart Poettering]

On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote:

> but that still don't explain why "ExecStopPost=/sur/bin/true" or
> whatever "ExecStopPost" solves that and if it is not supported
> why "systemctl" don't return after the one and only process
> exited

Well, this is a misunderstanding how ExecStop= and friends are supposed
to work. They are supposed to do what they did on sysvinit:
synchronously terminate a service. And not asynchronously do that. We
hence don't wait for anything else then, because what is left afterwards
must be left-over processes that ExecStop= and friends couldn't clean up
properly...

Lennart

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