Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation

[josh]

On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote:
> 2015-03-05 11:58 GMT+01:00  :
> > From: Harald Hoyer 
> >
> > The speedup is significant
> >
> > Original libtool
> > $ ccache -C && make clean && time make -j4
> > […]
> > real6m4.104s
> > user13m49.234s
> > sys7m37.864s
> >
> > Original libtool + dolt
> > $ ccache -C && make clean && time make -j4
> > […]
> > real2m24.869s
> > user7m30.198s
> > sys1m17.813s
> 
> Hm, the speedup is nowhere near as significant here:
> without dolt (make):
> real 4m2.749s
> user 3m9.304s
> sys 0m19.032s
> 
> with dolt (make):
> real 3m33.756s
> user 2m59.476s
> sys 0m17.632s
> 
> without dolt (make -j6):
> real 1m42.001s
> user 5m3.680s
> sys 0m26.608s
> 
> with dolt (make -j6)
> real 1m35.267s
> user 4m50.956s
> sys 0m24.724s
> 
> 
> libtool version is 2.4.2.

That's more what I'd expect with current versions of libtool, which has
supposedly fixed many of the issues that motivated the creation of dolt
in the first place.

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

Re: [systemd-devel] [PATCH] use dolt.m4 to speedup compilation

[josh]

On Thu, Mar 05, 2015 at 10:33:19PM -0300, Lucas De Marchi wrote:
> On Thu, Mar 5, 2015 at 9:58 PM,   wrote:
> > On Fri, Mar 06, 2015 at 12:55:38AM +0100, Michael Biebl wrote:
> >> 2015-03-05 11:58 GMT+01:00  :
> >> > From: Harald Hoyer 
> >> >
> >> > The speedup is significant
> >> >
> >> > Original libtool
> >> > $ ccache -C && make clean && time make -j4
> >> > […]
> >> > real6m4.104s
> >> > user13m49.234s
> >> > sys7m37.864s
> >> >
> >> > Original libtool + dolt
> >> > $ ccache -C && make clean && time make -j4
> >> > […]
> >> > real2m24.869s
> >> > user7m30.198s
> >> > sys1m17.813s
> >>
> >> Hm, the speedup is nowhere near as significant here:
> >> without dolt (make):
> >> real 4m2.749s
> >> user 3m9.304s
> >> sys 0m19.032s
> >>
> >> with dolt (make):
> >> real 3m33.756s
> >> user 2m59.476s
> >> sys 0m17.632s
> >>
> >> without dolt (make -j6):
> >> real 1m42.001s
> >> user 5m3.680s
> >> sys 0m26.608s
> >>
> >> with dolt (make -j6)
> >> real 1m35.267s
> >> user 4m50.956s
> >> sys 0m24.724s
> >>
> >>
> >> libtool version is 2.4.2.
> >
> > That's more what I'd expect with current versions of libtool, which has
> > supposedly fixed many of the issues that motivated the creation of dolt
> > in the first place.
> 
> Maybe it was a regression in libtool from 2.4.2 <-> 2.4.5?  I have 2.4.5 here:
> 
> make -j6, libtool
> real4m53.924s
> user11m4.323s
> sys 0m54.880s
> 
> make -j6, dolt
> real1m58.653s
> user6m20.523s
> sys 0m28.920s

Interesting.  How easily can you try 2.4.2?

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

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[josh]

On Fri, Apr 17, 2015 at 06:00:04PM +0200, David Herrmann wrote:
> Hi
> 
> On Fri, Apr 17, 2015 at 5:52 PM, Josh Triplett  wrote:
> > On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
> >> Now, to put together a more complex scenario for you: consider a small
> >> web UI that can be used to set the system time. It should realy run at
> >> minimal privileges, after all it has a surface to the web. Hence you
> >> write it as daemon, make it run as a user id of its own, set up a
> >> chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
> >> a bus connection open. With that setup the web daemon can pretty much
> >> only set the system clock, and if it exploited cannot be used for much
> >> else. It will not have access to /dev/rtc, due to the file system
> >> namespace, but it can nicely set the system clock via timedated still,
> >> and pretty much only that, and the clock will be synced to the RTC by
> >> it.
> >>
> >> To map this back to your earlier request for an example. In this case
> >> process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
> >> C is the SetTime() bus call. Daemon D is timedated.
> >>
> >> If the web UI daemon would not have CAP_SYS_TIME it couldn't change
> >> the time like this -- unless of course that web UI daemon would run as
> >> UID 0 all the time, which is certainly much much less desirable, given
> >> that it is a network facing daemon.
> >
> > I agree with your statement that any process with the ability to do an
> > operation directly (bypassing systemd) should have the ability to do so
> > safely through systemd.  However, that doesn't provide a complete
> > solution, because the reverse shouldn't necessarily be true: it should
> > be possible to grant a process the ability to do an operation safely
> > through systemd *without* granting it permission to do so directly.
> >
> > For instance, a user's desktop session should have permission to shut
> > down the system politely by asking systemd to shut down, without having
> > permission to shut down the system impolitely by invoking the reboot
> > system call.  Or in your time service example, the admin may want to
> > grant the web service permission to set the clock via timedated, but
> > *not* directly via settimeofday.
> >
> > (I'm assuming below that you agree there should be a mechanism to offer
> > privileges to do a safe operation but *not* the corresponding unsafe
> > operation.  If you don't agree, let's talk about that first.)
> >
> > Given that, some mechanism needs to exist to grant the
> > safe-but-not-unsafe permissions.  That might be polkit, or something
> > like dbus bus policies, or some other mechanism.
> 
> This is _exactly_ what we do whenever it's a reasonable choice.

Glad to hear that.  With that mechanism in place, then, is the
capability-based check really necessary?  It's a nice convenience, that
avoids needing to explicitly use the new mechanism to grant permission
to an already privileged process, but it doesn't seem necessary.

Would it be that much of an imposition to push kdbus without capability
capturing first, and then argue for kdbus with capability capturing
later as a convenience feature?  As far as I can tell, that mechanism
can be added in a backward-compatible way, with older kernels just not
supporting it.

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

Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

[josh]

On Mon, Oct 20, 2014 at 07:44:19PM +0200, Lennart Poettering wrote:
> On Fri, 17.10.14 06:29, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > This makes it possible to drop in logind configuration snippets from a
> > package or other configuration management mechanism.
> > 
> > Introduce a new helper, conf_parse_many, to parse configuration files in
> > a search path.
> > 
> > systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
> > rather than /etc/systemd/logind.conf .  Distributions should migrate
> > existing modified versions of /etc/systemd/logind.conf to
> > /etc/systemd/logind.conf.d/50-default.conf .
> > 
> > Move the logind.conf manpage to logind.conf.d, update it to document the
> > search paths, and update all references to it.
> 
> Humm
> 
> I'd really prefer if we'd keep things in logind.conf and just provide
> the option of using logind.conf.d. This would be similar to unit
> files, where the unit files are where the beef is and .d/ is just a
> way to override/extend is. THe man page of logind.conf should
> reference the ability that .d/ files are supported, but that should be
> it for the documentation. We should really try to not to be too
> surprising here for admins which tend to expect one configuration
> file, not many.

The main awkwardness there is that /etc/logind.conf, as a file in /etc,
should be parsed *after* /usr/lib/systemd/logind.conf.d/ and *before*
/etc/systemd/logind.conf.d/ , which breaks the usual logic to load all
files in order with files in /etc overriding files in /usr.

Suggestions?

> Also, I'd really prefer if we could do the same for all configuration
> files in /etc/systemd/*.conf, not just for logind.conf...

I'd be happy to, but I wanted to sort out the pattern before expanding
it to other cases.

> An additional idea might be to document in the main config files as a
> comment that extensions may be placed in the .d/ subdirs, to make this
> functionality more discoverable?

Yeah, if we keep logind.conf then it makes sense to document the .d/
variant there.

> > For systemd, are "git format-patch -M" patches (with git-style renames
> > rather than whole-file deletion/insertions) acceptable for mailing list
> > review?  That format makes renames much easier to review.
> 
> Sure!

Glad to hear that.

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

Re: [systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

[josh]

On Wed, Mar 12, 2014 at 04:44:55PM +0100, Lennart Poettering wrote:
> On Tue, 11.03.14 21:16, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > Some systems turn the backlight all the way off at the lowest levels.
> > Clamp saved brightness to at least 1 or 5% of max_brightness.  This
> > avoids preserving an unreadably dim screen, which would otherwise force
> > the user to disable state restoration.
> 
> Applied, made a minor change though: I downgrade the warning message to
> debug, since this isn' really something to warn about..

If you mean the message "Saved brightness %s too low; increasing to %s",
I think that one needs to be visible to users.  It shouldn't normally
happen, and if it does, the user should know why the saved brightness
wasn't preserved.

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

Re: [systemd-devel] logind.conf.d?

[josh]

On Tue, May 20, 2014 at 07:12:02PM +0200, Lennart Poettering wrote:
> On Fri, 16.05.14 12:58, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > I'd like to add support for /etc/systemd/logind.conf.d, parsed after
> > /etc/systemd/logind.conf.  My specific use case: I'd like to be able to
> > create a simple configuration package I can install on my systems that
> > changes the logind configuration by dropping in a snippet, rather than
> > hand-editing logind.conf.
> > 
> > Does that sound like a reasonable addition?  Happy to write the patch if
> > so.
> 
> Hum, so I must say that I am not enthusiastic about the idea, but I do
> see your usecase, and I can't come up with a reason to reject such a
> patch...
> 
> Hence, go ahead, I'll merge a good patch for it.

Thanks; will do.

> Please try to add this generically to conf-parser.c, but make it
> optional, so that can disable this for example for unit files, where we
> actually want to keep track of the drop-ins (and already do that) and
> thus wouldnt use the generic version anyway... Or in other words, if we
> add this for logind, we need to add it for journald, timesyncd,
> ... too...

As far as I can tell, systemd already has a standard idiom for parsing
configuration .d directories: call conf_files_list_nulstr (if you have
multiple directories) or conf_files_list/conf_files_list_strv (if you
just have one), and loop over the resulting configuration files.  I'd
intended to make logind do the same thing, in manager_parse_config_file,
changing the single parse call to a simple loop.  I'd expect the code
patch to be extremely short, and the documentation patch to be larger
than the code.

Are you looking for a generic function similar to config_parse, such as
config_parse_many, which combines a call to conf_files_list_* and a loop
calling config_parse on each result?

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

Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]

[josh]

On Tue, Jul 08, 2014 at 10:45:11PM +, "Jóhann B. Guðmundsson" wrote:
> 
> On 07/08/2014 10:45 PM, Josh Triplett wrote:
> >[Responding to this version because the latest thread hasn't appeared in
> >the mbox archives yet.  The comments apply equally well to the latest
> >version, "Add DEPLOYMENT to hostnamectl".]
> >
> >On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
> >>+static bool valid_environment(const char *environment) {
> >>+
> >>+assert(environment);
> >>+
> >>+return nulstr_contains(
> >>+"development\0"
> >>+"staging\0"
> >>+"production\0",
> >>+environment);
> >>+}
> >Can we please *not* attempt to limit or "standardize" this particular
> >set of machine roles?  As already demonstrated in the previous thread,
> >people have all sorts of staged deployment strategies.  Furthermore,
> >the concept of a machine role shouldn't be limited to service deployment
> >strategies.
> >
> 
> Roles != the environment they run in.

I'm not trying to bikeshed over the naming of the variable itself.  I'm
arguing that standardizing this particular bit of metadata won't work
well when so many different deployment strategies exist.  Thus, rather
than having a fixed set of keywords, I'd propose simply saying "this
contains keywords", and leaving the specific keywords up to the admin.
If you attempt to standardize production/development/staging, you'll
either end up with a model that only works for a small subset of
deployments, or you'll end up adding twelve more keywords, at which
point you might as well have just said "use whatever keyword you like".

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

Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

[Josh Triplett]

Lennart Poettering wrote:
> And noexec doesn't really make much sense for these dirs, as this
> blocks mmap() with MAP_EXEC and there are plenty apps that want to use
> that. Moreover "noexec" is at best a protection against accidental
> execution and not a security mechanism since it is trivially easy to
> circumvent (just call the interpreter directly with the file to
> execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 
> $BINARY")

That workaround doesn't actually work anymore; the former (blocking mmap
with MAP_EXEC) exists specifically to protect against the latter
(running the interpreter directly).

$ mount | grep '/run '
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=1620848k,mode=755)
$ sudo cp -a /bin/ls /run/ls
$ /run/ls
bash: /run/ls: Permission denied
(126) $ /lib64/ld-linux-x86-64.so.2 /run/ls
/run/ls: error while loading shared libraries: /run/ls: failed to map segment 
from shared object
(127) $

It's theoretically possible to work around *that* if you have permission
to run arbitrary code and to remap memory from write to execute (both of
which might also be locked down). But even without that, mount -o noexec
does meaningfully improve security, and the trivial workaround no longer
works.

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

[systemd-devel] ~/.local/bin , XDG, and environment variable overrides

[Josh Triplett]

systemd's file-hierarchy manpage
<https://www.freedesktop.org/software/systemd/man/file-hierarchy.html>
documents ~/.local/bin as the place under $HOME to install executables
in $PATH, and quite a bit of software has adopted that. However, unlike
the directories specified in the XDG Base Directory specification, this
doesn't include an environment variable (like $XDG_DATA_HOME for
~/.local/share) to override it. I've seen a proposal to use
$XDG_BIN_HOME for that. Might it make sense to include that, and start
getting software to adopt it?

Also, would it make sense to add ~/.local/bin to the XDG Base Directory
specification itself? I'd be happy to write up an addition to the spec
for that, and propose it on the appropriate list.

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

Re: [systemd-devel] ~/.local/bin , XDG, and environment variable overrides

[Josh Triplett]

On Tue, Aug 29, 2017 at 06:43:58PM +0200, Lennart Poettering wrote:
> On Sa, 26.08.17 10:43, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > systemd's file-hierarchy manpage
> > <https://www.freedesktop.org/software/systemd/man/file-hierarchy.html>
> > documents ~/.local/bin as the place under $HOME to install executables
> > in $PATH, and quite a bit of software has adopted that. However, unlike
> > the directories specified in the XDG Base Directory specification, this
> > doesn't include an environment variable (like $XDG_DATA_HOME for
> > ~/.local/share) to override it. I've seen a proposal to use
> > $XDG_BIN_HOME for that. Might it make sense to include that, and start
> > getting software to adopt it?
> 
> Quite frankly, I am not sure that having env vars for all those dirs
> was a good idea in the first place, but sure, if you want to
> standardize that, please go ahead, you have my support. A patch to the
> XDG basedir spec should be very welcome.

Developers on some platforms (e.g. Haiku) wanted the ability to set
those paths. This came up in the context of installing Rust binaries,
which didn't want to hardcode ~/.local/bin , and using something like
$XDG_DATA_HOME/../bin seems quite wrong as well.

> But do not the architecture issues with such a dir, i.e. home
> directories might be shared between systems of different archs, and
> binary programs compiled for one arch and placed in these dirs are
> unlikely to work on the other. I figure this is the reason why this
> concept was never included in XDG basedir spec, but then again I think
> it's fine to still add it as long as the issue is highlighted.

The second version of the patch from Johannes Löthberg seems to address
that.

I also suspect that $XDG_BIN_HOME might actually help folks who want to
deal with that issue, by setting it to a multiarch-style directory that
includes the architecture triple.  (Though that would also imply
installing architecture-independent scripts multiple times; however, I
don't think it's worth trying to define an elaborate scheme to handle
that, not when things like /usr/local/bin and /usr/bin *don't*. We're
not trying to solve that new and rare problem here; we're trying to
document the defacto standard that already exists.)

> > Also, would it make sense to add ~/.local/bin to the XDG Base Directory
> > specification itself? I'd be happy to write up an addition to the spec
> > for that, and propose it on the appropriate list.
> 
> If you add the env var then it should be added to the xdg basedir spec.

See the patches from Johannes Löthberg on the XDG list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] running systemd in a cgroup: future compatibility

[Josh Snyder]

Hi all,

I'm working on a use-case where I want to impose memory limits on the system in
aggregate, with one process (e.g. memcached) opted-out of the limit. With a
typical distribution's setup (Ubuntu, in my case), I would be able to impose a
memory limit on each systemd slice (viz. user, machine, system) separately, but
not in aggregate.

I've found a solution for this by launching systemd in a cgroup of its own. In
the initramfs, I have a script (snippet included below) which mounts the
cgroupfs, puts all of the extant processes into a new cgroup, and then umounts
the cgroupfs.

This works for my needs: all of the processes in the system live in one cgroup,
except memcached in a separate cgroup. systemd seems perfectly happy to boot in
this configuration, correctly sensing that it's operating in a cgroup and
nesting the processes it is responsible for under the existing cgroup. With
memcached running separately, the resulting hierarchy looks like:

/sys/fs/cgroup/
├── memcached
└── root
├── init.scope
├── system.slice
...

And /proc/1/cgroup shows that the systemd (and more importantly, its
descendants) lives in the memory cgroup:

11:net_cls,net_prio:/
10:cpuset:/
9:freezer:/
8:hugetlb:/
7:perf_event:/
6:pids:/root/init.scope
5:devices:/root/init.scope
4:cpu,cpuacct:/
3:blkio:/
2:memory:/root
1:name=systemd:/root/init.scope

I've tested against both legacy and unified cgroup hierarchies. The
functionality to detect the current cgroups and nest processes underneath them
appears to be in manager_setup_cgroup (src/core/cgroup.c:2033). My question for
the list is what motivated adding this awesome feature to systemd in the first
place, and (more importantly to me) is it likely to continue to exist in the
future?

Josh

---
#!/bin/sh

move_tasks()
{
  cd "${MOUNTPOINT}"
  mkdir root
  exec 3< "${CGROUP_FILE}"
  set +e
  while read task; do
  echo $task > "root/${CGROUP_FILE}" 2>/dev/null
  done <&3
  exec 3<&-
  set -e
  cd /
  umount "${MOUNTPOINT}"

}

MOUNTPOINT=/sys/fs/cgroup
CGROUP_FILE=tasks
mount -t cgroup -o none,name=systemd none "${MOUNTPOINT}"
move_tasks

mount -t cgroup -o memory none "${MOUNTPOINT}"
cd "${MOUNTPOINT}"
echo 1 > memory.use_hierarchy
move_tasks

mount -t cgroup2 none "${MOUNTPOINT}"
CGROUP_FILE=cgroup.procs
move_tasks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] running systemd in a cgroup: future compatibility

[Josh Snyder]

On Wed, Feb 14, 2018 at 1:38 AM, Lennart Poettering
 wrote:
>
> That all said, I think we should really try to make systemd work with
> your usecase directly and natively, i.e. add enough flexibility to
> systemd so that you don't have to wrap it in such a "foreign" prefix
> cgroup to do what you want... For example, if PID 1 knew a
> "DefaultSlice=" option in /etc/systemd/system.conf, and
> logind/machined knew similar options in their respective configuration
> files you could do what you are trying to do without leaving systemd
> territory relatively easily. Just set those options to some slice
> further down thre tree, and you could leave machined run inside of
> systemd just fine without having to arrange anything outside of it...

If the feature you describe existed, I'd throw away my initramfs script in a
heartbeat.

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

[systemd-devel] Robust getpid caching via MADV_WIPEONFORK?

[Josh Triplett]

[Bcced to other potentially interested folks.]

As discussed in various places, glibc removed the getpid() cache in
2.25, since it was not robust against all possible ways to fork a
process.

Linux 4.14 added MADV_WIPEONFORK, which robustly ensures that a page
gets wiped to zero on any possible process fork. The commit message
adding it even mentions, as a use case:
>  - systemd/pulseaudio API checks (fail after fork) (replacing a getpid
>check, which is too slow without a PID cache)

Given that, I wanted to start a thread about the idea of making
getpid() caching, and for that matter other potential uses of
pthread_atfork(), robust using MADV_WIPEONFORK when available.

I don't necessarily want to advocate this; rather, since it seems likely
that other applications may wish to do things like this, I wanted to
collect some information and discuss whether it makes sense or not.

I wrote a simple test program, attached (warning: quick hack), that
benchmarks the stock getpid() versus a trivial cached version of
getpid() using MADV_WIPEONFORK (marked as "noinline" to simulate
providing it as a library function), just to get a rough idea.  This
produced the following numbers on my system:

mmap: 3292.00 ns
madvise: 3273.00 ns
uncached getpid: 1 calls in 4569540458.000 ns;  45.695 ns/call
  cached getpid: 1 calls in  132862952.000 ns;   1.329 ns/call

That's a significant speedup per call, but that savings only pays off if
the program calls getpid() more than ~150 times, or ~75 times if the
separate mmap can be avoided.

Given that, I don't think it makes sense for glibc to take this approach
in the standard getpid().  For any program that doesn't call getpid()
extensively, this seems like a pessimization, and many such programs can
do such caching themselves without worrying about an unexpected fork().
I think only specialized library code would ever want to do this.

Hopefully these numbers will help anyone looking to implement such
caching in their own code.

- Josh Triplett
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef MADV_WIPEONFORK
#define MADV_WIPEONFORK 18
#endif

static pid_t *cached_getpid_page;

__attribute__((noinline))
static pid_t cached_getpid(void)
{
pid_t pid = *cached_getpid_page;
if (!pid)
*cached_getpid_page = pid = getpid();
return pid;
}

static struct timespec get_time(void)
{
struct timespec t;
if (clock_gettime(CLOCK_MONOTONIC_RAW, &t) < 0)
err(1, "clock_gettime");
return t;
}

static double to_nsec(struct timespec t)
{
return t.tv_sec * 10 + t.tv_nsec;
if (clock_gettime(CLOCK_MONOTONIC_RAW, &t) < 0)
err(1, "clock_gettime");
printf("%llu.%09lu\n", (unsigned long long)t.tv_sec, t.tv_nsec);
}

static const int ITERATIONS = 1;

int main(void)
{
struct timespec start, end;
double duration;

start = get_time();

void *page = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (page == MAP_FAILED)
err(1, "mmap");

end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("mmap: %f ns\n", duration);

start = get_time();

if (madvise(page, 4096, MADV_WIPEONFORK) < 0)
err(1, "madvise");
cached_getpid_page = page;

end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("madvise: %f ns\n", duration);

start = get_time();
for (int i = 0; i < ITERATIONS; i++)
getpid();
end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("uncached getpid: %d calls in %14.3f ns; %7.3f ns/call\n", ITERATIONS, duration, duration/ITERATIONS);

start = get_time();
for (int i = 0; i < ITERATIONS; i++)
cached_getpid();
end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("  cached getpid: %d calls in %14.3f ns; %7.3f ns/call\n", ITERATIONS, duration, duration/ITERATIONS);

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

Re: [systemd-devel] Monitor path to commit to git

[Josh Triplett]

Lennart Poettering wrote:
> inotify doesn't really provide such a feature, and fanotify is
> crap.

Leaving aside any other issues with fanotify, it doesn't seem to provide
this feature either; "man fanotify" says "Fanotify monitoring of
directories is not recursive: to monitor subdirectories under a
directory, additional marks must be created."

That aside, though, can you elaborate on other issues with fanotify?
(Or, do you have or know of something already written on that topic that
you could point to?)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random

[Josh Triplett]

On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote:
> On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org) 
> wrote:
> 
> > Using /dev/urandom as a key is valid for swap, do not
> > warn if this devices are world readable.
> > ---
> >  src/cryptsetup/cryptsetup.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
> > index e6b37ac..38930ae 100644
> > --- a/src/cryptsetup/cryptsetup.c
> > +++ b/src/cryptsetup/cryptsetup.c
> > @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
> >  
> >  /* Ideally we'd do this on the open fd, but since 
> > this is just a
> >   * warning it's OK to do this in two steps. */
> > -if (stat(key_file, &st) >= 0 && (st.st_mode & 
> > 0005))
> > -log_warning("Key file %s is 
> > world-readable. This is not a good idea!", key_file);
> > +if (stat(key_file, &st) >= 0 && (st.st_mode & 
> > 0005)) {
> > +if(!STR_IN_SET(key_file, "/dev/urandom", 
> > "/dev/random", "/dev/hw_random"))
> > +log_warning("Key file %s is 
> > world-readable. This is not a good idea!", key_file);
> > +}
> 
> I'd prefer if we'd change the check instead to only apply to
> S_ISREG() files. This way we wouldn't have to list all RNG device
> nodes.

With the exception of /dev/*random, you don't want a world-readable
device used for a key either.  Some people have setups that use a USB
device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that
case, the file should *not* be world-readable.

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

Re: [systemd-devel] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)

[Josh Triplett]

Lennart Poettering wrote:
> Hmm, so, I thought a lot about this in the past weeks. I think the way
> I'd really like to see this work in the end is that we never have to
> persist the UID mappings. This could work if the kernel would provide
> us with the ability to bind mount a file system into the container
> applying a fixed UID shift. That way, the shifted UIDs would never hit
> the actual disk, and hence we wouldn't have to persist their mappings.

It ought to be possible to run an arbitrary distribution inside a
container, even a distribution that itself wants to run sandboxed
applications in containers.  Nesting matters, so a bare shift may not
suffice.  On the other hand, a shift is the simplest solution for simple
utility containers, such as those launched by systemd-nspawn.  nspawn
could trivially avoid persisting the UID map by applying a shift, while
a full container solution might want to construct persistent dynamic UID
maps, or integrate with special PAM/NSS modules, or any number of other
creative solutions.

Container UID handling was exactly what I had in mind when I sent in a
kernel patch for the setusers() system call.  If an unprivileged user on
the host system can have a pile of UIDs handed to them by the host
system, and can use any of those IDs in their UID map, then they can set
up any arbitrary container UID handling without further assistance from
host root.  A PAM module on the host could then, by policy, hand some or
all unprivileged users a substantial stack of host UIDs that they can
arbitrarily map to container UIDs; together with support for applying
UID maps to a mounted filesystem, that would provide all the necessary
kernel support.

In addition to containers, that would also provide a sensible solution
for a smarter fakeroot-style tool that lets a user construct filesystems
with slightly more complicated policies than "root owns everything",
again without any help from host root other than "here, have a pile of
subordinate UIDs".

I'd be happy to revisit kernel setusers() support if anyone would be
interested in saying "yes, this is the solution we want".

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

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Josh Triplett]

On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
> Now, to put together a more complex scenario for you: consider a small
> web UI that can be used to set the system time. It should realy run at
> minimal privileges, after all it has a surface to the web. Hence you
> write it as daemon, make it run as a user id of its own, set up a
> chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
> a bus connection open. With that setup the web daemon can pretty much
> only set the system clock, and if it exploited cannot be used for much
> else. It will not have access to /dev/rtc, due to the file system
> namespace, but it can nicely set the system clock via timedated still,
> and pretty much only that, and the clock will be synced to the RTC by
> it.
> 
> To map this back to your earlier request for an example. In this case
> process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
> C is the SetTime() bus call. Daemon D is timedated. 
> 
> If the web UI daemon would not have CAP_SYS_TIME it couldn't change
> the time like this -- unless of course that web UI daemon would run as
> UID 0 all the time, which is certainly much much less desirable, given
> that it is a network facing daemon.

I agree with your statement that any process with the ability to do an
operation directly (bypassing systemd) should have the ability to do so
safely through systemd.  However, that doesn't provide a complete
solution, because the reverse shouldn't necessarily be true: it should
be possible to grant a process the ability to do an operation safely
through systemd *without* granting it permission to do so directly.

For instance, a user's desktop session should have permission to shut
down the system politely by asking systemd to shut down, without having
permission to shut down the system impolitely by invoking the reboot
system call.  Or in your time service example, the admin may want to
grant the web service permission to set the clock via timedated, but
*not* directly via settimeofday.

(I'm assuming below that you agree there should be a mechanism to offer
privileges to do a safe operation but *not* the corresponding unsafe
operation.  If you don't agree, let's talk about that first.)

Given that, some mechanism needs to exist to grant the
safe-but-not-unsafe permissions.  That might be polkit, or something
like dbus bus policies, or some other mechanism.

Now, I can still see the value in saying "if you have permission to do
the unsafe thing directly, you can do the safe thing".  However, that
seems like an optional enhancement, rather than core required
functionality to make sane use of (k)dbus.  kdbus without the
capability-passing mechanism still seems like a wildly useful
enhancement.

Based on that, I'm wondering if there's any fundamental reason not to
split that out as a separate patch, get the remaining less-controversial
parts of kdbus merged, and then make the case for that separately.  Then
kdbus would be available for everyone to use sooner, and later on it
could gain some additional features.

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

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Josh Triplett]

On April 20, 2015 8:39:33 AM PDT, Lennart Poettering  
wrote:
>On Fri, 17.04.15 08:52, Josh Triplett (j...@joshtriplett.org) wrote:
>
>> On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
>> > Now, to put together a more complex scenario for you: consider a
>small
>> > web UI that can be used to set the system time. It should realy run
>at
>> > minimal privileges, after all it has a surface to the web. Hence
>you
>> > write it as daemon, make it run as a user id of its own, set up a
>> > chroot() or a file system namespace, but you do keep CAP_SYS_TIME
>and
>> > a bus connection open. With that setup the web daemon can pretty
>much
>> > only set the system clock, and if it exploited cannot be used for
>much
>> > else. It will not have access to /dev/rtc, due to the file system
>> > namespace, but it can nicely set the system clock via timedated
>still,
>> > and pretty much only that, and the clock will be synced to the RTC
>by
>> > it.
>> > 
>> > To map this back to your earlier request for an example. In this
>case
>> > process A is the web UI daemon. Capability B is CAP_SYS_TIME.
>Message
>> > C is the SetTime() bus call. Daemon D is timedated. 
>> > 
>> > If the web UI daemon would not have CAP_SYS_TIME it couldn't change
>> > the time like this -- unless of course that web UI daemon would run
>as
>> > UID 0 all the time, which is certainly much much less desirable,
>given
>> > that it is a network facing daemon.
>> 
>> I agree with your statement that any process with the ability to do
>an
>> operation directly (bypassing systemd) should have the ability to do
>so
>> safely through systemd.  However, that doesn't provide a complete
>> solution, because the reverse shouldn't necessarily be true: it
>should
>> be possible to grant a process the ability to do an operation safely
>> through systemd *without* granting it permission to do so directly.
>
>yeah, for that side we have polkit.
>
>> Now, I can still see the value in saying "if you have permission to
>do
>> the unsafe thing directly, you can do the safe thing".  However, that
>> seems like an optional enhancement, rather than core required
>> functionality to make sane use of (k)dbus.  kdbus without the
>> capability-passing mechanism still seems like a wildly useful
>> enhancement.
>
>Well, sure, I mean, the caps stuff are *not* essential to kdbus' mode
>of operation. But I do believe they make the system better, and should
>be used preferably over broad uid == 0 checks.

I'd certainly agree that uid 0 checks are a bad idea, since as little code 
should run as root as possible. However, rather than handing out capabilities 
that allow bypassing systemd and talking directly to the kernel, it seems 
preferable to run unprivileged and grant the necessary permissions to that 
process.


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

[systemd-devel] [PATCH] TODO: add molly-guard functionality

[Josh Triplett]

Rather than requiring a third-party tool for this, systemctl should
handle this natively.
---
 TODO | 1 +
 1 file changed, 1 insertion(+)

diff --git a/TODO b/TODO
index 0fcd3a0..aaf6444 100644
--- a/TODO
+++ b/TODO
@@ -441,6 +441,7 @@ Features:
   - Something is wrong with symlink handling of "autovt@.service" in 
"systemctl list-unit-files"
   - better error message if you run systemctl without systemd running
   - systemctl status output should should include list of triggering units and 
their status
+  - add molly-guard functionality: prompt for hostname if interactively 
shutting down a remote system (running as child of ssh)
 
 * unit install:
   - "systemctl mask" should find all names by which a unit is accessible
-- 
2.1.0

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

Re: [systemd-devel] [PATCH] TODO: add molly-guard functionality

[Josh Triplett]

On Mon, Aug 25, 2014 at 07:19:47PM +0200, Lennart Poettering wrote:
> On Sat, 23.08.14 19:26, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > Rather than requiring a third-party tool for this, systemctl should
> > handle this natively.
> 
> This has been proposed before, but I sounds awfully random to me to have
> in systemd. I am pretty sure this should be an add-on, but not
> something we should support out-of-the-box.

I wouldn't argue that it's something we should *enable* by default, just
something to have available and enableable (perhaps via system.conf).

Related to that, would you be willing to take patches for separate tiny
binaries for shutdown/poweroff/etc, so that they don't depend on argv[0]
to decide what to do?  That would make it easier to do things like
diverting /sbin/poweroff to /sbin/poweroff.real and putting a wrapper in
/sbin/poweroff.

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

[systemd-devel] systemd-resolved, multi-home DNS resolution, VPNs, and privacy

[Josh Triplett]

The documentation for systemd-resolved says it sends DNS queries on all
interfaces.  That seems like a bug for privacy and security reasons: I
don't necessarily want a query for foo.internalhost.com going anywhere
other than my VPN for internalhost.com, and if I run a VPN for privacy
purposes then I don't want *anything* other than the VPN itself to send
traffic over a non-VPN interface.  Any way we could fix that while
retaining the "works out of the box" behavior?

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

Re: [systemd-devel] [PATCH] journalctl: add --utc option

[Josh Triplett]

On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote:
> Introduce option to display time in UTC.

Does "TZ=UTC journalctl" not do the right thing?  A quick test here
suggests that it does.  That seems preferable to teaching individual
tools to special-case UTC.

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

Re: [systemd-devel] [PATCH] journalctl: add --utc option

[Josh Triplett]

On Thu, Oct 02, 2014 at 09:11:39PM +0200, Lennart Poettering wrote:
> On Thu, 02.10.14 11:56, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote:
> > > Introduce option to display time in UTC.
> > 
> > Does "TZ=UTC journalctl" not do the right thing?  A quick test here
> > suggests that it does.  That seems preferable to teaching individual
> > tools to special-case UTC.
> 
> Not sure i agree. --utc really should only have an effect on our own
> output, and that's a good thing. If you set $TZ you end up changing
> much much more, for example the logic of glibc's own syslog() and what
> it passes on, and we shouldn't influence that.

True, but in the case of journalctl, which just queries and outputs
journal data, what would TZ=UTC affect that you *wouldn't* want?
journalctl shouldn't be calling syslog().

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

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

[Josh Triplett]

This makes it possible to drop in configuration file snippets from a
package or other configuration management mechanism.
---
 man/logind.conf.xml  |  4 +++-
 src/login/logind.c   | 21 +
 src/shared/conf-parser.c | 19 +++
 src/shared/conf-parser.h |  7 +++
 4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index 8ba9523..836f307 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -44,17 +44,19 @@
 
 
 logind.conf
+logind.conf.d
 Login manager configuration file
 
 
 
 /etc/systemd/logind.conf
+
/etc/systemd/logind.conf.d/*.conf
 
 
 
 Description
 
-This file configures various parameters of the systemd 
login manager, 
systemd-logind.service8.
+These files configures various parameters of the systemd 
login manager, 
systemd-logind.service8.
 
 
 
diff --git a/src/login/logind.c b/src/login/logind.c
index 8f00c46..1feb251 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -29,6 +29,7 @@
 
 #include "sd-daemon.h"
 #include "strv.h"
+#include "conf-files.h"
 #include "conf-parser.h"
 #include "mkdir.h"
 #include "bus-util.h"
@@ -1169,12 +1170,24 @@ int manager_run(Manager *m) {
 }
 
 static int manager_parse_config_file(Manager *m) {
+_cleanup_strv_free_ char **filenames = NULL;
+int r;
+
 assert(m);
 
-return config_parse(NULL, "/etc/systemd/logind.conf", NULL,
-"Login\0",
-config_item_perf_lookup, logind_gperf_lookup,
-false, false, true, m);
+r = conf_files_list(&filenames, ".conf", NULL, 
"/etc/systemd/logind.conf.d", NULL);
+if (r < 0)
+return r;
+
+r = config_parse(NULL, "/etc/systemd/logind.conf", NULL, "Login\0",
+ config_item_perf_lookup, logind_gperf_lookup,
+ false, false, true, m);
+if (r < 0)
+return r;
+
+return config_parse_many(filenames, "Login\0",
+ config_item_perf_lookup, logind_gperf_lookup,
+ false, m);
 }
 
 int main(int argc, char *argv[]) {
diff --git a/src/shared/conf-parser.c b/src/shared/conf-parser.c
index ee6de65..54bd642 100644
--- a/src/shared/conf-parser.c
+++ b/src/shared/conf-parser.c
@@ -430,6 +430,25 @@ int config_parse(const char *unit,
 return 0;
 }
 
+/* Parse each config file, if it exists. */
+int config_parse_many(char **filenames,
+  const char *sections,
+  ConfigItemLookup lookup,
+  const void *table,
+  bool relaxed,
+  void *userdata) {
+char **fn;
+int r;
+
+STRV_FOREACH(fn, filenames) {
+r = config_parse(NULL, *fn, NULL, sections, lookup, table, 
relaxed, false, true, userdata);
+if (r < 0)
+return r;
+}
+
+return 0;
+}
+
 #define DEFINE_PARSER(type, vartype, conv_func) \
 int config_parse_##type(const char *unit,   \
 const char *filename,   \
diff --git a/src/shared/conf-parser.h b/src/shared/conf-parser.h
index 62f2a01..37eee55 100644
--- a/src/shared/conf-parser.h
+++ b/src/shared/conf-parser.h
@@ -92,6 +92,13 @@ int config_parse(const char *unit,
  bool warn,
  void *userdata);
 
+int config_parse_many(char **filenames,
+  const char *sections,  /* nulstr */
+  ConfigItemLookup lookup,
+  const void *table,
+  bool relaxed,
+  void *userdata);
+
 /* Generic parsers */
 int config_parse_int(const char *unit, const char *filename, unsigned line, 
const char *section, unsigned section_line, const char *lvalue, int ltype, 
const char *rvalue, void *data, void *userdata);
 int config_parse_unsigned(const char *unit, const char *filename, unsigned 
line, const char *section, unsigned section_line, const char *lvalue, int 
ltype, const char *rvalue, void *data, void *userdata);
-- 
2.1.1

___
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

[Josh Triplett]

On Thu, Oct 16, 2014 at 03:36:57PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Oct 16, 2014 at 12:27:21PM +0200, Josh Triplett wrote:
> > This makes it possible to drop in configuration file snippets from a
> > package or other configuration management mechanism.
> What kind of settings would you install in this way?

In my case, I plan to have one of my personal configuration packages
install an /etc/systemd/logind.conf.d/lid.conf that contains:

[Login]
HandleLidSwitch=lock

- Josh Triplett
___
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

[Josh Triplett]

On Thu, Oct 16, 2014 at 09:42:50AM -0400, Rahul Sundaram wrote:
> On Thu, Oct 16, 2014 at 6:27 AM, Josh Triplett  wrote:
> > This makes it possible to drop in configuration file snippets from a
> > package or other configuration management mechanism.
>
> Shouldn't those go into /usr according to
>
> http://0pointer.net/blog/projects/stateless.html

Fair enough, I can trivially have it check
/usr/lib/systemd/logind.conf.d/*.conf as well.  Will do in v2.

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

[systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

[Josh Triplett]

This makes it possible to drop in logind configuration snippets from a
package or other configuration management mechanism.

Introduce a new helper, conf_parse_many, to parse configuration files in
a search path.

systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
rather than /etc/systemd/logind.conf .  Distributions should migrate
existing modified versions of /etc/systemd/logind.conf to
/etc/systemd/logind.conf.d/50-default.conf .

Move the logind.conf manpage to logind.conf.d, update it to document the
search paths, and update all references to it.
---

v2: Updated to use the usual search path mechanism and directories.


For systemd, are "git format-patch -M" patches (with git-style renames
rather than whole-file deletion/insertions) acceptable for mailing list
review?  That format makes renames much easier to review.

 Makefile-man.am  |   4 +-
 Makefile.am  |   5 +-
 man/loginctl.xml |   2 +-
 man/logind.conf.d.xml| 381 +++
 man/logind.conf.xml  | 359 -
 man/nss-myhostname.xml   |   2 +-
 man/pam_systemd.xml  |   2 +-
 man/systemd-inhibit.xml  |   4 +-
 man/systemd-logind.service.xml   |   4 +-
 src/login/50-default.conf|  29 +++
 src/login/logind.c   |  17 +-
 src/login/logind.conf|  29 ---
 src/shared/conf-parser.c |  25 +++
 src/shared/conf-parser.h |   7 +
 units/org.freedesktop.login1.busname |   2 +-
 units/systemd-logind.service.in  |   2 +-
 16 files changed, 469 insertions(+), 405 deletions(-)
 create mode 100644 man/logind.conf.d.xml
 delete mode 100644 man/logind.conf.xml
 create mode 100644 src/login/50-default.conf
 delete mode 100644 src/login/logind.conf

diff --git a/Makefile-man.am b/Makefile-man.am
index a13e948..f28eccd 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1096,7 +1096,7 @@ endif
 if ENABLE_LOGIND
 MANPAGES += \
man/loginctl.1 \
-   man/logind.conf.5 \
+   man/logind.conf.d.5 \
man/systemd-logind.service.8
 MANPAGES_ALIAS += \
man/systemd-logind.8
@@ -1547,7 +1547,7 @@ EXTRA_DIST += \
man/localectl.xml \
man/localtime.xml \
man/loginctl.xml \
-   man/logind.conf.xml \
+   man/logind.conf.d.xml \
man/machine-id.xml \
man/machine-info.xml \
man/machinectl.xml \
diff --git a/Makefile.am b/Makefile.am
index e52db17..e048d83 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,6 +95,7 @@ sysusersdir=$(prefix)/lib/sysusers.d
 sysctldir=$(prefix)/lib/sysctl.d
 binfmtdir=$(prefix)/lib/binfmt.d
 modulesloaddir=$(prefix)/lib/modules-load.d
+logindconfdir=$(prefix)/lib/logind.conf.d
 networkdir=$(rootprefix)/lib/systemd/network
 pkgincludedir=$(includedir)/systemd
 systemgeneratordir=$(rootlibexecdir)/system-generators
@@ -5361,8 +5362,8 @@ dist_dbussystemservice_DATA += \
 dist_dbuspolicy_DATA += \
src/login/org.freedesktop.login1.conf
 
-dist_pkgsysconf_DATA += \
-   src/login/logind.conf
+dist_logindconf_DATA = \
+   src/login/50-default.conf
 
 polkitpolicy_files += \
src/login/org.freedesktop.login1.policy
diff --git a/man/loginctl.xml b/man/loginctl.xml
index 749db92..b2eaea4 100644
--- a/man/loginctl.xml
+++ b/man/loginctl.xml
@@ -446,7 +446,7 @@
 
systemd1,
 
systemctl1,
 
systemd-logind.service8,
-
logind.conf5
+
logind.conf.d5
 
 
 
diff --git a/man/logind.conf.d.xml b/man/logind.conf.d.xml
new file mode 100644
index 000..1c34017
--- /dev/null
+++ b/man/logind.conf.d.xml
@@ -0,0 +1,381 @@
+ 
+http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl";?>
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+
+
+logind.conf.d
+systemd
+
+
+
+Developer
+Lennart
+Poettering
+lenn...@poettering.net
+
+
+
+
+
+logind.conf.d
+5
+
+
+
+logind.conf.d
+Login manager configuration files
+
+
+
+
/etc/systemd/logind.conf.d/*.conf
+
/run/systemd/logind.conf.d/*.conf
+
/usr/lib/systemd/logind.conf.d/*.conf
+
+
+
+Description
+
+These files configure various parameters of the systemd 
login manager, 
systemd-logind.service8.
+
+Each configuration file shall be named in the
+style of 
program.conf.
+Files in /etc/ override fi

Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

[Josh Triplett]

On Fri, Oct 17, 2014 at 08:40:48AM +0300, Mantas Mikulėnas wrote:
> On Fri, Oct 17, 2014 at 7:29 AM, Josh Triplett  wrote:
> > This makes it possible to drop in logind configuration snippets from a
> > package or other configuration management mechanism.
> 
> I'm still very curious what packages would need to install drop-ins for 
> logind?

Configuration packages, metapackages, configuration management systems,
etc.

> > Introduce a new helper, conf_parse_many, to parse configuration files in
> > a search path.
> >
> > systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
> > rather than /etc/systemd/logind.conf .  Distributions should migrate
> > existing modified versions of /etc/systemd/logind.conf to
> > /etc/systemd/logind.conf.d/50-default.conf .
> 
> Sounds like unnecessary shuffling things around...

It's the same process previously followed for /etc/modules moving to
/etc/modules-load.d, for instance.

> > For systemd, are "git format-patch -M" patches (with git-style renames
> > rather than whole-file deletion/insertions) acceptable for mailing list
> > review?  That format makes renames much easier to review.
> 
> I'm sure the patches are applied using `git am`, so that should work fine.

That was my hope as well.

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

Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

[Josh Triplett]

On Mon, Oct 20, 2014 at 08:48:01PM +0200, Lennart Poettering wrote:
> On Mon, 20.10.14 11:28, j...@joshtriplett.org (j...@joshtriplett.org) wrote:
> > > I'd really prefer if we'd keep things in logind.conf and just provide
> > > the option of using logind.conf.d. This would be similar to unit
> > > files, where the unit files are where the beef is and .d/ is just a
> > > way to override/extend is. THe man page of logind.conf should
> > > reference the ability that .d/ files are supported, but that should be
> > > it for the documentation. We should really try to not to be too
> > > surprising here for admins which tend to expect one configuration
> > > file, not many.
> > 
> > The main awkwardness there is that /etc/logind.conf, as a file in /etc,
> > should be parsed *after* /usr/lib/systemd/logind.conf.d/ and *before*
> > /etc/systemd/logind.conf.d/ , which breaks the usual logic to load all
> > files in order with files in /etc overriding files in /usr.
> 
> Well, as for units the main file should be read first (taking the
> /usr+/etc override logic into account), and only then we should read
> the .d/ drop-ins (individually following the /usr+/etc override
> logic). THis is what we do for unit files too.
> 
> .d/ in this context really are supposed to be for overrding and
> extending, and hence reading the .d/ snippets in /usr after the main
> confi file from /etc is the right thing to do I believe.
> 
> Ultimately the difference really shouldn#t matter too much I
> think. After all the version in /usr is for vendor defaults, and the
> stuff in /etc for user overrides. .d/ are for overrding hence mostly
> make sense in /etc only really, and should be the total exception in
> /usr.

OK, if you're fine with /usr/lib/systemd/logind.conf.d/*.conf overriding
/etc/logind.conf, then the patch gets *really* simple, and I'll submit
v3 soon.

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

[systemd-devel] [PATCH 1/2] Introduce CONF_DIRS_NULSTR helper to define standard conf dirs

[Josh Triplett]

Several different systemd tools define a nulstr containing a standard
series of configuration file directories, in /etc, /run, /usr/local/lib,
/usr/lib, and (#ifdef HAVE_SPLIT_USR) /lib.  Factor that logic out into
a new helper macro, CONF_DIRS_NULSTR.
---

Realized when defining the Nth instance of this for logind.conf.d that
it really ought to have a common definition.

 src/binfmt/binfmt.c | 10 +-
 src/modules-load/modules-load.c | 10 +-
 src/shared/macro.h  | 15 +++
 src/sysctl/sysctl.c | 10 +-
 src/sysusers/sysusers.c | 10 +-
 src/tmpfiles/tmpfiles.c | 10 +-
 6 files changed, 20 insertions(+), 45 deletions(-)

diff --git a/src/binfmt/binfmt.c b/src/binfmt/binfmt.c
index c1c1522..0a15faf 100644
--- a/src/binfmt/binfmt.c
+++ b/src/binfmt/binfmt.c
@@ -36,15 +36,7 @@
 #include "fileio.h"
 #include "build.h"
 
-static const char conf_file_dirs[] =
-"/etc/binfmt.d\0"
-"/run/binfmt.d\0"
-"/usr/local/lib/binfmt.d\0"
-"/usr/lib/binfmt.d\0"
-#ifdef HAVE_SPLIT_USR
-"/lib/binfmt.d\0"
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR("binfmt");
 
 static int delete_rule(const char *rule) {
 _cleanup_free_ char *x = NULL, *fn = NULL;
diff --git a/src/modules-load/modules-load.c b/src/modules-load/modules-load.c
index c77b092..84ae337 100644
--- a/src/modules-load/modules-load.c
+++ b/src/modules-load/modules-load.c
@@ -38,15 +38,7 @@
 
 static char **arg_proc_cmdline_modules = NULL;
 
-static const char conf_file_dirs[] =
-"/etc/modules-load.d\0"
-"/run/modules-load.d\0"
-"/usr/local/lib/modules-load.d\0"
-"/usr/lib/modules-load.d\0"
-#ifdef HAVE_SPLIT_USR
-"/lib/modules-load.d\0"
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR("modules-load");
 
 static void systemd_kmod_log(void *data, int priority, const char *file, int 
line,
  const char *fn, const char *format, va_list args) 
{
diff --git a/src/shared/macro.h b/src/shared/macro.h
index 9ee332c..6d4712c 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -384,6 +384,21 @@ do {   
 \
 _found; \
 })
 
+/* Return a nulstr for a standard cascade of configuration directories,
+ * suitable to pass to conf_files_list_nulstr or config_parse_many. */
+#define CONF_DIRS_NULSTR(n) \
+"/etc/" n ".d\0" \
+"/run/" n ".d\0" \
+"/usr/local/lib/" n ".d\0" \
+"/usr/lib/" n ".d\0" \
+CONF_DIR_SPLIT_USR(n)
+
+#ifdef HAVE_SPLIT_USR
+#define CONF_DIR_SPLIT_USR(n) "/lib/" n ".d\0"
+#else
+#define CONF_DIR_SPLIT_USR(n)
+#endif
+
 /* Define C11 thread_local attribute even on older gcc compiler
  * version */
 #ifndef thread_local
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 809e59b..edebe50 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -38,15 +38,7 @@
 
 static char **arg_prefixes = NULL;
 
-static const char conf_file_dirs[] =
-"/etc/sysctl.d\0"
-"/run/sysctl.d\0"
-"/usr/local/lib/sysctl.d\0"
-"/usr/lib/sysctl.d\0"
-#ifdef HAVE_SPLIT_USR
-"/lib/sysctl.d\0"
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR("sysctl");
 
 static char* normalize_sysctl(char *s) {
 char *n;
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 9b9be96..df585c1 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -67,15 +67,7 @@ typedef struct Item {
 
 static char *arg_root = NULL;
 
-static const char conf_file_dirs[] =
-"/etc/sysusers.d\0"
-"/run/sysusers.d\0"
-"/usr/local/lib/sysusers.d\0"
-"/usr/lib/sysusers.d\0"
-#ifdef HAVE_SPLIT_USR
-"/lib/sysusers.d\0"
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR("sysusers");
 
 static Hashmap *users = NULL, *groups = NULL;
 static Hashmap *todo_uids = NULL, *todo_gids = NULL;
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 1e4675f..23fd6ca 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -117,15 +117,7 @@ static char **arg_include_prefixes = NULL;
 static char **arg_exclude_prefixes = NULL;
 static char *arg_root = NULL;
 
-static const char conf_file_dirs[] =
-"/etc/tmpfiles.d\0"
-"/run/tmpfiles.d\0"
-"/usr/local/lib/tmpfiles.d\0"
-"/usr/lib/tmpfiles.d\0"
-#ifdef HAVE_SPLIT_USR
-"/lib/tmpfiles.d\0"
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR("tmpfiles");
 
 #define MAX_DEPTH 256
 
-- 
2.1.1

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

[systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths

[Josh Triplett]

This makes it possible to drop in logind configuration snippets from a
package or other configuration management mechanism.

Add documentation to the header of /etc/logind.conf pointing the user at
/etc/logind.conf.d/*.conf.

Introduce a new helper, conf_parse_many, to parse configuration files in
a search path.
---

Revised to keep /etc/systemd/logind.conf around, and to prefer the
entire series of conf.d directories over /etc/systemd/logind.conf, as
suggested by Lennart at
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024122.html

If this approach looks sensible, I'll send further patches for various
other tools with configuration files, such as journald and timesyncd;
however, I wanted to establish the pattern and the common helper
function first.  With the config_parse_many helper, further changes like
this should only require a one-line change to the actual tools, plus
documentation.

 man/logind.conf.xml  | 29 ++---
 src/login/logind.c   |  9 +
 src/login/logind.conf|  3 +++
 src/shared/conf-parser.c | 32 
 src/shared/conf-parser.h |  8 
 5 files changed, 74 insertions(+), 7 deletions(-)

diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index d245bf4..70ca837 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -44,18 +44,41 @@
 
 
 logind.conf
-Login manager configuration file
+Login manager configuration files
 
 
 
 /etc/systemd/logind.conf
+
/etc/systemd/logind.conf.d/*.conf
+
/run/systemd/logind.conf.d/*.conf
+
/usr/lib/systemd/logind.conf.d/*.conf
 
 
 
 Description
 
-This file configures various parameters of the systemd 
login manager, 
systemd-logind.service8.
-
+These files configure various parameters of the systemd 
login manager, 
systemd-logind.service8.
+
+Each configuration file shall be named in the style of
+filename.conf.
+Files in /etc/ override files with the
+same name in /usr/lib/ and
+/run/.  Files in
+/run/ override files with the same name in
+/usr/lib/. Packages should install their
+configuration files in /usr/lib/. Files in
+/etc/ are reserved for the local
+administrator, who may use this logic to override the
+configuration files installed by vendor packages. All
+configuration files are sorted by their filename in
+lexicographic order, regardless of which of the directories
+they reside in. If multiple files specify the same option, the
+entry in the file with the lexicographically latest name will
+be applied; entries in any logind.conf.d
+file override entries in
+/etc/systemd/logind.conf. It is
+recommended to prefix all filenames with a two-digit number and
+a dash, to simplify the ordering of the files.
 
 
 
diff --git a/src/login/logind.c b/src/login/logind.c
index 8f00c46..69b219d 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -1171,10 +1171,11 @@ int manager_run(Manager *m) {
 static int manager_parse_config_file(Manager *m) {
 assert(m);
 
-return config_parse(NULL, "/etc/systemd/logind.conf", NULL,
-"Login\0",
-config_item_perf_lookup, logind_gperf_lookup,
-false, false, true, m);
+return config_parse_many("/etc/systemd/logind.conf",
+ CONF_DIRS_NULSTR("systemd/logind.conf"),
+ "Login\0",
+ config_item_perf_lookup, logind_gperf_lookup,
+ false, m);
 }
 
 int main(int argc, char *argv[]) {
diff --git a/src/login/logind.conf b/src/login/logind.conf
index 4608a2c..6b1943a 100644
--- a/src/login/logind.conf
+++ b/src/login/logind.conf
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/logind.conf.d/*.conf.
+#
 # See logind.conf(5) for details
 
 [Login]
diff --git a/src/shared/conf-parser.c b/src/shared/conf-parser.c
index ee6de65..027c49c 100644
--- a/src/shared/conf-parser.c
+++ b/src/shared/conf-parser.c
@@ -27,6 +27,7 @@
 #include 
 
 #include "conf-parser.h"
+#include "conf-files.h"
 #include "util.h"
 #include "macro.h"
 #include "strv.h"
@@ -430,6 +431,37 @@ int config_parse(const char *unit,
 return 0;
 }
 
+/* Parse each config file in the specified directories. */
+int config_parse_many(const cha

Re: [systemd-devel] statelessy system

[Josh Triplett]

Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Nov 03, 2014 at 12:24:42PM +0100, Lennart Poettering wrote:
> > Would be happy to take a patch that makes those cases check for a
> > config file in /usr/lib as fallback though, to cover all bases.
> Didn't we have a patch to support .d directories floated on the ml?
> Can't seem to find it at the moment.

Yes, I posted one for logind.conf.d; see message IDs
<20141029120251.GA30088@thin> ("[PATCH 1/2] Introduce CONF_DIRS_NULSTR
helper to define standard conf dirs") and <20141029121045.GA5365@thin>
("[PATCH 2/2] logind: Support logind.conf.d directories in the usual
search paths").
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024676.html
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024677.html

I'd love to see those applied.  If those work for you, I can produce
additional patches for the other config files in /etc/systemd.

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

Re: [systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths

[Josh Triplett]

On Thu, Nov 27, 2014 at 01:45:43AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Nov 26, 2014 at 01:24:53PM +0100, Gergely Nagy wrote:
> > >>>>> "Josh" == Josh Triplett  writes:
> > 
> > Josh> This makes it possible to drop in logind configuration snippets 
> > from a
> > Josh> package or other configuration management mechanism.
> > [...]
> > Josh> If this approach looks sensible, I'll send further patches for 
> > various
> > Josh> other tools with configuration files, such as journald and
> > Josh> timesyncd;
> > 
> > I recently hit an issue where a journald.conf.d/ would have been
> > incredibly useful. Any news on this patchset, by any chance?
> 
> Applied. Sorry for the delay.

Thanks!  And no problem.

> It would be great if you could prepare patches for the other deamons.

Will do.

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

[systemd-devel] [PATCH 01/10] man/logind.conf.xml: Make "man logind.conf.d" work too

[Josh Triplett]

---
 Makefile-man.am | 5 +
 man/logind.conf.xml | 1 +
 2 files changed, 6 insertions(+)

diff --git a/Makefile-man.am b/Makefile-man.am
index f817a05..906a968 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1110,8 +1110,13 @@ MANPAGES += \
man/logind.conf.5 \
man/systemd-logind.service.8
 MANPAGES_ALIAS += \
+   man/logind.conf.d.5 \
man/systemd-logind.8
+man/logind.conf.d.5: man/logind.conf.5
 man/systemd-logind.8: man/systemd-logind.service.8
+man/logind.conf.d.html: man/logind.conf.html
+   $(html-alias)
+
 man/systemd-logind.html: man/systemd-logind.service.html
$(html-alias)
 
diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index 0b35f51..ca7525f 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -44,6 +44,7 @@
 
 
 logind.conf
+logind.conf.d
 Login manager configuration files
 
 
-- 
2.1.3

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

[systemd-devel] [PATCH 02/10] man: Factor out a common snippet for .d directories and precedence

[Josh Triplett]

Several manpages contain duplicate text describing a standard set of .d
configuration directories, with the usual sorting, precedence,
overrides, and so on.  Factor this common text out using XInclude before
proliferating it even further.
---
 Makefile-man.am|  1 +
 man/binfmt.d.xml   | 30 --
 man/logind.conf.xml| 27 +--
 man/modules-load.d.xml | 26 --
 man/standard-conf.xml  | 45 +
 man/sysctl.d.xml   | 33 -
 man/sysusers.d.xml | 27 ++-
 7 files changed, 69 insertions(+), 120 deletions(-)
 create mode 100644 man/standard-conf.xml

diff --git a/Makefile-man.am b/Makefile-man.am
index 906a968..c24606a 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1638,6 +1638,7 @@ EXTRA_DIST += \
man/sd_uid_get_state.xml \
man/sd_watchdog_enabled.xml \
man/shutdown.xml \
+   man/standard-conf.xml \
man/standard-options.xml \
man/sysctl.d.xml \
man/systemctl.xml \
diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml
index 2270166..55a3df0 100644
--- a/man/binfmt.d.xml
+++ b/man/binfmt.d.xml
@@ -19,7 +19,8 @@
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see .
 -->
-
+http://www.w3.org/2001/XInclude";>
 
 
 binfmt.d
@@ -74,33 +75,10 @@
 Empty lines and lines beginning with ; and # are
 ignored. Note that this means you may not use ; and #
 as delimiter in binary format rules.
-
-Each configuration file shall be named in the
-style of 
program.conf.
-Files in /etc/ override files
-with the same name in /usr/lib/
-and /run/. Files in
-/run/ override files with the
-same name in /usr/lib/. Packages
-should install their configuration files in
-/usr/lib/, files in
-/etc/ are reserved for the local
-administrator, who may use this logic to override the
-configuration files installed from vendor
-packages. All files are sorted by their filename in
-lexicographic order, regardless of which of the
-directories they reside in. If multiple files specify
-the same binary type name, the entry in the file with
-the lexicographically latest name will be applied.
-
-If the administrator wants to disable a
-configuration file supplied by the vendor, the
-recommended way is to place a symlink to
-/dev/null in
-/etc/binfmt.d/ bearing the
-same filename.
 
 
+
+
 
 Example
 
diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index ca7525f..e927cf4 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
 
 logind.conf
 systemd
@@ -59,29 +60,11 @@
 Description
 
 These files configure various parameters of the systemd 
login manager, 
systemd-logind.service8.
-
-Each configuration file shall be named in the style of
-filename.conf.
-Files in /etc/ override files with the
-same name in /usr/lib/ and
-/run/.  Files in
-/run/ override files with the same name in
-/usr/lib/. Packages should install their
-configuration files in /usr/lib/. Files in
-/etc/ are reserved for the local
-administrator, who may use this logic to override the
-configuration files installed by vendor packages. All
-configuration files are sorted by their filename in
-lexicographic order, regardless of which of the directories
-they reside in. If multiple files specify the same option, the
-entry in the file with the lexicographically latest name will
-be applied; entries in any logind.conf.d
-file override entries in
-/etc/systemd/logind.conf. It is
-recommended to prefix all filenames with a two-digit number and
-a dash, to simplify the ordering of the files.
 
 
+
+
+
 
 Options
 
diff --git a/man/modules-load.d.xml b/man/modules-load.d.xml
index 33c466f..4b578d7 100644
--- a/man/modules-load.d.xml
+++ b/man/modules-load.d.xml
@@ -19,7 +19,8 @@
   You should have received a copy o

[systemd-devel] [PATCH 03/10] core: Support system.conf.d and user.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am | 12 +++-
 man/systemd-system.conf.xml | 25 -
 man/systemd.xml | 10 ++
 src/core/main.c |  9 -
 src/core/system.conf|  3 +++
 src/core/user.conf  |  3 +++
 6 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index c24606a..f025be0 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -195,6 +195,7 @@ MANPAGES_ALIAS += \
man/sd_journal_wait.3 \
man/sd_machine_get_ifindices.3 \
man/sd_notifyf.3 \
+   man/system.conf.d.5 \
man/systemd-ask-password-console.path.8 \
man/systemd-ask-password-wall.path.8 \
man/systemd-ask-password-wall.service.8 \
@@ -227,7 +228,8 @@ MANPAGES_ALIAS += \
man/systemd-udevd-kernel.socket.8 \
man/systemd-udevd.8 \
man/systemd-update-done.8 \
-   man/systemd-user.conf.5
+   man/systemd-user.conf.5 \
+   man/user.conf.d.5
 man/SD_ALERT.3: man/sd-daemon.3
 man/SD_CRIT.3: man/sd-daemon.3
 man/SD_DEBUG.3: man/sd-daemon.3
@@ -301,6 +303,7 @@ man/sd_journal_test_cursor.3: man/sd_journal_get_cursor.3
 man/sd_journal_wait.3: man/sd_journal_get_fd.3
 man/sd_machine_get_ifindices.3: man/sd_machine_get_class.3
 man/sd_notifyf.3: man/sd_notify.3
+man/system.conf.d.5: man/systemd-system.conf.5
 man/systemd-ask-password-console.path.8: 
man/systemd-ask-password-console.service.8
 man/systemd-ask-password-wall.path.8: 
man/systemd-ask-password-console.service.8
 man/systemd-ask-password-wall.service.8: 
man/systemd-ask-password-console.service.8
@@ -334,6 +337,7 @@ man/systemd-udevd-kernel.socket.8: 
man/systemd-udevd.service.8
 man/systemd-udevd.8: man/systemd-udevd.service.8
 man/systemd-update-done.8: man/systemd-update-done.service.8
 man/systemd-user.conf.5: man/systemd-system.conf.5
+man/user.conf.d.5: man/systemd-system.conf.5
 man/SD_ALERT.html: man/sd-daemon.html
$(html-alias)
 
@@ -553,6 +557,9 @@ man/sd_machine_get_ifindices.html: 
man/sd_machine_get_class.html
 man/sd_notifyf.html: man/sd_notify.html
$(html-alias)
 
+man/system.conf.d.html: man/systemd-system.conf.html
+   $(html-alias)
+
 man/systemd-ask-password-console.path.html: 
man/systemd-ask-password-console.service.html
$(html-alias)
 
@@ -652,6 +659,9 @@ man/systemd-update-done.html: 
man/systemd-update-done.service.html
 man/systemd-user.conf.html: man/systemd-system.conf.html
$(html-alias)
 
+man/user.conf.d.html: man/systemd-system.conf.html
+   $(html-alias)
+
 
 if ENABLE_BACKLIGHT
 MANPAGES += \
diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml
index 284516d..dfb180c 100644
--- a/man/systemd-system.conf.xml
+++ b/man/systemd-system.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
 
 systemd-system.conf
 systemd
@@ -44,25 +45,39 @@
 
 
 systemd-system.conf
+system.conf.d
 systemd-user.conf
-System and session service manager configuration 
file
+user.conf.d
+System and session service manager configuration 
files
 
 
 
 /etc/systemd/system.conf
+
/etc/systemd/system.conf.d/*.conf
+
/run/systemd/system.conf.d/*.conf
+
/usr/lib/systemd/system.conf.d/*.conf
 /etc/systemd/user.conf
+
/etc/systemd/user.conf.d/*.conf
+
/run/systemd/user.conf.d/*.conf
+
/usr/lib/systemd/user.conf.d/*.conf
 
 
 
 Description
 
-When run as system instance systemd reads the
-configuration file system.conf,
-otherwise user.conf. These
+When run as a system instance, systemd interprets the
+configuration file system.conf and the
+files in system.conf.d directories; when
+run as a user instance, systemd interprets the configuration
+file user.conf and the files in
+user.conf.d directories. These
 configuration files contain a few settings controlling
 basic manager operations.
 
 
+
+
+
 
 Options
 
diff --git a/man/systemd.xml b/man/systemd.xml
index bf7a7a6..d776815 100644
--- a/man/systemd.xml
+++ b/man/systemd.xml
@@ -75,10 +75,12 @@
 
telinit8
 for more information.
 
-When run as system instance, systemd interprets
-the configuration file
-system.conf, otherwise
-user.conf. See
+When run as a system instance, systemd interprets the
+configuration file system.conf and the
+   

[systemd-devel] [PATCH 05/10] systemd-sleep: Support sleep.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am |  5 +
 man/systemd-sleep.conf.xml  | 15 ---
 man/systemd-suspend.service.xml |  3 ++-
 src/shared/sleep-config.c   |  7 ---
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index e0c15fa..2a0d73e 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -196,6 +196,7 @@ MANPAGES_ALIAS += \
man/sd_journal_wait.3 \
man/sd_machine_get_ifindices.3 \
man/sd_notifyf.3 \
+   man/sleep.conf.d.5 \
man/system.conf.d.5 \
man/systemd-ask-password-console.path.8 \
man/systemd-ask-password-wall.path.8 \
@@ -305,6 +306,7 @@ man/sd_journal_test_cursor.3: man/sd_journal_get_cursor.3
 man/sd_journal_wait.3: man/sd_journal_get_fd.3
 man/sd_machine_get_ifindices.3: man/sd_machine_get_class.3
 man/sd_notifyf.3: man/sd_notify.3
+man/sleep.conf.d.5: man/systemd-sleep.conf.5
 man/system.conf.d.5: man/systemd-system.conf.5
 man/systemd-ask-password-console.path.8: 
man/systemd-ask-password-console.service.8
 man/systemd-ask-password-wall.path.8: 
man/systemd-ask-password-console.service.8
@@ -562,6 +564,9 @@ man/sd_machine_get_ifindices.html: 
man/sd_machine_get_class.html
 man/sd_notifyf.html: man/sd_notify.html
$(html-alias)
 
+man/sleep.conf.d.html: man/systemd-sleep.conf.html
+   $(html-alias)
+
 man/system.conf.d.html: man/systemd-system.conf.html
$(html-alias)
 
diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml
index d724960..99e0e33 100644
--- a/man/systemd-sleep.conf.xml
+++ b/man/systemd-sleep.conf.xml
@@ -22,7 +22,8 @@ You should have received a copy of the GNU Lesser General 
Public License
 along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
   
 systemd-sleep.conf
 systemd
@@ -44,11 +45,15 @@ along with systemd; If not, see 
.
 
   
 systemd-sleep.conf
+sleep.conf.d
 Suspend and hibernation configuration file
   
 
   
 /etc/systemd/sleep.conf
+/etc/systemd/sleep.conf.d/*.conf
+/run/systemd/sleep.conf.d/*.conf
+/usr/lib/systemd/sleep.conf.d/*.conf
   
 
   
@@ -98,7 +103,7 @@ along with systemd; If not, see 
.
   
 
 
-Settings in this file determine what strings
+Settings in these files determine what strings
 will be written to
 /sys/power/disk and
 /sys/power/state by
@@ -108,12 +113,16 @@ along with systemd; If not, see 
.
 attempts to suspend or hibernate the machine.
   
 
+  
+  
+
   
 Options
 
 The following options can be configured in the
 [Sleep] section of
-/etc/systemd/sleep.conf:
+/etc/systemd/sleep.conf or a
+sleep.conf.d file:
 
 
   
diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml
index 9a3ae1b..375c255 100644
--- a/man/systemd-suspend.service.xml
+++ b/man/systemd-suspend.service.xml
@@ -114,7 +114,8 @@
 /sys/power/state, to trigger the
 actual system suspend. What exactly is written
 where can be configured in the [Sleep]
-section of /etc/systemd/sleep.conf.
+section of /etc/systemd/sleep.conf or a
+sleep.conf.d file.
 See 
systemd-sleep.conf5.
 
 
diff --git a/src/shared/sleep-config.c b/src/shared/sleep-config.c
index 0fd307d..ae14c6b 100644
--- a/src/shared/sleep-config.c
+++ b/src/shared/sleep-config.c
@@ -48,9 +48,10 @@ int parse_sleep_config(const char *verb, char ***_modes, 
char ***_states) {
 {}
 };
 
-config_parse(NULL, PKGSYSCONFDIR "/sleep.conf", NULL,
- "Sleep\0",
- config_item_table_lookup, items, false, false, true, 
NULL);
+config_parse_many(PKGSYSCONFDIR "/sleep.conf",
+  CONF_DIRS_NULSTR("systemd/sleep.conf"),
+  "Sleep\0", config_item_table_lookup, items,
+  false, NULL);
 
 if (streq(verb, "suspend")) {
 /* empty by default */
-- 
2.1.3

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

[systemd-devel] [PATCH 04/10] journald: Support journald.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am   |  5 +
 man/journald.conf.xml | 14 +++---
 src/journal/journald-server.c |  9 +
 src/journal/journald.conf |  3 +++
 4 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index f025be0..e0c15fa 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -148,6 +148,7 @@ MANPAGES_ALIAS += \
man/SD_NOTICE.3 \
man/SD_WARNING.3 \
man/init.1 \
+   man/journald.conf.d.5 \
man/poweroff.8 \
man/reboot.8 \
man/sd_id128_equal.3 \
@@ -256,6 +257,7 @@ man/SD_LISTEN_FDS_START.3: man/sd_listen_fds.3
 man/SD_NOTICE.3: man/sd-daemon.3
 man/SD_WARNING.3: man/sd-daemon.3
 man/init.1: man/systemd.1
+man/journald.conf.d.5: man/journald.conf.5
 man/poweroff.8: man/halt.8
 man/reboot.8: man/halt.8
 man/sd_id128_equal.3: man/sd-id128.3
@@ -416,6 +418,9 @@ man/SD_WARNING.html: man/sd-daemon.html
 man/init.html: man/systemd.html
$(html-alias)
 
+man/journald.conf.d.html: man/journald.conf.html
+   $(html-alias)
+
 man/poweroff.html: man/halt.html
$(html-alias)
 
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 5538b96..bf0b944 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
 
 journald.conf
 systemd
@@ -44,22 +45,29 @@
 
 
 journald.conf
-Journal service configuration file
+journald.conf.d
+Journal service configuration files
 
 
 
 /etc/systemd/journald.conf
+
/etc/systemd/journald.conf.d/*.conf
+
/run/systemd/journald.conf.d/*.conf
+
/usr/lib/systemd/journald.conf.d/*.conf
 
 
 
 Description
 
-This file configures various parameters of the
+These files configure various parameters of the
 systemd journal service,
 
systemd-journald.service8.
 
 
 
+
+
+
 
 Options
 
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 9ec425d..3bee18b 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1351,10 +1351,11 @@ static int server_parse_proc_cmdline(Server *s) {
 static int server_parse_config_file(Server *s) {
 assert(s);
 
-return config_parse(NULL, "/etc/systemd/journald.conf", NULL,
-"Journal\0",
-config_item_perf_lookup, journald_gperf_lookup,
-false, false, true, s);
+return config_parse_many("/etc/systemd/journald.conf",
+ CONF_DIRS_NULSTR("systemd/journald.conf"),
+ "Journal\0",
+ config_item_perf_lookup, 
journald_gperf_lookup,
+ false, s);
 }
 
 static int server_dispatch_sync(sd_event_source *es, usec_t t, void *userdata) 
{
diff --git a/src/journal/journald.conf b/src/journal/journald.conf
index 2073f1b..29bdf8f 100644
--- a/src/journal/journald.conf
+++ b/src/journal/journald.conf
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/journald.conf.d/*.conf.
+#
 # See journald.conf(5) for details
 
 [Journal]
-- 
2.1.3

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

[systemd-devel] [PATCH 06/10] bootchart: Support bootchart.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am  |  6 --
 man/bootchart.conf.xml   | 21 +++--
 src/bootchart/bootchart.c|  7 +++
 src/bootchart/bootchart.conf |  3 +++
 4 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 2a0d73e..593dc40 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -701,8 +701,10 @@ MANPAGES += \
man/bootchart.conf.5 \
man/systemd-bootchart.1
 MANPAGES_ALIAS += \
-   #
-
+   man/bootchart.conf.d.5
+man/bootchart.conf.d.5: man/bootchart.conf.5
+man/bootchart.conf.d.html: man/bootchart.conf.html
+   $(html-alias)
 
 endif
 
diff --git a/man/bootchart.conf.xml b/man/bootchart.conf.xml
index 68834c7..a364826 100644
--- a/man/bootchart.conf.xml
+++ b/man/bootchart.conf.xml
@@ -25,7 +25,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
 
 bootchart.conf
 systemd
@@ -47,23 +48,31 @@
 
 
 bootchart.conf
-Boot performance analysis graphing tool 
configuration file
+bootchart.conf.d
+Boot performance analysis graphing tool 
configuration files
 
 
 
 /etc/systemd/bootchart.conf
+
/etc/systemd/bootchart.conf.d/*.conf
+
/run/systemd/bootchart.conf.d/*.conf
+
/usr/lib/systemd/bootchart.conf.d/*.conf
 
 
 
 Description
 
 When starting, systemd-bootchart will read the
-configuration file bootchart.conf.
-This configuration file determines logging parameters and
-graph output.
-
+configuration file
+/etc/systemd/bootchart.conf, followed by
+the files in the bootchart.conf.d
+directories.  These configuration files determine logging
+parameters and graph output.
 
 
+
+
+
 
 Options
 
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 5bb4247..0808ba4 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -125,10 +125,9 @@ static void parse_conf(void) {
 { NULL, NULL, NULL, 0, NULL }
 };
 
-config_parse(NULL, BOOTCHART_CONF, NULL,
- NULL,
- config_item_table_lookup, items,
- true, false, true, NULL);
+config_parse_many(BOOTCHART_CONF,
+  CONF_DIRS_NULSTR("systemd/bootchart.conf"),
+  NULL, config_item_table_lookup, items, true, NULL);
 
 if (init != NULL)
 strscpy(arg_init_path, sizeof(arg_init_path), init);
diff --git a/src/bootchart/bootchart.conf b/src/bootchart/bootchart.conf
index d7e0dab..c73328f 100644
--- a/src/bootchart/bootchart.conf
+++ b/src/bootchart/bootchart.conf
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/bootchart.conf.d/*.conf.
+#
 # See bootchart.conf(5) for details
 
 [Bootchart]
-- 
2.1.3

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

[systemd-devel] [PATCH 07/10] coredump: Support coredump.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am   |  6 --
 man/coredump.conf.xml | 14 +++---
 src/journal/coredump.c|  9 +
 src/journal/coredump.conf |  3 +++
 4 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 593dc40..01d3408 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -714,8 +714,10 @@ MANPAGES += \
man/coredumpctl.1 \
man/systemd-coredump.8
 MANPAGES_ALIAS += \
-   #
-
+   man/coredump.conf.d.5
+man/coredump.conf.d.5: man/coredump.conf.5
+man/coredump.conf.d.html: man/coredump.conf.html
+   $(html-alias)
 
 endif
 
diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml
index 5eb5c5f..37916f0 100644
--- a/man/coredump.conf.xml
+++ b/man/coredump.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
   
 coredump.conf
 systemd
@@ -44,20 +45,27 @@
 
   
 coredump.conf
-Coredump storage configuration file
+coredump.conf.d
+Coredump storage configuration files
   
 
   
 /etc/systemd/coredump.conf
+/etc/systemd/coredump.conf.d/*.conf
+/run/systemd/coredump.conf.d/*.conf
+/usr/lib/systemd/coredump.conf.d/*.conf
   
 
   
 Description
 
-This file configures the behaviour of 
systemd-coredump,
+These files configure the behaviour of 
systemd-coredump,
 a handler for core dumps invoked by the kernel.
   
 
+  
+  
+
   
 Options
 
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index d889ed1..be45a68 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -120,10 +120,11 @@ static int parse_config(void) {
 {}
 };
 
-return config_parse(NULL, "/etc/systemd/coredump.conf", NULL,
-"Coredump\0",
-config_item_table_lookup, items,
-false, false, true, NULL);
+return config_parse_many("/etc/systemd/coredump.conf",
+ CONF_DIRS_NULSTR("systemd/coredump.conf"),
+ "Coredump\0",
+ config_item_table_lookup, items,
+ false, NULL);
 }
 
 static int fix_acl(int fd, uid_t uid) {
diff --git a/src/journal/coredump.conf b/src/journal/coredump.conf
index 0cc328f..0fe9fe8 100644
--- a/src/journal/coredump.conf
+++ b/src/journal/coredump.conf
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/coredump.conf.d/*.conf.
+#
 # See coredump.conf(5) for details
 
 [Coredump]
-- 
2.1.3

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

[systemd-devel] [PATCH 09/10] timesyncd: Support timesyncd.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am|  7 ++-
 man/timesyncd.conf.xml | 17 +++--
 src/timesync/timesyncd-conf.c  |  9 +
 src/timesync/timesyncd.conf.in |  3 +++
 4 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 36e0ebb..e3c43b2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1244,11 +1244,16 @@ MANPAGES += \
man/systemd-timesyncd.service.8 \
man/timesyncd.conf.5
 MANPAGES_ALIAS += \
-   man/systemd-timesyncd.8
+   man/systemd-timesyncd.8 \
+   man/timesyncd.conf.d.5
 man/systemd-timesyncd.8: man/systemd-timesyncd.service.8
+man/timesyncd.conf.d.5: man/timesyncd.conf.5
 man/systemd-timesyncd.html: man/systemd-timesyncd.service.html
$(html-alias)
 
+man/timesyncd.conf.d.html: man/timesyncd.conf.html
+   $(html-alias)
+
 endif
 
 if ENABLE_VCONSOLE
diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml
index aeb7182..1a56c2c 100644
--- a/man/timesyncd.conf.xml
+++ b/man/timesyncd.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
 
 timesyncd.conf
 systemd
@@ -44,24 +45,28 @@
 
 
 timesyncd.conf
-Network Time Synchronization configuration 
file
+timesyncd.conf.d
+Network Time Synchronization configuration 
files
 
 
 
 /etc/systemd/timesyncd.conf
+
/etc/systemd/timesyncd.conf.d/*.conf
+
/run/systemd/timesyncd.conf.d/*.conf
+
/usr/lib/systemd/timesyncd.conf.d/*.conf
 
 
 
 Description
 
-When starting, systemd-timesyncd will read the
-configuration file
-timesyncd.conf.  This
-configuration file controls NTP network time
+These configuration files control NTP network time
 synchronization.
 
 
 
+
+
+
 
 Options
 
diff --git a/src/timesync/timesyncd-conf.c b/src/timesync/timesyncd-conf.c
index 4c2dcdb..be1f4bb 100644
--- a/src/timesync/timesyncd-conf.c
+++ b/src/timesync/timesyncd-conf.c
@@ -97,8 +97,9 @@ int config_parse_servers(
 int manager_parse_config_file(Manager *m) {
 assert(m);
 
-return config_parse(NULL, "/etc/systemd/timesyncd.conf", NULL,
-"Time\0",
-config_item_perf_lookup, timesyncd_gperf_lookup,
-false, false, true, m);
+return config_parse_many("/etc/systemd/timesyncd.conf",
+ CONF_DIRS_NULSTR("systemd/timesyncd.conf"),
+ "Time\0",
+ config_item_perf_lookup, 
timesyncd_gperf_lookup,
+ false, m);
 }
diff --git a/src/timesync/timesyncd.conf.in b/src/timesync/timesyncd.conf.in
index 674a51d..fc3c6c4 100644
--- a/src/timesync/timesyncd.conf.in
+++ b/src/timesync/timesyncd.conf.in
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/timesyncd.conf.d/*.conf.
+#
 # See timesyncd.conf(5) for details
 
 [Time]
-- 
2.1.3

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

[systemd-devel] [PATCH 08/10] resolved: Support resolved.conf.d directories in the usual search paths

[Josh Triplett]

---
 Makefile-man.am  |  5 +
 man/resolved.conf.xml| 16 +++-
 src/resolve/resolved-conf.c  |  9 +
 src/resolve/resolved.conf.in |  3 +++
 4 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 01d3408..36e0ebb 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1204,8 +1204,13 @@ MANPAGES += \
man/resolved.conf.5 \
man/systemd-resolved.service.8
 MANPAGES_ALIAS += \
+   man/resolved.conf.d.5 \
man/systemd-resolved.8
+man/resolved.conf.d.5: man/resolved.conf.5
 man/systemd-resolved.8: man/systemd-resolved.service.8
+man/resolved.conf.d.html: man/resolved.conf.html
+   $(html-alias)
+
 man/systemd-resolved.html: man/systemd-resolved.service.html
$(html-alias)
 
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
index c582368..36013a5 100644
--- a/man/resolved.conf.xml
+++ b/man/resolved.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see .
 -->
 
-
+http://www.w3.org/2001/XInclude";>
 
 resolved.conf
 systemd
@@ -44,23 +45,28 @@
 
 
 resolved.conf
-Network Name Resolution configuration 
file
+resolved.conf.d
+Network Name Resolution configuration 
files
 
 
 
 /etc/systemd/resolved.conf
+
/etc/systemd/resolved.conf.d/*.conf
+
/run/systemd/resolved.conf.d/*.conf
+
/usr/lib/systemd/resolved.conf.d/*.conf
 
 
 
 Description
 
-When starting, systemd-resolved will read the
-configuration file resolved.conf.
-This configuration file controls local DNS and LLMNR
+These configuration files control local DNS and LLMNR
 name resolving.
 
 
 
+
+
+
 
 Options
 
diff --git a/src/resolve/resolved-conf.c b/src/resolve/resolved-conf.c
index 63e87f8..81b9d34 100644
--- a/src/resolve/resolved-conf.c
+++ b/src/resolve/resolved-conf.c
@@ -147,8 +147,9 @@ int config_parse_support(
 int manager_parse_config_file(Manager *m) {
 assert(m);
 
-return config_parse(NULL, "/etc/systemd/resolved.conf", NULL,
-"Resolve\0",
-config_item_perf_lookup, resolved_gperf_lookup,
-false, false, true, m);
+return config_parse_many("/etc/systemd/resolved.conf",
+ CONF_DIRS_NULSTR("systemd/resolved.conf"),
+ "Resolve\0",
+ config_item_perf_lookup, 
resolved_gperf_lookup,
+ false, m);
 }
diff --git a/src/resolve/resolved.conf.in b/src/resolve/resolved.conf.in
index c8263d6..e5a19ee 100644
--- a/src/resolve/resolved.conf.in
+++ b/src/resolve/resolved.conf.in
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/resolved.conf.d/*.conf.
+#
 # See resolved.conf(5) for details
 
 [Resolve]
-- 
2.1.3

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

[systemd-devel] [PATCH 10/10] journald-remote: Support journal-remote.conf.d and journal-upload.conf.d directories in the usual search paths

[Josh Triplett]

---
 src/journal-remote/journal-remote.c | 8 
 src/journal-remote/journal-upload.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/journal-remote/journal-remote.c 
b/src/journal-remote/journal-remote.c
index a5d40cb..6ec5ad2 100644
--- a/src/journal-remote/journal-remote.c
+++ b/src/journal-remote/journal-remote.c
@@ -1131,10 +1131,10 @@ static int parse_config(void) {
 { "Remote",  "TrustedCertificateFile", config_parse_path,  
   0, &arg_trust  },
 {}};
 
-return config_parse(NULL, PKGSYSCONFDIR "/journal-remote.conf", NULL,
-"Remote\0",
-config_item_table_lookup, items,
-false, false, true, NULL);
+return config_parse_many(PKGSYSCONFDIR "/journal-remote.conf",
+ 
CONF_DIRS_NULSTR("systemd/journal-remote.conf"),
+ "Remote\0", config_item_table_lookup, items,
+ false, NULL);
 }
 
 static void help(void) {
diff --git a/src/journal-remote/journal-upload.c 
b/src/journal-remote/journal-upload.c
index 8be0f93..62853b6 100644
--- a/src/journal-remote/journal-upload.c
+++ b/src/journal-remote/journal-upload.c
@@ -532,10 +532,10 @@ static int parse_config(void) {
 { "Upload",  "TrustedCertificateFile", config_parse_path,   0, 
&arg_trust  },
 {}};
 
-return config_parse(NULL, PKGSYSCONFDIR "/journal-upload.conf", NULL,
-"Upload\0",
-config_item_table_lookup, items,
-false, false, true, NULL);
+return config_parse_many(PKGSYSCONFDIR "/journal-upload.conf",
+ 
CONF_DIRS_NULSTR("systemd/journal-upload.conf"),
+ "Upload\0", config_item_table_lookup, items,
+ false, NULL);
 }
 
 static void help(void) {
-- 
2.1.3

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

[systemd-devel] [PATCH] NEWS: Document new .conf.d configuration directories

[Josh Triplett]

Also provide guidance to distributions, to make sure they don't start
dropping files in the configuration directories in /etc/.
---
 NEWS | 13 +
 1 file changed, 13 insertions(+)

diff --git a/NEWS b/NEWS
index 0d3ab2b..8fc0720 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,19 @@ CHANGES WITH 218:
   will spew out warnings if the compilation fails. This
   requires libxkbcommon to be installed.
 
+* All systemd programs that read standalone configuration files
+  in /etc now also support a corresponding series of
+  .conf.d configuration directories in /etc/, /run/,
+  /usr/local/lib/, /usr/lib/, and (if configured with
+  --enable-split-usr) /lib/.  In particular, the following
+  configuration files now have corresponding configuration
+  directories: system.conf user.conf, logind.conf,
+  journald.conf, sleep.conf, bootchart.conf, coredump.conf,
+  resolved.conf, timesyncd.conf, journal-remote.conf, and
+  journal-upload.conf.  Note that distributions should use the
+  configuration directories in /usr/lib/; the directories in
+  /etc/ are reserved for the system administrator.
+
 CHANGES WITH 217:
 
 * journalctl gained the new options -t/--identifier= to match
-- 
2.1.3

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

Re: [systemd-devel] [PATCH] NEWS: Document new .conf.d configuration directories

[Josh Triplett]

On Sun, Nov 30, 2014 at 12:23:07AM +0100, Lennart Poettering wrote:
> Applied! Thanks!

Thanks for the fast response!

Out of curiosity, what's the process/criteria to apply for commit
access?  (I have an fd.o account already.)  I didn't see any documented
on the systemd homepage.

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

[systemd-devel] [PATCH 0/5] Enhancements to libabc template project

[Josh Triplett]

I went to use libabc as the basis for a new library, and found a few issues;
rather than just correcting them in my own library, I'd like to push the
changes back into libabc.

Josh Triplett (5):
  Makefile.am: Don't add abc subdirectory to include path
  Makefile.am: Don't define LIBEXECDIR
  autogen.sh: set -e separately, rather than putting -e in the shebang line
  m4/.gitignore: Remove stray blank line.
  Remove FSF mailing address

 Makefile.am  | 2 --
 autogen.sh   | 3 ++-
 m4/.gitignore| 1 -
 src/abc/libabc.h | 4 
 src/libabc-private.h | 4 
 src/libabc.c | 4 
 src/test-libabc.c| 4 
 7 files changed, 2 insertions(+), 20 deletions(-)

-- 
2.1.3

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

[systemd-devel] [PATCH 1/5] Makefile.am: Don't add abc subdirectory to include path

[Josh Triplett]

Source files, including those in the library itself, should include
, not .
---
 Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 1ac18d0..aa53b51 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,7 +7,6 @@ AM_CPPFLAGS = \
-include $(top_builddir)/config.h \
-DSYSCONFDIR=\""$(sysconfdir)"\" \
-DLIBEXECDIR=\""$(libexecdir)"\" \
-   -I${top_srcdir}/src/abc \
-I${top_srcdir}/src
 
 AM_CFLAGS = ${my_CFLAGS} \
-- 
2.1.3

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

[systemd-devel] [PATCH 2/5] Makefile.am: Don't define LIBEXECDIR

[Josh Triplett]

As README points out, the library should not execute out-of-process
tools.  Thus, it should never need to know LIBEXECDIR.
---
 Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index aa53b51..d7dcaed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6,7 +6,6 @@ AM_MAKEFLAGS = --no-print-directory
 AM_CPPFLAGS = \
-include $(top_builddir)/config.h \
-DSYSCONFDIR=\""$(sysconfdir)"\" \
-   -DLIBEXECDIR=\""$(libexecdir)"\" \
-I${top_srcdir}/src
 
 AM_CFLAGS = ${my_CFLAGS} \
-- 
2.1.3

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

[systemd-devel] [PATCH 3/5] autogen.sh: set -e separately, rather than putting -e in the shebang line

[Josh Triplett]

Otherwise, if someone uses "sh autogen.sh", the -e will get ignored.
---
 autogen.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/autogen.sh b/autogen.sh
index 0d60b0a..07afd85 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,4 +1,5 @@
-#!/bin/sh -e
+#!/bin/sh
+set -e
 
 if [ -f .git/hooks/pre-commit.sample -a ! -f .git/hooks/pre-commit ] ; then
 cp -p .git/hooks/pre-commit.sample .git/hooks/pre-commit && \
-- 
2.1.3

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

[systemd-devel] [PATCH 4/5] m4/.gitignore: Remove stray blank line.

[Josh Triplett]

---
 m4/.gitignore | 1 -
 1 file changed, 1 deletion(-)

diff --git a/m4/.gitignore b/m4/.gitignore
index 8bab51c..38066dd 100644
--- a/m4/.gitignore
+++ b/m4/.gitignore
@@ -3,4 +3,3 @@ ltoptions.m4
 ltsugar.m4
 ltversion.m4
 lt~obsolete.m4
-
-- 
2.1.3

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

[systemd-devel] [PATCH 5/5] Remove FSF mailing address

[Josh Triplett]

It has changed in the past, and these days, anyone can get a copy of the
LGPL via the web rather than by post.
---
 src/abc/libabc.h | 4 
 src/libabc-private.h | 4 
 src/libabc.c | 4 
 src/test-libabc.c| 4 
 4 files changed, 16 deletions(-)

diff --git a/src/abc/libabc.h b/src/abc/libabc.h
index 8924033..d33129b 100644
--- a/src/abc/libabc.h
+++ b/src/abc/libabc.h
@@ -12,10 +12,6 @@
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public
-  License along with this library; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #ifndef _LIBABC_H_
diff --git a/src/libabc-private.h b/src/libabc-private.h
index a76f822..7c9ad93 100644
--- a/src/libabc-private.h
+++ b/src/libabc-private.h
@@ -12,10 +12,6 @@
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public
-  License along with this library; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #ifndef _LIBABC_PRIVATE_H_
diff --git a/src/libabc.c b/src/libabc.c
index 23fdcd5..d6ef0b4 100644
--- a/src/libabc.c
+++ b/src/libabc.c
@@ -12,10 +12,6 @@
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public
-  License along with this library; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #include 
diff --git a/src/test-libabc.c b/src/test-libabc.c
index 6734944..9051966 100644
--- a/src/test-libabc.c
+++ b/src/test-libabc.c
@@ -12,10 +12,6 @@
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc.,
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 */
 
 #include 
-- 
2.1.3

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

[systemd-devel] libabc, sub-objects, and reference counting

[Josh Triplett]

The sample libabc includes functions to get a "thing", as a sample
sub-object of the overall library context.  Each "thing" has a reference
to the parent library context, and a function to return that reference.
Given that, shouldn't abc_thing_new_from_string call abc_ref, and
abc_thing_unref call abc_unref?

In particular, consider a language binding for a language with garbage
collection, built-in reference counting, or some other mechanism to
avoid requiring explicit calls to _unref functions.  The creation of a
new abc context would call abc_new, and arrange to call abc_unref when
the program no longer needs that abc context.  Similarly, the creation
of a new thing would take an abc context, call abc_thing_new_from_string
(or some similar creation function), and arrange to call abc_thing_unref
when the program no longer needs that thing.  Code in such a language
might create an abc, immediately create a thing, use the thing, and let
all the now-unreferenced objects get destroyed.  If "use the thing"
references the thing but not the abc context, the language could decide
to call abc_unref immediately after creating the thing, then use the
thing, which would have a pointer to an invalid abc context.

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

Re: [systemd-devel] libabc, sub-objects, and reference counting

[Josh Triplett]

On Mon, Dec 08, 2014 at 05:09:17PM +0100, David Herrmann wrote:
> On Sun, Dec 7, 2014 at 2:39 AM, Josh Triplett  wrote:
> > The sample libabc includes functions to get a "thing", as a sample
> > sub-object of the overall library context.  Each "thing" has a reference
> > to the parent library context, and a function to return that reference.
> > Given that, shouldn't abc_thing_new_from_string call abc_ref, and
> > abc_thing_unref call abc_unref?
> 
> Sure! Sounds like an oversight in libabc.

I'll send in a patch.

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

[systemd-devel] [PATCH] libabc: Make things hold a reference to their context

[Josh Triplett]

The sample libabc includes functions to get a "thing", as a sample
sub-object of the overall library context.  Each "thing" has a reference
to the parent library context, and a function to return that reference.
Given that, abc_thing_new_from_string should call abc_ref, and
abc_thing_unref should call abc_unref when freeing a thing.
---
 src/libabc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/libabc.c b/src/libabc.c
index d6ef0b4..21e434b 100644
--- a/src/libabc.c
+++ b/src/libabc.c
@@ -251,6 +251,7 @@ ABC_EXPORT struct abc_thing *abc_thing_unref(struct 
abc_thing *thing)
 if (thing->refcount > 0)
 return NULL;
 dbg(thing->ctx, "context %p released\n", thing);
+abc_unref(thing->ctx);
 free(thing);
 return NULL;
 }
@@ -269,7 +270,7 @@ ABC_EXPORT int abc_thing_new_from_string(struct abc_ctx 
*ctx, const char *string
 return -ENOMEM;
 
 t->refcount = 1;
-t->ctx = ctx;
+t->ctx = abc_ref(ctx);
 *thing = t;
 return 0;
 }
-- 
2.1.3

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

Re: [systemd-devel] [PATCH 0/5] Enhancements to libabc template project

[Josh Triplett]

On Thu, Dec 25, 2014 at 10:20:14PM +0100, Kay Sievers wrote:
> On Sat, Dec 6, 2014 at 11:46 PM, Josh Triplett  wrote:
> > I went to use libabc as the basis for a new library, and found a few issues;
> > rather than just correcting them in my own library, I'd like to push the
> > changes back into libabc.
> >
> > Josh Triplett (5):
> >   Makefile.am: Don't add abc subdirectory to include path
> >   Makefile.am: Don't define LIBEXECDIR
> >   autogen.sh: set -e separately, rather than putting -e in the shebang line
> >   m4/.gitignore: Remove stray blank line.
> >   Remove FSF mailing address
> 
> All five patches applied.

Thanks!

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

[systemd-devel] [PATCH] TODO: Simple conditionals in tmpfiles

[Josh Triplett]

---

Strawman proposal, open to suggestions.  A change like this would make
tmpfiles flexible enough to detect what permission configuration an
admin wants to use and go along with that.  In general, "set a
directory's permissions based on the set{u,g}id status of the binary"
seems common enough to want to support; tmpfiles can implement this with
a simple stat and comparison.

Could potentially be more configurable, by capturing the mode, user, and
group of the item listed as the conditional path, and making them
available as placeholders within the subitem, but that seems like
overkill for the most common cases.

 TODO | 4 
 1 file changed, 4 insertions(+)

diff --git a/TODO b/TODO
index 6cac3e2..988f855 100644
--- a/TODO
+++ b/TODO
@@ -570,6 +570,10 @@ Features:
 * tmpfiles:
   - check systemd-tmpfiles for selinux context hookup for mknod(), symlink() 
and similar
   - apply "x" on "D" too (see patch from William Douglas)
+  - Simple conditionals: "C path mode user group - (tmpfiles-line)" does 
tmpfiles-line if path has mode, user, and group:
+C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775 root utmp
+C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755 root utmp
+C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777 root utmp
 
 * for services: don't set $HOME in services unless requested
 
-- 
1.9.0

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

Re: [systemd-devel] [PATCH] TODO: Simple conditionals in tmpfiles

[Josh Triplett]

On Sat, Mar 01, 2014 at 03:03:17PM +, Colin Walters wrote:
> On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett
>  wrote:
> >---
> >
> >Strawman proposal, open to suggestions.
> >
> ...
> >
> >+  - Simple conditionals: "C path mode user group -
> >(tmpfiles-line)" does tmpfiles-line if path has mode, user, and
> >group:
> >+C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775
> >root utmp
> >+C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755
> >root utmp
> >+C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777
> >root utmp
> >
> While I know I *just* posted a mail suggesting that more service
> state move to unit files... this feels pretty hacky to me.
> 
> Are there any use cases other than screen?

Games: "if the game has group games and mode 2755...".  But yeah, it
does seem like a hack.  In any case, given that the Debian screen
maintainer ended up accepting another solution instead (telling the
admin to create an overriding /etc/tmpfiles.d file if they change the
permissions, and handling upgrades via postinst), I don't feel strongly
attached to this proposal if nobody sees another useful application for
it.

Besides, inventing a new conditional syntax seems wrong.  Might work
better to introduce a new unit type, foo.tmpfiles, with the full set of
ConditionFoo from unit files, and then add a couple of additional
ConditionFoo types based on data available by statting files.

> I also don't like the idea of admins "configuring" via chmod on
> stuff in /usr/bin.  OSTree simply won't support that for example.

I can't argue with that; I'd personally rather see screen handled via a
set of packages, one per permission model, with the admin installing the
one they want.  Or better yet:

> A lot of this may come back to the discussion about screen and
> sessions.  If for example, users could request a new headless
> session, then most of the screen security-related architecture would
> be completely unnecessary with systemd, since the per-user state
> could just be hooked off of the per-user runtime dir.
> 
> The per-user runtime dir would stay alive because the headless
> session would keep the user around.

I'd certainly love to see a saner implementation of screen multiuser
support that doesn't require root.

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

[systemd-devel] systemd-backlight and backlight level 0

[Josh Triplett]

systemd-backlight saves backlight levels on shutdown, and restores them
on startup.  However, on some systems, backlight level 0 actually turns
the backlight *off*; this can potentially make the system unusable.
Complicating matters, on most systems, nothing pays attention to the
brightness adjustment keys in text mode.

I'd suggest one or both of the following two changes, to avoid a painful
failure mode:

- systemd-backlight should avoid saving/restoring a backlight level of
  0, and have a minimum backlight level.  (Possibly overridable via
  configuration, for people who *really* want to restore backlight level
  0.)

- Something ought to listen to the brightness keys (and perhaps other
  hotkeys) in pure text mode.  systemd seems like a good place for such
  a something to live.


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

Re: [systemd-devel] systemd-backlight and backlight level 0

[Josh Triplett]

On Wed, Mar 05, 2014 at 06:59:27PM +0100, David Herrmann wrote:
> On Wed, Mar 5, 2014 at 6:46 PM, Josh Triplett  wrote:
> > systemd-backlight saves backlight levels on shutdown, and restores them
> > on startup.  However, on some systems, backlight level 0 actually turns
> > the backlight *off*; this can potentially make the system unusable.
> > Complicating matters, on most systems, nothing pays attention to the
> > brightness adjustment keys in text mode.
> >
> > I'd suggest one or both of the following two changes, to avoid a painful
> > failure mode:
> >
> > - systemd-backlight should avoid saving/restoring a backlight level of
> >   0, and have a minimum backlight level.  (Possibly overridable via
> >   configuration, for people who *really* want to restore backlight level
> >   0.)
> 
> Never restoring val==0 seems fine to me.

Likewise.

> > - Something ought to listen to the brightness keys (and perhaps other
> >   hotkeys) in pure text mode.  systemd seems like a good place for such
> >   a something to live.
> 
> We cannot do that. It requires keymap-handling (as brightness keys are
> handled on the keysym, not keycode level) and this is exclusive
> territory of the compositor (or other foreground session controllers).

Perhaps this will get fixed when we switch from kernel VTs to a
userspace-managed console, then.

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

Re: [systemd-devel] systemd-backlight and backlight level 0

[Josh Triplett]

On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote:
> On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote:
> > systemd-backlight saves backlight levels on shutdown, and restores them
> > on startup.  However, on some systems, backlight level 0 actually turns
> > the backlight *off*; this can potentially make the system unusable.
> > Complicating matters, on most systems, nothing pays attention to the
> > brightness adjustment keys in text mode.
> > 
> > I'd suggest one or both of the following two changes, to avoid a painful
> > failure mode:
> > 
> > - systemd-backlight should avoid saving/restoring a backlight level of
> >   0, and have a minimum backlight level.  (Possibly overridable via
> >   configuration, for people who *really* want to restore backlight level
> >   0.)
> 
> To deal with situations like this there's systemd.restore_state=0 on the
> kernel cmdline, see kernel-command-line(7).

Yeah, I've seen that one; however, having to reboot the system and
change the kernel command line to unbreak it seems less ideal than
having the system avoid broken states to begin with.

> I could be convinced to fix brightness level 0 to 1 when restoring. But
> then again, I fear the next people will come then and say "1 is only
> marginally better than 0, i want the minimum to be 16!"... Or even
> others saying "Dude, I only got 3 brightness levels, and you took one
> away from me...". So I am not enthusiastic about the idea...

Given the choice between maximum flexibility and never making the system
unusable, I'll take the latter.  Not that hard to make it configurable,
if that proves necessary.

On restore, I'd suggest reading max_brightness, and if the stored value
falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it
to that value instead.  (Ideally there should be some way to ask the
driver "what level of brightness will produce a non-zero value in
actual_brightness", but no such mechanism seems to exist.)

Does that sound reasonable?

> > - Something ought to listen to the brightness keys (and perhaps other
> >   hotkeys) in pure text mode.  systemd seems like a good place for such
> >   a something to live.
> 
> That's definitely a job for the DE I am sure, so that can it do an OSD
> and all the other stuff. We do power button handling in logind only
> because what it does is relatively important and really close to the
> system lifecycle... But brightness keys (or volume keys..) are not close
> at all. I am really sure that that's for the DEs to handle, not us.

DEs don't handle the text consoles.  However, it does sound like this
will have to wait for kmscon or equivalent.

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

Re: [systemd-devel] systemd-backlight and backlight level 0

[Josh Triplett]

On Wed, Mar 05, 2014 at 10:21:17PM +0100, David Herrmann wrote:
> On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett  wrote:
> > On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote:
> >> On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote:
> >> > systemd-backlight saves backlight levels on shutdown, and restores them
> >> > on startup.  However, on some systems, backlight level 0 actually turns
> >> > the backlight *off*; this can potentially make the system unusable.
> >> > Complicating matters, on most systems, nothing pays attention to the
> >> > brightness adjustment keys in text mode.
> >> >
> >> > I'd suggest one or both of the following two changes, to avoid a painful
> >> > failure mode:
> >> >
> >> > - systemd-backlight should avoid saving/restoring a backlight level of
> >> >   0, and have a minimum backlight level.  (Possibly overridable via
> >> >   configuration, for people who *really* want to restore backlight level
> >> >   0.)
> >>
> >> To deal with situations like this there's systemd.restore_state=0 on the
> >> kernel cmdline, see kernel-command-line(7).
> >
> > Yeah, I've seen that one; however, having to reboot the system and
> > change the kernel command line to unbreak it seems less ideal than
> > having the system avoid broken states to begin with.
> 
> I'd expect this to be set on the "recovery boot" option. At I know
> some distros always provide two boot entries and to me this seems like
> the right place to set it.

Not a bad idea, but rather than requiring the addition of an extra
option (or potentially more than one, if other parts of systemd might
want to be more conservative on recovery as well), how about having
systemd-backlight treat "single" as "systemd.restore_state=0"?

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

[systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer

[Josh Triplett]

avoid_cleanup also returns a copy of the pointer, making it convenient
to use at the point where initialization completes, to hand the constructed
object off somewhere without freeing it.

Change all NULL assignments tagged with /* avoid cleanup */ to use this
instead.
---

Seems like a common pattern, and this makes it more self-documenting.
In particular, the use in systemctl.c's list_timers function now feels
like a single logical operation of "hand ownership of this object off to
something else and don't clean it up".

 src/shared/macro.h| 7 +++
 src/systemctl/systemctl.c | 8 +++-
 src/timedate/timedated.c  | 5 +
 src/tmpfiles/tmpfiles.c   | 2 +-
 src/udev/udevadm-hwdb.c   | 2 +-
 5 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/src/shared/macro.h b/src/shared/macro.h
index 08a036b..1e521bc 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -337,6 +337,13 @@ do {   
 \
 _found; \
 })
 
+#define avoid_cleanup(p)\
+({  \
+typeof(p) _p = (p); \
+(p) = NULL; \
+_p; \
+})
+
 /* Define C11 thread_local attribute even on older gcc compiler
  * version */
 #ifndef thread_local
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..d7983d1 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -749,8 +749,8 @@ static int list_sockets(sd_bus *bus, char **args) {
 
 /* from this point on we will cleanup those socket_infos */
 cs += c;
-free(listening);
-listening = triggered = NULL; /* avoid cleanup */
+free(avoid_cleanup(listening));
+avoid_cleanup(triggered);
 }
 
 qsort_safe(socket_infos, cs, sizeof(struct socket_info),
@@ -979,10 +979,8 @@ static int list_timers(sd_bus *bus, char **args) {
 timer_infos[c++] = (struct timer_info) {
 .id = u->id,
 .next_elapse = m,
-.triggered = triggered,
+.triggered = avoid_cleanup(triggered),
 };
-
-triggered = NULL; /* avoid cleanup */
 }
 
 qsort_safe(timer_infos, c, sizeof(struct timer_info),
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index d85ce57..0494d53 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -281,10 +281,7 @@ static char** get_ntp_services(void) {
 }
 }
 
-i = r;
-r = NULL; /* avoid cleanup */
-
-return strv_uniq(i);
+return strv_uniq(avoid_cleanup(r));
 }
 
 static int context_read_ntp(Context *c, sd_bus *bus) {
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 6e36dc7..45f79e2 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1261,7 +1261,7 @@ static int parse_line(const char *fname, unsigned line, 
const char *buffer) {
 return r;
 }
 
-i = NULL; /* avoid cleanup */
+avoid_cleanup(i);
 
 return 0;
 }
diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c
index 65cbf61..7b6e0af 100644
--- a/src/udev/udevadm-hwdb.c
+++ b/src/udev/udevadm-hwdb.c
@@ -219,7 +219,7 @@ static int trie_insert(struct trie *trie, struct trie_node 
*node, const char *se
 if (err)
 return err;
 
-new_child = NULL; /* avoid cleanup */
+avoid_cleanup(new_child);
 break;
 }
 i += p;
-- 
1.9.0

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

[systemd-devel] [PATCH] Use strlen even for constant strings

[Josh Triplett]

GCC optimizes strlen("string constant") to a constant, even with -O0.
Thus, replace patterns like sizeof("string constant")-1 with
strlen("string constant") where possible, for clarity.  In particular,
for expressions intended to add up the lengths of components going into
a string, this often makes it clearer that the expression counts the
trailing '\0' exactly once, by putting the +1 for the '\0' at the end of
the expression, rather than hidden in a sizeof in the middle of the
expression.
---

Motivation: staring at a pile of string handling code, carefully vetting
it for off-by-one errors, and encountering one too many size expressions
whose handling of the trailing '\0' didn't instantly follow from a
glance at the expression.

 src/core/dbus.c|  2 +-
 src/core/service.c |  2 +-
 src/journal/journald-server.c  |  2 +-
 src/journal/journald-syslog.c  |  2 +-
 src/libsystemd/sd-bus/bus-kernel.c |  4 ++--
 src/libsystemd/sd-bus/bus-socket.c |  4 ++--
 src/libsystemd/sd-bus/bus-track.c  |  2 +-
 src/shared/cgroup-util.c   |  2 +-
 src/shared/unit-name.c |  2 +-
 src/shared/util.c  |  2 +-
 src/sysctl/sysctl.c|  2 +-
 src/systemctl/systemctl.c  | 40 +++---
 src/udev/udev-rules.c  | 14 ++---
 13 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/src/core/dbus.c b/src/core/dbus.c
index 03f3738..72f36bd 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -953,7 +953,7 @@ static int bus_init_private(Manager *m) {
 return 0;
 
 strcpy(sa.un.sun_path, "/run/systemd/private");
-salen = offsetof(union sockaddr_union, un.sun_path) + 
sizeof("/run/systemd/private") - 1;
+salen = offsetof(union sockaddr_union, un.sun_path) + 
strlen("/run/systemd/private");
 } else {
 size_t left = sizeof(sa.un.sun_path);
 char *p = sa.un.sun_path;
diff --git a/src/core/service.c b/src/core/service.c
index 121ddec..41b95ab 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -361,7 +361,7 @@ static int service_arm_timer(Service *s, usec_t usec) {
 static char *sysv_translate_name(const char *name) {
 char *r;
 
-r = new(char, strlen(name) + sizeof(".service"));
+r = new(char, strlen(name) + strlen(".service") + 1);
 if (!r)
 return NULL;
 
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 8680650..7595248 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -686,7 +686,7 @@ static void dispatch_message_real(
 #ifdef HAVE_SELINUX
 if (use_selinux()) {
 if (label) {
-x = alloca(sizeof("_SELINUX_CONTEXT=") + 
label_len);
+x = alloca(strlen("_SELINUX_CONTEXT=") + 
label_len + 1);
 
 *((char*) mempcpy(stpcpy(x, 
"_SELINUX_CONTEXT="), label, label_len)) = 0;
 IOVEC_SET_STRING(iovec[n++], x);
diff --git a/src/journal/journald-syslog.c b/src/journal/journald-syslog.c
index 241f7ed..eadc0c4 100644
--- a/src/journal/journald-syslog.c
+++ b/src/journal/journald-syslog.c
@@ -45,7 +45,7 @@ static void forward_syslog_iovec(Server *s, const struct 
iovec *iovec, unsigned
 .msg_iovlen = n_iovec,
 .msg_name = &sa,
 .msg_namelen = offsetof(union sockaddr_union, un.sun_path)
-   + sizeof("/run/systemd/journal/syslog") - 1,
+   + strlen("/run/systemd/journal/syslog"),
 };
 struct cmsghdr *cmsg;
 union {
diff --git a/src/libsystemd/sd-bus/bus-kernel.c 
b/src/libsystemd/sd-bus/bus-kernel.c
index 2a1b0b4..d339090 100644
--- a/src/libsystemd/sd-bus/bus-kernel.c
+++ b/src/libsystemd/sd-bus/bus-kernel.c
@@ -1389,7 +1389,7 @@ int bus_kernel_create_starter(const char *bus, const char 
*name, BusNamePolicy *
 assert(bus);
 assert(name);
 
-p = alloca(sizeof("/dev/kdbus/") - 1 + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + sizeof("/bus"));
+p = alloca(strlen("/dev/kdbus/") + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + strlen("/bus") + 1);
 sprintf(p, "/dev/kdbus/%lu-%s/bus", (unsigned long) getuid(), bus);
 
 fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC);
@@ -1501,7 +1501,7 @@ int bus_kernel_create_monitor(const char *bus) {
 
 assert(bus);
 
-p = alloca(sizeof("/dev/kdbus/") - 1 + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + sizeof("/bus"));
+p = alloca(strlen("/dev/kdbus/") + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + strlen("/bus") + 1);
 sprintf(p, "/dev/kdbus/%lu-%s/bus", (unsigned long) getuid(), bus);
 
 fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC);
diff --git a/src/libsystemd/sd-bus/bus-socket.c 
b/src/

Re: [systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer

[Josh Triplett]

On Mon, Mar 10, 2014 at 04:44:02PM +0100, Lennart Poettering wrote:
> On Sat, 08.03.14 20:33, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > avoid_cleanup also returns a copy of the pointer, making it convenient
> > to use at the point where initialization completes, to hand the constructed
> > object off somewhere without freeing it.
> > 
> > Change all NULL assignments tagged with /* avoid cleanup */ to use this
> > instead.
> > ---
> > 
> > Seems like a common pattern, and this makes it more self-documenting.
> > In particular, the use in systemctl.c's list_timers function now feels
> > like a single logical operation of "hand ownership of this object off to
> > something else and don't clean it up".
> 
> Hmmm, I am all for synctactic sugar, but I don't see the benefit of this
> one really... Especially given that that disabling cleanup is done
> different for different types... For example, disabling cleanup for an
> fd is by assigning -1...

As far as I can tell, that's the *only* differing case.  Everything else
is a pointer and uses NULL.

> I would see benefit in this if we could maybe make this
> type-sensitive... not sure though if C would allow that? I at least
> cannot think of a way to do that?

C11 allows it using _Generic, if you're willing to rely on that.
__builtin_types_compatible_p and some casts could work too.  But again,
I think the only two cases are "int" and "pointer".

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

Re: [systemd-devel] [PATCH] util: Rewrite in_charset to use strspn

[Josh Triplett]

On Wed, Mar 12, 2014 at 12:49:08AM +0100, Lennart Poettering wrote:
> Can you turn this into an inline function please? If it's that simple it
> sounds better to just make it an inline function in the .h file, instead
> of the .c file...

Sure.  Mind if I do that as a two-patch series?  I prefer to avoid
simultaneously changing code and moving it, since it makes the change
diff less obvious.

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

[systemd-devel] [PATCH] util: Make in_charset a static inline in util.h

[Josh Triplett]

With in_charset now reduced to a one-liner (plus asserts), make it a
static inline.
---

This applies on top of the previous patch simplifying in_charset.

 src/shared/util.c | 6 --
 src/shared/util.h | 6 +-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index 82326df..9f79409 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -920,12 +920,6 @@ char *delete_chars(char *s, const char *bad) {
 return s;
 }
 
-bool in_charset(const char *s, const char* charset) {
-assert(s);
-assert(charset);
-return s[strspn(s, charset)] == '\0';
-}
-
 char *file_in_same_dir(const char *path, const char *filename) {
 char *e, *r;
 size_t k;
diff --git a/src/shared/util.h b/src/shared/util.h
index c2bc977..0c8eb4b 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -529,7 +529,11 @@ char *strjoin(const char *x, ...) _sentinel_;
 
 bool is_main_thread(void);
 
-bool in_charset(const char *s, const char* charset) _pure_;
+static inline bool _pure_ in_charset(const char *s, const char* charset) {
+assert(s);
+assert(charset);
+return s[strspn(s, charset)] == '\0';
+}
 
 int block_get_whole_disk(dev_t d, dev_t *ret);
 
-- 
1.9.0

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

[systemd-devel] [PATCH 1/2] backlight: Fix copy/paste error printing an unrelated error code

[Josh Triplett]

udev_device_get_sysattr_value returns NULL on failure, but doesn't
provide an error code; thus, when printing an error from it, don't print
an unrelated error code from a previous call.
---
 src/backlight/backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 86f10cc..81470b3 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -322,7 +322,7 @@ int main(int argc, char *argv[]) {
 
 value = udev_device_get_sysattr_value(device, "brightness");
 if (!value) {
-log_error("Failed to read system attribute: %s", 
strerror(-r));
+log_error("Failed to read system attribute");
 return EXIT_FAILURE;
 }
 
-- 
1.9.0

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

[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

[Josh Triplett]

Some systems turn the backlight all the way off at the lowest levels.
Clamp saved brightness to at least 1 or 5% of max_brightness.  This
avoids preserving an unreadably dim screen, which would otherwise force
the user to disable state restoration.
---
 src/backlight/backlight.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 81470b3..b776ab5 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -292,6 +292,7 @@ int main(int argc, char *argv[]) {
 
 if (streq(argv[1], "load") && shall_restore_state()) {
 _cleanup_free_ char *value = NULL;
+const char *max_brightness_str;
 
 if (!validate_device(udev, device))
 return EXIT_SUCCESS;
@@ -306,6 +307,44 @@ int main(int argc, char *argv[]) {
 return EXIT_FAILURE;
 }
 
+/* Some systems turn the backlight all the way off at the
+ * lowest levels.  Clamp saved brightness to at least 1 or 5%
+ * of max_brightness.  This avoids preserving an unreadably dim
+ * screen, which would otherwise force the user to disable
+ * state restoration.
+ */
+max_brightness_str = udev_device_get_sysattr_value(device, 
"max_brightness");
+if (!max_brightness_str) {
+log_warning("Failed to read max_brightness attribute; 
not checking saved brightness");
+} else {
+unsigned long long brightness, max_brightness, 
new_brightness;
+
+r = safe_atollu(value, &brightness);
+if (r < 0) {
+log_error("Failed to parse brightness \"%s\": 
%s", value, strerror(-r));
+return EXIT_FAILURE;
+}
+
+r = safe_atollu(max_brightness_str, &max_brightness);
+if (r < 0) {
+log_error("Failed to parse max_brightness 
\"%s\": %s", max_brightness_str, strerror(-r));
+return EXIT_FAILURE;
+}
+
+new_brightness = MAX3(brightness, 1, 
max_brightness/20);
+if (new_brightness != brightness) {
+_cleanup_free_ char *old_value = value;
+
+value = asprintf("%llu", new_brightness);
+if (!value) {
+log_oom();
+return EXIT_FAILURE;
+}
+
+log_warning("Saved brightness %s too low; 
increasing to %s", old_value, value);
+}
+}
+
 r = udev_device_set_sysattr_value(device, "brightness", value);
 if (r < 0) {
 log_error("Failed to write system attribute: %s", 
strerror(-r));
-- 
1.9.0

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

[systemd-devel] [PATCH] util: Rewrite in_charset to use strspn

[Josh Triplett]

This simplifies in_charset down to a one-liner, and allows for possible
optimizations of strspn in libc.
---
 src/shared/util.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index d28caae..82326df 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -921,16 +921,9 @@ char *delete_chars(char *s, const char *bad) {
 }
 
 bool in_charset(const char *s, const char* charset) {
-const char *i;
-
 assert(s);
 assert(charset);
-
-for (i = s; *i; i++)
-if (!strchr(charset, *i))
-return false;
-
-return true;
+return s[strspn(s, charset)] == '\0';
 }
 
 char *file_in_same_dir(const char *path, const char *filename) {
-- 
1.9.0

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

Re: [systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

[Josh Triplett]

On Wed, Mar 12, 2014 at 03:32:47AM +0100, Lennart Poettering wrote:
> On Tue, 11.03.14 18:55, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > +/* Some systems turn the backlight all the way off at the
> > + * lowest levels.  Clamp saved brightness to at least 1 or 
> > 5%
> > + * of max_brightness.  This avoids preserving an 
> > unreadably dim
> > + * screen, which would otherwise force the user to disable
> > + * state restoration.
> > + */
> > +max_brightness_str = udev_device_get_sysattr_value(device, 
> > "max_brightness");
> > +if (!max_brightness_str) {
> > +log_warning("Failed to read max_brightness 
> > attribute; not checking saved brightness");
> > +} else {
> 
> We try to avoid unnnecessary {} for single-line if blocks, if we can...

Even when the else block *does* need the braces?  (Note that kernel
style says to avoid braces on single-line blocks but always use braces
on all branches of an if/else-if/else if any branch needs them.)

> Hmmm, could you maybe move the entire clamping thing into a function of
> its own?  Maybe clamp_brightness(struct udev_device *d, char
> **brightness) or so, that simply patches the brightness string if it
> feels like it, otherwise leaves it unmodified?

Sure.

> > +unsigned long long brightness,
> > max_brightness, new_brightness;
> 
> Wow, you expect a lot of brightness levels! ;-)
> 
> I'd just stick to "unsigned" here... Keeps it more readable...

It's just two words ("long long") and a couple of "ll"s later, but OK.

> > +
> > +r = safe_atollu(value, &brightness);
> > +if (r < 0) {
> > +log_error("Failed to parse brightness 
> > \"%s\": %s", value, strerror(-r));
> > +return EXIT_FAILURE;
> > +}
> > +
> > +r = safe_atollu(max_brightness_str, 
> > &max_brightness);
> > +if (r < 0) {
> > +log_error("Failed to parse max_brightness 
> > \"%s\": %s", max_brightness_str, strerror(-r));
> > +return EXIT_FAILURE;
> > +}
> 
> Hmm, I'd prefer if the whole clamping business would be
> non-fatal. i.e. it clamps if it can read the files and parse them, but
> if it can't it won't do anything...

I thought about that, but it would have complicated the logic, and those
kernel files should always be numbers anyway.  However, with a move to a
separate function, this gets easier with early return, so sure.

> > +new_brightness = MAX3(brightness, 1, 
> > max_brightness/20);
> > +if (new_brightness != brightness) {
> > +_cleanup_free_ char *old_value = value;
> > +
> > +value = asprintf("%llu",
> > new_brightness);
> 
> asprintf() works differently... r = asprintf(&value, "%llu", 
> new_brightness)...

Gah, I fixed that and then managed to send the wrong patch, sorry.

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

[systemd-devel] [PATCHv2 1/2] backlight: Fix copy/paste error printing an unrelated error code

[Josh Triplett]

udev_device_get_sysattr_value returns NULL on failure, but doesn't
provide an error code; thus, when printing an error from it, don't print
an unrelated error code from a previous call.
---
v2: Patch 1/2 unchanged from v1.
 src/backlight/backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 86f10cc..81470b3 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -322,7 +322,7 @@ int main(int argc, char *argv[]) {
 
 value = udev_device_get_sysattr_value(device, "brightness");
 if (!value) {
-log_error("Failed to read system attribute: %s", 
strerror(-r));
+log_error("Failed to read system attribute");
 return EXIT_FAILURE;
 }
 
-- 
1.9.0

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

[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

[Josh Triplett]

Some systems turn the backlight all the way off at the lowest levels.
Clamp saved brightness to at least 1 or 5% of max_brightness.  This
avoids preserving an unreadably dim screen, which would otherwise force
the user to disable state restoration.
---
v2: Send the right patch this time.  Factor clamping into a separate
function.  Make failures in clamping non-fatal.  Use unsigned rather
than unsigned long long.

 src/backlight/backlight.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 81470b3..44308e0 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -192,6 +192,48 @@ static bool validate_device(struct udev *udev, struct 
udev_device *device) {
 return true;
 }
 
+/* Some systems turn the backlight all the way off at the lowest levels.
+ * clamp_brightness clamps the saved brightness to at least 1 or 5% of
+ * max_brightness.  This avoids preserving an unreadably dim screen, which
+ * would otherwise force the user to disable state restoration. */
+static void clamp_brightness(struct udev_device *device, char **value) {
+int r;
+const char *max_brightness_str;
+unsigned brightness, max_brightness, new_brightness;
+
+max_brightness_str = udev_device_get_sysattr_value(device, 
"max_brightness");
+if (!max_brightness_str) {
+log_warning("Failed to read max_brightness attribute; not 
checking saved brightness");
+return;
+}
+
+r = safe_atou(*value, &brightness);
+if (r < 0) {
+log_warning("Failed to parse brightness \"%s\": %s", *value, 
strerror(-r));
+return;
+}
+
+r = safe_atou(max_brightness_str, &max_brightness);
+if (r < 0) {
+log_warning("Failed to parse max_brightness \"%s\": %s", 
max_brightness_str, strerror(-r));
+return;
+}
+
+new_brightness = MAX3(brightness, 1U, max_brightness/20);
+if (new_brightness != brightness) {
+char *old_value = *value;
+
+r = asprintf(value, "%u", new_brightness);
+if (r < 0) {
+log_warning("Failed to format new brightness: %s", 
strerror(-r));
+return;
+}
+
+log_warning("Saved brightness %s too low; increasing to %s", 
old_value, *value);
+free(old_value);
+}
+}
+
 int main(int argc, char *argv[]) {
 _cleanup_udev_unref_ struct udev *udev = NULL;
 _cleanup_udev_device_unref_ struct udev_device *device = NULL;
@@ -306,6 +348,8 @@ int main(int argc, char *argv[]) {
 return EXIT_FAILURE;
 }
 
+clamp_brightness(device, &value);
+
 r = udev_device_set_sysattr_value(device, "brightness", value);
 if (r < 0) {
 log_error("Failed to write system attribute: %s", 
strerror(-r));
-- 
1.9.0

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

[systemd-devel] [PATCH rebased] Use strlen even for constant strings

[Josh Triplett]

GCC optimizes strlen("string constant") to a constant, even with -O0.
Thus, replace patterns like sizeof("string constant")-1 with
strlen("string constant") where possible, for clarity.  In particular,
for expressions intended to add up the lengths of components going into
a string, this often makes it clearer that the expression counts the
trailing '\0' exactly once, by putting the +1 for the '\0' at the end of
the expression, rather than hidden in a sizeof in the middle of the
expression.
---

On Sat, Mar 15, 2014 at 05:37:49AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> strlen() is indeed much nicer. Unfortunately it stopped applying cleanly...
> Could you rebase this?

Done; git rebased it automatically with no conflicts.  (am -3 might work
in the future for patches that trivially rebase.)

 src/core/dbus.c|  2 +-
 src/core/service.c |  2 +-
 src/journal/journald-server.c  |  2 +-
 src/journal/journald-syslog.c  |  2 +-
 src/libsystemd/sd-bus/bus-kernel.c |  4 ++--
 src/libsystemd/sd-bus/bus-socket.c |  4 ++--
 src/libsystemd/sd-bus/bus-track.c  |  2 +-
 src/shared/cgroup-util.c   |  2 +-
 src/shared/unit-name.c |  2 +-
 src/shared/util.c  |  2 +-
 src/sysctl/sysctl.c|  2 +-
 src/systemctl/systemctl.c  | 40 +++---
 src/udev/udev-rules.c  | 14 ++---
 13 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/src/core/dbus.c b/src/core/dbus.c
index 03f3738..72f36bd 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -953,7 +953,7 @@ static int bus_init_private(Manager *m) {
 return 0;
 
 strcpy(sa.un.sun_path, "/run/systemd/private");
-salen = offsetof(union sockaddr_union, un.sun_path) + 
sizeof("/run/systemd/private") - 1;
+salen = offsetof(union sockaddr_union, un.sun_path) + 
strlen("/run/systemd/private");
 } else {
 size_t left = sizeof(sa.un.sun_path);
 char *p = sa.un.sun_path;
diff --git a/src/core/service.c b/src/core/service.c
index 121ddec..41b95ab 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -361,7 +361,7 @@ static int service_arm_timer(Service *s, usec_t usec) {
 static char *sysv_translate_name(const char *name) {
 char *r;
 
-r = new(char, strlen(name) + sizeof(".service"));
+r = new(char, strlen(name) + strlen(".service") + 1);
 if (!r)
 return NULL;
 
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index f0117e7..5befe93 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -686,7 +686,7 @@ static void dispatch_message_real(
 #ifdef HAVE_SELINUX
 if (use_selinux()) {
 if (label) {
-x = alloca(sizeof("_SELINUX_CONTEXT=") + 
label_len);
+x = alloca(strlen("_SELINUX_CONTEXT=") + 
label_len + 1);
 
 *((char*) mempcpy(stpcpy(x, 
"_SELINUX_CONTEXT="), label, label_len)) = 0;
 IOVEC_SET_STRING(iovec[n++], x);
diff --git a/src/journal/journald-syslog.c b/src/journal/journald-syslog.c
index cbb944f..fee7d91 100644
--- a/src/journal/journald-syslog.c
+++ b/src/journal/journald-syslog.c
@@ -46,7 +46,7 @@ static void forward_syslog_iovec(Server *s, const struct 
iovec *iovec, unsigned
 .msg_iovlen = n_iovec,
 .msg_name = &sa,
 .msg_namelen = offsetof(union sockaddr_union, un.sun_path)
-   + sizeof("/run/systemd/journal/syslog") - 1,
+   + strlen("/run/systemd/journal/syslog"),
 };
 struct cmsghdr *cmsg;
 union {
diff --git a/src/libsystemd/sd-bus/bus-kernel.c 
b/src/libsystemd/sd-bus/bus-kernel.c
index 80ef15b..5c955f4 100644
--- a/src/libsystemd/sd-bus/bus-kernel.c
+++ b/src/libsystemd/sd-bus/bus-kernel.c
@@ -1390,7 +1390,7 @@ int bus_kernel_create_starter(const char *bus, const char 
*name, BusNamePolicy *
 assert(bus);
 assert(name);
 
-p = alloca(sizeof("/dev/kdbus/") - 1 + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + sizeof("/bus"));
+p = alloca(strlen("/dev/kdbus/") + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + strlen("/bus") + 1);
 sprintf(p, "/dev/kdbus/%lu-%s/bus", (unsigned long) getuid(), bus);
 
 fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC);
@@ -1502,7 +1502,7 @@ int bus_kernel_create_monitor(const char *bus) {
 
 assert(bus);
 
-p = alloca(sizeof("/dev/kdbus/") - 1 + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + sizeof("/bus"));
+p = alloca(strlen("/dev/kdbus/") + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + strlen("/bus") + 1);
 sprintf(p, "/dev/kdbus/%lu-%s/bus", (unsigned long) getuid(), bus);
 
 fd = open(p, O_RDWR|O_NOCTTY|O_

Re: [systemd-devel] [PATCH rebased] Use strlen even for constant strings

[Josh Triplett]

On Sun, Mar 16, 2014 at 02:56:10PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 15, 2014 at 11:40:07AM -0700, Josh Triplett wrote:
> > GCC optimizes strlen("string constant") to a constant, even with -O0.
> > Thus, replace patterns like sizeof("string constant")-1 with
> > strlen("string constant") where possible, for clarity.  In particular,
> > for expressions intended to add up the lengths of components going into
> > a string, this often makes it clearer that the expression counts the
> > trailing '\0' exactly once, by putting the +1 for the '\0' at the end of
> > the expression, rather than hidden in a sizeof in the middle of the
> > expression.
> Applied, thanks.
> 
> > On Sat, Mar 15, 2014 at 05:37:49AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > strlen() is indeed much nicer. Unfortunately it stopped applying 
> > > cleanly...
> > > Could you rebase this?
> > 
> > Done; git rebased it automatically with no conflicts.  (am -3 might work
> > in the future for patches that trivially rebase.)
> I tried that, but for some reason it didn't seem to work. Maybe
> your patch was missing the headers necessayr for -3?

Full commits have all those headers (the "index" lines with partial
hashes on them), but possibly I'm overestimating the capabilities of -3.
In any case, git rebase automatically did the three-way merge.

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

[systemd-devel] logind.conf.d?

[Josh Triplett]

I'd like to add support for /etc/systemd/logind.conf.d, parsed after
/etc/systemd/logind.conf.  My specific use case: I'd like to be able to
create a simple configuration package I can install on my systems that
changes the logind configuration by dropping in a snippet, rather than
hand-editing logind.conf.

Does that sound like a reasonable addition?  Happy to write the patch if
so.

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

[systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]

[Josh Triplett]

[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet.  The comments apply equally well to the latest
version, "Add DEPLOYMENT to hostnamectl".]

On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
> +static bool valid_environment(const char *environment) {
> +
> +assert(environment);
> +
> +return nulstr_contains(
> +"development\0"
> +"staging\0"
> +"production\0",
> +environment);
> +}

Can we please *not* attempt to limit or "standardize" this particular
set of machine roles?  As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies.  Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.

Debian has a file /etc/debian_chroot, used to describe the nature of a
chroot environment, such as "i386 cross" for a 32-bit build chroot, or
similar.  The default prompt then incorporates that string.  This seems
quite similar, and I'd love to see a standardized mechanism for that
kind of string.

Rather than limiting this list to a few specific tokens, could we just
provide a "MachineRole" or similar, which accepts a short freeform text
string?  Then, a staged deployment system could use this for
development/staging/production/validation/replication/blue/whatever,
while another type of system can use its own tokens here.

As general guidance, we could say something like "MachineRole should
consist of a space-separated series of printable tokens, such as
'production' or 'staging'.".  This also allows MachineRole to contain
something like "staging foobranch", for instance, which indicates a
staging server that's part of the experimental parallel foobranch
infrastructure.

This would still allow the role string to serve its primary functions:
querying it to check for particular values used within an organization,
or inserting it into prompts, window titles, and similar.

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

Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]

[Josh Triplett]

On Wed, Jul 09, 2014 at 01:16:04AM +, "Jóhann B. Guðmundsson" wrote:
> 
> On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
> >On Tue, Jul 08, 2014 at 10:45:11PM +, "Jóhann B. Guðmundsson" wrote:
> >>>
> >>>On 07/08/2014 10:45 PM, Josh Triplett wrote:
> >>>> >[Responding to this version because the latest thread hasn't appeared in
> >>>> >the mbox archives yet.  The comments apply equally well to the latest
> >>>> >version, "Add DEPLOYMENT to hostnamectl".]
> >>>> >
> >>>> >On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
> >>>>> >>+static bool valid_environment(const char *environment) {
> >>>>> >>+
> >>>>> >>+assert(environment);
> >>>>> >>+
> >>>>> >>+return nulstr_contains(
> >>>>> >>+"development\0"
> >>>>> >>+"staging\0"
> >>>>> >>+"production\0",
> >>>>> >>+environment);
> >>>>> >>+}
> >>>> >Can we please*not*  attempt to limit or "standardize" this particular
> >>>> >set of machine roles?  As already demonstrated in the previous thread,
> >>>> >people have all sorts of staged deployment strategies.  Furthermore,
> >>>> >the concept of a machine role shouldn't be limited to service deployment
> >>>> >strategies.
> >>>> >
> >>>
> >>>Roles != the environment they run in.
> >I'm not trying to bikeshed over the naming of the variable itself.  I'm
> >arguing that standardizing this particular bit of metadata won't work
> >well when so many different deployment strategies exist.  Thus, rather
> >than having a fixed set of keywords, I'd propose simply saying "this
> >contains keywords", and leaving the specific keywords up to the admin.
> >If you attempt to standardize production/development/staging, you'll
> >either end up with a model that only works for a small subset of
> >deployments, or you'll end up adding twelve more keywords, at which
> >point you might as well have just said "use whatever keyword you like".
> 
> The 4 tier covers the majority of the models since more or less the entire
> internet recommend three tier model including M$ [1]
> Anyone wanting to extend that further can do so using the "PRETTY_HOSTNAME="

"PRETTY_HOSTNAME" does not equate to "description", and in any case is
not the same thing as a deployment environment.

> This patch is very specific to deployment environment and to solve a very
> specific long standing problem and to achieve that we need to a standardize,
> if we dont we can just as well drop this patch since in the long run we
> cannot introduce something like "ConditionDeployment=" like David mentioned
> and it kinda defeat's my purpose working in this in the firsplace...

Distribution unit files will never use ConditionDeployment; only
admin-created or admin-modified unit files will.  Given that, it will
work perfectly without a standardized set of names.  Just specify that
DEPLOYMENT contains a keyword *such as* (but not limited to)
"production" or "development", and then state that ConditionDeployment
can specify a keyword.  That will work perfectly without limiting the
set of possible keywords.

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

[systemd-devel] SocketUser and SocketGroup?

[Josh Triplett]

Some daemons provide an access-controlled service via UNIX domain
sockets that have a specified user or group, and a mode like 0660.  For
instance, clamd does this.  systemd .socket units don't support setting
the user or group; systemd always creates sockets as root:root.  This
prevents replacing the socket setup code in such daemons with socket
activation, or requires workarounds such as shelling out to chown.

Commit aea54018a5e66a41318afb6c6be745b6aef48d9e
(http://cgit.freedesktop.org/systemd/systemd/commit/?id=aea54018a5e66a41318afb6c6be745b6aef48d9e)
added support for SocketUser and SocketGroup options, to set the
user and group for a UNIX domain socket or FIFO.  However, commit
e4f44e734c4f397ee5e7ba3270e014a8ae0043dd
(http://cgit.freedesktop.org/systemd/systemd/commit/?id=e4f44e734c4f397ee5e7ba3270e014a8ae0043dd)
shortly afterward reverted that, removing the new options.

Is this due to the issues with touching NSS from PID 1?

What might it take to add those options back?

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

Re: [systemd-devel] [PATCH] systemd: mount the EFI variable filesystem

[Josh Boyer]

On Wed, Oct 31, 2012 at 9:13 AM, Kay Sievers  wrote:
> On Wed, Oct 31, 2012 at 2:04 PM, Colin Walters  wrote:
>> On Mon, 2012-10-29 at 10:21 +0800, joeyli wrote:
>>
>>> I tested this patch on my UEFI notebook with latest EFI kernel git tree,
>>> the efivarfs mounted normally after system boot and I can delete/add EFI
>>> variable through /sys/firmware/efi/efivars.
>>
>> This causes systemd to output a warning if the kernel doesn't have an
>> efivars module.  I suppose to do this kind of thing "right" we'd
>> have to conditionalize the module loads on available kernel version they
>> first appeared in?
>
> We should probably suppress the warning that the module cannot be
> loaded. And then maybe make the mount conditional, depending on the
> existence of the target directory.
>
> This should make all that only trigger when the kernel module is
> available or it is compiled-in (libkmod tells the same), and do
> nothing on older kernel, kernels without the filesysystem, or
> platforms without EFI.

Yes to all of that.

For those wanting a distro kernel to play with that has this support,
we've included efivarfs in Fedora rawhide and soon in F18.

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

[systemd-devel] [PATCH] TODO: uses for SO_REUSEPORT

[Josh Triplett]

The new socket option SO_REUSEPORT would enable some new functionality;
add it to TODO.
---
 TODO |5 +
 1 file changed, 5 insertions(+)

diff --git a/TODO b/TODO
index f1a0bcf..f469e96 100644
--- a/TODO
+++ b/TODO
@@ -46,6 +46,11 @@ Fedora 19:
 
 Features:
 
+* Support SO_REUSEPORT with socket activation:
+  - Let systemd maintain a pool of servers.
+  - Use for seamless upgrades, by running the new server before stopping the
+old.
+
 * BootLoaderSpec: drop allowing ext234 for $BOOT. Clarify that the
   kernel has to be in $BOOT. Clarify that the boot loader should be
   installed to the ESP. Define a way how an installer can figure out
-- 
1.7.10.4

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

[systemd-devel] [PATCH] TODO: timer unit generation

[Josh Triplett]

---
 TODO |1 +
 1 file changed, 1 insertion(+)

diff --git a/TODO b/TODO
index 48e5d2e..eb482d0 100644
--- a/TODO
+++ b/TODO
@@ -320,6 +320,7 @@ Features:
 o CLOCK_REALTIME makes jumps (TFD_TIMER_CANCEL_ON_SET)
 o DST changes
   - Support 2012-02~4 as syntax for specifying the fourth to last day of the 
month.
+  - unit generator for compatibility with crontab and cron.d
 
 * update the kernel's TZ (sys_tz) when DST changes
 
-- 
1.7.10.4

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

[systemd-devel] [PATCH] TODO: add various journal enhancements

[Josh Triplett]

---
 TODO |7 +++
 1 file changed, 7 insertions(+)

diff --git a/TODO b/TODO
index 88be72d..48e5d2e 100644
--- a/TODO
+++ b/TODO
@@ -272,6 +272,13 @@ Features:
   - journal: store euid in journal if it differs from uid
   - journal: sanely deal with entries which are larger than the individual 
file size, but where the components would fit
   - journalctl: make journalctl smarter, and actually check groups that have 
access to /var/log/journal before printing message about recomming group 
membership for journal access
+  - Replace utmp, wtmp, btmp, and lastlog completely with journal
+  - Provide one or more FUSE filesystems:
+- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for 
all writes rather than limiting permissions
+- Provide /var/spool/crash or equivalent, exposing an index of coredumps 
directly
+- Provide decoded text logs in /var/log
+  - Port upower to use the journal for historical power information used in 
future calculations
+  - Support optional database-style indexes for frequent or 
performance-critical queries
 
 * document:
   - document unit_name_mangle()
-- 
1.7.10.4

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

[systemd-devel] [PATCH] TODO: passwd.d, group.d

[Josh Triplett]

---
 TODO |5 +
 1 file changed, 5 insertions(+)

diff --git a/TODO b/TODO
index eb482d0..6cf632a 100644
--- a/TODO
+++ b/TODO
@@ -679,6 +679,11 @@ External:
- put bootcharts in the journal
- kernel cmdline "bootchart" option for simplicity?
 
+* Support passwd.d and group.d; accumulate a persistent name/number map, to
+  preserve UID/GID assignments without requiring assignment of unique IDs at
+  adduser time.  Allows installing users without maintainer scripts, and makes
+  UID namespaces easier to manage.
+
 Regularly:
 
 * look for close() vs. close_nointr() vs. close_nointr_nofail()
-- 
1.7.10.4

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

Re: [systemd-devel] [PATCH] TODO: timer unit generation

[Josh Triplett]

On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote:
> On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett  wrote:
> 
> > +  - unit generator for compatibility with crontab and cron.d
> 
> We kind of decided to port the 40-60 things that use the .d/ dirs to
> native units right away, and leave cron as it is, and not parse its
> config files from systemd.
> 
> If people want cron, they should install it; new or common stuff
> should just not pull it in anymore. The default install should not
> require it.

I figured this fell in the general area of "wouldn't do it ourselves,
but would probably take a clean patch", which seemed like a good use of
TODO.

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

Re: [systemd-devel] [PATCH] TODO: add various journal enhancements

[Josh Triplett]

On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote:
> On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett  wrote:
> 
> > +  - Replace utmp, wtmp, btmp, and lastlog completely with journal
> 
> We should definitely add the data needed to constuct this information,
> if they are not already there.
> 
> The tools could just use the journal directly, but there is the glibc api.

Exactly; barring a compatibility library that provides the same
functions as glibc, which seems hazardous, I'd like to support tools
that only know how to read and write those files directly.

> > +  - Provide one or more FUSE filesystems:
> > +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials 
> > for all writes rather than limiting permissions
> 
> That sounds like overkill. We should surely externalize the creation
> of the files from systemd and make it optional to support legacy
> stuff, otherwise these files should rather be phased out, than
> emulated, I think.

Separate, external, and optional, definitely; no sense running it if you
have no tools around that read or write the format directly.  But given
that the glibc API (and corresponding expectations about the file
format) will exist forever, it seems sensible to have a way to support
that without actually having the files on the filesystem.

> > +- Provide /var/spool/crash or equivalent, exposing an index of 
> > coredumps directly
> 
> Coredump are really not consumed by any legacy thing that would need a
> file system. What do you have in mind here. Specialized apps that need
> that should just use the native API, not expect a file system, I
> think.

Just an idea for how to better satisfy user expectations.  Approximately
zero cost, mounted on demand, gives a view into the journal.

> > +- Provide decoded text logs in /var/log
> 
> I really don't think these plain text streams make much sense today.
> If people want them, they should install syslog. Or some other project
> can do that, I'm confident we do not want that code in systemd.

Maintaining a separate copy of log messages seems like overkill; I want
the data stored solely in the journal.  And I agree that the code
doesn't belong in the journal itself; I'm suggesting that a standalone
FUSE filesystem based on the journal library would prove useful for
compatibility with both tools that want to consume the log format and
users used to /var/log.  Seems pretty trivial to write, as well.

> > +  - Port upower to use the journal for historical power information used 
> > in future calculations
> 
> Yeah, that would be useful.
> 
> > +  - Support optional database-style indexes for frequent or 
> > performance-critical queries
> 
> Well, it is not a database, it's a pretty specialized format based on
> bisection lists. What specific thing do you have in mind?

Telling the journal in advance that you'd like to make a lot of queries
for PROPERTY, or for PROPERTY=value, and having it maintain an index
that makes such queries faster than a linear scan and filter.

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

Re: [systemd-devel] [PATCH] TODO: timer unit generation

[Josh Triplett]

On Thu, Apr 18, 2013 at 12:15:22AM +0200, Kay Sievers wrote:
> On Thu, Apr 18, 2013 at 12:11 AM, Josh Triplett  wrote:
> > On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote:
> >> On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett  
> >> wrote:
> >>
> >> > +  - unit generator for compatibility with crontab and cron.d
> >>
> >> We kind of decided to port the 40-60 things that use the .d/ dirs to
> >> native units right away, and leave cron as it is, and not parse its
> >> config files from systemd.
> >>
> >> If people want cron, they should install it; new or common stuff
> >> should just not pull it in anymore. The default install should not
> >> require it.
> >
> > I figured this fell in the general area of "wouldn't do it ourselves,
> > but would probably take a clean patch", which seemed like a good use of
> > TODO.
> 
> Not really, we cannot or don't want to cover all of cron, so cron
> stays around anyway for the grey beards, or existing things out there.

As far as I can tell, timer units already support almost everything
crontabs do; the problem then just becomes a format parser and unit
generator.

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

[systemd-devel] [PATCH] systemd-logind: Fix linking by reordering libraries in LDADD

[Josh Triplett]

libsystemd-audit needs functions from libsystemd-shared, so
libsystemd-audit needs to appear first.  Otherwise:

  CCLD   systemd-logind
./.libs/libsystemd-audit.a(audit.o): In function `audit_session_from_pid':
/home/josh/src/systemd/src/shared/audit.c:50: undefined reference to 
`detect_container'
---
 Makefile.am |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7b4b2d8..dede567 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3461,8 +3461,8 @@ systemd_logind_CFLAGS = \
 
 systemd_logind_LDADD = \
libsystemd-label.la \
-   libsystemd-shared.la \
libsystemd-audit.la \
+   libsystemd-shared.la \
libsystemd-daemon.la \
libsystemd-dbus.la \
libudev.la
-- 
1.7.10.4

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

[systemd-devel] [PATCHv2] TODO: journal enhancements

[Josh Triplett]

---

Resubmitting the uncontroversial bits.

 TODO | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/TODO b/TODO
index 88be72d..33c24ea 100644
--- a/TODO
+++ b/TODO
@@ -272,6 +272,8 @@ Features:
   - journal: store euid in journal if it differs from uid
   - journal: sanely deal with entries which are larger than the individual 
file size, but where the components would fit
   - journalctl: make journalctl smarter, and actually check groups that have 
access to /var/log/journal before printing message about recomming group 
membership for journal access
+  - Replace utmp, wtmp, btmp, and lastlog completely with journal
+  - Port upower to use the journal for historical power information used in 
future calculations
 
 * document:
   - document unit_name_mangle()
-- 
1.8.2.1

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

Re: [systemd-devel] [PATCH] TODO: add various journal enhancements

[Josh Triplett]

On Thu, Apr 18, 2013 at 12:42:38AM +0200, Kay Sievers wrote:
> On Thu, Apr 18, 2013 at 12:28 AM, Josh Triplett  wrote:
> > On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote:
> >> On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett  
> >> wrote:
> >> > +  - Provide one or more FUSE filesystems:
> >> > +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording 
> >> > credentials for all writes rather than limiting permissions
> >>
> >> That sounds like overkill. We should surely externalize the creation
> >> of the files from systemd and make it optional to support legacy
> >> stuff, otherwise these files should rather be phased out, than
> >> emulated, I think.
> >
> > Separate, external, and optional, definitely; no sense running it if you
> > have no tools around that read or write the format directly.  But given
> > that the glibc API (and corresponding expectations about the file
> > format) will exist forever, it seems sensible to have a way to support
> > that without actually having the files on the filesystem.
> 
> I don't know what *forever* means here, I kind of doubt that. It's
> pure legacy stuff that needs that, and that works with current
> systemd. Most systems out there should not need these silly files at
> all, and the use will surely not grow in the future.

Every terminal emulator, display manager, screen/tmux/etc program, or
other program that needs to embed an interactive shell should log to
utmp and family.  The glibc API represents the standard way to do so.
So either the glibc API needs to directly support logging to (and
reading from) journald, or some compatibility shim like this needs to
exist.

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

Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d

[Josh Triplett]

On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote:
> On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett  wrote:
> > ---
> >  TODO |5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/TODO b/TODO
> > index eb482d0..6cf632a 100644
> > --- a/TODO
> > +++ b/TODO
> > @@ -679,6 +679,11 @@ External:
> > - put bootcharts in the journal
> > - kernel cmdline "bootchart" option for simplicity?
> >
> > +* Support passwd.d and group.d; accumulate a persistent name/number map, to
> > +  preserve UID/GID assignments without requiring assignment of unique IDs 
> > at
> > +  adduser time.
> 
> Hmm, how is that related to systemd code? Sounds more like a glibc
> shipped feature/plugin?

It would involve a PAM plugin as well, yes, but also a system daemon
watching those directories for changes and allocating new systemwide
UIDs and GIDs, and I also suspect several bits of systemd functionality
would want to integrate with it, notably logind and container bits.

> > Allows installing users without maintainer scripts, and makes
> > +  UID namespaces easier to manage.
> 
> How would that happen? How do you pre-allocate the numbers in a tiny
> 32bit number range. We do not have UUIDs for that like some "real"
> operating systems have. :)

It'd be nice to start looking into what it would take to support 64-bit
UIDs and GIDs, but in the meantime 32 bits still seems like enough to
allocate new system UIDs when files show up in one of the passwd.d
directories, preserve their mapping, and garbage-collect them when no
longer needed.  That garbage-collection bit also seems like something
systemd would need to help with.

As for containers, it just means that users would get very few UIDs and
GIDs to use in their containers.

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

Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d

[Josh Triplett]

On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote:
> On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett  wrote:
> > On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote:
> >> On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett  
> >> wrote:
> >> > ---
> >> >  TODO |5 +
> >> >  1 file changed, 5 insertions(+)
> >> >
> >> > diff --git a/TODO b/TODO
> >> > index eb482d0..6cf632a 100644
> >> > --- a/TODO
> >> > +++ b/TODO
> >> > @@ -679,6 +679,11 @@ External:
> >> > - put bootcharts in the journal
> >> > - kernel cmdline "bootchart" option for simplicity?
> >> >
> >> > +* Support passwd.d and group.d; accumulate a persistent name/number 
> >> > map, to
> >> > +  preserve UID/GID assignments without requiring assignment of unique 
> >> > IDs at
> >> > +  adduser time.
> >>
> >> Hmm, how is that related to systemd code? Sounds more like a glibc
> >> shipped feature/plugin?
> >
> > It would involve a PAM plugin as well, yes, but also a system daemon
> > watching those directories for changes and allocating new systemwide
> > UIDs and GIDs, and I also suspect several bits of systemd functionality
> > would want to integrate with it, notably logind and container bits.
> >
> >> > Allows installing users without maintainer scripts, and makes
> >> > +  UID namespaces easier to manage.
> >>
> >> How would that happen? How do you pre-allocate the numbers in a tiny
> >> 32bit number range. We do not have UUIDs for that like some "real"
> >> operating systems have. :)
> >
> > It'd be nice to start looking into what it would take to support 64-bit
> > UIDs and GIDs, but in the meantime 32 bits still seems like enough to
> > allocate new system UIDs when files show up in one of the passwd.d
> > directories, preserve their mapping, and garbage-collect them when no
> > longer needed.  That garbage-collection bit also seems like something
> > systemd would need to help with.
> >
> > As for containers, it just means that users would get very few UIDs and
> > GIDs to use in their containers.
> 
> Sorry, I lost you. I have really no idea what you are looking for.
> 
> Care to start at the beginning again, I read all that again but I
> don't get it. :)

1) Leave only root in /etc/passwd and /etc/group.
2) Add passwd.d and group.d directories in /etc and under /usr, which
   accept one record per file (with name given by the filename) and
   which do not include UIDs or GIDs.
3) When new users or groups show up, dynamically allocate new IDs for
   them, and record them in a separate persistent name<->number mapping
   used by the PAM module.  Keep them there as long as the .d file
   exists, or as long as anything on the system (file or process) uses
   the UID.
4) When the .d file goes away, and nothing uses the UID or GID anymore,
   throw it at the back of the list of IDs to reuse.
5) In the same daemon managing this, optionally support minting small
   numbers of ephemeral UIDs/GIDs for use in containers, when they don't
   need to map to any useful persistent privileges on the host system.
   Also optionally support creating new non-ephemeral UIDs/GIDs, for
   persistent use on the host.
6) Eventually move to a big enough ID space that reuse becomes
   irrelevant, and then allow users to obtain larger blocks of IDs for
   container use.

Effectively, treat ID numbers as magic rotating implementation details
that nobody should care about, and names as the primary identifier.

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

Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d

[Josh Triplett]

On Tue, Apr 23, 2013 at 01:45:32AM +0200, Tom Gundersen wrote:
> On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett  wrote:
> > 1) Leave only root in /etc/passwd and /etc/group.
> 
> Not commenting on the overall idea, but if you are going to do
> something like this, at least allow the the files not to exist at all,
> and in this case a default entry for the root user to be assumed.

Sure, seems easy enough to make that entry synthetic as part of the PAM
module.

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

[systemd-devel] What makes systemd-nspawn "not suitable for secure container setups"?

[Josh Triplett]

The systemd-nspawn manpage lists the various mechanisms used to isolate
the container, and then says "Note that even though these security
precautions are taken systemd-nspawn is not suitable for secure
container setups. Many of the security features may be circumvented and
are hence primarily useful to avoid accidental changes to the host
system from the container."

How can a process in a systemd-nspawn container circumvent the container
setup?  What additional steps would systemd-nspawn need to take to
provide a secure container setup?

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

Re: [systemd-devel] What makes systemd-nspawn "not suitable for secure container setups"?

[Josh Triplett]

On Sat, Apr 23, 2011 at 11:28:58AM +0800, microcai wrote:
> 于 2011年04月23日 10:55, Josh Triplett 写道:
> > The systemd-nspawn manpage lists the various mechanisms used to isolate
> > the container, and then says "Note that even though these security
> > precautions are taken systemd-nspawn is not suitable for secure
> > container setups. Many of the security features may be circumvented and
> > are hence primarily useful to avoid accidental changes to the host
> > system from the container."
> > 
> > How can a process in a systemd-nspawn container circumvent the container
> 
> remount /proc and /sys

Ah, good point.  So, root inside the container can trivially circumvent
the container that way.  Any way to prevent that with current kernel
support, or would fixing this require additional kernel changes to lock
down other /proc and /sys mounts?

That particular problem only applies if running code within the
container as root.  How about if running code as an unprivileged user?
With that addition, does systemd-nspawn provide a secure container
(modulo local privilege escalation vulnerabilities)?

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

[systemd-devel] What makes systemd-nspawn "not suitable for secure container setups"?

[Josh Triplett]

The systemd-nspawn manpage lists the various mechanisms used to isolate
the container, and then says "Note that even though these security
precautions are taken systemd-nspawn is not suitable for secure
container setups. Many of the security features may be circumvented and
are hence primarily useful to avoid accidental changes to the host
system from the container."

How can a process in a systemd-nspawn container circumvent the container
setup?  What additional steps would systemd-nspawn need to take to
provide a secure container setup?

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

[systemd-devel] (newbie) question: dependency on ldap/kerberos

[Josh Geisser]

Hi there

As Fedora Core user I was always abusing the Runlevel idea of the init/runlevel 
idea in on 'powerful' remote machines:

multicore Linux machines authenticating against Active Directory (with schema 
extension for Unix holding uid/etc), each carrying a virtual Windows domain 
controller (using VMware)

Background idea of either you can authenticate using remote domain controllers 
via VPN, or use the local virtual Domain controller, on the very same anyway 
oversized(but only one per site) machine.

To catch the case where VPN is down and the server is booting (power outage, 
firewall burned?), we basically did this:

1. At the earliest possibility:
   - cp -v /etc/nsswitch.conf.local /etc/nsswitch.conf
   - cp -v /etc/pam.d/system-auth.local /etc/pam.d/system-auth

2. booting into runlevel 3, starting all 'server services':
   - network, etc, vmware(!)

3. At the latest possibility (rc3.d/S99..) a script was kicked off that:
   - was trying every few seconds to auth. against _any_ available DC
   - if succeed: 
 - cp -v /etc/nsswitch.conf.ldap /etc/nsswitch.conf
 - cp -v /etc/pam.d/system-auth.ldap /etc/pam.d/system-auth
 - start into runlevel 4

4. when at least one DC available: runlevel 4: 'networked services':
   - start samba
   - start NFS
   - other things, some cases even X11


Equals: on boot, start the virtual domain controller, then either wait for this 
one to become available, or if any other is reachable also good :)

(Despite an abuse of infrastructure, this actually works quite well, the 
on-site used severs serving SMB are in either 2min or 15minutes available, 
regardless of whether the firewall could establish the VPN's)

Any hint how I can implement this scenario with systemd?

Cheers
Josh


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

Re: [systemd-devel] (newbie) question: dependency on ldap/kerberos

[Josh Geisser]

I think I understand the .target and .wants in the meanwhile, so I gave up with 
trying achieving the exact same as before :) 

I see the advantage of systemd. What I basically want is to make samba 
dependent on my own 'check-ad-avail.target', which depends on network.

What I failed yet is to actually assemble what I've been used with 
/etc/init.d/myrcscript [start|stop|status] into a .target, but that'll take 
another weekend of trial'n'error with VirtualBox and some custom RC scripts, 
and getting a bit used to systemd.

Do you have a good page translating "how in  RH/SuSE/Ubuntu/SUN/AIX/...,  so in 
systemd "? howto for unix operators?

Cheers & thx 
Josh

Btw: because of better cached-credentials support in pam and nscd on F15, the 
whole situation eases a bit anyway :)


-Ursprüngliche Nachricht-
Von: Lennart Poettering [mailto:lenn...@poettering.net] 
Gesendet: Mittwoch, 15. Juni 2011 20:23
An: Josh Geisser
Cc: systemd-devel@lists.freedesktop.org
Betreff: Re: [systemd-devel] (newbie) question: dependency on ldap/kerberos

On Sun, 05.06.11 03:30, Josh Geisser (j...@gebaschtel.ch) wrote:

> Equals: on boot, start the virtual domain controller, then either wait for 
> this one to become available, or if any other is reachable also good :)
> 
> (Despite an abuse of infrastructure, this actually works quite well, the 
> on-site used severs serving SMB are in either 2min or 15minutes available, 
> regardless of whether the firewall could establish the VPN's)
> 
> Any hint how I can implement this scenario with systemd?

The equivalent of runlevels in systemd is targets. You may have as many
of them as you wish and label them freely. Simply create a file
/etc/systemd/system/foobar.target and write data like the following into it:


[Unit]
Description=My Pretty Little Foobar Target


And there you have a new target just for yourself. And then you can pull
in other stuff into it, with symlinks in a .wants subdir.

# mkdir -p /etc/systemd/system/foobar.target.wants/
# ln -sf /lib/systemd/system/httpd.service 
/etc/systemd/system/foobar.target.wants/

And this new target will then pull in httpd. (don't forget to reload the
systemd config with "systemctl daemon-reload".)

You can easily define supersets of other targets with this. For example,
add in everything that is already in multi-user.target:

# ln -sf /lib/systemd/system/multi-user.traget 
/etc/systemd/system/foobar.target.wants/

You have a lot of flexibility with this.

Lennart

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

[systemd-devel] Tomcat.service / PID aquiring

[Josh Geisser]

Hi there

We developt an own rc script a while ago for maintaining our tomcats. (mainly 
improved shutdown behaviour with eventual kill). 
The script takes start/Stopp/status as arguments, and identifies the right PID 
by a filtered 'ps'. It also keeps track of the tomcats pid in an own pid-file.

So far the ExecStart and ExecStop is clear, but is there something like 
ExecStatus? Or, is it possible that systemd reads the service-pid from a file 
generated by not himself?

Cheers
Josh

[Unit]
Description=Atlassian Confluence Tomcat
Wants=network.target mysql.target

[Service]
ExecStart=/home/confluence/rc.confluence start
ExecStop=/home/confluence/rc.confluence start
Type=forking

[Install]
WantedBy=multi-user.target 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Tomcat.service / PID aquiring

[Josh Geisser]

Ah i skipped the notice of "systemd will not write to the file configured here" 
:)

Seems to work fine

Thanks a lot

-Ursprüngliche Nachricht-
Von: systemd-devel-bounces+josh=gebaschtel...@lists.freedesktop.org 
[mailto:systemd-devel-bounces+josh=gebaschtel...@lists.freedesktop.org] Im 
Auftrag von Miklos Vajna
Gesendet: Donnerstag, 4. August 2011 01:43
An: systemd-devel@lists.freedesktop.org
Betreff: Re: [systemd-devel] Tomcat.service / PID aquiring

On Wed, Aug 03, 2011 at 07:46:25AM +0200, Josh Geisser  
wrote:
> So far the ExecStart and ExecStop is clear, but is there something
> like ExecStatus? Or, is it possible that systemd reads the service-pid
> from a file generated by not himself?

man systemd.service, search for pidfile. :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc

[Josh Triplett]

Many people prefer to avoid clearing /tmp and /var/tmp, and
distributions often have explicit settings for how often to clear them
if at all.  Overriding those with systemd currently requires overriding
all of /usr/lib/tmpfiles.d/systemd.conf via
/etc/tmpfiles.d/systemd.conf, copying across all the other entries, and
updating that override when systemd.conf changes.

Move the /tmp and /var/tmp entries from systemd.conf to a separate
tmp.conf, making them easier to override without affecting the rest of
systemd.conf.
---

This change will allow me to create a personal package which ships
/etc/tmpfiles.d/tmp.conf, without having to include the remainder of
systemd.conf and update the package every time systemd.conf changes.

 Makefile.am |1 +
 tmpfiles.d/systemd.conf |3 ---
 tmpfiles.d/tmp.conf |   12 
 3 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 tmpfiles.d/tmp.conf

diff --git a/Makefile.am b/Makefile.am
index b9c8074..2dc3579 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -285,6 +285,7 @@ dist_bashcompletion_DATA = \
 
 dist_tmpfiles_DATA = \
tmpfiles.d/systemd.conf \
+   tmpfiles.d/tmp.conf \
tmpfiles.d/x11.conf
 
 if HAVE_SYSV_COMPAT
diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
index 7d4b356..be29c06 100644
--- a/tmpfiles.d/systemd.conf
+++ b/tmpfiles.d/systemd.conf
@@ -13,9 +13,6 @@ F /run/utmp 0664 root utmp -
 f /var/log/wtmp 0664 root utmp -
 f /var/log/btmp 0600 root utmp -
 
-d /tmp 1777 root root 10d
-d /var/tmp 1777 root root 30d
-
 d /var/cache/man - - - 30d
 
 r /forcefsck
diff --git a/tmpfiles.d/tmp.conf b/tmpfiles.d/tmp.conf
new file mode 100644
index 000..8915b82
--- /dev/null
+++ b/tmpfiles.d/tmp.conf
@@ -0,0 +1,12 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+
+# See tmpfiles.d(5) for details
+
+# Clear tmp directories separately, to make them easier to override
+d /tmp 1777 root root 10d
+d /var/tmp 1777 root root 30d
-- 
1.7.5.4

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