Re: [systemd-devel] [PATCH 3/3] run: introduce timer support option

[WaLyong Cho]

On 10/23/2014 12:56 AM, Lennart Poettering wrote:

On Tue, 07.10.14 14:20, WaLyong Cho (walyong@samsung.com) wrote:


If systemd-run is called with timer option, then systemd-run call
NewTransientUnit with service unit. And also call StartTransientUnit
with timer unit which has same name with the service. So actually, two
method call is coming and two transient unit is generated. One is
service and the other is timer.

Supported timer options are --after=, --after-boot=, --after-startup=,
--after-active=, --after-inactive=, --calendar=, --accuracy= and
--wake-system. Each option corresponding with OnActiveSec=,
OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=,
AccuracySec= and AccuracySec= of timer respectively.


Hmm, I'd really like to stay close to the underlying props here in
naming, and call the options "--on-boot=", "--on-inactive=" and so on
(the -sec suffix we can probably drop).

I'd really tought and worried about naming of the options. At the first 
time, I'd made similar named option with timer unit. But I tought the 
command line options should be more meaningful or easy to understand. So 
I changed like this. But if you say so, I don't want to against to your 
opinion. I will change those.



The AccuracySec= and WakeSystem= stuff I think we don't need to cover
with a command line argument of its own, we can cover that with
--property=.


Ah, good, I didn't know that. I will do like that.


+static bool with_timer = false;
+static char *arg_after = NULL;
+static char *arg_after_boot = NULL;
+static char *arg_after_startup = NULL;
+static char *arg_after_active = NULL;
+static char *arg_after_inactive = NULL;
+static char *arg_calendar = NULL;
+static char *arg_accuracy = NULL;
+static bool arg_wake_system = false;


I'd just do one arg_on_timer usec_t variable to store most of the
--on-xyz= values in. Plus one arg_on_calendar to hold the calendar
expression. This should be much simpler than keeping one variable
around for each.


+case ARG_AFTER:
+r = parse_sec(optarg, &u);
+if (r < 0) {
+log_error("Failed to parse timer value: %s", 
optarg);
+return r;
+}
+arg_after = optarg;
+with_timer = true;
+break;


This stuff really should not store the string, but the parsed value.


Yeah, a couple of parse_sec doesn't make sense.
How about calendar_spec_from_string? calendar_spec_from_string also be 
called twice on run and dbus-timer. I'm not sure the parsed calendar 
spec is able to be sent on current StartTransientUnit() interface. But 
even if possible, just string is obiously easy to send and receive. How 
do you think?



(I'll leave the rest unreviewed for now, please rework this first to
make use of the fourth StartTransientUnit() bus call argument!)


If you reply on above question, then I will send patch again soon.

Thanks,

WaLyong


Thanks,

Lennart


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

Re: [systemd-devel] [PATCH] journalctl: Unify boot id lookup into common function get_boots

[Zbigniew Jędrzejewski-Szmek]

On Fri, Oct 10, 2014 at 01:21:10PM +0200, Jan Janssen wrote:
> ---
>  src/journal/journalctl.c | 133 
> +--
>  1 file changed, 58 insertions(+), 75 deletions(-)
> 
> diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
> index 328e40b..550b610 100644
> --- a/src/journal/journalctl.c
> +++ b/src/journal/journalctl.c
> @@ -824,28 +824,31 @@ static int boot_id_cmp(const void *a, const void *b) {
>  return _a < _b ? -1 : (_a > _b ? 1 : 0);
>  }
Hi,

sorry for not responding earlier.

This patch makes valgrind very unhappy:

% valgrind build/journalctl --list-boots
==17017== Memcheck, a memory error detector
==17017== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17017== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==17017== Command: build/journalctl --list-boots
==17017== 
==17017== Conditional jump or move depends on uninitialised value(s)
==17017==at 0x16B66F: greedy_realloc (util.c:5988)
==17017==by 0x11262B: get_boots (journalctl.c:868)
==17017==by 0x1128ED: list_boots (journalctl.c:932)
==17017==by 0x1160B4: main (journalctl.c:1820)
==17017== 
==17017== Conditional jump or move depends on uninitialised value(s)
==17017==at 0x16B6C5: greedy_realloc (util.c:5995)
==17017==by 0x11262B: get_boots (journalctl.c:868)
==17017==by 0x1128ED: list_boots (journalctl.c:932)
==17017==by 0x1160B4: main (journalctl.c:1820)
==17017== 
==17017== Conditional jump or move depends on uninitialised value(s)
==17017==at 0x4C28BCD: malloc (vg_replace_malloc.c:296)
==17017==by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==17017==by 0x16B6E3: greedy_realloc (util.c:5998)
==17017==by 0x11262B: get_boots (journalctl.c:868)
==17017==by 0x1128ED: list_boots (journalctl.c:932)
==17017==by 0x1160B4: main (journalctl.c:1820)

...

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

Re: [systemd-devel] [Feature request] Retentiontime per unit configuration

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 23, 2014 at 01:09:25AM +0200, Lennart Poettering wrote:
> On Wed, 27.08.14 08:39, Kris Erik Schwerdt (schwe...@itsc.uni-luebeck.de) 
> wrote:
> 
> > Hallo 
> > 
> > During a task of migration of multiple servers to a systemd-based
> > distribution I was wondering if there would be a way of setting the
> > retentiontime of journald per unit.
> > In some cases e.g. there are limits for special program e.g. webserver
> > where it is not allowed to keep the logs as long as the syslog. So it would
> > be nice to have such a feature to avoid as much as possible plain-logfiles.
> 
> The retention logic is currently implemented per-journal. As soon as
> the retention time is reached we rotate the whole journal away, and
> rotate.
> 
> To allow per-service retention times would mean we'd either have to
> split up the journal files per-service from the beginning (which would
> suck perfomance-wise while viewing), or we'd have to "repack" the
> files during rotate/vacuuming (which would suck perfomance-wise while
> roating/vacuuming). The latter sounds slightly better for this. 
> 
> In the past, we got requests to allow different retention times for
> the various log priorities. I figure if we implement that we can also
> implement per-service retention times at the same time, using the same
> logic. 
> 
> That all said, I am not entirely sure what a natural way to configure
> the retention time could be and (assuming that we'd want to configure
> this in .service files) how we'd pass this nicely to journald to
> enforce.
> 
> Anyway, for now I added this to the TODO list, so that it is not
> forgotten.
The code to rewrite journal files is mostly there... You could already
do something like this:

  for i in /var/log/journal/*/*@*; do
 journalctl --file $i -p info -o export | systemd-journal-remote -o $i.tmp 
- \
 && mv $i.tmp $i
  done

(which would filter out all debug messages, but you can apply any filter).

Doing this in C should be fairly easy. I don't see why this couldn't be
run as a separate process.

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

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Mantas Mikulėnas]

On Oct 23, 2014 1:54 AM, "Lennart Poettering" 
wrote:
>
> On Wed, 22.10.14 12:44, Damien Robert (
damien.olivier.robert+gm...@gmail.com) wrote:
>
> > Colin Guthrie  wrote in message :
> > > I want to rely on systemd --user to handle PulseAudio's activation
> > > (ditching the built in stuff) and but I'm worried that e.g. GNOME or
KDE
> > > might start up their own session stuff and spawn some PA consuming
> > > process before systemd --user has reached it's sockets.target and is
> > > thus ready and listening on PA's native socket.
> >
> > Interesting, does PA now support socket activation? Mine (pulseaudio
5.0)
> > does not seem to support it.
>
> Colin recently posted the patches for this on the PA ML.
>
> > > Doesn't seem to be a problem on my machine here (it's working really
> > > nicely actually!) but figured I should ask here too.
> >
> > I have been using systemd user sessions for a long time, and it works
really
> > well, except for this policykit "bug":
> > https://bugs.freedesktop.org/show_bug.cgi?id=67728
> >
> > For instance since I start dbus under the user session, the dbus
activated
> > services also run inside it:
> >CGroup: /user.slice/user-1000.slice/user@1000.service
> >├─615 /usr/lib/systemd/systemd --user
> >├─616 (sd-pam)
> >├─dbus.service
> >│ ├─  702 /usr/bin/dbus-daemon --session --address=systemd:
--nofork
> >│ ├─  835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
> >
> > So udisks2 fails to mount my usb keys because it is not under an active
> > session (since it is not launche from my active session) so it gets
denied
> > by policykit.
>
> policykit really should get fixed there. it shouldn't try to do access
> control for individual sessions but for users on specific
> sessions.

Wasn't this already fixed in polkit.git recently?

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

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Cristian Rodríguez]

El 22/10/14 a las #4, Rob Owens escribió:

> It is your ML, so I will oblige.  But I think it is a mistake to not consider 
> a broader view of your project than just the strictly technical aspects.

It is not *his* mailing list..but it is the place where *technical*
discussions about the systemd project take place. I can only speak for
myself but if you have been subscribed for a reasonable  amount of time,
 you will see the concurrence is mostly if not completely only in the
technical aspect and does not seem to have any interest on the topic of
philosophical wanking.



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

Re: [systemd-devel] Unprivileged poweroff

[Djalal Harouni]

On Wed, Oct 22, 2014 at 12:59:45PM +0100, Simon McVittie wrote:
> On 22/10/14 12:37, Lennart Poettering wrote:
> > When used with kdbus we actually do check for that client-side
> > capability. THis is not available on dbus1 however, since we cannot
> > determine the capability racefreely and thus safely
> 
> ... because the kernel doesn't give us that ability on Unix sockets. See
>  for more on what
> Unix socket semantics *do* allow socket-based D-Bus to rely on.
Yes. From that link the privileged process should not trust the passed
fds (including:stdin...) so we can blame it... but in the other hand,
even if it closes the fds, there will always be a window for races...
but hey it should also be careful what to do with these fds. Anyway
running a suid in an untrusted environment is just asking for trouble.

> A solution requires new kernel features: either something like kdbus, or
> a way for a Unix socket client to prove to the server that it had a
> particular capability either at the time the socket opened (a new
> SCM_CAPABILITIES analogous to SCM_CREDS?) or at the time that a
> particular message was queued (subtle, probably best avoided).
Hmm, when the message is queued you should just trust those
capabilities (metadata), there is no another way! so if it is really
unprivileged you are safe. For two reasons:

1) Even if privileged leaks the connection fd to unprivileged, you will
   get the capabilities of the unprivileged one. The real one that is
   sending messages.

2) Privileged should not trust the passed fd nor queue a message using
   this passed fd. No sane program should do this, otherwise it will
   just break every thing.

   And if we assume from that fdo bug id=83499:
   "* connect to the D-Bus socket
   * race with dbus-daemon, and win:
 - queue up the entire handshake, plus a malicious message, in the
   outgoing socket buffer
 - make the D-Bus connection not close-on-exec
 - exec() a setuid process, or fd-pass the D-Bus connection to a more
   privileged process
   * dbus-daemon checks the sender's credentials (let's say "uid 1000"),
 and thinks it has the credentials of the setuid process
 (e.g. "uid 0")
   * now dbus-daemon reads the malicious message, determines that uid 0
 may send it, and forwards it to the recipient, with no indication
 that uid 1000 was actually responsible"

   So:
   If the unprivileged queues up a message then exec() a suid and passes
   the fd to the privileged one, we sill get the capabilities of the
   process that did send the message, the unprivileged one. This way if
   we ever someday get SCM_CAPABILITIES, it should reflect the caps at
   the time the message was queued, *not* when the connection was opened.


Here, the capabilities are metadata attached to the message, that can't
be faked...


However, when trying to talk to a service/well-known name from a pure
D-Bus perspective, you talk to the interface that is offering the
poweroff methode, then in this case the TALK check is performed against
creds (uid/gid) at the *time* the connection was *created*. So if uid/gid
do not match, good, unprivileged do not allow contacting the service at
all.

However if uid/gid matches or if the connection was created by a
privileged, we allow the TALK to that service since it was privileged or
the uid/gid did match when the connection was created. The privileged is
*responsible* of the connection fd.

Doing this allows privileged to create connections (store the cred),
drop privs, then pass the connection fd to a normal process. This way
some unprivileged code is able to talk to some restricted names... and
the receiving service is able to inspect the *correct* capabilities of
this unprivileged (capabilities gathered when the message was queued).


Hope I'm not missing something, otherwise let me know, thank you Simon!


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

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

Re: [systemd-devel] container login

[Lennart Poettering]

On Sat, 30.08.14 21:26, Ruben Kerkhof (ru...@rubenkerkhof.com) wrote:

> Hi all,

heya,

> I'm playing around a bit with systemd-nspawn, and the new --volatile option.
> I've got it mostly working so far, except for loggin in to the container as 
> root.
> 
> Looking at the code, IIUC systemd-firstboot is supposed to prompt for the 
> root password, but it doesn't do this if /etc/shadow exists.
> systemd-sysusers creates the root account, and, since 9ab315ccf22a,
> also creates a (locked) entry in /etc/shadow.
> 
> Now the obvious question is, how do I get into my volatile container?

Indeed! This was borked. I have now fix this by ordering
systemd-firstboot before systemd-sysuers, so that it can ask for the
root password, before sysusers adds in the rest.

Thanks for te pointer!

Lennart

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

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

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/10/2014 1:03, Lennart Poettering wrote:
> On Thu, 23.10.14 00:52, Philip Van Hoof (phi...@codeminded.be)
> wrote:
> 
>>> Don't try to work around limitations of kernel APIs by 
>>> implementing inherently not scalabale algorithms in userspace.
>>> I mean, you implemented something that scales O(n) with n the
>>> numbers of dirs. That's what you need to fix, there's no way
>>> around that. Just looking for magic wands in cgroups and
>>> scheduling facilities to make an algorithm that fundamentally
>>> scales badly acceptable is not going to work.
>> 
>> The problem with allowing unprivileged processes is that a
>> misbehaving process will cause the kernel to buffer events for
>> it, forcing the kernel to dynamically allocate memory. Not
>> something kernel or inotify developers will like a lot.
> 
> This is fixable, by enforcing a size limit on the queue. As the
> limit is hit the algorithm should coalesce queued events based on 
> subtrees. For example, if one event for /foo/bar/buzz and one for 
> /foo/bar/waldo is queued, and the queue hits its limit, both are 
> replaced by an entry for /foo/bar which is marked with a new flag
> that some event was lost below this subtree. For clients this would
> then mean that when they receive this they must rescan that
> specific subtree again, but not the whole tree.
> 
> It's a simple algorithm, the max number of entries stays fixed,
> but perfomance doesn't go completely horrible when the limit is
> reached.
> 
> Such a scheme should be implemented in fanotify on the kernel
> side.

And clients must be prepared to scan coalesced queued events, which
can be large (when /foo/bar/waldo and /foo/bar/buzz are directories
with large amounts of files, coalescing to /foo/bar means
tracker-miner-fs suddenly has a lot of work to do) ..

But yes. The coalesce solution in fanotify would be a good idea to
allow unprivileged processes. Probably better than what FSEvents does.

Kind regards,

Philip

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUSDzAAAoJEEP2NSGEz4aD6I8H/i/POL3hIfCCz/wwA+F6Kwol
ytuFKWXYedtfApkzbbeX8aH+CYiTZfq9Ld46MVgKzz3oydD5JSsnFVns33yuumW8
AZ66yhZWTJZnfCDE8ZJnLq5/lxyfgZq0AOlfLW9loXwQ54zPLBqFztSdtDr7EXMS
2dQ134h9N2em4vdYV0p3hwCKSwifOdCZRi2xMvr03RGPDTTsnvMN9Ou6gCEscTEA
fjNATi969kfjQsf08C5VVVwemyU8pf5RU725ZfoQmpMamJcTREVSrjt/qpno7F03
5rAoJWXCkTEGl56cbeQJX0n54m45Ce6XHpPJLfkouKoxGWhNVg8ThU/Pw0GKHZs=
=slie
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Feature request] Retentiontime per unit configuration

[Lennart Poettering]

On Wed, 27.08.14 08:39, Kris Erik Schwerdt (schwe...@itsc.uni-luebeck.de) wrote:

> Hallo 
> 
> During a task of migration of multiple servers to a systemd-based
> distribution I was wondering if there would be a way of setting the
> retentiontime of journald per unit.
> In some cases e.g. there are limits for special program e.g. webserver
> where it is not allowed to keep the logs as long as the syslog. So it would
> be nice to have such a feature to avoid as much as possible plain-logfiles.

The retention logic is currently implemented per-journal. As soon as
the retention time is reached we rotate the whole journal away, and
rotate.

To allow per-service retention times would mean we'd either have to
split up the journal files per-service from the beginning (which would
suck perfomance-wise while viewing), or we'd have to "repack" the
files during rotate/vacuuming (which would suck perfomance-wise while
roating/vacuuming). The latter sounds slightly better for this. 

In the past, we got requests to allow different retention times for
the various log priorities. I figure if we implement that we can also
implement per-service retention times at the same time, using the same
logic. 

That all said, I am not entirely sure what a natural way to configure
the retention time could be and (assuming that we'd want to configure
this in .service files) how we'd pass this nicely to journald to
enforce.

Anyway, for now I added this to the TODO list, so that it is not
forgotten.

Lennart

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

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

[Lennart Poettering]

On Thu, 23.10.14 00:52, Philip Van Hoof (phi...@codeminded.be) wrote:

> > Don't try to work around limitations of kernel APIs by
> > implementing inherently not scalabale algorithms in userspace. I
> > mean, you implemented something that scales O(n) with n the numbers
> > of dirs. That's what you need to fix, there's no way around that.
> > Just looking for magic wands in cgroups and scheduling facilities
> > to make an algorithm that fundamentally scales badly acceptable is
> > not going to work.
> 
> The problem with allowing unprivileged processes is that a misbehaving
> process will cause the kernel to buffer events for it, forcing the
> kernel to dynamically allocate memory. Not something kernel or inotify
> developers will like a lot.

This is fixable, by enforcing a size limit on the queue. As the limit
is hit the algorithm should coalesce queued events based on
subtrees. For example, if one event for /foo/bar/buzz and one for
/foo/bar/waldo is queued, and the queue hits its limit, both are
replaced by an entry for /foo/bar which is marked with a new flag that
some event was lost below this subtree. For clients this would then
mean that when they receive this they must rescan that specific
subtree again, but not the whole tree.

It's a simple algorithm, the max number of entries stays fixed, but
perfomance doesn't go completely horrible when the limit is reached.

Such a scheme should be implemented in fanotify on the kernel side.

Lennart

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

Re: [systemd-devel] [BUG] time-sync.target reached prematurely

[Lennart Poettering]

On Wed, 27.08.14 09:50, Lukasz Stelmach (stl...@poczta.fm) wrote:

> Yes that is a point. However, the current description the man page
> provides is a bit less accurate than the above. Then, the delay you
> describe does not seem as bad to me as you say. Suppose we've got two
> services: aiccu, systemd-logind. Their dependencies look (very) roughly
> like this:
> 
> 
>multi-user.target
>/   \
> aiccu.service- systemd-logind.service
>   |   \ |
> time-sync.target   \___basic.target
>   |
>   |   sysinit.target
>   |  /
> systemd-timesyncd.service
> 
> This means that waiting for systemd-timesyncd to contact NTP server
> indeed delays reaching multi-user.target but it does not affect
> systemd-logind (actually it does, because systemd-timesyncd is wanted by
> sysinit.target but if it was a part of multi-user.target then it is not
> a problem (time-sync-wait.service?)) or any other services that do not
> depend on time-sync.target. If a service really needs "correct time"
> then I assume its authors and users are aware of the fact it won't start
> that instantly upon boot.
> 
> You are right saying RTC provides acceptable accuracy in most cases and
> NTP is ther to correct slight errors. There are systems (distributed
> filesystems?) that need sub(micro?)second accuracy provided by PTP.
> Other systems may use GPS receivers which make network connectivity
> unnecessary. Mobiles may use GSM network to get time (I wonder if
> entering PIN is required).
> 
> All in all, IMHO, time-sync.target should be reached after synchronising
> the system clock which doesn't have to mean delaying services that make
> the system appear to boot fast. It appears to be easier to provide a
> single target that modify many applications to check for STA_UNSYNC in a
> loop.

I have now added a TODO list item, for a minimal service
systemd-timesync-wait.service or so, that works akin to
systemd-network-wait-online.service or so. I find this kinda ugly,
but, I figure it might have some users

That said, I can only recommend apps who really want accurate clocks
to subscribe to time jumps via TFD_TIMER_CANCEL_ON_SET and then check
for the STA_UNSYNC flag. It's certainly much nicer.

Lennart

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

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Lennart Poettering]

On Wed, 22.10.14 12:44, Damien Robert (damien.olivier.robert+gm...@gmail.com) 
wrote:

> Colin Guthrie  wrote in message :
> > I want to rely on systemd --user to handle PulseAudio's activation
> > (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
> > might start up their own session stuff and spawn some PA consuming
> > process before systemd --user has reached it's sockets.target and is
> > thus ready and listening on PA's native socket.
> 
> Interesting, does PA now support socket activation? Mine (pulseaudio 5.0)
> does not seem to support it.

Colin recently posted the patches for this on the PA ML.

> > Doesn't seem to be a problem on my machine here (it's working really
> > nicely actually!) but figured I should ask here too.
> 
> I have been using systemd user sessions for a long time, and it works really
> well, except for this policykit "bug":
> https://bugs.freedesktop.org/show_bug.cgi?id=67728
> 
> For instance since I start dbus under the user session, the dbus activated
> services also run inside it:
>CGroup: /user.slice/user-1000.slice/user@1000.service
>├─615 /usr/lib/systemd/systemd --user
>├─616 (sd-pam)  
>├─dbus.service
>│ ├─  702 /usr/bin/dbus-daemon --session --address=systemd: 
> --nofork 
>│ ├─  835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
> 
> So udisks2 fails to mount my usb keys because it is not under an active
> session (since it is not launche from my active session) so it gets denied
> by policykit.

policykit really should get fixed there. it shouldn't try to do access
control for individual sessions but for users on specific
sessions. 

Lennart

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

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

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/10/2014 13:21, Lennart Poettering wrote:

> Well, looking at that bug it appears to me that this is caused
> because you try to use inotify for something it shouldn't be used
> for: to recursively watch an entire directory subtree. If you fake
> recursive fs watching by recursively adding all subdirs to the
> inotify watch then of course you eat a lot of CPU.
> 
> The appropriate fix for this is to not make use of inotify this
> way, which might mean fixing the kernel to provide recursive
> subscription to fs events for unpriviliged processes. Sorry if
> that's disappointing, but no amount of cgriups can work around
> that.
> 
> Don't try to work around limitations of kernel APIs by
> implementing inherently not scalabale algorithms in userspace. I
> mean, you implemented something that scales O(n) with n the numbers
> of dirs. That's what you need to fix, there's no way around that.
> Just looking for magic wands in cgroups and scheduling facilities
> to make an algorithm that fundamentally scales badly acceptable is
> not going to work.

The problem with allowing unprivileged processes is that a misbehaving
process will cause the kernel to buffer events for it, forcing the
kernel to dynamically allocate memory. Not something kernel or inotify
developers will like a lot.

I guess the kernel could reduce the buffer by not storing the
null-terminated name of the inotify_event, and reconstructing it
on-demand at the read() moment .. but that still means buffering.

I guess that's why we have /proc/sys/fs/inotify/max_queued_events

FSEvents 'solves' this by having a well behaved single process
journalling it to disk, and then providing an API for other consumers
to query the journal.

We could develop a privileged well behaving such process that does
exactly that. We need writable storage in $HOME/.cache/tracker anyway,
tracker-miner-fs could register itself to it to get such logs written
in the user's .cache location.

Maybe that's something for systemd to provide :-)? I wonder how well
that will burn in the plasma-hot flamewars surrounding poor systemd.

/me hides

Kind regards,

Philip


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUSDVJAAoJEEP2NSGEz4aDPsYH/1y6F1N67RyvBd50QEBHh7fH
m4AezEi4a+nFZVxFW3iXfLyp0Df0kkXSRwZAGgAOTVXbbrvi8aOmuFYSIsAqUuaU
9m98Dh6gTM1Zusa79sWLT1Ktp8bJ9Pa+dNenjXU2cizwkhuqYd58P4SoWAjbUDaA
quQVMrPD50Jyjf6zfCe2IeSUhG0v0leazs6o2XxmKSSNs/EBXf32w17GZd8dh3FX
8QcCxtTz+Lz+LJ92fwYEPPVh094hu0X79pB8st3ES0b+iZLaoDPrPRiOJn2kAETx
S+4V0F5/bQf4lQ8eTRHn7UDjOLLvqZ4PgsBAwSskVjykfCgCu9N+qEBlg5Ho6d4=
=HIJP
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] So how am I supposed to put together my Linux system?

[Lennart Poettering]

On Wed, 22.10.14 21:08, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> > My idea would be that the initrd contains that info. Each usr tree
> > comes with one initrd, and that initrd knows which usr tree to boot.
> 
> That implies that each installation snapshot must come with an initrd,
> even if the only change to earlier versions is the snapshot name. That
> sounds suboptimal to me.

Correct. I can see that for some uses this might appear as overkill,
but in general I would not make much of a distinction between the
kernel and the basic userspace here, they really belong together.

> I am following Arch and create new snapshots daily. For me the kernel
> updates way less often than the rest. The initrd does change for each
> snapshot though. I need to investigate what is causing that. I would
> have expected the initrd to change more often than the kernel, but
> definitely not for each update. Maybe mkinitcpio bakes in some
> timestamp or something.

I figure they want to make sure the files in the initrd are actually
always identical to the source they are copied from in /usr. That
kinda requires updating the initrd on each update of /usr.

> >> secure boot. That leaves EFI vars I think. Do those integrate with
> >> secure boot?
> >
> > Sure, we can store failure info in EFI Vars, no problem really.
> 
> I agree that this should work for secure boot and a classic
> distribution upgrade.
> 
> For my non-secure boot use case with incremental/daily upgrades the
> necessary changes to the systemd-fstab-generator were already merged
> (Thanks!), so I am waiting impatiently for the next systemd release to
> hit the arch repos.

I am working on it, but there are a couple of things I still need to
work on before the release. Sorry!

Lennart

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

Re: [systemd-devel] [PATCH] journal: grant systemd-journal group permission

[Lennart Poettering]

On Wed, 22.10.14 23:53, Lennart Poettering (lenn...@poettering.net) wrote:

> On Fri, 29.08.14 22:03, WaLyong Cho (walyong@samsung.com) wrote:
> 
> > On 08/27/2014 02:55 AM, Lennart Poettering wrote:
> > > On Tue, 26.08.14 15:43, WaLyong Cho (walyong@samsung.com) wrote:
> > > 
> > >> There is no Bofore= or After= dependencies between
> > >> systemd-journald.service and systemd-tmpfiles-setup.service. So if both
> > >> "/run/log/journal" and "/var/log/journal" does not exist then those can
> > >> be make as root:root and also its ids directory and journal files. To
> > >> make sure, do chown systemd-journal group to journal directories and
> > >> files.
> > > 
> > > Hmm? /run/log/journal will be recursively updated, and /var/log/journal
> > > is not created by journald ever, but only by tmpfiles, which uses g+s to
> > > ensure all files that will be created have the right owner from the
> > > beginning.
> > > 
> > I hope you test like me. Set *Storage=persistent* in journald.conf and
> > remove(back it up to other) "/var/log/journal" and restart.
> 
> Ah, umm. Yuck. Storage=persistent is indeed a different case...
> 
> Hmm, not sure what we can do here. We cannot do NSS lookups in
> journald though, we need to find another way. 
> 
> Hmm, one idea is to make systemd-journal-flush synchronous, and then
> order it before systemd-tmpfiles. That way, if Storage=persistent is
> set we would *know* that the dir is first created, and tmpfiles could
> then just adjust the ACLs for it...
> 
> However, making systemd-journal-flush isn't that easy I fear. It would
> be easy if we had dbus as IPC, but that's something we cannot use
> unless we have kdbus, since we cannot allow a cyclic loop between
> dbus-daemon logging to journald, and journald waiting for dbus
> 
> I need to think about this more...

OK, I thought a bit about this more. And now changed
systemd-journal-flush.service to be asynchronous, so that it can be
ordered before systemd-tmpfiles-setup.service and the ownership of the
dirs can be correctly applied. Please give this a test run.

I implemented this via a new "journalctl --flush" command which will
first send SIGUSR1 to journald, and then wait for
/run/systemd/journal/flushed to appear in the FS which is what
journald uses internally to remember if it already flushed the journal
or not.

Lennart

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

Re: [systemd-devel] Compatibility between D-Bus and kdbus

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/10/2014 15:33, Simon McVittie wrote:
[cut]

> Resource limits ===
> 
> Some resource limits are lower in kdbus than in dbus-daemon.
> 
> In kdbus, the number of unread messages per recipient is limited to
> 256, with up to 16 per uid; subsequent broadcasts are silently
> dropped, and subsequent unicast messages cause the sender to
> block.
> 
> The message header (fixed-length header and header fields) is
> limited to 2 MiB in kdbus, whereas on dbus-daemon it may be up to a
> configurable limit, by default 32 MiB for the system bus or 128 MiB
> for the session bus. Broadcast messages (header + body) have the
> same 2 MiB limit, but unicast message bodies may be any size: kdbus
> itself does not impose any limit. I don't know whether anything
> sends broadcasts as large as 2 MiB (Tracker perhaps?): if you do,
> please share.

Tracker's GraphUpdated will 'compress' its payload by sending
numerical ID's that represent the graph, resource, property and
sometimes value to signal inserts and deletes on a graph.

It has two triggers to invoke it (which also flushes it)

When the amount of events is larger than a certain number:

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n25

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n312

And timer based as configured as graphupdated_delay (dconf config):

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n297

Some more explanation here:

http://pvanhoof.be/blog/index.php/2010/08/24/trackers-new-class-signal-system-being-developed


Of greater concern is an API which I always considered to be for
debugging purposes only. That's the Query API on Resources1 of Tracker:

libtracker-sparql will not ever use it, the library will either use a
direct connection with sqlite's meta.db using WAL journaling for read
queries, or fall back to using FD passing with as you mentioned in
your mail pipe() and vmsplice(). That's the Steroids1 D-Bus interface
of Tracker's SPARQL endpoint.

Although I consider the Query API on Resources1 to be a private or
debug D-Bus API, it can indeed cause a very large DBusMessage.

This was once put in place to guard ourselves against it:

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n50

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n111

Some explanation here:
https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n27

[cut]

> Comments, corrections? (To the dbus list, please.)

Kind regards,

Philip

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJUSCi9AAoJEEP2NSGEz4aDDKEH/RDRuIHtmUljzdYX7XQqGA6N
I/0DAaCHRCg0D2az9MbzgEnrFrvVmhACtGrFcWA15hfasNadcCmPnIBRJk84WOld
rELimMayQ8wyCsKlCBszoAjQKVe4Qr5KVw3zVNBTPvfs6xsqdeGFSaNbFDrrCZtC
5SmwnlI9ezenJ3+EjAbTqPUDi7rMciA4BvDWI0HSa4TQD/ggtnHnVyikff6POPX7
BQcHp65vBSCvz+mwVPUawTI04l3MC8UXzMOYw/I+UduESnptbD7ZyJ0GzUY7rxxI
Se/Et+ijSBCdvb3cuBnDk14kZ+slJFEBrYLsukZVdQ8hqzm1NmU0/XBsMK3eN+c=
=GA7y
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] journal: grant systemd-journal group permission

[Lennart Poettering]

On Fri, 29.08.14 22:03, WaLyong Cho (walyong@samsung.com) wrote:

> On 08/27/2014 02:55 AM, Lennart Poettering wrote:
> > On Tue, 26.08.14 15:43, WaLyong Cho (walyong@samsung.com) wrote:
> > 
> >> There is no Bofore= or After= dependencies between
> >> systemd-journald.service and systemd-tmpfiles-setup.service. So if both
> >> "/run/log/journal" and "/var/log/journal" does not exist then those can
> >> be make as root:root and also its ids directory and journal files. To
> >> make sure, do chown systemd-journal group to journal directories and
> >> files.
> > 
> > Hmm? /run/log/journal will be recursively updated, and /var/log/journal
> > is not created by journald ever, but only by tmpfiles, which uses g+s to
> > ensure all files that will be created have the right owner from the
> > beginning.
> > 
> I hope you test like me. Set *Storage=persistent* in journald.conf and
> remove(back it up to other) "/var/log/journal" and restart.

Ah, umm. Yuck. Storage=persistent is indeed a different case...

Hmm, not sure what we can do here. We cannot do NSS lookups in
journald though, we need to find another way. 

Hmm, one idea is to make systemd-journal-flush synchronous, and then
order it before systemd-tmpfiles. That way, if Storage=persistent is
set we would *know* that the dir is first created, and tmpfiles could
then just adjust the ACLs for it...

However, making systemd-journal-flush isn't that easy I fear. It would
be easy if we had dbus as IPC, but that's something we cannot use
unless we have kdbus, since we cannot allow a cyclic loop between
dbus-daemon logging to journald, and journald waiting for dbus

I need to think about this more...

Lennart

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

Re: [systemd-devel] [PATCH] cryptsetup-generator: Allow specifiying a name on the kernel command line

[Lennart Poettering]

On Fri, 29.08.14 15:28, Jan Janssen (medhe...@web.de) wrote:

heya,

sorry for the late review!

Hmm, not generally opposed to allowing this to be configured on the
kernel cmdline, but this is so awfully asymmetric now.

  luks.uuid= so far accepts a single UUID, but may be specified multiple times
  luks.options= accepts a UUID, followed by a "=", followed by the options for 
that specific volume, may be specified multiple times
  luks.key= accepts a single key file, but may be specified a single time only

Now you want to extend:

  luks.uuid= would then accept a UUID, followed by a ":", followed by the dm 
name for the specific volume

Correct? I really don't like that. It's already awfull chaotic, and
now it becomes even worse...

Maybe, to stay uniform, introduce luks.name=$UUID=$NAME or so? this
would map the luks.options= syntax at least (not that that was a
particularly pretty syntax, but well...). In fact, we should probably
extend luks.key= to also accept a syntax for this: luks.key=$UUID=$KEY
or so... Any maybe if luks.options= does not start with $UUID= it
should just be considered the default options for all entries.

Does that make any sense?

For now, could you rework your patch to follow this scheme? (I mean,
only do the luks.name= syntax the way I propose above, not the other
stuff).

I'd prefer if we'd push all luks partitions that are configured into a
Hashmap btw, keyed by the uuid, and with a new struct as value, where
we can fill things in. Constantly iterating through the various arrays
over and over again is neither pretty nor efficient.

Lennart

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

Re: [systemd-devel] [PATCH 2/3] mac: rename apis with mac_{selinux/smack}_ prefix

[Lennart Poettering]

On Wed, 22.10.14 23:12, Lennart Poettering (lenn...@poettering.net) wrote:

> On Thu, 16.10.14 16:59, WaLyong Cho (walyong@samsung.com) wrote:
> 
> > -if (smack_label_ip_in_fd(fd, s->smack_ip_in) < 0)
> > -log_error_unit(UNIT(s)->id, "smack_label_ip_in_fd: 
> > %m");
> > +if (mac_smack_ip_in_fd(fd, s->smack_ip_in) < 0)
> > +log_error_unit(UNIT(s)->id,
> > -"mac_smack_ip_in_fd: %m");
> 
> I think this call should still contern a verb of some kind, do
> indicate what it does. mac_smack_label_ip_in_fd() or even
> mac_smack_relabel_ip_in_fd() or so?

Or maybe even mac_smack_fix_ip_in_fd()?

Lennart

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

Re: [systemd-devel] [PATCH 3/3] udev: do NOT re-label smack

[Lennart Poettering]

On Thu, 16.10.14 16:59, WaLyong Cho (walyong@samsung.com) wrote:

> If selinux is disabled and smack is only enabled, smack label is
> relable-ed by label_fix. To avoid, make only be labeled for selinux.
> ---
>  src/udev/udev-node.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c
> index 9796672..6dd4e74 100644
> --- a/src/udev/udev-node.c
> +++ b/src/udev/udev-node.c
> @@ -317,8 +317,8 @@ static int node_permissions_apply(struct udev_device 
> *dev, bool apply,
>  }
>  
>  /* set the defaults */
> -if (!selinux)
> -label_fix(devnode, true, false);
> +if (!selinux && use_selinux())
> +mac_selinux_fix(devnode, true, false);

Hmm, but doesn't mac_selinux_fix() check for use_selinux() internally
anyway? Checking this outside sounds redundant, no?

Lennart

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

Re: [systemd-devel] [PATCH 2/3] mac: rename apis with mac_{selinux/smack}_ prefix

[Lennart Poettering]

On Thu, 16.10.14 16:59, WaLyong Cho (walyong@samsung.com) wrote:

> -if (smack_label_ip_in_fd(fd, s->smack_ip_in) < 0)
> -log_error_unit(UNIT(s)->id, "smack_label_ip_in_fd: 
> %m");
> +if (mac_smack_ip_in_fd(fd, s->smack_ip_in) < 0)
> +log_error_unit(UNIT(s)->id,
> -"mac_smack_ip_in_fd: %m");

I think this call should still contern a verb of some kind, do
indicate what it does. mac_smack_label_ip_in_fd() or even
mac_smack_relabel_ip_in_fd() or so?

> --- a/src/resolve/resolved-dns-domain.c
> +++ b/src/resolve/resolved-dns-domain.c
> @@ -169,7 +169,7 @@ int dns_label_escape(const char *p, size_t l, char **ret) 
> {
>  return r;
>  }
>  
> -int dns_label_apply_idna(const char *encoded, size_t encoded_size, char 
> *decoded, size_t decoded_max) {
> +int dns_mac_selinux_apply_idna(const char *encoded, size_t
> encoded_size, char *decoded, size_t decoded_max) {

THis looks like a copy/past error. This is not a security label here,
but just a part of a DNS domain

Otherwise looks good!

Could you please fix and rebase the series? I promise I will merge
this quickly now, sorry reviewing this so slowly! It must have been
awful constantly rebasing this without getting this merged! Sorry for
that!

Lennart

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

Re: [systemd-devel] [RFC][PATCH 1/2] resolve: resolved-manager: Avoid null dereference

[Lennart Poettering]

On Wed, 22.10.14 22:12, Tom Gundersen (t...@jklm.no) wrote:

> On Wed, Oct 22, 2014 at 12:19 PM, Lennart Poettering
>  wrote:
> > On Sat, 13.09.14 20:40, Tom Gundersen (t...@jklm.no) wrote:
> >
> >> Yeah, this could happen. It so happens that the loopback link will
> >> always have ifindex 1, so I guess we could just fall back to checking
> >> for that if we don't have the real flags.
> >
> > Is that true even in network namespaces? Is this really exported API?
> > I really don't want to rely on behaviour here that is not considered
> > official API of Linux.
> >
> > If it is safe API of Linux, then we really should drop
> > manager_ifindex_is_loopback() entirely, and just always compare the
> > ifindex.
> >
> > Anyone has some pointers where this is made API?
> 
> We may want to ask the kernel guys to export LOOPBACK_IFINDEX, as it
> is not at the moment. However, I think relying on it is fine even
> without that as the kernel will BUG_ON if "lo" does not have ifindex
> 1[0], and no other netdev can have ifindex 1[1]:
> 
> /* The loopback device is special if any other network devices
>  * is present in a network namespace the loopback device must
>  * be present.

BTW, I changed resolved now to only use LOOPBACK_IFINDEX when
identifying loopback devices, and dropped the code that checks for
IFF_LOOPBACK. That should simplify things a bit. 

I also documented the situation around LOOPBACK_IFINDEX in the
comments.

Lennart

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

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

> From: Lennart Poettering 

> We are always interested in technical feedback. 
> 
> We are not very interested in FUD mails that tell us how we'd "force"
> people, how we'd behave like microsoft and so on. That's not useful,
> that's pretty much only hurtful. 

I haven't read this full thread, and it probably isn't useful for me
to do so.  But it seems that the first question to be answered by the
developers is:

Are they concerned that uptake is not as fast as they'd like?

and if the answer to that is Yes, then:

Would they like to hear feedback from users as to what they
might do about it?

There's no point in jabbering about it unless the answer to the second
question is Yes.

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

Re: [systemd-devel] Stop Job for User Manager

[Chris Bell]

On Wed, Oct 22, 2014 at 10:49 AM, Chris Bell  wrote:
> Why 90 seconds? Can this duration be changed?

Could I accomplish this with the `JobTimeoutSec' systemd parameter in
the `user@.service' unit file? I can't seem to force my system to get
stuck on a stop job at the moment to test it. Would changing this to
e.g. 15 affect the hold timer in this case?

On Wed, Oct 22, 2014 at 10:54 AM, Reindl Harald  wrote:
> there are more rough edges in that context

Next time it hangs, I'll have to examine this from the emergency
console. Thanks for the info.

Chris Bell

Ph.D. Student
University of South Florida
College of Engineering
Department of Computer Science and Engineering
NarMOS Research Team
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Rob Owens]

- Original Message -
> From: "Lennart Poettering" 
> 
> On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote:
> 
> > > We are always interested in technical feedback.
> > 
> > I have seen this comment several times from the systemd devs, and I
> > don't doubt it.  But I think much of the criticism of systemd is not
> > technical. It has a more social/political nature, and I think you
> > should be interested in that feedback as well (even if it is
> > technically un-interesting).
> 
> Please, let's discuss this elsewhere. Let's keep a strict technical
> focus on this ML!
> 
> Thank you for your understanding!
> 
> Lennart

It is your ML, so I will oblige.  But I think it is a mistake to not consider a 
broader view of your project than just the strictly technical aspects.

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

Re: [systemd-devel] So how am I supposed to put together my Linux system?

[Tobias Hunger]

Hi Lennart,

On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering
 wrote:
> Sorry for the late response, been travelling for a month, and then
> have been more travelling, and still trying to process all the mails
> that queued up since.

No problem at all:-)

>> On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering
>> I see that secure boot wants one file and that you will need to merge kernel
>> and initrd into one. But you will need the meta data to link the 
>> kernel/initrd
>> combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos
>> also has that and stores that meta-data in non-volatile memory accessible to
>> the BIOS.
>
> My idea would be that the initrd contains that info. Each usr tree
> comes with one initrd, and that initrd knows which usr tree to boot.

That implies that each installation snapshot must come with an initrd,
even if the only change to earlier versions is the snapshot name. That
sounds suboptimal to me.

But then I am playing with atomic upgrades for a while now and in
practice each snapshots comes with its own initrd anyway.

>> > 2. If we cannot have external config files, then kernel/initrd should
>> > find their stuff an empty kernel cmdline option.
>>
>> Nice ideal, but I do not see how that will work in general. You could bake 
>> some
>> id into the kernel (kernel version or whatever), but usually the kernel 
>> changes
>> slower than the sum of the files in /usr. You do want to boot different of 
>> these
>> usr-setups with one kernel.
>
> Note that at least chromeos doesn't do this. They update the whole OS
> at once, including the kernel. And never kernel and /usr independently.

I am following Arch and create new snapshots daily. For me the kernel
updates way less often than the rest. The initrd does change for each
snapshot though. I need to investigate what is causing that. I would
have expected the initrd to change more often than the kernel, but
definitely not for each update. Maybe mkinitcpio bakes in some
timestamp or something.

>> > 4. The initrds should probably use information from
>> > /usr/lib/os-release (as shipped in the initrd as a copy of the OS'
>> > version) to build the btrfs sub-volume name to boot from. It should
>> > not allow overriding this name via the kernel cmdline, at least as
>> > long as we are in a mode where secureboot is actually turned on...
>>
>> That could work, provided there is something like a timestamp/version number
>> in /usr/lib/os-release that actually changes every time *anything* in
>> /usr changes
>> (or at least when those changes are getting distributed as an image).
>>
>> You still need to store that information somewhere though for the kernel to 
>> know
>> what to boot.
>
> Well, gummiboot picks a kernel with the initrd attached. the initrd
> then finds the right /usr tree according to the information it contains.
>
>> > Hope that makes some sense?
>>
>> Not really. I do see how this can work to boot the newest
>> installation of distroX: You just need to look for the newest
>> version of the usr-subvolume and boot that.
>
> Well, I think kernel and /usr hierarchy really belong together. If you
> pick a kernel you thus implicitly also pick a /usr tree.
>
> (Of course, this strict we only need to be for a verified boot. For
> other cases, we of course can allow passing arbitrary kernel cmdline
> options, to pick different usr tree. The user should be able to
> override things, unless the device is in trusted mode)
>
>> How do I boot the version I ran before the upgrade in case the
>> upgrade failed?
>
> In general the rule should probably be to go back in version one-by-one
> if a kernel/system failed to boot. THe boot loader should by default
> boot the newest kernel, thus the newest /usr, too. if that for some
> reason nerver finishes, on next reboot it should pick the kernel one
> version older, and so on.
>
>> I really do not see how you can get around storing meta-data somehow.
>>
>> You can not change the kernel/initrd when it is signed, so you can not bake 
>> any
>> information into that file. You can apparently not have a separate
>> file when using
>>
>> secure boot. That leaves EFI vars I think. Do those integrate with
>> secure boot?
>
> Sure, we can store failure info in EFI Vars, no problem really.

I agree that this should work for secure boot and a classic
distribution upgrade.

For my non-secure boot use case with incremental/daily upgrades the
necessary changes to the systemd-fstab-generator were already merged
(Thanks!), so I am waiting impatiently for the next systemd release to
hit the arch repos.

Those were the last bits I needed for my grand atomic upgrade scheme
to work without me having to patch stuff locally:-) Now I can proceed
to move more of my systems over to actually use it.

PS: Your scheme was significantly simpler to get up and running than
the ostree-approach I tried before. But maybe that was just because I
started out with a working ostree setup:-)

Best Regards,
To

Re: [systemd-devel] User systemd unit files

[Chris Morgan]

On Wed, Oct 22, 2014 at 12:20 PM, Lennart Poettering
 wrote:
> On Thu, 11.09.14 07:07, Chris Morgan (chmor...@gmail.com) wrote:
>
>> Hmm. I figured that the environment was used when the systemd user
>> instance was started.
>>
>> I tried systemctl --user set-environment and it shows up if I use
>> show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on
>> mobile and mistakenly typed USER instead of UNIT), and reloaded the
>> daemon it doesn't appear to be taking effect, the test unit file I
>> created isn't located.
>
> SYSTEMD_UNIT_PATH should still work. You have to specify it in the
> user@.service template unit file, then reload the daemon and restart
> that service. Otherwise it will not take effect. Make sure to then
> check if it is properly set by looking at /proc/$PID/environ for the
> systemd user instance.
>
> That all said, for testing purposes systemd-nspawn is probably the
> much better idea. I mean, we wrote it only for the purpose of
> testing...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat


I ended up getting pretty much everything working.

Right now we are using the same service files on desktop as on
embedded (albeit they are being partially generated by cmake's
configure_file() macro)

To recap, on the desktop we:
- Generate service files from blah.service.in files during the build,
this lets us put in hardcoded paths etc for things that need them.
- Run a script that uses 'systemctl link' to link to the users systemd folder
- Run another script to start the services

On embedded side we:
- Generate the service files...
- Run the normal 'systemctl enable xxx'
- Let the system start the services up at boot time.


The only wrinkle I've run into is that the version of systemd on f20
is old and doesn't appear to support things like 'systemctl start
company*', so we have to iterate through a manually built list of
service names. I'm hoping f21 resolves this.

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

Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface

[Lennart Poettering]

On Wed, 22.10.14 20:49, Tom Gundersen (t...@jklm.no) wrote:

> On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering
>  wrote:
> > On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote:
> >
> >> Hi guys,
> >>
> >> I finally got around to have a look at this. I can reproduce the
> >> problem, and for me a workaround is to set RequestBroadcast=yes in the
> >> DHCP section in the .network file for your host0 interface in the
> >> container. Does that work for you too.
> >
> > Hmm, maybe the default .network file we ship for this case should
> > include this setting? Or will it in turn break the non-bridged veth
> > setups?
> 
> Yeah, there is no perfect option. Some networks will filter broadcast
> messages (though that is arguably even more broken than filtering
> messed up unicast ones).

Hmm? Not following. 

I understood that RequestBroadcast=yes is necessary to make dhcp work
on the Linux kernel bridge. Or is that a misunderstanding?

What I am wondering about specifically is whether
80-container-host0.network shall default to RequestBroadcast=yes, or not?

Aso, if there are some networks that require the bit set, and others
that require it unset, what about trying the other after not getting a
reply on the first?

Lennart

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

Re: [systemd-devel] Suppressing automounting

[Lennart Poettering]

On Fri, 12.09.14 15:25, Dale R. Worley (wor...@alum.mit.edu) wrote:

> > From: Tobias Geerinckx-Rice 
> 
> > Step back, and define exactly what it is you actually need^Wwant to do.
> 
> For a certain entry in /etc/fstab (which will in practice always have
> the option "nofail"), if the device is not available "until booting is
> over" (which I'm willing to denote with a specified period of time),
> after that, it will not be automatically mounted if it becomes
> available.

This is currently not available, and it sounds very special and racy
to support it upstream I think. Sorry!

If you want to hack something up like this, I'd recommend writing a
timer unit/cronjob that creates a file $PATH after $SECONDS after boot. Then, 
add
a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and
write into it:

[Unit]
ConditionFileExists=!/the/file/you/create

That way the mount unit will always be queued, but will actually be
conditionalized out $SECONDS after boot, if you follow what I mean.

Hope this is helpful.

Lennart

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

Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface

[Tom Gundersen]

On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering
 wrote:
> On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote:
>
>> Hi guys,
>>
>> I finally got around to have a look at this. I can reproduce the
>> problem, and for me a workaround is to set RequestBroadcast=yes in the
>> DHCP section in the .network file for your host0 interface in the
>> container. Does that work for you too.
>
> Hmm, maybe the default .network file we ship for this case should
> include this setting? Or will it in turn break the non-bridged veth
> setups?

Yeah, there is no perfect option. Some networks will filter broadcast
messages (though that is arguably even more broken than filtering
messed up unicast ones).

Cheers,

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

Re: [systemd-devel] [PATCH] journal: do server_vacuum for sigusr1

[Lennart Poettering]

On Thu, 28.08.14 21:33, WaLyong Cho (walyong@samsung.com) wrote:

> runtime journal is migrated to system journal when only
> "/run/systemd/journal/flushed" exist. It's ok but according to this
> the system journal directory size(max use) can be over the config. If
> journal is not rotated during some time the journal directory can be
> remained as over the config(or default) size. To avoid, do
> server_vacuum just after the system journal migration from runtime.

OK, makes sense. 

Applied!

Thanks!

> ---
>  src/journal/journald-server.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
> index 01da38b..7e85892 100644
> --- a/src/journal/journald-server.c
> +++ b/src/journal/journald-server.c
> @@ -1224,6 +1224,7 @@ static int dispatch_sigusr1(sd_event_source *es, const 
> struct signalfd_siginfo *
>  touch("/run/systemd/journal/flushed");
>  server_flush_to_var(s);
>  server_sync(s);
> +server_vacuum(s);
>  
>  return 0;
>  }
> -- 
> 1.9.3
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] [PATCH] bootchart: only show printable processes

[Lennart Poettering]

On Thu, 28.08.14 00:44, WaLyong Cho (walyong@samsung.com) wrote:

> On 08/27/2014 03:49 AM, Lennart Poettering wrote:
> > On Tue, 26.08.14 18:11, Mantas Mikulėnas (graw...@gmail.com) wrote:
> > 
> >> On Tue, Aug 26, 2014 at 5:07 PM, WaLyong Cho  
> >> wrote:
> >>>
> >>> This case really shouldn't be happen. (But actually sometime that was
> >>> happen.) Eeven if happened we maybe want to see the bootchart exclude
> >>> not printable processes.
> >>> ---
> >>>  src/bootchart/svg.c | 3 +++
> >>>  1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
> >>> index 135883f..9b7de33 100644
> >>> --- a/src/bootchart/svg.c
> >>> +++ b/src/bootchart/svg.c
> >>> @@ -1014,6 +1014,9 @@ static void svg_ps_bars(void) {
> >>>  if (!enc_name)
> >>>  continue;
> >>>
> >>> +if (!utf8_is_printable(enc_name, strlen(enc_name)))
> >>> +continue;
> >>> +
> >>>  /* leave some trace of what we actually filtered etc. */
> >>>  svg("\n", 
> >>> enc_name, ps->pid,
> >>>  ps->ppid, ps->total);
> >>
> >> If the name is not printable, wouldn't it be better to show it in
> >> escaped form rather than pretend it doesn't exist at all?
> > 
> > Yeah I agree. I'd love to merge a patch that intrdouces
> > utf8_escape_non_printable() or so, that works similar to
> > utf8_escape_invalid(), but also escapes non-printable chars, and then
> > make use of this here...
> 
> OK, but I'm confusing. We already have *cescape*. Is it not enough with
> *cescape*?

cescape() escapes all chars < 32 and >= 127, that means it only leaves
ASCII printable characters, but not UTF8 printable characters, since
most of them are encoded in > 127...

Lennart

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

Re: [systemd-devel] [PATCH] firstboot: remove extra paranoia in --root checking

[Lennart Poettering]

On Thu, 28.08.14 13:30, Dave Reisner (dreis...@archlinux.org) wrote:

> Some package managers will chroot before running post-install and
> post-upgrade scripts. Doing this prevents systemd-firstboot from being
> used piecemeal at installation or upgrade time, as the --root=/ will be
> "cleverly" ignored.
> 
> There's already enough sanity checks in this tool that we don't also
> need add "intelligence" on top of the --root parameter. If a sys-admin
> wants to run this tool with --root=/, I see no reason why we should
> actively stop them.

Hmmm, I now commited a different patch that just removes the
--setup-machine-id refusal to operate on /. After all, if the machine
id is really missing in the root fs there's no reason to block this
off.

This should fix your issue too, right? Could you check please?

(Reducing arg_root == "/" into arg_root = NULL is really more about
optimization I guess, so I figured we should leave it in).

Lennart

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

Re: [systemd-devel] [PATCH v2] journalctl: Allow to disable line cap with --lines=all

[Lennart Poettering]

On Sun, 31.08.14 11:12, Jan Janssen (medhe...@web.de) wrote:

> @@ -68,7 +68,7 @@ static bool arg_follow = false;
>  static bool arg_full = true;
>  static bool arg_all = false;
>  static bool arg_no_pager = false;
> -static int arg_lines = -1;
> +static int arg_lines = -2;

Humm. No, please don't! This is ugly. Don't introduce constant values
without giving them a name, expecting everybody to remember the
numeric values you assign.

I have have now pushed a patch that fixes this and introduces proper
enum values ARG_LINE_DEFAULT and ARG_LINE_ALL to use.

Lennart

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

Re: [systemd-devel] systemd build dependency on dbus

[Lennart Poettering]

On Mon, 25.08.14 21:58, Filipe Brandenburger (filbran...@google.com) wrote:

> 
> On Wed, Aug 20, 2014 at 3:27 PM, Lennart Poettering
>  wrote:
> > Well, we have our own dbus library implementation since a while
> > ("sd-bus") that supports both dbus1 and kdbus as transport. We only link
> > against libdbus1 in a test to validate our marshalling against the dbus1
> > one.
> 
> That's interesting.
> 
> Indeed it would be good to clarify that libdbus is not required at
> build time (except for the test case, and maybe it can be made
> optional or dynamic loaded in that one?) There seems to be other
> configurations that are pulled from dbus, like the dbuspolicydir,
> dbussessionservicedir, etc.

The current configure.ac logic is actually broken. We pretend that
dbus was optional, but we use it's pkg-config file to derive the
default paths you point out. 

We should fix that. Happy to take a patch. Also added a TODO list item
for this.

Lennart

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

Re: [systemd-devel] Bridge not picking up DHCP address

[Lennart Poettering]

On Fri, 29.08.14 16:22, Mauricio Tavares (raubvo...@gmail.com) wrote:

Heya,

it's fun picking up two month old threads! ;-)

>   So I have a system 2 interfaces, each of them using dhcp in
> different networks (both served by the same nameserver but in
> different vlans). Let's begin by showing my config files:

Anyway, just to make sure this is not forgotten: this is being
discussed now again in this thread.

http://lists.freedesktop.org/archives/systemd-devel/2014-October/024296.html

(or well, at least I *think* this is the same issue. If not, and your
problem continues to exist, say something)

Lennart

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

Re: [systemd-devel] [PATCH] shutdown: pass own argv to /run/initramfs/shutdown

[Lennart Poettering]

On Tue, 30.09.14 17:02, Marius Tessmann (mus@gmail.com) wrote:

> On 09/30/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, Aug 29, 2014 at 05:51:45PM +0200, Marius Tessmann wrote:
> >>Since commit b1e90ec515408aec2702522f6f68c4920b56375b systemd passes
> >>its log settings to systemd-shutdown via command line parameters.
> >>However, systemd-shutdown doesn't pass these parameters to
> >>/run/initramfs/shutdown, causing it to fall back to the default log
> >>settings.
> >Hi,
> >sorry for the late reply.
> >
> >Your patch should work fine if /run/initramfs/shutdown accepts
> >those arguments, i.e. if it another systemd binary. But otherwise
> >it might fail, no?
> 
> Well, yes. I didn't really think about other implementations. I just checked
> the Dracut source and it shouldn't break anything there since it only parses
> the first argument as the verb [1]. I don't know what other implementations
> are out there, but I doubt they would break since they have no reason to
> parse
> anything but the first argument in the first place.
> 
> Also, the Initrd Interface [2] doesn't even mention what arguments are
> passed
> to the shutdown binary (not even the verb), so one could argue that
> implementations should expect this to change. ;)
> 
> Imho it would be enough to mention this in the release notes so that it can
> be fixed if necessary. Other implementations may even want to make use of
> the
> new parameters. ;)
> 
> If possible breakage for other implementations is not acceptable I would
> love
> to know how else this could/should be fixed properly.
> 
> [1] 
> https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/99shutdown/shutdown.sh#n7
> [2] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

Patch looks fine to me, but Harald (as dracut guy) shoiuld say
something about this before we merge this.

Harald?

Lennart

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

Re: [systemd-devel] Starting configurable set of services first

[Lennart Poettering]

On Tue, 02.09.14 10:06, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> Hi,
> 
> I would like to start a configurable set of services first and the
> services are wanted by multi-user.target. I am using a service to jump
> to multi-user.target and I was wondering if we can support this use
> case natively by systemd.
> 
> multi-user.target.wants
>   A.service
>   B.service
>   C.service
>   D.service
> 
> default.target > stage.target
> stage.target.wants (These are set by generator)
>   A.service
>   C.service
>   switcher.service
> 
> switcher.service (This is generated by generator)
>   [Unit]
>   Description=Switch to multi-user.targe
>   After=A.service C.service
>   [Service]
>   Type=oneshot
>   RemainAfterExit=yes
>   ExecStart=/usr/bin/systemctl --no-block start multi-user.target
> 
> This way I am jumping from one target to another target during runtime.
> 
> - What stage.target wants is dynamic. If it was static, my job would
> have been very simple.
> - I am aware of StartupCPUShares but it is not the ultimate solution
> A) there is a configurable minimum quota in CFS which still gives CPU
> to other processes. B) We still fork other processes and this causes
> changes in timeout values of other processes.
> - Adding dynamically After= to B and D service files is not the
> ultimate solution either because B and D might be socket/dbus
> activated by A or C.
> 
> Should this be something we should support natively by systemd?

As discussed at th systemd hackfest: I am a bit conservative about
this as it introduces plenty chance for deadlocks, where services
might trigger/request some other unit but we'd delay it until the
later stage...

I think the implementation you chose is actually pretty good. I am not
sure though that we should do this upstream. I mean, I really would
prefer if we'd dump as much work as possible on the IO elevator and
CPU scheduler, and then adjust the priorities of it to give hints what
matters more. Trying to second-guess the elevator and scheduler in
userspace feels a bit like chickening out to me, even though I am sure
that it might be something that one has to do for now, in the real
world...

There's one change I'd really like to see done though in systemd, that
might make things nicer for you. Currently, it's undefined in systemd
which job is dispatched first, if multiple jobs can be executed. That
means when we are about to fork off a number of processes there's no
way to control which one gets forked off first. I'd be willing to
merge a patch that turns this into a prioq, so that some priority
value can be configured (or automatically derived) for each unit, and
the one with the highest priority would win, and be processed
first. This would not provide you with everything what you want, but
would make things a bit nicer when we dump all possible work on the
scheduler/elevator, because after all we cannot really dump all work
at the same time, and hence should at least give you control in which
order to dump it, if you follow what I mean.

Lennart

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

Re: [systemd-devel] systemd-215: could not boot, missing /dev/disk/...-part2 symlink

[Lennart Poettering]

On Tue, 02.09.14 11:15, Alexander E. Patrakov (patra...@gmail.com) wrote:

> Hello.
> 
> I have a Gentoo system, with btrfs on /dev/sda2 (also known as
> /dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2) and with dracut
> 038 with Gentoo patches that you can view here:
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/dracut/files/
> (see 0038-*)
> 
> Today, I powered the computer on (without applying any updates since the
> previous successful boot), but the boot stalled, and I was dropped into an
> emergency shell. I have saved the SOS report, see the attachment.
> 
> As you can see, /dev/sda2 exists, but the link doesn't. "udevadm trigger"
> helped it to appear, and the boot continued.
> 
> I initially thought that it might be due to locking that systemd-udevd
> applies to block devices for the period of running its IMPORT{program}
> rules. Look: if in worker_new() the lock is not acquired successfully, then
> the event processing is skipped (and this also means symlinks are not
> created). But then there should be an "Unable to flock" debug message in
> "journalctl -b -p debug", and it doesn't exist. So it must be something
> else. Any other ideas?

Have you enabled CONFIG_FHANDLE in your kernel? If not, enable it. 

Lennart

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

Re: [systemd-devel] Please help: systemd "special targets" activaton order for fast boot

[Lennart Poettering]

On Fri, 05.09.14 16:17, Chaiken, Alison (alison_chai...@mentor.com) wrote:

> (BTW, Lennart and Kai, is there a reason this great article couldn't
> be hosted at freedesktop.org or 0pointer.de?)

Well, not sure if we own all the rights to be able to do that. As it
appears h-online.com is back up though, at least as an archive.

Lennart

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

Re: [systemd-devel] Please help: systemd "special targets" activaton order for fast boot

[Lennart Poettering]

On Fri, 05.09.14 13:52, Viswambharan, Vibin (V.) (vvi...@visteon.com) wrote:

> 1/ Is there a recommended way to re-organize the boot target order (
> I don't see there is a way to fit my userlevel application
> executables or deamons needed for early functionality to be
> associated with these "primitive target" appearing in the boot
> chain".

Well, the unit files are all just text files, you can mostly just edit
them and adjust to your needs.

That said, the default unit files contain pretty minimal dependencies
only, just the stuff that is really needed. Hence optimizing the
dependencies is not rally typically necessary or sometimes even
possible.

Usually, if there's something you want to run earlier than the
default, you can move them into the early boot process, but if you do
this you need to write that program in a style that it is capable of
working in such an early-boot environment. Among other things this
means no access to /var and suchlike, no persistent storage. Also, no
access to D-Bus, and so on.

> 2/ Is there a way to define custom target like "early-boot.target"
> and can be placed well on top of these special targets which can be
> used to start my user space applications that needs to be started
> well early during the boot process ( for example my full functional
> UI to be available within 8 sec from a cold boot which is has a X11
> dependency) . So I mean that I need a way to start the X11 and my UI
> executable soon after systemd gets initialized and very early during
> the boot process.Currently the service files for the X11 and UI
> after associated with the basic.target and now the service
> activation can happen only around 7 sec after power on and when the
> basic.target is activated.

You can add such a service to the normal target, but set
DefaultDependencies=no for it. If you do the service will not be
ordered after basic.target (which is the default), thus run in the
early-boot mode described above. However, be careful, as pointed out above.

> 3/ Is there any special consideration to disable these special
> targets like (swap.target,local-fs target if they are not used in
> the embedded devices?).

Well, they cost nothing if there are no swaps or local file systems to
mount. I'd suggest not to bother.

Lennart

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

Re: [systemd-devel] [PATCH] journald: add CAP_MAC_OVERRIDE in journald for SMACK issue

[Lennart Poettering]

On Thu, 11.09.14 15:54, juho son (juho80@samsung.com) wrote:

> >We don't use S-O-b on systemd...
> I will send again follow.

Oh, that was just a hint for the future, no need to redo the patch
just to drop s-o-b. We usually drop it though while committing.

Anyway, merged your repost. 

Thanks,

Lennart

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

Re: [systemd-devel] [PATCH v2] journald: add CAP_MAC_OVERRIDE in journald for SMACK issue

[Lennart Poettering]

On Thu, 11.09.14 16:06, Juho Son (juho80@samsung.com) wrote:

> systemd-journald check the cgroup id to support rate limit option for
> every messages. so journald should be available to access cgroup node in
> each process send messages to journald.
> In system using SMACK, cgroup node in proc is assigned execute label
> as each process's execute label.
> so if journald don't want to denied for every process, journald
> should have all of access rule for all process's label.
> It's too heavy. so we could give special smack label for journald te get
> all accesses's permission.
> '^' label.
> When assign '^' execute smack label to systemd-journald,
> systemd-journald need to add  CAP_MAC_OVERRIDE capability to get that smack 
> privilege.
> 
> so I want to notice this information and set default capability to
> journald whether system use SMACK or not.
> because that capability affect to only smack enabled kernel

Applied! Thanks!

> ---
>  units/systemd-journald.service.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/units/systemd-journald.service.in 
> b/units/systemd-journald.service.in
> index 7013979..4de38fa 100644
> --- a/units/systemd-journald.service.in
> +++ b/units/systemd-journald.service.in
> @@ -20,7 +20,7 @@ Restart=always
>  RestartSec=0
>  NotifyAccess=all
>  StandardOutput=null
> -CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE 
> CAP_SYSLOG CAP_AUDIT_CONTROL CAP_CHOWN CAP_DAC_READ_SEARCH CAP_FOWNER 
> CAP_SETUID CAP_SETGID
> +CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE 
> CAP_SYSLOG CAP_AUDIT_CONTROL CAP_CHOWN CAP_DAC_READ_SEARCH CAP_FOWNER 
> CAP_SETUID CAP_SETGID CAP_MAC_OVERRIDE
>  WatchdogSec=1min
>  
>  # Increase the default a bit in order to allow many simultaneous
> -- 
> 1.9.1
> 
> 


Lennart

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

Re: [systemd-devel] So how am I supposed to put together my Linux system?

[Lennart Poettering]

On Fri, 05.09.14 20:34, Tobias Hunger (tobias.hun...@gmail.com) wrote:

Heya,

Sorry for the late response, been travelling for a month, and then
have been more travelling, and still trying to process all the mails
that queued up since.

> On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering
>  wrote:
> > Yeah, we want to encourage distros to install kernels into /usr,
> > somewhere next to where the kmods already are, and then copy that over
> > where necessary into the used boot partition. We actually have sime
> > infrastructure for this in place in systemd, in the "install-kernel"
> > script, which also has a man page.
> 
> Any place that you would care to recomend? It would suck to have each
> distro put kernels somewhere else.

Hmm, dunno, I figure Kay/Harald might have an idea about this. Kay? Harald?

> I see that secure boot wants one file and that you will need to merge kernel
> and initrd into one. But you will need the meta data to link the kernel/initrd
> combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos
> also has that and stores that meta-data in non-volatile memory accessible to
> the BIOS.

My idea would be that the initrd contains that info. Each usr tree
comes with one initrd, and that initrd knows which usr tree to boot.

> > 2. If we cannot have external config files, then kernel/initrd should
> > find their stuff an empty kernel cmdline option.
> 
> Nice ideal, but I do not see how that will work in general. You could bake 
> some
> id into the kernel (kernel version or whatever), but usually the kernel 
> changes
> slower than the sum of the files in /usr. You do want to boot different of 
> these
> usr-setups with one kernel.

Note that at least chromeos doesn't do this. They update the whole OS
at once, including the kernel. And never kernel and /usr independently.

> > 4. The initrds should probably use information from
> > /usr/lib/os-release (as shipped in the initrd as a copy of the OS'
> > version) to build the btrfs sub-volume name to boot from. It should
> > not allow overriding this name via the kernel cmdline, at least as
> > long as we are in a mode where secureboot is actually turned on...
> 
> That could work, provided there is something like a timestamp/version number
> in /usr/lib/os-release that actually changes every time *anything* in
> /usr changes
> (or at least when those changes are getting distributed as an image).
> 
> You still need to store that information somewhere though for the kernel to 
> know
> what to boot.

Well, gummiboot picks a kernel with the initrd attached. the initrd
then finds the right /usr tree according to the information it contains.

> > Hope that makes some sense?
> 
> Not really. I do see how this can work to boot the newest
> installation of distroX: You just need to look for the newest
> version of the usr-subvolume and boot that.

Well, I think kernel and /usr hierarchy really belong together. If you
pick a kernel you thus implicitly also pick a /usr tree. 

(Of course, this strict we only need to be for a verified boot. For
other cases, we of course can allow passing arbitrary kernel cmdline
options, to pick different usr tree. The user should be able to
override things, unless the device is in trusted mode)

> How do I boot the version I ran before the upgrade in case the
> upgrade failed?

In general the rule should probably be to go back in version one-by-one
if a kernel/system failed to boot. THe boot loader should by default
boot the newest kernel, thus the newest /usr, too. if that for some
reason nerver finishes, on next reboot it should pick the kernel one
version older, and so on.

> I really do not see how you can get around storing meta-data somehow.
> 
> You can not change the kernel/initrd when it is signed, so you can not bake 
> any
> information into that file. You can apparently not have a separate
> file when using
>
> secure boot. That leaves EFI vars I think. Do those integrate with
> secure boot?

Sure, we can store failure info in EFI Vars, no problem really.

Lennart

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

Re: [systemd-devel] Log unit's name instead of unit's description?

[Lennart Poettering]

On Mon, 08.09.14 11:56, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

> On 05/09/14 18:22, Jakub Klinkovský wrote:
> > What is the reason behind logging unit's description? Consider the
> > following journal message (from `journalctl -b`):
> > 
> > systemd[1]: Starting A secure, fast, compliant and very flexible
> > web-server...
> 
> As a data point, Debian's init scripts have traditionally combined the
> description and name like this:
> 
> Starting miscellaneous widget daemon: miscd.
> Starting Apache web server: apache2.
> 
> Perhaps something like this would make more (grammatical and UI) sense
> for a systemd unit named miscd.service with Description="Miscellaneous
> widget daemon", in a way that degrades gracefully if the maintainer
> has (IMO incorrectly) used a Description like the one quoted above?
> 
> systemd[1]: Starting miscd.service (Miscellaneous widget daemon)...
> systemd[1]: Started miscd.service (Miscellaneous widget daemon).
> systemd[1]: Starting apache2.service (Apache web server)...
> systemd[1]: Started apache2.service (Apache web server).
> 
> or
> 
> systemd[1]: Starting miscd.service: Miscellaneous widget daemon...
> systemd[1]: Started miscd.service: Miscellaneous widget daemon.
> systemd[1]: Starting apache2.service: Apache web server...
> systemd[1]: Started apache2.service: Apache web server.
> 
> As a native Speaker of a Language that does not capitalize Nouns :-)
> I've always found "Starting Miscellaneous widget daemon" a bit
> jarring. Or is the intention that that unit should have had
> "miscellaneous widget daemon", without the initial capital, as its
> Description?

Hmm, this is something to think about. I have for now added this to
the TODO list. That said, the boot output is supposed to be "pretty"
stuff, hence at least should contain the pretty description. We can
also add the non-pretty one, but that would certainly make the strings
even longer...

So far, our idea was to enable unit file authors to control what is
shown. The burden is currently on them to set the description to
something really useful. However, I do agree with the sentiment that
including the unit name might be useful too, since it would make the
log output "more actionable", if you follow what I mean.

Lennart

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

Re: [systemd-devel] systemd-journald watchdog timeout

[Lennart Poettering]

On Wed, 22.10.14 18:35, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> > That's difficult to say just from these logs. Can you reliably
> > reproduce this? If so, can you attach strace to journald before this
> > happens and see what it is doing?
> 
> I am wondering if we should send another signal that generates core
> when the watchdog is not fed. It would be nice to get the coredump of
> a frozen process.

Oh indeed, we should probably send a SIGABRT in this case. Makes a ton
of sense. Love it!

Added to the TODO list.

Lennart

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

Re: [systemd-devel] [PATCH] build-sys: make hibernation support configure option also handle hybrid-sleep; fix indentation

[Lennart Poettering]

On Tue, 09.09.14 01:40, Ivan Shapovalov (intelfx...@gmail.com) wrote:

> The patch by Umut did miss at least hybrid-sleep -- it involves hibernation
> as well (hybrid sleep is a hibernation followed by S3 rather than S4 
> powerdown).
> 
> Also, it messed up indentation a bit (Makefile.am seems to use tabs), which I
> fixed as well.

This patch was applied a while back by Tom. Thanks!

> And I wonder, maybe it makes sense to conditionalize sleep (suspend) support 
> as well
> as hibernation? Or are there use-cases when suspend is possible, but not 
> hibernation?

Yes, suspend is much better supported thatn hibernation, usually.

I'd take a patch to make it optional too, I guess.

Lennart

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

Re: [systemd-devel] systemd-journald watchdog timeout

[Umut Tezduyar Lindskog]

On Wed, Oct 22, 2014 at 4:59 PM, Lennart Poettering
 wrote:
> On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) 
> wrote:
>
>> On one boot I got a watchdog timeout on systemd-journald:
>>
>> Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 
>> 68.7M (m
>> Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var 
>> is 2
>> Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not 
>> rea
>> Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40
>> Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 
>> 1/3)
>> Oct 21 20:08:25 feanor kernel: wlan0: authenticated
>> Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 
>> 1/3)
>> Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 
>> (capab
>> Oct 21 20:08:25 feanor kernel: wlan0: associated
>> Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link 
>> become
>> Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to 
>> Persis
>> Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and 
>> Directories
>> Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization...
>> Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System 
>> Boot/Shutdo
>> Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System 
>> Boot/Shutdow
>> Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization.
>> Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization.
>> Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization.
>> Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket.
>> Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket.
>> Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket.
>> Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0.
>> Oct 21 20:08:25 feanor systemd-networkd[518]: lo  : gained 
>> carrier
>> Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on 
>> /dev/inpu
>> Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on 
>> /dev/inpu
>> Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on 
>> /dev/inpu
>> Oct 21 20:08:25 feanor systemd[1]: Started Network Service.
>> Oct 21 20:08:25 feanor systemd[1]: Starting Network.
>> Oct 21 20:08:25 feanor systemd[1]: Reached target Network.
>> Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution...
>> Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 
>> 75.1M (m
>> Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
>> Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not 
>> read
>> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout 
>> (li
>> Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
>> Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2.
>> Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed 
>> out. Te
>> Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog 
>> timeout (l
>> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm 
>> timed o
>> Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
>> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process 
>> exited
>> Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered 
>> failed
>> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff 
>> time,
>> Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service...
>> Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
>> Oct 21 20:11:20 feanor systemd[1]: Started Journal Service.
>>
>> As you can see at 20:08:20 things appears to look fine, but everything
>> get stuck during 3 minutes until there is a watchdog timeout for the
>> journal and it gets restarted. Then the boot finished without any further
>> problem. The next time everything worked fine, so I am wondering what could
>> have happened?
>
> That's difficult to say just from these logs. Can you reliably
> reproduce this? If so, can you attach strace to journald before this
> happens and see what it is doing?

I am wondering if we should send another signal that generates core
when the watchdog is not fed. It would be nice to get the coredump of
a frozen process.

Umut

>
> What I find interesting is that after the 3min pause suddenly the
> network driver allocates irq 55. This kinda makes me wonder if this
> might be a kernel/driver problem of some kind, where for some reason
> userspace (and hence journald) don't get scheduled?
>
> What distro/version/arch is this?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_

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

[Ronny Chevalier]

2014-10-22 18:30 GMT+02:00 Lennart Poettering :
> On Wed, 22.10.14 18:28, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
>
>> >> I'm not sure abou the name 'amendments.conf'. Wouldn't 'local.conf'
>> >> be more idiomatic, and also easier to type?
>> >
>> > I was thinking about this too, and I wanted to propose "override.conf"
>> > instead?
>> >
>> > The word "amendment" I only know from the US constitution...
>> Ok, both are fine for me.
>
> I'd prefer "override" still...
Yeah I misspoke, I meant "local" and "override" were fine. I'll set it
to "override.conf" ;)

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

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

[Lennart Poettering]

On Wed, 22.10.14 18:28, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:

> >> I'm not sure abou the name 'amendments.conf'. Wouldn't 'local.conf'
> >> be more idiomatic, and also easier to type?
> >
> > I was thinking about this too, and I wanted to propose "override.conf"
> > instead?
> >
> > The word "amendment" I only know from the US constitution...
> Ok, both are fine for me.

I'd prefer "override" still...

Lennart

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

Re: [systemd-devel] [PATCH] networkd: allow specification of DHCP route metric

[Lennart Poettering]

On Mon, 08.09.14 15:09, Tom Gundersen (t...@jklm.no) wrote:

> Applied. Thanks!

Hmm, the route metric for dhcp routes is now configurable. But what
about implied routes created due to static IP configuration?

I wonder if it wouldn't be a better idea to move RouteMetric= from the
[DHCP] section into the [Network] section, and make it affect all
routes, regardless if created implicitly due to static IP
configuration, or if created due to DHCP configuration or created via
explicit [Route] blocks. (Of course, the latter should allow
individual overrides, and they already do...)

Lennart

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

Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface

[Lennart Poettering]

On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote:

> Hi guys,
> 
> I finally got around to have a look at this. I can reproduce the
> problem, and for me a workaround is to set RequestBroadcast=yes in the
> DHCP section in the .network file for your host0 interface in the
> container. Does that work for you too.

Hmm, maybe the default .network file we ship for this case should
include this setting? Or will it in turn break the non-bridged veth
setups?

Lennart

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

Re: [systemd-devel] [systemd.link] How to use NamePolicy=mac?

[Tom Gundersen]

On Wed, Oct 8, 2014 at 10:04 AM, Moviuro  wrote:
> Hi all!
>
> In order to fix in an easily predictable manner the interfaces' names, I went
> and wrote the following .link file:
>
> /etc/systemd/network/00-default.link
> [Link]
> NamePolicy=mac
> MACAddressPolicy=persistent

Looks good.

> I daemon-reload, reboot:
>
> $ ip a
> [...]
> 4: eth0:  mtu 1500 qdisc pfifo_fast state UP
> group default qlen 1000
> link/ether b8:27:eb:aa:aa:d2 brd ff:ff:ff:ff:ff:ff
> [...]
> [...]
>
> However,
> $ udevadm test-builtin net_setup_link /sys/class/net/eth0
> calling: test-builtin
> load module index
> timestamp of '/etc/systemd/network' changed
> Parsed configuration file /usr/lib/systemd/network/99-default.link
> Parsed configuration file /etc/systemd/network/00-default.link
> Created link configuration context.
> ID_NET_DRIVER=smsc95xx
> Config file /etc/systemd/network/00-default.link applies to device eth0
> ID_NET_NAME=enxb827ebd2

Looks bad. This is a bug somewhere, if ID_NET_NAME is set, then also
your if should get renamed. Does this also happen if you reboot, and
can you reproduce with current git?

I'll take a look. Thanks for the report!

Cheers,

Tom

> unload module index
> Unloaded link configuration context.
>
> Also,
> # /lib/systemd/systemd-udevd --debug
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram9'
> restoring old watch on '/dev/ram9'
> adding watch on '/dev/ram9'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram8'
> restoring old watch on '/dev/ram8'
> adding watch on '/dev/ram8'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram7'
> restoring old watch on '/dev/ram7'
> adding watch on '/dev/ram7'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram5'
> restoring old watch on '/dev/ram5'
> adding watch on '/dev/ram5'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram14'
> restoring old watch on '/dev/ram14'
> adding watch on '/dev/ram14'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram2'
> restoring old watch on '/dev/ram2'
> adding watch on '/dev/ram2'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram15'
> restoring old watch on '/dev/ram15'
> adding watch on '/dev/ram15'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram6'
> restoring old watch on '/dev/ram6'
> adding watch on '/dev/ram6'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram4'
> restoring old watch on '/dev/ram4'
> adding watch on '/dev/ram4'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram3'
> restoring old watch on '/dev/ram3'
> adding watch on '/dev/ram3'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram13'
> restoring old watch on '/dev/ram13'
> adding watch on '/dev/ram13'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram11'
> restoring old watch on '/dev/ram11'
> adding watch on '/dev/ram11'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop6'
> restoring old watch on '/dev/loop6'
> adding watch on '/dev/loop6'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram12'
> restoring old watch on '/dev/ram12'
> adding watch on '/dev/ram12'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop3'
> restoring old watch on '/dev/loop3'
> adding watch on '/dev/loop3'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop5'
> restoring old watch on '/dev/loop5'
> adding watch on '/dev/loop5'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram1'
> restoring old watch on '/dev/ram1'
> adding watch on '/dev/ram1'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram0'
> restoring old watch on '/dev/ram0'
> adding watch on '/dev/ram0'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop7'
> restoring old watch on '/dev/loop7'
> adding watch on '/dev/loop7'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/ram10'
> restoring old watch on '/dev/ram10'
> adding watch on '/dev/ram10'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop1'
> restoring old watch on '/dev/loop1'
> adding watch on '/dev/loop1'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop2'
> restoring old watch on '/dev/loop2'
> adding watch on '/dev/loop2'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop4'
> restoring old watch on '/dev/loop4'
> adding watch on '/dev/loop4'
> device 0xb78bb3f8 has devpath '/devices/virtual/block/loop0'
> restoring old watch on '/dev/loop0'
> adding watch on '/dev/loop0'
> device 0xb78bb3f8 has devpath '/devices/platform/mmc-
> bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0/mmcblk0p2'
> restoring old watch on '/dev/mmcblk0p2'
> adding watch on '/dev/mmcblk0p2'
> device 0xb78bb3f8 has devpath '/devices/platform/mmc-
> bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0/mmcblk0p1'
> restoring old watch on '/dev/mmcblk0p1'
> adding watch on '/dev/mmcblk0p1'
> device 0xb78bb3f8 has devpath '/devices/platform/mmc-
> bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0'
> restoring old watch on '/dev/mmcblk0'
> adding watch on '/dev/mmcblk0'
>

Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface

[Tom Gundersen]

On Sun, Oct 12, 2014 at 12:57 AM, Tom Gundersen  wrote:
> On Fri, Sep 26, 2014 at 4:52 AM, Leonid Isaev  wrote:
>> Hi,
>>
>> On Thu, Sep 25, 2014 at 04:56:55PM -0700, James Lott wrote:
>>> Actually, the reason I am using dhcpcd fro mthe command line is as a 
>>> debugging
>>> measure, because I originally setup a .network file for this interface to
>>> attempt to allow systemd-networkd to handle acquiring the DHCP lease.
>>
>> You could run networkd manually as
>> # SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd
>>
>> but this will also show endless DISCOVER attempts. In my case, I controlled 
>> the
>> DHCP server, and according to its logs the lease is actually assigned but the
>> client never receives it. So, I suspect a bug either in kernel or systemd
>> because packets get lost in the bridge (or bond in my case). I suspect the
>> former because restarting networkd didn't help (i.e. the DHCP lease never got
>> received).
>>
>>> Yuck. I'm really not a fan of netctl, and would probably sooner hack 
>>> together
>>> some oneshot service files that manually setup the interfaces and acquire
>>> leases. So it sounds like systemd-networkd is not quite ready for prime time
>>> when it comes to being a complete interface management solution. I guess
>>> that's what I get for living life on the edge ;)
>>
>> Netctl is better in this situation because it allows ordering of different
>> profiles w.r.t. each other because they are just systemd services (in 
>> networkd
>> language this would be ordering of different .net* units if such existed). So
>> you can first set up vlans, then bridge and do the DHCP stuff.
>>
>> There is an additional problem with networkd: you never know how to order
>> against it. Sure there are network* targets (and ideally things _should_ 
>> work)
>> but they are useless in this context because they can be reached before
>> (virtual) devices are actually initialized. OTOH, when a netctl script
>> successfully returns, you know that things are properly set up.
>>
>> Hopefully this thread attracts relevant attention because I don't know how to
>> debug this...
>
> Hi Leonid and James,
>
> Thanks for debugging this so far, I'll take a look next week.
>
> Cheers,
>
> Tom

Hi guys,

I finally got around to have a look at this. I can reproduce the
problem, and for me a workaround is to set RequestBroadcast=yes in the
DHCP section in the .network file for your host0 interface in the
container. Does that work for you too.

We should probably come up with some better way to handle this, but it
is not clear to me at the moment how this can best be done to work
nicely out of the box.

Cheers,

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

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote:

> > We are always interested in technical feedback.
> 
> I have seen this comment several times from the systemd devs, and I
> don't doubt it.  But I think much of the criticism of systemd is not
> technical. It has a more social/political nature, and I think you
> should be interested in that feedback as well (even if it is
> technically un-interesting).

Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!

Thank you for your understanding!

Lennart

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

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Rob Owens]

- Original Message -
> From: "Lennart Poettering" 

> We are always interested in technical feedback.

I have seen this comment several times from the systemd devs, and I don't doubt 
it.  But I think much of the criticism of systemd is not technical. It has a 
more social/political nature, and I think you should be interested in that 
feedback as well (even if it is technically un-interesting).

Here is an example of what I consider a social/political problem stemming from 
technical decisions:

Say you are a housing developer.  After many calculations, you have decided 
that the best design for housing is a cube.  It has a high 
volume-to-surface-area ratio, which allows it to house the most people with 
minimal heating/cooling loss to the outside environment.  It is easier to build 
than a sphere (which would have a higher volume-to-surface-area ratio).  To 
further maximize efficiency, each building will be a multi-unit dwelling.  
Interior units will have very little heat transfer to the outside, because the 
surrounding units help insulate them.

However, I don't want to share walls with another family, so I decide to buy a 
standalone house even though it is technically less efficient.  That's my 
choice, and choice is great, right.  But then I try to buy an air conditioner 
(cooling unit), and I find out that it is only compatible with your 
multi-dwelling cube house.  Why?  Because you have integrated some wonderful 
sensor technology into your buildings that the air conditioner manufacturer 
wants to take advantage of.  

So now I have a choice:  live in the house of my choice with no air 
conditioner, or live in your building with an air conditioner.

If you had designed your sensor system to be a separate piece, rather than 
integrating it directly into the building, I could buy any house I want and 
still have an air conditioner.  But because of your design choices (as well as 
the choices of the air conditioning manufacturer), my choice of housing is 
limited or even eliminated.  Tightly integrating the sensor system into the 
building may have been the technically best solution, but it has negative 
consequences in non-technical areas.

I hope you will give consideration to the non-technical as well as the 
technical when making your design decisions.

In case anybody's having trouble with the analogy:

The cube house is systemd.
The sensor technology is logind.
The air conditioner is pretty much any Gnome application.
The non-cube house is any other init system besides systemd.

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

Re: [systemd-devel] [PATCH 0/5] Coverity fixes

[Lennart Poettering]

On Wed, 10.09.14 13:51, Philippe De Swert (philippedesw...@gmail.com) wrote:

> Ok so it has been taken into use and can actually somehow be considered part 
> of 
> the coding style? The mail was still speculating about it and I could not
> quickly see a confirmation of this.

Yes, it is the coding style now, also see the CODING_STYLE text file
in the git repo.

Lennart

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

Re: [systemd-devel] [PATCH 1/5] [use after free] Avoid using m->kdbus after freeing it.

[Lennart Poettering]

On Wed, 10.09.14 12:20, philippedesw...@gmail.com (philippedesw...@gmail.com) 
wrote:

> From: Philippe De Swert 
> 
> m->kdbus could be freed before it is released. Changing the
> order fixes the issue.

David applied this now, but actually, just for the sakes of archives,
this is a false positive. The KDBUS_CMD_FREE ioctl and the free() are
never invoked at the same time. Either the message is stored in a
kdbus buffer in which case we issue KDUS_CMD_FREE, or it's stored in a
malloc()ed area, in which case we call free().

This commit hence was entirely bogus, but of course doesn't matter.

> 
> Found with Coverity. Fixes: CID#1237798
> 
> Signed-off-by: Philippe De Swert 
> ---
>  src/libsystemd/sd-bus/bus-message.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/libsystemd/sd-bus/bus-message.c 
> b/src/libsystemd/sd-bus/bus-message.c
> index d00455a..bfb14fc 100644
> --- a/src/libsystemd/sd-bus/bus-message.c
> +++ b/src/libsystemd/sd-bus/bus-message.c
> @@ -127,9 +127,6 @@ static void message_free(sd_bus_message *m) {
>  
>  message_reset_parts(m);
>  
> -if (m->free_kdbus)
> -free(m->kdbus);
> -
>  if (m->release_kdbus) {
>  uint64_t off;
>  
> @@ -137,6 +134,9 @@ static void message_free(sd_bus_message *m) {
>  ioctl(m->bus->input_fd, KDBUS_CMD_FREE, &off);
>  }
>  
> +if (m->free_kdbus)
> +free(m->kdbus);
> +
>  sd_bus_unref(m->bus);
>  
>  if (m->free_fds) {
> -- 
> 1.8.3.2
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


Lennart

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

Re: [systemd-devel] [PATCH 3/3] run: introduce timer support option

[Lennart Poettering]

On Tue, 07.10.14 14:20, WaLyong Cho (walyong@samsung.com) wrote:

> If systemd-run is called with timer option, then systemd-run call
> NewTransientUnit with service unit. And also call StartTransientUnit
> with timer unit which has same name with the service. So actually, two
> method call is coming and two transient unit is generated. One is
> service and the other is timer.
> 
> Supported timer options are --after=, --after-boot=, --after-startup=,
> --after-active=, --after-inactive=, --calendar=, --accuracy= and
> --wake-system. Each option corresponding with OnActiveSec=,
> OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=,
> AccuracySec= and AccuracySec= of timer respectively.

Hmm, I'd really like to stay close to the underlying props here in
naming, and call the options "--on-boot=", "--on-inactive=" and so on
(the -sec suffix we can probably drop).

The AccuracySec= and WakeSystem= stuff I think we don't need to cover
with a command line argument of its own, we can cover that with
--property=.

> +static bool with_timer = false;
> +static char *arg_after = NULL;
> +static char *arg_after_boot = NULL;
> +static char *arg_after_startup = NULL;
> +static char *arg_after_active = NULL;
> +static char *arg_after_inactive = NULL;
> +static char *arg_calendar = NULL;
> +static char *arg_accuracy = NULL;
> +static bool arg_wake_system = false;

I'd just do one arg_on_timer usec_t variable to store most of the
--on-xyz= values in. Plus one arg_on_calendar to hold the calendar
expression. This should be much simpler than keeping one variable
around for each.

> +case ARG_AFTER:
> +r = parse_sec(optarg, &u);
> +if (r < 0) {
> +log_error("Failed to parse timer value: %s", 
> optarg);
> +return r;
> +}
> +arg_after = optarg;
> +with_timer = true;
> +break;

This stuff really should not store the string, but the parsed value. 

(I'll leave the rest unreviewed for now, please rework this first to
make use of the fourth StartTransientUnit() bus call argument!)

Thanks,

Lennart

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

Re: [systemd-devel] [PATCH 1/3] dbus: introduce new method call NewTransientUnit

[Lennart Poettering]

On Tue, 07.10.14 14:20, WaLyong Cho (walyong@samsung.com) wrote:

> It similar with StartTransientUnit but the NewTransientUnit does not
> start the unit immediately. Newly generated transient unit can be
> activated by "systemctl start".

So far units are immediately GC'ed when they aren't running or
otherwise referenced anymore. That's really a behaviour I'd like to
retain. Hence, let's just make the final argument of
StartTransientUnit() do something useful, so that there's one primary
unit to create and start, plus any number of additional units that can
be referenced by the primary one, but are not started immediately.

(see other mail for details)

Lennart

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

Re: [systemd-devel] systemd-journald watchdog timeout

[Damien Robert]

>From Lennart Poettering, Wed 22 Oct 2014 at 16:59:09 (+0200) :
> On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) 
> wrote:
> That's difficult to say just from these logs.

Yeah that was what I feared.

> Can you reliably reproduce this? If so, can you attach strace to journald 
> before this happens and see what it is doing?

Un(?)fortunately no.

> What I find interesting is that after the 3min pause suddenly the
> network driver allocates irq 55. This kinda makes me wonder if this
> might be a kernel/driver problem of some kind, where for some reason
> userspace (and hence journald) don't get scheduled?

I am not sure this is related, on a non troublesome boot I also have
similar lines:
Oct 22 09:12:39 feanor systemd[1]: Started Network Service.
Oct 22 09:12:39 feanor systemd[1]: Starting Network.
Oct 22 09:12:39 feanor systemd[1]: Reached target Network.
Oct 22 09:12:39 feanor systemd[1]: Starting Network Name Resolution...
Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
Oct 22 09:12:39 feanor systemd-resolved[526]: Using system hostname 'feanor'.
Oct 22 09:12:39 feanor systemd[1]: Started Network Name Resolution.
Oct 22 09:12:39 feanor systemd[1]: Starting Multi-User System.
Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
Oct 22 09:12:39 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read
Oct 22 09:12:39 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40

> What distro/version/arch is this?

Up to date archlinux, kernel 3.16.4-1-ARCH x86_64, systemd 216-3.

-- 
Damien Robert
http://www.normalesup.org/~robert/pro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] runtime configurable timer

[Lennart Poettering]

On Wed, 17.09.14 16:20, WaLyong Cho (walyong@samsung.com) wrote:

> Before start working it, we need some of discussion about how make the
> transient unit. I think we have two options.
> One is, as you said, make systemd-at and the other is add option to
> systemd-run. (e.g. --OnCalendar=, --OnActiveSec= or so)

I'd vote for the latter, and call the options --on-calendar= and
--on-active-sec= and so on. (CameCase as command line arguments is not
really that common)

Lennart

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

Re: [systemd-devel] [RFC] runtime configurable timer

[Lennart Poettering]

On Thu, 11.09.14 17:45, WaLyong Cho (walyong@samsung.com) wrote:

> (I will happy there is already similar method already exist.)
> 
> systemd already has similar functionality "systemd-run" but that is only
> for scope or service unit. I think that is useful run a service without
> unit file on permanent storage.
> 
> As a similar method, is it possible to generate or configure timer unit
> on runtime?

Currently not, but this would be certainly useful.

> Honestly, now, I need a runtime configurable timer interface. If systemd
> has this then I can reduce one of daemon.

Currently pid1's StartTransientUnit() bus call already takes four arguments
arguments: 

  1. a name for the unit to create and start
  2. a mode how to start it
  3. an array with properties for the unit
  4. an array conisting of unit names plus a property array each,
 which is supposed to contain additional unit definitions which can
 be referenced by the main unit you are creating.

Now, while the method takes that fourth argument it is actually just
ignored. The plan was (and still is) to beef this up and make it
useful for installing both a transient service and a timer unit at
once. More specifically: to implement something that would work like
"at" a client would invoke StartTransientUnit(), create the timer unit
as primary unit, and then include the service definition for the
service to eventually start in the second array.

I would love to see this getting fully implemented now, it would be
great if systemd-run would get an --on-calendar= switch or so, which
makes use of this behaviour.

Lennart

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

Re: [systemd-devel] Timers without matching units?

[Cristian Rodríguez]

El 22/10/14 a las #4, Ivan Shapovalov escribió:
> Hi,
> 
> The systemd.timer(5) manpage states:
> 
> "For each timer file, a matching unit file must exist, describing the unit to
> activate when the timer elapses."
> 

I guess for now you can create a dummy unit that executes /bin/true to
workaround this limitation. ;-)



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

Re: [systemd-devel] Forwarding to syslog missed XX messages

[Lennart Poettering]

On Wed, 22.10.14 14:28, Reindl Harald (h.rei...@thelounge.net) wrote:

> >Why precisely your syslog implementation is too slow is something
> >you'd have to debug on the side of theat implementation, we cannot
> >determine this from systemd's side.
> >
> >Note that rsyslog doesn't need the syslog forwarding anymore these
> >days, it picks up the messages directly from the journal. You can thus
> >turn syslog forwarding off with ForwardToSyslog=no in
> >journald.conf. In fact, very recent systemd versions actually changed
> >the default here to off, given the fact that rsyslog doesn't need this
> >any more
> 
> that is in fact the case on all of my machines
> 
> so why does systemd-journal complain about missed forwarding at all?

We increase the counter each time we try to send something to the
other syslogd and get EAGAIN back, which is an indication tht the
socket buffer is full at the moment.

Lennart

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

Re: [systemd-devel] [PATCH] hwdb: Add mapping for special keys on compaq ku 0133 keyboards

[Lennart Poettering]

On Wed, 22.10.14 14:09, Hans de Goede (hdego...@redhat.com) wrote:

> The compaq ku 0133 keyboard has 8 special keys at the top:
> http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg
> 
> 3 of these use standard HID usage codes from the consumer page, the 5
> others use part of the reserved 0x07 - 0x1f range.
> 
> This commit adds mapping for this keyboard for these reserved codes, making
> the other 5 keys work.

Thanks! Applied!

Lennart

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

Re: [systemd-devel] New systemd bindings for GLib

[Lennart Poettering]

On Wed, 10.09.14 09:12, Tristan Brindle (tcbrin...@gmail.com) wrote:

> 
> Hi all,
> 
> I needed to use systemd for a new project, and I was surprised to
> find that there was no nice client library available wrapping the
> D-Bus API in GObjects (or at least, if one exists, Google couldn’t
> find it). So I wrote one myself.
> 
> The code is available at
> 
> https://github.com/tcbrindle/systemd-glib
> 
> It uses Vala for code generation rather than gdbus-codegen because
> honestly I just like Vala’s generated C API better, but my original
> version using gdbus-codegen is available in the gdbus branch of the
> above repo if people prefer that.
> 
> This is all new code and hasn’t been heavily tested, so if there are
> any bugs please let me know.

Thanks for doing this. I have now added a link to this from the
"Related Packages" part of the systemd homepage:

http://www.freedesktop.org/wiki/Software/systemd

(at the bottom)

Thanks,

Lennart

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

Re: [systemd-devel] Timers without matching units?

[Lennart Poettering]

On Wed, 22.10.14 14:05, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Wed, Oct 22, 2014 at 02:50:13PM +0400, Ivan Shapovalov wrote:
> > Hi,
> > 
> > The systemd.timer(5) manpage states:
> > 
> > "For each timer file, a matching unit file must exist, describing the unit 
> > to
> > activate when the timer elapses."
> > 
> > However, if I need the timer unit just to wake up the machine (e. g. I have 
> > a
> > GUI alarm which does everything except configuring the wakealarm), I don't
> > need the timer unit to start something else. Does this sound like a valid
> > reason to make timers' Unit= optional?
> Hi,
> 
> yeah, when timers were implemented, this wasn't possible, but now
> it makes sense and would be useful.

I added this to the TODO list for now.

Lennart

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

Re: [systemd-devel] systemd-journald watchdog timeout

[Lennart Poettering]

On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) 
wrote:

> On one boot I got a watchdog timeout on systemd-journald:
> 
> Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M 
> (m
> Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var 
> is 2
> Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not 
> rea
> Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40
> Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3)
> Oct 21 20:08:25 feanor kernel: wlan0: authenticated
> Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 
> 1/3)
> Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 
> (capab
> Oct 21 20:08:25 feanor kernel: wlan0: associated
> Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link 
> become
> Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to 
> Persis
> Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and 
> Directories
> Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization...
> Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System 
> Boot/Shutdo
> Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System 
> Boot/Shutdow
> Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization.
> Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization.
> Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization.
> Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket.
> Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket.
> Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket.
> Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0.
> Oct 21 20:08:25 feanor systemd-networkd[518]: lo  : gained carrier
> Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on 
> /dev/inpu
> Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on 
> /dev/inpu
> Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on 
> /dev/inpu
> Oct 21 20:08:25 feanor systemd[1]: Started Network Service.
> Oct 21 20:08:25 feanor systemd[1]: Starting Network.
> Oct 21 20:08:25 feanor systemd[1]: Reached target Network.
> Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution...
> Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M 
> (m
> Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
> Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not 
> read
> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout 
> (li
> Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
> Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2.
> Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. 
> Te
> Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout 
> (l
> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm 
> timed o
> Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process 
> exited
> Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered 
> failed 
> Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff 
> time,
> Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service...
> Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
> Oct 21 20:11:20 feanor systemd[1]: Started Journal Service.
> 
> As you can see at 20:08:20 things appears to look fine, but everything
> get stuck during 3 minutes until there is a watchdog timeout for the
> journal and it gets restarted. Then the boot finished without any further
> problem. The next time everything worked fine, so I am wondering what could
> have happened?

That's difficult to say just from these logs. Can you reliably
reproduce this? If so, can you attach strace to journald before this
happens and see what it is doing?

What I find interesting is that after the 3min pause suddenly the
network driver allocates irq 55. This kinda makes me wonder if this
might be a kernel/driver problem of some kind, where for some reason
userspace (and hence journald) don't get scheduled?

What distro/version/arch is this?

Lennart

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

Re: [systemd-devel] Stop Job for User Manager

[Reindl Harald]

Am 22.10.2014 um 16:49 schrieb Chris Bell:

I'm running into an annoying issue. I use systemd 216 on an Arch box,
and systemd 208 on a Fedora box; the issue exists on both. Logins are
handled through getty; there is no desktop manager involved.
Occasionally, on shutdown, I get a 90 second hold while waiting for a
'Stop Job for User 1000'. Logging out before shutdown reduces, but
does not eliminate, the occurrence.

The issue is documented in far more detail at
https://bugs.freedesktop.org/show_bug.cgi?id=70593 ; I'm the Chris in
the comments (starting with #15). I was led here for assistance with
the following questions related to this issue:

What, exactly, is this stop job? What's it waiting for? Why 90
seconds? Can this duration be changed? Where should I start bughunting
here?


there are more rough edges in that context

that below is a system-session triggered by SSHD with openssh-chroot in 
combination with pam-mysql - obviously the user-manager inherits the 
sshd-chroot and so can't call the kill command


[root@sftp:~]$ ps aux | grep 29657
 29657  0.0  0.4  46580  4288 ?Ss   Okt17   0:00 
/usr/lib/systemd/systemd --user
root 31532  0.0  0.2 112684  2160 pts/0S<+  16:51   0:00 
/usr/bin/grep --color 29657


[root@sftp:~]$ kill 29657

[root@sftp:~]$ cat messages
Oct 22 16:51:48 sftp systemd: Failed at step CHDIR spawning 
/usr/bin/kill: No such file or directory
Oct 22 16:51:48 sftp systemd: systemd-exit.service: main process exited, 
code=exited, status=200/CHDIR

Oct 22 16:51:48 sftp systemd: Failed to start Exit the Session.
Oct 22 16:51:48 sftp systemd: Dependency failed for Exit the Session.
Oct 22 16:51:48 sftp systemd:
Oct 22 16:51:48 sftp systemd: Unit systemd-exit.service entered failed 
state.




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

[systemd-devel] Stop Job for User Manager

[Chris Bell]

Hi all,

I'm running into an annoying issue. I use systemd 216 on an Arch box,
and systemd 208 on a Fedora box; the issue exists on both. Logins are
handled through getty; there is no desktop manager involved.
Occasionally, on shutdown, I get a 90 second hold while waiting for a
'Stop Job for User 1000'. Logging out before shutdown reduces, but
does not eliminate, the occurrence.

The issue is documented in far more detail at
https://bugs.freedesktop.org/show_bug.cgi?id=70593 ; I'm the Chris in
the comments (starting with #15). I was led here for assistance with
the following questions related to this issue:

What, exactly, is this stop job? What's it waiting for? Why 90
seconds? Can this duration be changed? Where should I start bughunting
here?

The bugzilla hasn't had much activity from devs recently; the last
official-looking comments deal with systemd-208, last December.

I'm not even sure this is actually a 'bug'. For all I know, it's
actually, legitimately, waiting for something. The problem is, I have
no idea - and don't know how to find out - what it thinks it's waiting
for. Any assistance to that end would also be greatly appreciated.

Thanks!

Chris Bell

Ph.D. Student
University of South Florida
College of Engineering
Department of Computer Science and Engineering
NarMOS Research Team
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix a couple of typos

[Lennart Poettering]

On Wed, 22.10.14 16:00, Torstein Husebø (torst...@huseboe.net) wrote:

Thanks!

Applied!

> ---
>  src/systemd/sd-network.h | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/systemd/sd-network.h b/src/systemd/sd-network.h
> index 203a2a6a47..bb69940930 100644
> --- a/src/systemd/sd-network.h
> +++ b/src/systemd/sd-network.h
> @@ -61,7 +61,7 @@ int sd_network_get_operational_state(char **state);
>  int sd_network_get_dns(char ***dns);
>  
>  /* Get NTP entries for all links. These are domain names or string
> - * reperesentations of IP addresses */
> + * representations of IP addresses */
>  int sd_network_get_ntp(char ***ntp);
>  
>  /* Get the search/routing domains for all links. */
> @@ -80,7 +80,7 @@ int sd_network_get_domains(char ***domains);
>   */
>  int sd_network_link_get_setup_state(int ifindex, char **state);
>  
> -/* Get operatinal state from ifindex.
> +/* Get operational state from ifindex.
>   * Possible states:
>   *   off: the device is powered down
>   *   no-carrier: the device is powered up, but it does not yet have a carrier
> @@ -101,13 +101,14 @@ int sd_network_link_get_network_file(int ifindex, char 
> **filename);
>  int sd_network_link_get_dns(int ifindex, char ***addr);
>  
>  /* Get NTP entries for a given link. These are domain names or string
> - * reperesentations of IP addresses */
> + * representations of IP addresses */
>  int sd_network_link_get_ntp(int ifindex, char ***addr);
>  
>  /* Indicates whether or not LLMNR should be enabled for the link
>   * Possible levels of support: yes, no, resolve
>   * Possible return codes:
> - *   -ENODATA: networkd is not aware of the link*/
> + *   -ENODATA: networkd is not aware of the link
> + */
>  int sd_network_link_get_llmnr(int ifindex, char **llmnr);
>  
>  /* Get the DNS domain names for a given link. */
> -- 
> 2.1.1
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> 


Lennart

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

[systemd-devel] [PATCH] Fix a couple of typos

[Torstein Husebø]

---
 src/systemd/sd-network.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/systemd/sd-network.h b/src/systemd/sd-network.h
index 203a2a6a47..bb69940930 100644
--- a/src/systemd/sd-network.h
+++ b/src/systemd/sd-network.h
@@ -61,7 +61,7 @@ int sd_network_get_operational_state(char **state);
 int sd_network_get_dns(char ***dns);
 
 /* Get NTP entries for all links. These are domain names or string
- * reperesentations of IP addresses */
+ * representations of IP addresses */
 int sd_network_get_ntp(char ***ntp);
 
 /* Get the search/routing domains for all links. */
@@ -80,7 +80,7 @@ int sd_network_get_domains(char ***domains);
  */
 int sd_network_link_get_setup_state(int ifindex, char **state);
 
-/* Get operatinal state from ifindex.
+/* Get operational state from ifindex.
  * Possible states:
  *   off: the device is powered down
  *   no-carrier: the device is powered up, but it does not yet have a carrier
@@ -101,13 +101,14 @@ int sd_network_link_get_network_file(int ifindex, char 
**filename);
 int sd_network_link_get_dns(int ifindex, char ***addr);
 
 /* Get NTP entries for a given link. These are domain names or string
- * reperesentations of IP addresses */
+ * representations of IP addresses */
 int sd_network_link_get_ntp(int ifindex, char ***addr);
 
 /* Indicates whether or not LLMNR should be enabled for the link
  * Possible levels of support: yes, no, resolve
  * Possible return codes:
- *   -ENODATA: networkd is not aware of the link*/
+ *   -ENODATA: networkd is not aware of the link
+ */
 int sd_network_link_get_llmnr(int ifindex, char **llmnr);
 
 /* Get the DNS domain names for a given link. */
-- 
2.1.1

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

[systemd-devel] systemd-journald watchdog timeout

[Damien Robert]

On one boot I got a watchdog timeout on systemd-journald:

Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M (m
Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var is 2
Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not rea
Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40
Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3)
Oct 21 20:08:25 feanor kernel: wlan0: authenticated
Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 1/3)
Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 (capab
Oct 21 20:08:25 feanor kernel: wlan0: associated
Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link become
Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to Persis
Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and Directories
Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization...
Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System Boot/Shutdo
Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System Boot/Shutdow
Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization.
Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization.
Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization.
Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket.
Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket.
Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket.
Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0.
Oct 21 20:08:25 feanor systemd-networkd[518]: lo  : gained carrier
Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu
Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu
Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu
Oct 21 20:08:25 feanor systemd[1]: Started Network Service.
Oct 21 20:08:25 feanor systemd[1]: Starting Network.
Oct 21 20:08:25 feanor systemd[1]: Reached target Network.
Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution...
Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M (m
Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X
Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout (li
Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2.
Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. Te
Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout (l
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm timed o
Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process exited
Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered failed 
Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff time,
Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service...
Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service...
Oct 21 20:11:20 feanor systemd[1]: Started Journal Service.

As you can see at 20:08:20 things appears to look fine, but everything
get stuck during 3 minutes until there is a watchdog timeout for the
journal and it gets restarted. Then the boot finished without any further
problem. The next time everything worked fine, so I am wondering what could
have happened?

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

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

Lennart Poettering  wrote in message <20141020173828.GA4509@gardel-login>:
> They should probably adopt socket activation anyway, otherwise they'd
> be quite annoying on multi-user systems if lingering is used.

I am brainstorming here, but would it make sense to add hooks to logind
when a session is started/closed (both system hooks and user hooks)?

For instance when I log into X, my .xprofile contains
systemctl --no-block --user  start "xsession@${DISPLAY}.target"
to start my user services.

I need to make sure that everyway I have to log into X (with a *DM, with
startx, with xinit) I somehow source .xprofile.

Stopping the started services also involve some contorsion. When I quit X
most of the services started by xsession@$DISPLAY fails because X is no
longer available, and I don't want systemd to try to restart them in this
case. So I need to stop these services whenever X exits.

So inside xsession@.target, I launch xwatch@.service:

[Unit]
Description=Watch for X on display %I
BindsTo=xsession@.target

[Service]
Environment=DISPLAY=%I
SyslogIdentifier=xwatch@%I
ExecStart=/bin/sh -c 'exec %h/mine/script/services/xwatch %I'
Nice=19

[Install]
WantedBy=xsession@.target

with $ cat ~/script/services/xwatch
#!/bin/sh
xprop -spy -root XFree86_VT
systemctl --user stop "xsession@$1.target"

So whenever my X session stops, xwatch will stop xsession@$DISPLAY.target,
and thus stop all services files that I configured to be PartOf
xsession@.target. For instance xcompmgr@.service:

[Unit]
Description=xcompmgr on display %I 
PartOf=xsession@.target
ConditionFileIsExecutable=/usr/bin/xcompmgr

[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/xcompmgr
Restart=on-failure
RestartSec=3
StandardOutput=null

[Install]
WantedBy=xsession@.target
Also=xwatch@.service

It works really well, I can even log onto different X sessions and have the
corresponding services launched into the different $DISPLAY, but having
some close hooks in logind would help getting rid of xwatch.service.

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

Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Damien Robert]

Colin Guthrie  wrote in message :
> I want to rely on systemd --user to handle PulseAudio's activation
> (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
> might start up their own session stuff and spawn some PA consuming
> process before systemd --user has reached it's sockets.target and is
> thus ready and listening on PA's native socket.

Interesting, does PA now support socket activation? Mine (pulseaudio 5.0)
does not seem to support it.

> Doesn't seem to be a problem on my machine here (it's working really
> nicely actually!) but figured I should ask here too.

I have been using systemd user sessions for a long time, and it works really
well, except for this policykit "bug":
https://bugs.freedesktop.org/show_bug.cgi?id=67728

For instance since I start dbus under the user session, the dbus activated
services also run inside it:
   CGroup: /user.slice/user-1000.slice/user@1000.service
   ├─615 /usr/lib/systemd/systemd --user
   ├─616 (sd-pam)  
   ├─dbus.service
   │ ├─  702 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
   │ ├─  835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor

So udisks2 fails to mount my usb keys because it is not under an active
session (since it is not launche from my active session) so it gets denied
by policykit.

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

Re: [systemd-devel] [PATCH 21/26] hashmap: rewrite the implementation

[Michal Schmidt]

On 10/20/2014 08:42 PM, Lennart Poettering wrote:
> On Thu, 16.10.14 09:50, Michal Schmidt (mschm...@redhat.com) wrote:
>> +/* Fields that all hashmap/set types must have */
>> +struct HashmapBase {
>> +const struct hash_ops *hash_ops;  /* hash and compare ops to use */
>> +
>> +union _packed_ {
>> +struct indirect_storage indirect; /* if  has_indirect */
>> +struct direct_storage direct; /* if !has_indirect */
>> +};
>> +
>> +uint8_t type:2; /* HASHMAP_TYPE_* */
> 
> Should probably be a named enum (see above)
> 
>> +uint8_t has_indirect:1; /* whether indirect storage is
>> used */
> 
> Should really be a "bool", no?

Interestingly, changing this confuses pahole greatly.
With all the three bitfields declared as uint8_t pahole showed the struct
layout sanely:

struct HashmapBase {
const struct hash_ops  *   hash_ops; /* 0 8 */
union {
struct indirect_storage indirect;/*  39 */
struct direct_storage direct;/*  39 */
};   /* 839 */
uint8_ttype:2;   /*47: 6  1 */
uint8_thas_indirect:1;   /*47: 5  1 */
uint8_tn_direct_entries:3;   /*47: 2  1 */

/* size: 48, cachelines: 1, members: 5 */
/* bit_padding: 2 bits */
/* last cacheline: 48 bytes */
};

With "type" changed to a named enum, "has_indirect" to bool,
and "n_direct_entries" to unsigned, pahole says:

base_type__name_to_size: base_type __unknown__
base_type__name_to_size: base_type __unknown__
die__process_inline_expansion: tag not supported (INVALID)!
base_type__name_to_size: base_type __unknown__
...
struct HashmapBase {
const struct hash_ops  *   hash_ops; /* 0 8 */
union {
struct indirect_storage indirect;/*  39 */
struct direct_storage direct;/*  39 */
};   /* 839 */

/* Bitfield combined with next fields */

enum HashmapType   type:2;   /*44: 6  4 */

/* XXX 22 bits hole, try to pack */
/* Bitfield combined with next fields */

_Bool  has_indirect:1;   /*47: 5  1 */

/* Bitfield combined with previous fields */

__unknown__n_direct_entries:3;   /*44: 2  0 */

/* size: 48, cachelines: 1, members: 5 */
/* bit holes: 1, sum bit holes: 22 bits */
/* padding: 4 */
/* bit_padding: 252 bits */
/* last cacheline: 48 bytes */

/* BRAIN FART ALERT! 48 != 48 + 0(holes), diff = 0 */

};

But as far as I can tell, generated code looks OK and it still runs
fine, so I won't worry about it.

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Jóhann B. Guðmundsson]

On 10/22/2014 11:51 AM, Alexandre Detiste wrote:

Why not migrate what needs to be migrated to native system timer formats

This would be the responsability of each individual package manager;
after some policy would have mandated it and it's too late before the release 
freeze.
Debian only ships exaclty one timer now: systemd-tmpfiles-clean.timer

This may evolve next year after Jessie is released.

I would then adapt systemd-cron not to process/etc/cron.d/$(package)
if (/usr)/lib/systemd/system/$(package).timer exists .

I'll asks what the others downstreams (Arch...) think of it;
if it might already be implented that way.


In Fedora we had 100 components that shipped cron jobs of some short, 
out of those, 50 components depend on systemd and then there was further 
filter due to things not being "legacy" and no longer used or simply not 
beneficial to be migrated ( It would just cause administrative nuance in 
doing so and those 50 jobs or so would have been less for every distro 
to worry about but I got fedup with how things where handled so I 
abandoned that feature of mine after correcting the dependence of those 
50 components that would definitely not be migrated ) so as I say you 
should easily be able to migrate that stuff since I dont expect Debian 
shipping much more than that and well before Jessie gets released, 
especially now since Ian seems to be keen on misusing the GR process ( 
and delay the release even further as an result of that ) to hinder the 
adoption of systemd in the project.


Dont hesitate to be in contact if you need help with that since these 
kind of migration/integration work in distributions with systemd is 
beneficial to *all* so it does not take many resources from systemd 
community from every distro to lend a hand and help with that migration. 
It just requires a bit of organizing and packagers ( in all distros ) to 
be on stand by when that happens and it will be quickly over.


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

Re: [systemd-devel] Forwarding to syslog missed XX messages

[Reindl Harald]

Am 22.10.2014 um 13:22 schrieb Lennart Poettering:

On Mon, 15.09.14 13:20, Reindl Harald (h.rei...@thelounge.net) wrote:


anybody an idea why?

Sep 15 13:14:43 localhost systemd-journal[4650]: Forwarding to syslog missed 2 
messages.
Sep 15 13:15:13 localhost systemd-journal[4650]: Forwarding to syslog missed 
196 messages.
Sep 15 13:15:44 localhost systemd-journal[4650]: Forwarding to syslog missed 
236 messages.
Sep 15 13:16:14 localhost systemd-journal[4650]: Forwarding to syslog missed 
180 messages.
Sep 15 13:16:44 localhost systemd-journal[4650]: Forwarding to syslog missed 
323 messages.
Sep 15 13:17:15 localhost systemd-journal[4650]: Forwarding to syslog missed 
232 messages.
Sep 15 13:17:45 localhost systemd-journal[4650]: Forwarding to syslog missed 
156 messages.


Apparently syslog forwarding is on but your syslog implementation is
not capable of keeping up processing the messages quickly enough. Note
that by default the number of messages that may be queued in the
syslog socket is relatively low, you can bump it via
/proc/sys/net/unix/max_dgram_qlen, which would allow more messages to
be queued so that your syslog implementation has more time to process
the messages.


i doubt - my homeserver don't log that much


Why precisely your syslog implementation is too slow is something
you'd have to debug on the side of theat implementation, we cannot
determine this from systemd's side.

Note that rsyslog doesn't need the syslog forwarding anymore these
days, it picks up the messages directly from the journal. You can thus
turn syslog forwarding off with ForwardToSyslog=no in
journald.conf. In fact, very recent systemd versions actually changed
the default here to off, given the fact that rsyslog doesn't need this
any more


that is in fact the case on all of my machines

so why does systemd-journal complain about missed forwarding at all?

[root@srv-rhsoft:~]$ journalctl  | grep missed
Okt 21 17:30:22 srv-rhsoft.rhsoft.net systemd-journal[551]: Forwarding 
to syslog missed 1 messages.
Okt 21 17:34:46 srv-rhsoft.rhsoft.net systemd-journal[551]: Forwarding 
to syslog missed 10 messages.


[root@srv-rhsoft:~]$ cat /etc/systemd/journald.conf
[Journal]
Storage=volatile
Compress=yes
RateLimitInterval=10s
RateLimitBurst=5000
RuntimeMaxUse=10M
ForwardToSyslog=no

[root@srv-rhsoft:~]$ cat rsyslog.conf
$ModLoad imjournal
$MainMsgQueueSize 3
$WorkDirectory /var/lib/rsyslog
$IMJournalStateFile imjournal.state



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

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Colin Guthrie]

Hello Martin,

Firstly, I apologise if you took what I said as a personal insult. It
was not my intention to do so (and I did try to make that explicitly
clear in a footnote).

I will certainly admit that some of my wording was more directed than I
had intended. This is something I would normally edit out and soften on
a read over, but time constraints didn't allow me that luxury.

That said, I do stand by my general comments. I will attempt a briefer
reply below [Spoiler: I failed!]

Martin Steigerwald wrote on 22/10/14 01:13:
> I received this twice on this mailing list. Once from Lennart ("being a dick 
> now") and now from you calling me a troll.

For the avoidance of doubt, I didn't directly call you a troll. I was
trying to point out that even well intentioned discussions, like yours,
cat at times become indistinguishable from a trolling discussion. Not
deliberate (which trolling is), but because no matter what reply is
sent, the participants will not be satisfied with the answers and will
continue the discussion. It would appear that this discussion has
reached that stage.

Over various points, there have been answers given and corrections made,
and yet still no acceptance is really given to those decisions - it's at
a time like this where further discussion is counter productive to your
goal and just serves to alienate people rather than get them any closer
to sharing your opinion.

> I will make an effort to reply to your mail and then most likely unsubscribe, 
> cause for me I feel like being in an hostile environment.

I disagree that this is a hostile environment. It's just that people
here will (by definition) generally just disagree with you. I apologise
if my reply was worded in an overly-hostile way (I'll try better in this
email), but ultimately you're going to get replies here that will
generally disagree with your stance.

>>> Thats rather much.
>>>
>>> Really rather much.
>>>
>>> Way more than traditonal sysvinit covered.
>>
>> This is because traditional sysvinit covered PID 1 and performing it's
>> job (if you consider e.g. killall5 and friends).
>>
>> You seem to be conflating systemd as PID 1 and systemd as a project.
>> These are two completely different things.
> 
> No. I am concerned about both. The functionality that is stuffed inside PID 1 
> which is more than 1,3 MiB and also sports user session functionality.

You use the term "stuffed" which is preloaded with negativity. Your
wording here would be better if you'd used the more neutral term
"included in" rather than "stuffed inside". By using this phrasing
you're already building up a barrier and will be polarising upstream
developers and will be reflected in their replies.

As another technical correction, PID 1 does NOT sport user session
functionality. It sports a general resource management concept (scopes
and slices) that is a userspace abstraction of the kernel cgroups
concept used for resource management. This is seen as core functionality
as it's PID1's job to fundamentally fork off other processes. I don't
think this is a point of contention.

Some people have argued that resource management should NOT be PID1's
job, and it should handled by a separate daemon. The argument thus far
from the systemd side is that doing this out of process would create a
chicken and egg problem. It's PID1's job to fork of processes and
configure their resources, but the "resource manager" processes' forking
would have to be special cased as there would be no "resource manager"
available when it was forked.  If this sub component fails, then PID1
fails too. It's so tightly coupled that the arguments for doing it out
of process are simply not sufficiently compelling, so this special
casing is not something systemd developers are comfortable with
technically due to both startup and runtime requirements.

The user session functionality you speak of is implemented outside of
PID1 in logind. Because it also needs to manager resources, it has to
work with the resource manager which, as described above, is PID1 in
systemd.

If other init systems want to do this differently they are welcome to do so.

>> An alternative would be to make the utility functions API stable and
>> export the shared library publicly and give API guarantees, but that
>> puts a lot of pressure and it's a difficult thing to provide and it has
>> long term maintenance overhead. This is something that *costs*. It costs
>> in time/man hours and therefore it carries real overheads. Doing this
>> for the convenience of splitting things out is simply not worth it -
>> especially so as the main people working on these things are the same
>> people.
> 
> I don´t think it would be just for the convenience of splitting things. It 
> would also be to address the concerns I summarized and that have been made 
> elsewhere. You may heard these concerns often, you may not agree to them. 
> Yet, 
> if you say later that some of these concerns were made 5 years ago already… 
> If 
> thos

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Jóhann B. Guðmundsson]

On 10/22/2014 11:26 AM, Alexandre Detiste wrote:

it just doesn't send emails like cron; but that will remain an wontfix I guess.


Systemd itself does not send email but you can configure the timer units 
( the service part ) to do so when they fail via OnFailure=custom email script> but you have to do so individually per timer's 
service units ( you cannot define that Onfailure= behaviour default for 
all units or just timer units ) .


That takes care of failed starting timer jobs which is how I'm accustom 
to receive notifications from cron
( there seems to be split in practical sense of this as in those that 
only want to get email when things fail to run and those that always 
want to get email regardless if they failed to run or not )


The always part you handle in the script being run or via another Exec* line

I would recommend you to label the timer in the journal as well for 
quick searching only for relevant timer info


ExecStart=/bin/systemd-cat -t "" /usr/bin/$FOO  whatever

Then run ( or script for email ) something like

journalctl SYSLOG_IDENTIFIER=

Which will output you just the info you need.

Arguable we should always label timer units in the journal which in turn 
would take care of that usability bug where users complain about timers 
being to noisy in log  but Lennart can comment on that if he considers 
that viable solution for that "bug".


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

[systemd-devel] [PATCH] hwdb: Add mapping for special keys on compaq ku 0133 keyboards

[Hans de Goede]

The compaq ku 0133 keyboard has 8 special keys at the top:
http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg

3 of these use standard HID usage codes from the consumer page, the 5
others use part of the reserved 0x07 - 0x1f range.

This commit adds mapping for this keyboard for these reserved codes, making
the other 5 keys work.

Cc: Hans de Goede 
Signed-off-by: Hans de Goede 
---
 hwdb/60-keyboard.hwdb | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
index 59f467b..06caba9 100644
--- a/hwdb/60-keyboard.hwdb
+++ b/hwdb/60-keyboard.hwdb
@@ -181,6 +181,13 @@ keyboard:dmi:bvn*:bvr*:bd*:svnCompaq*:pn*Evo*N*:pvr*
  KEYBOARD_KEY_9e=email
  KEYBOARD_KEY_9f=homepage
 
+keyboard:usb:v049Fp0051d*dc*dsc*dp*ic*isc*ip*in01*
+ KEYBOARD_KEY_0c0011=presentation
+ KEYBOARD_KEY_0c0012=addressbook
+ KEYBOARD_KEY_0c0013=info
+ KEYBOARD_KEY_0c0014=prog1
+ KEYBOARD_KEY_0c0015=messenger
+
 ###
 # Dell
 ###
-- 
2.1.0

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

Re: [systemd-devel] Timers without matching units?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 22, 2014 at 02:50:13PM +0400, Ivan Shapovalov wrote:
> Hi,
> 
> The systemd.timer(5) manpage states:
> 
> "For each timer file, a matching unit file must exist, describing the unit to
> activate when the timer elapses."
> 
> However, if I need the timer unit just to wake up the machine (e. g. I have a
> GUI alarm which does everything except configuring the wakealarm), I don't
> need the timer unit to start something else. Does this sound like a valid
> reason to make timers' Unit= optional?
Hi,

yeah, when timers were implemented, this wasn't possible, but now
it makes sense and would be useful.

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

Re: [systemd-devel] Unprivileged poweroff

[Simon McVittie]

On 22/10/14 12:37, Lennart Poettering wrote:
> When used with kdbus we actually do check for that client-side
> capability. THis is not available on dbus1 however, since we cannot
> determine the capability racefreely and thus safely

... because the kernel doesn't give us that ability on Unix sockets. See
 for more on what
Unix socket semantics *do* allow socket-based D-Bus to rely on.

A solution requires new kernel features: either something like kdbus, or
a way for a Unix socket client to prove to the server that it had a
particular capability either at the time the socket opened (a new
SCM_CAPABILITIES analogous to SCM_CREDS?) or at the time that a
particular message was queued (subtle, probably best avoided).

S

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Alexandre Detiste]

>Why not migrate what needs to be migrated to native system timer formats

This would be the responsability of each individual package manager;
after some policy would have mandated it and it's too late before the release 
freeze.
Debian only ships exaclty one timer now: systemd-tmpfiles-clean.timer 

This may evolve next year after Jessie is released.

I would then adapt systemd-cron not to process /etc/cron.d/$(package) 
if (/usr)/lib/systemd/system/$(package).timer exists . 

I'll asks what the others downstreams (Arch...) think of it;
if it might already be implented that way.

Alexandre



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

Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories

[Simon McVittie]

On 21/10/14 20:25, Lennart Poettering wrote:
> Ah, well, at least they should make the lib64 thing arch dependent.

Multiarch means that whichever architecture systemd happens to have been
compiled for, /lib64 might exist. If it does, it's a system library
directory.

(Consider an i386 or armhf systemd on a mixed i386 + amd64 or armhf +
arm64 system, for instance. On a developer's system, you might even have
mixed i386 + amd64 + armhf + s390x or something.)

S

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

Re: [systemd-devel] transforming Iptables bash script to systemd service file -help

[Simon McVittie]

On 21/10/14 20:30, Lennart Poettering wrote:
> But in cases like the iptables tool (which
> is written in a style that kinda requires the usage of shell scripts
> to invoke it, since it is more a programming language and is seldom
> called just once at boot)

If your ruleset is static (e.g. does not depend on the local IP
address), it's very close to not needing a shell: all it would need is
for systemd to support StandardInput=/a/file/path, or for
iptables-restore to support "--file /a/file/path", or something similar.

iptables-save | sudo tee /etc/my-firewall
ip6tables-save | sudo tee /etc/my-firewall6

ExecStart=/bin/sh -c 'iptables-restore < /etc/my-firewall'

ExecStart=/bin/sh -c 'ip6tables-restore < /etc/my-firewall6'

S

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

Re: [systemd-devel] Unprivileged poweroff

[Lennart Poettering]

On Wed, 10.09.14 16:03, Michal Witanowski (m.witanow...@samsung.com) wrote:

> Hi,
> 
> I was wondering if there is a possibility to call "systemctl poweroff" as
> non-root user in this scenario:
> 
> 1.I have no PolicyKit on my system, so I get access denied.
> 
> 2.   Calling with "-f" parameter also fails, with "Must be root" error.
> 
> 3.   I'd like to avoid using "sudo".
> 
> Theoretically there is no other way, am I right?
> 
> But what about CAP_SYS_BOOT? Does the systemctl shouldn't verify if this
> capability is set and allow non-root user to shut down the system?

When used with kdbus we actually do check for that client-side
capability. THis is not available on dbus1 however, since we cannot
determine the capability racefreely and thus safely.

Lennart

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

Re: [systemd-devel] udev database backwards compatibility guarantees

[Lennart Poettering]

On Thu, 11.09.14 10:49, Alexander Larsson (al...@redhat.com) wrote:

> Hi, I'm looking at creating a runtime/app thing for Gnome in the style
> of:
> http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
> 
> However, I noticed that some core dependencies like mesa uses libudev.
> And in fact, needs user-set additional info not in sysfs. In particular,
> it reads ID_PATH_TAG on render device nodes to pick what GPU to use in
> multi-gpu situations (PRIME):
> http://lists.freedesktop.org/archives/mesa-dev/2014-June/061798.html
> 
> It seems to me that this means I need the host /run/udev inside the
> application. I know that the udev database format changed in the past,
> but can I rely on it being stable in the future, even if the host udev
> is rev:ed to a later version than what is in the application runtime?
> 
> Of course, there is also the question of /dev and /sys management in
> sandboxed apps in general. Clearly any "modern" app will require some
> real devices for things like direct rendering. But it would be ideal to
> not expose "everything". How do we see this working?

Good question. Ideally we wouldn't expose any raw devices to apps, but
I figure this is not going to suffice (already with video4linux and
things).

Kay, any ideas on the udev database stability?

Lennart

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

Re: [systemd-devel] help with systemd socket file for programs in the quagga suite

[Lennart Poettering]

On Sat, 13.09.14 23:04, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> В Fri, 12 Sep 2014 19:10:01 +0100
> "lux-integ"  пишет:
> 
> > On Friday 12 September 2014 18:28:30 Dave Reisner wrote:
> > > I'll stop you here. You can't simply "synthesize" a socket unit for any
> > > arbitrary program that uses a socket (regardless of the address family).
> > > Socket units are specific to socket-activated services (which requires
> > > code changes in the daemon itself) and per-connection spawning.
> > > 
> > > Based on a perusal of the manpage and source, Zebra appears to be
> > > neither of these
> > 
> > 
> > thanks a lot
> > 
> > I too checked the man page  I found on the internet  and found them to be 
> > different to doing 
> > /usr/sbin/zebra --help
> > 
> > I  tend to err on the side of trusting the installed more   and so 
> >  why does   this line :-
> > ( -z, --socket   Set path of zebra socket )
> > results from 
> > /usr/sbin/zebra  --help
> > ( and indeed all the programs in the quagga suite ? )
> > 
> > Is it in error ?
> > 
> 
> May be not, but socket activated services in systemd receive socket on
> stdin/stdout, not as argument.

That's not entirely true. In inetd-style activation the sockets are
passed as stdin/stdout. On systemd-style activation they are passed as
sockets 3,4,5,..., i.e. the ones immediately following
stdin/stderr/stdout.

But anyway, the gist of it is true: socket activation requires proper
support for it in the daemons. And just being able to set the socket
path is not enough. Without patching zebra to support proper
systemd-style socket activation (or even inetd-style as we support
either) this is not available.

Lennart

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Alexandre Detiste]

(sorry mail fired up too soon)

> Or to put this differently we will not create. come up with, ship ( and 
> thus support those ) generators but expect consumers of systemd to use 
> systemd and it's format natively in their environment.
> 
> Alexandre why did you decide to write that generate to begin with?

Hi, 

I didn't wrote it.

I've been using the systemd-cron Debian package since 2013/10 to take care of 
/etc/cron.daily/
I soon noticed it wasn't processing the crontabs , I added a symlink on 
/etc/cron.weekly/
to emulate the one I cared about and forgot about it.

Then in june there was a bug filled to remove the "Provides: cron-daemon" 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376

This virtual package cron-daemon act as a gear box that lets users switch
at their will from one cron daemon to another. It documents a specific interface
( /etc/crontab , /etc/cron.*/ ...)

Without this "Provides:", systemd-cron would had been useless.
This prompted me to find a better solution.

Konstantin Stepanov (https://github.com/kstep/systemd-crontab-generator)
and Dwayne bent (static units, build infrastructure)
kindly agreed to let me merge their respective projects to get a full feature
systemd-cron package.

Then I went on with development.


> Why not migrate what needs to be migrated to native system timer formats 
> for those relevant component 
I have no power over this.

> and leave the rest be handled by the 
> traditional cron daemons since those two components complement each 
> others shortcomings ?

"The rest" ? The generator can now handle all possible cases;
it just doesn't send emails like cron; but that will remain an wontfix I guess.

Alexandre Detiste


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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Jóhann B. Guðmundsson]

On 10/22/2014 11:16 AM, Alexandre Detiste wrote:



>Why not migrate what needs to be migrated to native system timer formats
>for those relevant component and leave the rest be handled by the
>traditional cron daemons since those two components complement each
>others shortcomings ?

"The rest" ? The generator can now handle all possible cases



You did not answer my question.

Why dont you migrate the components depending on the core/baseOS and 
ship cron jobs to native systemd timer units ( and upstream them in the 
process ) and leave the rest up to the traditional daemons to handle?


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

Re: [systemd-devel] Forwarding to syslog missed XX messages

[Lennart Poettering]

On Mon, 15.09.14 13:20, Reindl Harald (h.rei...@thelounge.net) wrote:

> anybody an idea why?
> 
> Sep 15 13:14:43 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 2 messages.
> Sep 15 13:15:13 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 196 messages.
> Sep 15 13:15:44 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 236 messages.
> Sep 15 13:16:14 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 180 messages.
> Sep 15 13:16:44 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 323 messages.
> Sep 15 13:17:15 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 232 messages.
> Sep 15 13:17:45 localhost systemd-journal[4650]: Forwarding to syslog missed 
> 156 messages.

Apparently syslog forwarding is on but your syslog implementation is
not capable of keeping up processing the messages quickly enough. Note
that by default the number of messages that may be queued in the
syslog socket is relatively low, you can bump it via
/proc/sys/net/unix/max_dgram_qlen, which would allow more messages to
be queued so that your syslog implementation has more time to process
the messages.

Why precisely your syslog implementation is too slow is something
you'd have to debug on the side of theat implementation, we cannot
determine this from systemd's side.

Note that rsyslog doesn't need the syslog forwarding anymore these
days, it picks up the messages directly from the journal. You can thus
turn syslog forwarding off with ForwardToSyslog=no in
journald.conf. In fact, very recent systemd versions actually changed
the default here to off, given the fact that rsyslog doesn't need this
any more.

Lennart

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Alexandre Detiste]

> Or to put this differently we will not create. come up with, ship ( and 
> thus support those ) generators but expect consumers of systemd to use 
> systemd and it's format natively in their environment.
> 
> Alexandre why did you decide to write that generate to begin with?

Hi, 

I've been using the systemd-cron Debian package since 2013/10 to take care of 
/etc/cron.daily/
I soon noticed it wasn't processing the crontabs , I added a symlink on 
/etc/cron.weekly/
to emulate the one I cared about and forgot about it.

Then in june there was a bug filled to remove the "Provides: cron-daemon" 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376

This prompted me to find a better solution.

Konstantin Stepanov and 
 




> Why not migrate what needs to be migrated to native system timer formats 
> for those relevant component and leave the rest be handled by the 
> traditional cron daemons since those two components complement each 
> others shortcomings ?

"The rest" ? The generator can now handle all possible cases

> 
> JBG

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

Re: [systemd-devel] instantiated services set up

[Lennart Poettering]

On Mon, 15.09.14 13:03, Jan Včelák (jan.vce...@nic.cz) wrote:

> > After=syslog.target is redundant since a long time. Consider removing
> > this. And After=network.target usually doesn't do what one might thing
> > it does and with well written software that listens to rtnl or uses
> > IP_FREEBIND not even necessary...
> 
> OK. I will remove the syslog. But I will have to keep network.target for now 
> as we support non-Linux systems as well. Adding support for rtnl or 
> IP_FREEBIND would mean duplicating a lot of code... probably.

Note that invoking IP_FREEBIND is just a single setsockopt() line...

> > > 1.) Is it valid to ship both knot.service and knot@.service file?
> > 
> > Sure, but for the sake of simplicity and not confusing the user I would
> > avoid this.
> > 
> > I'd just ship the templated version, and then maybe add
> > DefaultInstance=something to the [Install] section in order to make one
> > instance the "default" one...
> 
> DefaultInstance sounds great. Will this get backported into systemd-stable at 
> some time? Because I'm looking for a solution for RHEL 7.

Please file a bug for RHEL 7 and the right peple will make sure this happens.

Lennart

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Lennart Poettering]

On Wed, 22.10.14 13:03, Alexandre Detiste (alexandre.deti...@gmail.com) wrote:

> > > -) how can I trigger a rerun of the generator 
> > 
> > generators are rerun if you issue "systemctl daemon-reload"
> 
> I already know, 
> 
> this is what our "trigger unit" does.
> https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in
> https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in
> 
> >> ... after /var is mounted.
> this is the point I didn't get right.
> Would linking cron-update.service in new folder 
> (/usr)/lib/systemd/system/var.mount.wants/ 
> do the trick ?

Well, you can order your reload service After=local-fs.target, which
should do the trick. As /var might be subdivided into more submounts
you really want to order after local-fs.target, and nothing earlier.

> I currently start it from /etc/rc.local

Yuck! Tha'ts more or less obsolete, and is only supported (in a
limited way) for compat.

Lennart

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Lennart Poettering]

On Wed, 22.10.14 14:48, Ivan Shapovalov (intelfx...@gmail.com) wrote:

> On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote:
> > 
> > On 10/22/2014 09:44 AM, Lennart Poettering wrote:
> > > So, I thought myself a couple of times about adding a cron generator
> > > upstream
> > 
> > As far as I can tell generators serve only one purpose and that is to 
> > bridge an gap to allow users of consumers of systemd to migrate to it's 
> > native format
> 
> I don't think this is correct. Take, for example, gpt-auto-generator,
> efi-boot-generator, hibernate-resume-generator...

Correct. It's a way how to convert other runtime or static
configuration into native configuration. A primary usecase for that is
compat, but other runtime parameters are not like that.

Lennart

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

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Alexandre Detiste]

> > -) how can I trigger a rerun of the generator 
> 
> generators are rerun if you issue "systemctl daemon-reload"

I already know, 

this is what our "trigger unit" does.
https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in
https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in

>> ... after /var is mounted.
this is the point I didn't get right.
Would linking cron-update.service in new folder 
(/usr)/lib/systemd/system/var.mount.wants/ 
do the trick ?

I currently start it from /etc/rc.local

> it's OK to cover /etc/cron.daily and friends natively with a generator
The issue with a generator is there must be some name mangling
to ensure that the units have an unique name and
unit name like 'cron-root-13.timer' in systemctl list-timers are not user 
friendly.
(we use now cron-$filename-$userid-$pkey.timer )

That is why cron.hourly|daily|weekly ... are provided as static units
that can be safely referenced in man pages;
this way systemd-cron can even work with an empty /etc/crontab .

> (and that's easy as the stuff is in
> /etc), but for the per-user stuff stored in /var it is a better idea
> to just leave traditional crond around, however, with one trick: only
> start it as soon as there is a file dropped into the cron subdir in
> /var. This way, users can use cron as they always did: as long as they
> did not install any user cronjobs everything works fine without crond
> started, and then when they install user cronjobs crond magically gets
> started in the background. The way how users install cronjobs is by
> invoking "crontab -e" anyway, and that tool needs to be installed
> anyway of the crond package, hence installing crond in a way that it
> is triggered via a crond.path unit should be OK too.
> 
> Hope that makes sense?
That makes sense, but I'm not responsible for packaging 'cron' in Debian;
that must also work for sysvinit. I doubt someone will like this half&half 
solution.

The crontab shipped with systemd-cron is written in python and can't be setgid 
like the real crontab;
so I asked if vixie-crontab could be shipped in an extra standalone package,
but I don't expect much more.


> > - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a 
> > shutdown,
> > it is not restarted on next reboot.
> 
> Hmm, could you file a bug about this issue on fdo bz? we should
> probably cover for this nicely.
https://bugs.freedesktop.org/show_bug.cgi?id=85321

Ok it's done, it would benefit native units too.

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

[systemd-devel] Timers without matching units?

[Ivan Shapovalov]

Hi,

The systemd.timer(5) manpage states:

"For each timer file, a matching unit file must exist, describing the unit to
activate when the timer elapses."

However, if I need the timer unit just to wake up the machine (e. g. I have a
GUI alarm which does everything except configuring the wakealarm), I don't
need the timer unit to start something else. Does this sound like a valid
reason to make timers' Unit= optional?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

[Ivan Shapovalov]

On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote:  
> 
> On 10/22/2014 09:44 AM, Lennart Poettering wrote:
> > So, I thought myself a couple of times about adding a cron generator
> > upstream
> 
> As far as I can tell generators serve only one purpose and that is to 
> bridge an gap to allow users of consumers of systemd to migrate to it's 
> native format

I don't think this is correct. Take, for example, gpt-auto-generator,
efi-boot-generator, hibernate-resume-generator...

Also, systemd.mount(5) page states: "In general, configuring mount points
through /etc/fstab is the preferred approach."

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel