Re: [systemd-devel] ruby bindings

[David Timothy Strauss]

For what it's worth, I try to encourage projects to identify their bindings
as simply for systemd, even if the journal support is the first (and only)
set of APIs available. It's just so easy to support the other APIs once the
journal is already supported, and daemons that want to use the journal
should consider using the notify API as well for startup/shutdown status --
and other APIs offered for daemons by systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

[David Timothy Strauss]

On Thu, Jul 14, 2016, 19:07 Kai Hendry  wrote:

> I would love to see that 10 lines of shell you claimed, but I think you
> might be underestimating the fine work that went into Dokku!
>

It's not so much underestimating the work in Dokku as much as leveraging
what systemd and a tool like haproxy provide for services.

Here's what a script would do with no socket activation, assuming you're
sending traffic to the services with a tool like haproxy and have an
interface like a control socket [1]:

   1. Tell haproxy to stop sending traffic to service instance A.
   2. systemctl restart instance-a.service
   3. Tell haproxy to start sending traffic to service instance A and stop
   to B.
   4. systemctl restart instance-b.service
   5. Tell haproxy to start sending traffic to service instance B.

Alternatively, you could track state of a flip-flop and stabilize on only
one service instance at a time after the restart.

[1] https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

[David Timothy Strauss]

Dokku would be about a 5-10 lines of shell script with services running in
systemd.

On Wed, Jul 13, 2016, 20:41 Kai Hendry  wrote:

> On Sat, 18 Jun 2016, at 07:56 PM, Paul Menzel wrote:
> > Is that possible by just using systemd, or is a load balancer like
> > HAProxy or a special NGINX configuration and service file templates
> > needed?
>
> I'm looking for answers too and the best switcheroo I've found so far is
> http://dokku.viewdocs.io/dokku/deployment/zero-downtime-deploys/ which
> leverages Docker and it's not at all integrated with systemd.
>
> Guess a systemd integrated solution would be leveraging machinectl,
> journalctl and more powerful service control, but I haven't seen an
> orchestrated deployment like that yet. Maybe CoreOS has something, I am
> not sure.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adding a Timer section to .service files

[David Timothy Strauss]

On Fri, Jul 8, 2016 at 9:07 AM Lennart Poettering 
wrote:

> Ultimately it's really a design decision: tabular file formats have
> the benefit of being a lot more dense, but are neither particularly
> extensible nor self-explanatory (as you need to know what each column
> means). Unit files are a bit longer to write, but more extensible and
> self-explanatory. When we designed this we preferred the latter two
> properties over the density property.
>

Tabular file formats are also much harder to manage with configuration
tools like Chef, Puppet, and Ansible. They almost always require some
"generator" to handle the composition from multiple sources.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

[David Timothy Strauss]

You either need a load balancer (less elegant) or need to make use of the
Linux kernel's SO_REUSEPORT option so the new application can bind to the
same port as the old one (at which point the old application should unbind
the port and shut itself down).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rkt container engine fetch user/perm patterns

[David Timothy Strauss]

There could be a (potentially socket-activated) service that handles
requests for image downloads.

On Tue, May 31, 2016, 11:06 Brandon Philips  wrote:

> Hello Everyone-
>
> The rkt container engine wants to run with different permissions pre-start
> and start. In pre-start it needs to fetch/download the container image
> which is an unprivileged operation. In start it needs admin level
> permissions to start the container stage1 (e.g. systemd-nspawn) and mount
> the root overlayfs.
>
> One way of accomplishing this is:
>
> ExecStartPre=/usr/bin/su rktfetchuser -c /usr/bin/rkt fetch
> quay.io/coreos/etcd blah blah
> ExecStart=/usr/bin/rkt run $(COREOS_VERSIONS_ETCD_FULL) blah blah
>
> The other way would be to create a fetch service and a run service but
> that is sort of clunky for users to configure.
>
> Are there other mechanisms to not require the use of wrappers like su?
>
> Thank You,
>
> Brandon
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[David Timothy Strauss]

Rebooting an old thread now that we're finally testing this out.

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

This turns out to be less useful than it seems.

There are two major ways to invoke strace, each with caveats:

   - Launch the process with strace. This captures everything from the
   first syscall to daemonized operation, but it's hard to create an
   equivalent context and environment versus how the service runs normally.
   This is especially bad for socket-activated services because those may
   actually use fewer or different syscalls than if they have to open their
   own listener sockets.
   - Attach to an existing process. This allows seeing behavior under
   systemd, but it misses early service startup because the PID is only
   knowable after the service has started. We've specifically seen issues
   where some syscalls are only used in early service startup.

It would be useful if systemd could help packagers, developers, and
administrators configure better sandboxes for services by, say, using
strace (or equivalent) to capture any unique syscalls in use, starting from
the beginning of execution. This wouldn't be the normal mode of operation,
but maybe part of a service profiling mode or a property in unit files.
___
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=

[David Timothy Strauss]

On Fri, Jan 22, 2016 at 1:36 PM Mantas Mikulėnas  wrote:

> There's a third way:
>
> ExecStart=/usr/bin/strace -D -ff -o /tmp/myservice.trace
> /usr/bin/myservlce --foo
>

Do you know if that would pass through file descriptors for socket
activation?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Scheme bindings

[David Timothy Strauss]

Would you be interested in moving this work to the systemd umbrella project
on GitHub? You would still manage the team, but it may get more visibility.

On Fri, Nov 13, 2015, 19:27 Jan Synáček  wrote:

> Hello,
>
> if anybody lurking here and hacking on systemd also likes scheme, I
> created bindings for GNU Guile [1]. The API is far from covered, but
> journal API and sd_listen* stuff is usable. You can now write socket
> activated services in scheme!
>
> [1] https://github.com/jsynacek/guile-systemd
>
> Have fun,
> --
> Jan Synacek
> Software Engineer, 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] about socket

[David Timothy Strauss]

The wording of your questions isn't clear to me. Do you mean that A and B
are socket-activated services, each requiring C? And when you say "the
message of A and the message of B," do you mean packets going to the
sockets for A and B?

If so, a packet going to A or B will also start C. The requests to start
services are processed FIFO by a single thread, so it's effectively one
queue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] A few GitHub team changes

[David Timothy Strauss]

On Wed, Oct 14, 2015 at 9:35 AM Jóhann B. Guðmundsson 
wrote:

> What makes up that members list [1] in the first place?
>

I think it includes anyone on any team associated with the organization. It
also provides organization-level permissions for things like making new
projects (but not being an admin on existing ones).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] A few GitHub team changes

[David Timothy Strauss]

In case anyone in the former owners group is checking here, you would have
received an email saying you've been removed from the "Core" team. GitHub
wanted me to rename it, so I did to "Core" before ultimately realizing it
served no further purpose. No one should have any less access to systemd
GitHub resources from the changes today.

As for the Erlang team, Sebastian (the existing team member) kindly offered
very quickly to head it and will handle further requests to join. I'll
already replied to the other offer privately and refereed them to him.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] A few GitHub team changes

[David Timothy Strauss]

I made a few minor GitHub team changes:

(1) The "Owners" team is now deleted. GitHub migrated the access this team
originally provided to an "owner" attribute, making the team unnecessary.
Leaving the team would have only caused the actual owners to be out-of-sync
with the named "Owners" team. You can still list owners by filtering the
entire members list [1].

(2) I've rationalized the Python and Erlang team names to simply be
"Python" and "Erlang." They are already namespaced under the systemd
project, and the shorter names will make mentions easier and cleaner
(@systemd/python versus the old @systemd/python-systemd or
@systemd/erlang-bindings).

(3) For Erlang support, at Sebastian Schindler's request, I've added
Vladimir Tarasenko [2] and Sascha Kattelmann [3]. Sebastian was already on
the team. I would like to promote someone else to maintain the Erlang team,
though. It's definitely not my area of focus. If you'd like to step up, let
me know.

[1] https://github.com/orgs/systemd/people?query=role%3Aowner
[2] https://github.com/umatomba
[3] https://github.com/galaxygorilla
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] run no more than one of foo@.service at a time

[David Timothy Strauss]

If you only want one instance running, why not just create one service and
reconfigure/restart it?

On Mon, Oct 5, 2015, 09:04 Johannes Ernst  wrote:

> I have a foo@.service. When started as
> systemctl start foo@abc
> I’d like all other currently active foo@… services to stop, and vice
> versa. All of the foo@.services are supposed to be mutually exclusive
> with each other.
>
> In foo@.service, I attempted:
> Conflicts: foo@.service
> but that does not seem to do the trick (Starting foo@abc produces
> "Dependency Conflicts=foo@abc.service dropped”)
>
> I’d like to avoid having to enumerate foo@abc, foo@def etc. in the
> Conflicts section.
>
> Ideas?
>
> Thanks,
>
>
>
> Johannes.
>
> ___
> 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] [HEADS-UP] Please register for systemd.conf 2015 now, only 14 tickets left!

[David Timothy Strauss]

On Wed, Sep 23, 2015, 18:14 Lennart Poettering 
wrote:

> We are close to being sold out now, only 14 tickets are still
> available now. If you intend to attend, make sure to register for the
> conference *now*, before it's too late and all tickets are gone.
>
> Register here:
>
> https://systemd.events/systemdconf-2015/registration
>
> To get an idea about the sessions offered, please see our preliminary
> schedule:
>
> https://systemd.events/systemdconf-2015/schedule
>

How should users of sponsorship tickets register?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd and hostname supplied by DHCP

[David Timothy Strauss]

On Mon, Sep 28, 2015 at 1:19 AM Alessio Igor Bogani <
alessioigorbog...@gmail.com> wrote:

> Hi systemd developers and users,
>
> The systemd 219 brought with Yocto "Fido" can't set hostname supplied
> by DHCP on my Beaglebone:
>
> eth0: eth0: could not bring up interface:
> Invalid argument
> eth0: gained carrier
> eth0: DHCPv4 address 192.168.205.87/24 via 192.168.205.1
> eth0: link configured
> eth0: Could not set hostname: No route to host
>

"Could not set hostname: No route to host" sounds like systemd is trying to
resolve and ping the provided hostname. But, it's failing, and so systemd
is deciding that it's not a usable hostname. Doesn't seem related to the
DHCP protocol implementation at all.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: filter and search journalctl

[David Timothy Strauss]

I think you should look into forwarding your logs to a more sophisticated
aggregator, like the ELK stack.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Timothy Strauss]

Let's just try the GitHub tracker. I like how it associates issues with
pull requests and supports auto-linking for commit IDs, user names, and
other issue numbers. Is there any serious use case for systemd upstream it
doesn't support?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Timothy Strauss]

On Tue, Jun 2, 2015 at 5:03 PM Kay Sievers k...@vrfy.org wrote:

 Could you please check your old repos at:
   https://github.com/systemd
 and move or delete them if they are no longer needed. One of them at
 least has a comment like This is old. Actual repo is on my
 davidstrauss account. Will clean up soon. (2012)

 We should only keep repos here for code that we actually host. Cloned
 repos should only be there if they are supposed to be shared by
 multiple people to work on them at the same time, everything else
 should be done in a user repo.


This is now done. The only remaining forked repository is the Linux kernel,
which appears to be for kdbus work.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Timothy Strauss]

Looks like everything's in place now at the new github.com/systemd/systemd
home.

I've halted the Jenkins CI from pushing to that repository (which was
formerly the mirror updated whenever CI passed). I'll probably update CI to
merely push a branch like master-passing so there's still a way to get
the latest passing commit, but it's just disabled for now.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[David Timothy Strauss]

On Mon, Jun 1, 2015 at 11:20 AM Zbigniew Jędrzejewski-Szmek 
zbys...@in.waw.pl wrote:

 On Mon, Jun 01, 2015 at 08:12:37PM +0200, David Herrmann wrote:
  [1] https://github.com/systemd-devs/systemd
 Is there a particular reason not to use the existing
 https://github.com/systemd/systemd ?


No idea why not. I even replied that I'd take care of it this week. I need
to move the CI repo out of the way and update permissions.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=

[David Timothy Strauss]

On Tue, Apr 21, 2015 at 12:26 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 So I see no use case for idle timer based cleanup. Can you please
 explain why they are better than on-demand cleanup?

We do it on Pantheon's infrastructure because many daemons have a
resource footprint that is more than just allocated memory, like
waking themselves up for cache cleanup or inefficient polling on
sockets. We shut down socket-activated applications after an hour of
idle time, and it dramatically frees up server resources for active
daemons.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] regarding to cgroup siblings mask

[David Timothy Strauss]

On Fri, Mar 27, 2015 at 7:56 PM, WaLyong Cho walyong@gmail.com wrote:
 Hmm, it seems not. When I added MemoryLimit= option to just one service,
 cgroups for every unit were generated on memory cgroup.

It looks like memory_limit and cpu_quota_per_sec_usec both have this
potential issue. The other four controllers managed this way are
clearly proportional (using weights or shares).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] regarding to cgroup siblings mask

[David Timothy Strauss]

On Thu, Mar 26, 2015 at 7:33 PM, WaLyong Cho walyong@samsung.com wrote:
 Thanks, understood. But I think this propagation is needed only for
 taking weight argument such like CPUShares=weight,
 StartupCPUShares=weight, BlockIOWeight=weight,
 StartupBlockIOWeight=weight, BlockIODeviceWeight=device weight. For
 example, I don't think MemoryLimit= is not option of proportional. It
 just only limit of its cgroup and does not race with other cgroup.

 If I'm right, we need to modify unit_get_target_mask() to get only mask
 for proportional properties.

I'm pretty sure we already do that. If not, it's a bug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] regarding to cgroup siblings mask

[David Timothy Strauss]

On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho walyong@samsung.com wrote:
 If this can be configurable, how about add a configuration for cgroup
 mask propagation to siblings?

I believe the way to prevent propagation is to separate the units into
different slices.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] regarding to cgroup siblings mask

[David Timothy Strauss]

On Tue, Mar 24, 2015 at 4:29 AM, WaLyong Cho walyong@samsung.com wrote:
 Could anyone explain why?

An admin using CPUShares= or a similar proportional CGroup controller
probably assumes that setting the shares to twice the default (for
example) increases the relative proportion of resources for that unit.
However, that is only true if other units competing for that resource
have the same controller(s) enabled so that the kernel knows to
balance the resources accordingly.

The code in systemd ensures that if any unit uses a proportional
CGroups controller in a slice, all other units in that same slice
enable that controller as well, usually with the default proportions.

unit_get_target_mask() is part of an optimization I added so that
initializing CGroups controllers for a given unit doesn't require
iterating through every other unit in a slice to figure out the
necessary controllers. It provides a bitmask indicating the
controllers in use by its siblings so the unit can enable, say,
CPUShares= if one of its siblings is doing so.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: add edit verb

[David Timothy Strauss]

On Fri, Oct 17, 2014 at 1:24 PM, Lennart Poettering
lenn...@poettering.net wrote:
 Does this make sense?

Speaking as a nano user and someone who barely knows how to quit vim,
I still think the decision of the default editor should be vi or the
distribution's choice.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH, v3 3/3] find_symlinks: adds a cache of enabled unit symbolic link state

[David Timothy Strauss]

On Thu, Oct 23, 2014 at 5:15 AM, Lennart Poettering
lenn...@poettering.net wrote:
 With your patch you generate a system-wide cache for that, but when do
 you flush it precisely? What's the logic there?

It updates on daemon-reload or daemon-reexec, consistent with how we
load modified unit files. systemctl enable/disable unit already
performs a daemon-reload after manipulating symlinks, which should
make the impact on users minimal.

Even admins who manipulate the symlinks directly will usually get the
intended effect because they're choosing which services start by
default on the next boot, and we freshly populate the cache on systemd
startup. They would see stale data in systemctl status, though.

 Do we really need to keep the cache around? I mean, it see that it
 can help if people invoke multiple bus calls one after the other, but
 then again, we actually allow passing an array in anyway, so if people
 want to take benefit of the optimization they can just issue one call
 with multipls args instead of many calls with one each?

Aside from the small amount of additional memory required (which we
can easily reduce to be proportional to the number of enabled units,
if we're not doing that already), I don't see much downside to keeping
the cache around. It's used every time someone runs systemctl status
unit, even if the calls are not one-after-the-other. Running
systemctl alone hits the cache once for every unit. It's also an
optimization for the critical path of getting PID 1 back to its event
loop, which is key for minimizing socket activation latency.

That said, if it's a blocker, I can work with Ken to make the cache
more ephemeral.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use cgroups for Tracker?

[David Timothy Strauss]

On Thu, Oct 16, 2014 at 6:07 AM, Martyn Russell mar...@lanedo.com wrote:
 True, but some users (I am guessing with low end machines) are complaining
 about Tracker while they're trying to use their system.

I said that having an active user does not inherently imply resource
contention, not that they're uncorrelated. It's important to remember
because you were suggesting designs that work for the case of active
users needing all resources but create a worse experience for users
with idle resources.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting different services from same process

[David Timothy Strauss]

On Fri, Oct 17, 2014 at 9:03 AM, Paassen, Hiram van
hiram.van.paas...@mastervolt.com wrote:
 Is it possible to start multiple different services from one process?

In short, that is not sanely possible. If you care about latency for
accessing the service, even on the first request, then just don't
activate it using DBus. Enable it to start by default.

There are hacks you could use to move a process into another service's
cgroup, but it's highly unsupported and may not work coming kernel and
systemd changes to cgroups.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How is desktop container getting along?

[David Timothy Strauss]

On Fri, Oct 17, 2014 at 9:47 AM, Leslie Zhai xiangzha...@gmail.com wrote:
 But there are only lots of use cases about Linux Server and web application,
 as a Linux desktop geek, I often consider about the disadvantage of
 traditional deployment of Linux desktop application. Krita, for example, an
 awesome digital painting application in KDE`s calligra suite, is depend on
 Qt4, kdepimlibs 4.6.0, kdelibs4 and sort of KDE4 relative libraries; but
 also as a KDE develop, my desktop environment is Qt5 and KF5, so I have to
 git clone KDE4 relative libraries` repositories, then built them by myself
 as what other Linux geeks often experienced

Desktop containers are not that far along, at least in the sense of
seeing any major distribution on the verge of installing applications
via containers. Even if/when it happens, it may not be the panacea for
dependencies you're expecting.

First, there are multiple ways to install different library versions
simultaneously without containers. Distributions regularly do this for
things like GTK2 and GTK3. Have you checked with your distribution?

Second, you don't need containers to package an application with its
own libraries. Distributions usually frown on packaging shared
libraries with an application. What you're suggesting for containers
wouldn't be any better than packaging to /opt/krita with all libraries
in the same directory, which is what some apps have done for years.

Finally, your desktop can only support a fixed set of graphical APIs.
Unless you render the application in the container and connect with
something like SPICE (which wouldn't be that great), containers won't
allow you to run arbitrary applications.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf

[David Timothy Strauss]

Changes like this make config management so much easier. +1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] A schedule for the systemd hackfest next week?

[David Timothy Strauss]

I would like to discuss the state of systemd scalability on dense/large
systems.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use cgroups for Tracker?

[David Timothy Strauss]

I'm responding here only to the systemd list.

On Tue, Oct 14, 2014 at 4:35 PM, Martyn Russell mar...@lanedo.com wrote:
 Another option would be to use systemd. However, I am mindful that it's not
 available everywhere just yet (but soon will be I hear) I am also aware, I
 might get a biased answer here :)

systemd probably won't ever be available everywhere, if you define
everywhere to be any machine running the Linux kernel. But, that's
true of many extremely common tools we've come to rely on, including
the GNU userland. I think systemd is a reasonable dependency for tools
like Tracker that target desktop Linux.

 Does anyone have any suggestions or projects that lead by example that
 Tracker could/should follow?

Your case with the out-of-control plugins is hard, but I think a
simple hard limit on memory is the wrong answer (as the bug
demonstrates). With cgroups, you can register handlers for memory
pressure to elegantly handle shutting down or unloading plugins. You
can also query the memory usage charged to a cgroup to determine
when things are getting out of control. While cgroups can also set
memory limits where the processes will swap when allocation exceeds a
specified limit, you may find that creates an even more undesirable
load on I/O.

It is easier to throttle CPU or I/O as prevention against running
wild. For those, I recommend reading what systemd offers for
cgroups-cased resource management [1]. Those controls may be overkill,
though, if you don't care about starvation, so please consider my
answer to your next question, too.

 Orthogonal to all of this, is another idea I had, which is to completely
 pause Tracker when the user is present (keyboard/mouse use) to avoid wasting
 cycles on stuff the user doesn't care about - a bit like how chat clients
 know when you're away or not. Maybe we should do both?

The user being active doesn't mean substantial load is on the system.
Plus, users might get annoyed that changes they're making aren't
getting indexed. If you're okay with the Tracker getting starved --
and you seem to be given the thought of stopping it when a user is
active -- I would have the Tracker run with IOSchedulingClass=idle and
Nice=19 [2], which aren't options exclusive to systemd in any way.

[1] 
http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
[2] http://www.freedesktop.org/software/systemd/man/systemd.exec.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] stunnel now supports socket activation

[David Timothy Strauss]

Mark Theunissen, part of the team here at Pantheon, got our changes
upstream in version 5.05:

https://www.stunnel.org/sdf_ChangeLog.html

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

Re: [systemd-devel] [PATCH v2] Added test for unit file state returned by unit_file_get_state and unit_file_get_list. Made test-enabled units more basic, removing superfluous fields. Cleaned up test p

[David Timothy Strauss]

It looks like newlines at the end of the new files are inconsistent
(No newline at end of file).

Other than that +1. It's great to add tests, have them pass on master,
optimize master (the next patch), and then still have them pass.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/3] Made test-enabled units more basic, removing superfluous fields.

[David Timothy Strauss]

I think the test additions need to be rebased into a single commit
onto master rather than the initial patch plus the fixes as a second
commit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Added test for unit file state returned by unit_file_get_state and unit_file_get_list.

[David Timothy Strauss]

It would be good if the test units were more basic, not things
including Crash recovery kernel arming. This makes it seems like the
contents are substantial to the tests, when they're not. Just run
something like ExecStart=/usr/bin/echo to make it clear that the units
are stubs. Then, anything but the Type=oneshot and
ExecStart=/usr/bin/echo will be clearly for the sake of the tests.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Added test for unit file state returned by unit_file_get_state and unit_file_get_list.

[David Timothy Strauss]

Just to give some context, at Pantheon, we're working on optimizations
for the enabled part of systemd core. The first step we're doing is
enhancing the test suite. The additions here pass on master and will
also pass with the changes we'll submit after more tests are in core.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-socket-proxyd slapd

[David Timothy Strauss]

Would you be willing to post the entire unit files for everything
here, just so future users can see them? Presumably, you're using
JoinsNamespaceOf=proxy-to-directory-400.service in
vgp.master-ldap-400.service?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-socket-proxyd slapd

[David Timothy Strauss]

On Wed, Jul 16, 2014 at 7:29 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 This won't work, since proxyd now cannot connect to port 400.

There is now a way to make that work with JoinsNamespaceOf=
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6

[David Timothy Strauss]

On Sun, Jul 6, 2014 at 3:32 PM, Tom Gundersen t...@jklm.no wrote:
 yes is a synonym for both and no for none.

These are odd semantics, given that IPv6 is completely configurable
using router advertisements for even DNS information (that is, no DHCP
whatsoever). Perhaps the option should be Autoconfig= with options for
DHCPv4, DHCPv6, and RA and yes meaning all?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl

[David Timothy Strauss]

As someone who deploys developer VMs and production ones, this is
useful. Will it be possible to make units have ConditionDeployment=?
That would allow disabling, say, pushes of log messages to our log
aggregation servers from development and testing deployments.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Extending machine-info to include machine roles

[David Timothy Strauss]

I don't see much value in choosing a role from a predefined list.
Rarely do machines fit into one single, straightforward role.

It would be more useful to support machine tags/labels/roles that map
to units, especially if that's dynamically configurable using, say,
DHCP(v6). Then, something may be WantedBy=nameserver.role. That would
support both livestock deployments with a standardized /usr and
pet deployments where admins sign on and may enable roles shipped
with the distribution.

Then again, I don't see how those would be different from shipping
more unit.target files and adding some method to dynamically enable
them.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Improve xz compression performance.

[David Timothy Strauss]

+1 on anything that makes the journal faster on heavy workloads. It
remains a major bottleneck on our systems.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Seeking advice for configuring SystemCallFilter=

[David Timothy Strauss]

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

Re: [systemd-devel] Systemd-networkd: Prepend static nameserver to DHCP-discovered nameservers

[David Timothy Strauss]

On Tue, Jun 17, 2014 at 4:33 AM, Mantas Mikulėnas graw...@gmail.com wrote:
 I mean, as long as the first-listed server responds – and localhost always
 responds – then the fallback servers won't be used at all.

Localhost can be subject to two types of failure:
 * The local daemon being down.
 * The resources the local daemon uses being inaccessible. It is
possible for root servers, for example, to be inaccessible while the
DHCP-issued nameservers can still be. Not all local daemons will
prefer to use the DHCP-issued nameservers as their upstream,
particularly if DNSSec is preferred/required.

Therefore, it can be useful to have a local daemon followed by
fallback to using the DHCP-issued nameservers.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API

[David Timothy Strauss]

On Tue, Jun 10, 2014 at 6:07 AM, Dan Mace dm...@redhat.com wrote:
 Which only handles writes via the Unix socket.  The implementation we're 
 prototyping supports journal queries in ways that (to my knowledge) aren't 
 possible without either forking to external tools (e.g. journalctl) or 
 linking to sd-journal.

 If there's already code out there which satisfies the need, I'd be happy to 
 use and contribute to it.

I just pinged someone from CoreOS to hopefully shed more light on
this. What you linked on GitHub is what I remember from LinuxCon in
New Orleans.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API

[David Timothy Strauss]

The CoreOS crew has already done most of this work by writing a native
Go implementation (rather than wrapping the C APIs).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to escape from systemd slice

[David Timothy Strauss]

One of the cleanest ways to do what you want is to create a
D-Bus-activated systemd service (or socket-activated, if that's more
appropriate). That allows activation completely outside the user's
session without elevated privileges. Of course, it requires
considerable work for each service to do it right.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] units: use KillMode=process for systemd-nspawn@.service

[David Timothy Strauss]

Is there a downside to using KillMode=mixed instead?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timesyncd, dnssec

[David Timothy Strauss]

On Wed, May 21, 2014 at 5:48 AM, Jason A. Donenfeld ja...@zx2c4.com wrote:
 Temporary work around is to hard code IPs into NTP.

It'd be neat to do the following:
 (1) Do a DNS lookup for NTP servers, fetching DNSSec information.
 (2) If a signature/clock sync issue is the only barrier to validating
the response, still use the response for the next couple steps.
 (3) Fetch time from the NTP servers, but only use it to validate the
DNS response signatures.
 (4) If the signature now checks out, sync the local clock to the data.

Code could ship minimum timestamps to accept in step #3, thereby
ensuring that malicious, replayed responses are never older than the
release itself. This is superior to shipping fixed IPs because this
algorithm ensures the IPs are *at least* as fresh as the release
rather than *exactly* as fresh as the release.

It's a shame that there's no provision in DNSSec for a server creating
custom-signed responses based on a client nonce, just for this sort of
case. That would only require the ability to generate one-time values,
even if it's just a MAC address plus a counter. Might be an easy way
to DoS attack DNS servers, though, by breaking through caches and
forcing lots of signing work. Wouldn't work with servers supporting
only offline signing, either.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.

[David Timothy Strauss]

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

Re: [systemd-devel] User and Group permissions for .socket files

[David Timothy Strauss]

An alternative workaround is to put the socket into a directory that
has the permissions desired. If you can't read the directory, you
can't use a socket in that directory.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] timer: allow user to control activation time of cron-like timers

[David Timothy Strauss]

On Sun, May 11, 2014 at 9:30 AM, Alex B pkunk...@gmail.com wrote:
 It's ok for one timer, but not for the set of them.
 In general I'm want to schedule all maintenance tasks to 5 a.m.
 or lunch break and forget about them.
 This applies both for distro provided timers an my own.

I'd personally like sort of timer that activates at times of low
system load but with quality-of-service guarantees, like never running
less frequently than once a day.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Disable timers

[David Timothy Strauss]

systemctl disable or systemctl mask. You also have to stop it first,
as that only changes the default.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.

[David Timothy Strauss]

This is a completed version of the patch Lennart and I worked on at
the hackfest. The version we worked on had separate string arguments
for each type of state. This patch harmonizes it more with the way
systemctl --state already works, which is an array of possible states
to match across all state types. ListUnits is retained for API
compatibility, but systemctl is updated to always use
ListUnitsFiltered, even with an empty array.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ systemd-devel ] [PATCH] Fix Bug 72611 (systemctl is-enabled scales poorly with many units

[David Timothy Strauss]

Posting here for discussion at the systemd hackfest today.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Two git trees

[David Timothy Strauss]

Tests are back to passing, so GitHub is now in sync with the
freedesktop.org git.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql

[David Timothy Strauss]

On Thu, Apr 10, 2014 at 9:01 PM, Lennart Poettering
lenn...@poettering.net wrote:
 Yuck, I figure we need to ignore RemoveIPC for all system users, not
 just for root.

This still seems dangerous to me. I'm sure I have services running
under users where I've forgotten the system flag for the users.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql

[David Timothy Strauss]

Maybe if any service is running something as a user *or* it's a system
user, that user is immune to RemoveIPC?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cgroup: After MemmoryAccounting=yes running scope has no memusage

[David Timothy Strauss]

+1 from me. Seems like a good bugfix.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Two git trees

[David Timothy Strauss]

On Tue, Apr 8, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 I think it is synchronized after successful jenkins runs, so it is always 
 buildable
 and unit tests pass.

That's my GitHub mirror, not anything on freedesktop.org.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Two git trees

[David Timothy Strauss]

On Tue, Apr 8, 2014 at 11:31 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 https://github.com/systemd/systemd is not yours?

Nope, that's mine. You were right. I misread the two trees as the
authenticated and anonymous git on freedesktop.org for some reason.

They were out of sync because CI broke. It should never be more than
30 minutes behind unless master is broken on freedesktop.org. Fixing
it now.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Two git trees

[David Timothy Strauss]

CI is back online, but test-dhcp-option is currently failing, so it
won't update on GitHub until that's fixed.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

[David Timothy Strauss]

On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu wrote:
 init.debug would be better than systemd.debug, in my opinion. It
 is shorter (less typing and no possible end-user confusion over
 systemd.debug vs. system.debug), and it is init-agnostic. Other
 init systems (OpenRC, Upstart, etc.) would be able to add their own
 support for this, if they want, without requiring an init-specific
 kernel parameter.

 It just seems a lot simpler this way.

It would be a little odd given how systemd.name is how other
probably portable options get namespaced. Arguably, systemd.log_level
would become init.log_level. I'm not against it, but it couldn't be
just init.debug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug

[David Timothy Strauss]

On Thu, Apr 3, 2014 at 12:03 PM, Florian Albrechtskirchinger
falbrechtskirchin...@gmail.com wrote:
 Both you and Tom Gundersen raised the point of assisting end-users with
 boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as
 concise and simple as it gets.

-1 on this because it moves in the opposite direction of namespace
clarity. systemd should not use both more verbose, namespaced versions
of kernel options and abbreviated, non-namespaced versions of the
same. At least do sd.dbg or similar; we already use sd as a
namespace prefix elsewhere.

With respect to the main change suggested in this thread, I'm a +1 for
systemd.debug, especially because it's consistent with log level
options.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power

[David Timothy Strauss]

-1 on adding ConditionACPower=true

I frequently only plug in my laptop after putting it to sleep and then
disconnect it before waking it up again. It'd be possible to run
cleanup less frequently when on battery, but that would just delay the
work and increase the impact (which is pretty negligible right now)
when it happens.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql

[David Timothy Strauss]

Oh dear. Perhaps there's a way to use cgroups data to more selectively
do cleanup when there's overlap between regular users and service
users?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Failed to start Sendmail Mail Transport Agent

[David Timothy Strauss]

On Fri, Mar 28, 2014 at 12:41 PM, Lee Atkinson linuxle...@gmail.com wrote:
 .reading the Fedora 18 Users Guide

Fedora 18 is not a currently supported release, and its systemd is
ancient by this mailing list's standards.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[David Timothy Strauss]

On Mon, Mar 24, 2014 at 12:16 PM, Lennart Poettering
lenn...@poettering.net wrote:
 So on Fedora tcpwrap is unlikely to go away soon.

Not necessarily. We just decided this morning in the server working
group that we would only include it if base OS insists:

http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-25/fedora-meeting-1.2014-03-25-15.00.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit

[David Timothy Strauss]

Other than for zswap discussions, I spent the whole time on the
storage and file system side. I've filled in the topics that came up
(or I could topically ask about), and I have some good contacts now if
answering any others proves essential.

Outside the file system/MM space, at least one Ganesha developer is
working on a comprehensive credential-setting/caching syscall that
might be useful for systemd's privilege dropping for starting
services. It would set credentials and return an fd that is usable to
rapidly set the same credentials again. He's planning on stuffing the
file descriptors into an LRU cache to both reduce syscalls and
accelerate the application of credentials in the kernel. His work is
focused on FS permissions, but it would make sense for it to be
available for general ones, too.

It may be useful to see if we can use Trinity for kdbus and systemd testing.

On Thu, Feb 27, 2014 at 3:09 PM, Lennart Poettering
lenn...@poettering.net wrote:
 - quota for tmpfs

 - saner autofs elapse logic (no blocking ioctls...)

 - uuids for btrfs subvols

 - a umount (or maybe last-change) timestamp in the btrfs superblock,
   which we can use to initialize the system clock from if a machine
   lacks RTC or has a dead battery. Even better: a unified ioctl() to
   query this from all file systems the same way.

 - fanotify: accessible to unprivileged users

I asked about the state of this given Ganesha's userspace operation. I
don't think there are any changes. Many services using fanotify seem
to require root privileges for other reasons, too.

 - fanotify: events for renames

 - fanotify: pass info about open() flags to monitoring processes

 - fanotify: when getting getting a notification for close, actually
   get information whether the file was changed or not

 - an ioctl-based way to change FAT file system labels

 - cheaper xattrs. currently querying xattrs on most file systems is
   prohibitively slow, since it results in seeks and whatnot. Which has
   the result that pretty nobody uses them. One way to make things better
   would be to maybe expose in some fstat2() call a flag whether there
   even are xattrs, so that apps could check for that flag before
   actually trying to read them

This is being suggested as a readdir+ enhancement for Ganesha's sake.
It would only be a flag that xattrs exist.

 - An API to query the birthtime of files. ext234 actually stores that
   and keeps it up-to-date, but there's no API to get to this data

 - An fsetxattrat() call, so that race-free selinux relabelling can be
   done

 - a way to mark an entire tree of mounts read-only with one call. i.e. a
   working combination of MS_REC|MS_RDONLY

 - Allow creating read-only bind mounts in a single mount() invocation,
   instead of requiring two. Similar, a way to set the propagation
   settings for a mount when one creates it, rather than requiring two
   mount() invocations for that.

 - Swappiness control for individual pages via madvise()

 - volatile ranges

There was a session on this, but I went to Direct I/O instead.

 - A better SIGBUS/SIGSEGV API (for accessing invalidated memory maps),
   that actually works for libraries. i.e. a sane way how libraries can
   register handlers for specific memory regions they maage. Currently
   there can only be one handler for the entire process which makes this
   totally unavailable for libraries, since they'd always step on each
   others toes. Probably hard one to get into the brains of kernel guys,
   since for them that is a userspace problem.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting a socket starts the associated service

[David Timothy Strauss]

It's already reported (by me):
https://bugs.freedesktop.org/show_bug.cgi?id=75185
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-journal-remote

[David Timothy Strauss]

On Sun, Mar 16, 2014 at 11:29 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 Curl requires the whole file to be exported first, which isn't great,
 because it wants to give the content size in the header. I'm note
 sure if it is possible to tell it to not do that.

I'm think you just need to implement your own function to use with
CURLOPT_READFUNCTION and set a chunked encoding header [1] instead of
giving libcurl an actual file to upload. You can return zero when
you're done sending everything you want to send.

[1] http://curl.haxx.se/libcurl/c/post-callback.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Forwarding logs to another systems journal

[David Timothy Strauss]

On Thu, Mar 13, 2014 at 12:54 PM, Anand Neeli anand.ne...@gmail.com wrote:
 I have multiple systems, How do i forward logs from one system running
 systemd-journald to another remote systems journal service, so that all the
 logs are stored on a centralized machine.

 Have went through systemd-journal-gatewayd, but this forwards logs on
 http/https, doesnt send it to another remote systems journal.

 can this be done only using systemd services? without using syslog-ng or any
 other tools?

 can anyone please give more details. If this is already answered then pls
 point me to the mail thread.

You'll really want to use a more sophisticated aggregator than the
journal. We use Kibana [1] with journal2gelf [2].

[1] http://www.elasticsearch.org/overview/kibana/
[2] https://github.com/systemd/journal2gelf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] man: systemd-bootchart - fix spacing in command

[David Timothy Strauss]

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

Re: [systemd-devel] Talks comparing systemd and launchd.

[David Timothy Strauss]

On Mon, Mar 3, 2014 at 5:47 PM, David Farning dfarn...@gmail.com wrote:
 Several of the ground breaking ideas in systemd seem to come directly from
 launchd.

systemd makes no claim to be original or ground-breaking with many of
its ideas. As you mention, some come from launchd. Others come from
Solaris service management. I don't know any presentations off the top
of my head drawing direct comparisons, though.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Talks comparing systemd and launchd.

[David Timothy Strauss]

On Thu, Mar 6, 2014 at 2:57 PM, David Farning dfarn...@gmail.com wrote:
 Now my philosophical sticking point is how big pid1 should be to do
 what it needs to do. Practically, I am trying to understand where
 those boundaries should be and how to communicate that information.

A large amount of systemd's code does not run in PID 1. Are you
referring to systemd's code or PID 1 in particular?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: add startup resource control option

[David Timothy Strauss]

When is startup considered over? I'd like if it meant before the
WantedBy unit was started so this value still has use for arbitrary
startup.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to build systemd with statically linking

[David Timothy Strauss]

On Sat, Mar 1, 2014 at 12:46 AM, 황재영 j-zero.hw...@samsung.com wrote:
 I've tried to build systemd(v43) with statically linking.

That version is ancient. I'm afraid you won't find much help with it
here. Have you tried a newer release?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] statically linking systemd-socket-proxyd

[David Timothy Strauss]

On Thu, Feb 27, 2014 at 12:35 PM, Vincent Batts vba...@redhat.com wrote:
 Can we get a Makefile target for compiling the
 systemd-socket-proxyd as statically linked? For it to be portable for
 any guest container.

I think that would be neat. While I wrote much of that proxy, I'm not
versed well enough on linking and our toolchain to do static linking
work myself. I'd happily review a patch, though.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support

[David Timothy Strauss]

This is a lot of code, and this approach is largely obsoleted by
link-local IPv6 addressing, which also has the benefits of being
simpler, deterministic (at least with RFC 4862), and collision-proof.
Both Apple [1] and Microsoft [2] prefer IPv6 link-local as the best
practice.

Is it really that important to support self-assigned IPv4?

[1] 
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/NetServices/Articles/about.html
[2] 
https://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Topics for the Linux Storage, Filesystem MM Summit

[David Timothy Strauss]

I'll be attending the Linux Storage, Filesystem  MM Summit in March.
Are there any topics germane to systemd I should put on the agenda or
discuss with other folks there?

Things I have in mind so far:

 * Next steps for mount and automount units
 * That's it so far.

I'm mostly attending for my company's FuseDAV/Valhalla work, but I'd
like to effectively represent systemd as well.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] socket-proxyd: resolve addrinfo using sd-resolve

[David Timothy Strauss]

It's not ridiculous, but it's also no better. This patch still blocks
the main event loop during each lookup.

Proper integration of non-blocking lookup would involve using
sd_resolve_get_fd() to integrate with the main event loop.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Docker, Supervisor and systemd

[David Timothy Strauss]

On Thu, Feb 20, 2014 at 2:25 PM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Or is there a reason why systemd should not be used for that?

Distro portability, but that's rapidly dying as a reason.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] It's release time!

[David Timothy Strauss]

The only thing in master I'm still having to patch in production is
the is-enabled code path so it doesn't look up all the symlinks. I
don't see that as a release blocker, though.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] It's release time!

[David Timothy Strauss]

On Wed, Feb 19, 2014 at 10:57 AM, Lennart Poettering
lenn...@poettering.net wrote:
 did you see the changes I made to the cgroup mask propagation bits? I
 reworked some code there to make sure that the mask doesn't keep
 increasing, but actually can lose bits again if cgroup properties are
 unset. Now, as far as I can see I didn't break your scalibility changes,
 but I was wondering if you could give this a test run with your huge
 number of units setup?

I actually hadn't noticed them yet. I looked at them just now, and it
seems like the running time should be identical if controllers don't
get removed (and longer but actually correct if they do).

I'll test out master on a VM to ensure there's no major performance
regression. There's nothing complicated happening in our production
environment with cgroups and parents that I can't replicate on a test
machine.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] It's release time!

[David Timothy Strauss]

On Wed, Feb 19, 2014 at 10:57 AM, Lennart Poettering
lenn...@poettering.net wrote:
 Now, as far as I can see I didn't break your scalibility changes,
 but I was wondering if you could give this a test run with your huge
 number of units setup?

With 4000 units (2000 sockets and 2000 corresponding services with
CPUShares= enabled), Fedora 20 boots fine on master. Fedora 20's
normal systemd v208 *does not* boot fine with that number of units,
especially with controllers in use.

I'm 99% sure your changes don't introduce any performance regression.
And, based on my reading of the changes, I'm 100% sure that any
regression we might find later would be solvable with a simple,
backportable patch.

In an unrelated note, I'm not sure if we can fix the Failed to get
D-Bus connection: Failed to connect to socket /run/systemd/private: No
such file or directory stuff or make it less noisy. IIRC, that goes
away with kdbus, but it will be a while before that's in general use.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614

[David Timothy Strauss]

On Wed, Feb 12, 2014 at 12:37 PM, Tomasz Torcz to...@pipebreaker.pl wrote:
 That's some downstream distro bug.  And this is Fedora mailinglist.
 RHEL issues are offtopic here.

This is not a Fedora mailing list at all.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/3] Add SELinuxContext configuration item

[David Timothy Strauss]

In order to maximize consistency with newly committed options in
systemd-nspawn, would it make sense to allow independent configuration
of the process and file labels instead?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Use normal English elide in place of ellipsize

[David Timothy Strauss]

Elided sees widespread use in the kernel and libc for locks:
http://lwn.net/Articles/534758/

They're not referring to adding ellipses, though. They're talking
about just removing locks. In that sense, elide and ellipsize are
not synonyms.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/1] Add SELinux support to systemd-nspawn

[David Timothy Strauss]

On Tue, Feb 4, 2014 at 5:22 AM, Lennart Poettering
lenn...@poettering.net wrote:
 processlabel

The actual code processes this option as label. I'll fix all of this
up (including the asprintf) and then commit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/1] Add SELinux support to systemd-nspawn

[David Timothy Strauss]

Pushed with the following changes:
 * Lennart's suggestions for option names.
 * Lennart's other suggestion for no asprintf() in the options
processing. Moved the concatenation to strjoin() on use.
 * Removed redundant trailing NULL in the arguments to strjoin().
 * Removed invalid option -s from the example command.
 * Added OOM check following the strjoin() into options.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/1] Add SELinux support to systemd-nspawn

[David Timothy Strauss]

We would find this extremely useful. Our #1 long-term feature need is
a containerization tool that supports both socket activation and
selinux. libvirt-lxc has the former, but I'm seeing inconsistent
documentation on the latter. I'd be glad to see systemd-nspawn get
good support.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix a typo

[David Timothy Strauss]

On Sun, Feb 2, 2014 at 8:55 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 I'm not certain if the current version is gramatically correct, but
 the proposed version seems wrong: there's just one sender, so only
 singular form makes sense.

The current text makes more sense to me.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/1] Allow systemd to run without assigning container to machine.slice

[David Timothy Strauss]

This seems applicable to what I'm working on (SaaS/PaaS company), but
I'm not sure I understand the distinction in capability this change
makes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Drop Before=paths/sockets/timers.target from DefaultDependencies.

[David Timothy Strauss]

On Wed, Jan 29, 2014 at 3:14 AM, Lennart Poettering
lenn...@poettering.net wrote:
 What's the rationale here?

Three possibilities for an *enabled* timer with DefaultDependencies=true:
 (1) WantedBy=timers.target, which redundantly adds
Before=timers.target (because DefaultDependencies already adds it)
 (2) WantedBy= and After=something-later-than-timers.target (like
multi-user.target), which creates a cycle systemd has to break (like
Before=timers.target combined with After=multi-user.target). This is
our use case, which we have because we want a timer to start at
multi-user.target completing.
 (3) WantedBy=something-earlier-than-timers.target (like
sysinit.target), which is transitively redundant because
Before=basic.target is already before timers.target

So, having Before=timers.target as a default dependency is either
redundant or cyclical/conflicting. These same arguments are true for
sockets and (probably) paths.

 Documenting what DEfaultDependencies= does is something that has been on
 the todo list since a long time, we really should document this.

Yes, and documentation is an alternative that I mentioned to the patch.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What do I need to do to force systemd to create folders in the cgroups tree?

[David Timothy Strauss]

You're using both onelan-player.slice and onelan-players.slice in your
example. Correct this first.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Drop Before=paths/sockets/timers.target from DefaultDependencies.

[David Timothy Strauss]

Alternatively, we should update the man pages to reflect what the
DefaultDependencies= option affects.

Zbyszek's argument for the patch, however, is that following the
recommended WantedBy= behavior already applies the same Before=
dependency, and anyone doing otherwise ought not to be subjected to a
possibly circular Before= dependency.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .socket in a network namespace

[David Timothy Strauss]

Has anyone looked at using socketat() for this? It's unclear whether
that syscall actually exists in any supported form; it's certainly not
documented.

[1] http://lwn.net/Articles/407495/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel