Re: [systemd-devel] Can't make local user.conf work

[Kok, Auke-jan H]

On Mon, Mar 7, 2016 at 7:31 AM, G D'Arezzo <gdarre...@gmail.com> wrote:
> On 29 February 2016 at 19:05, Kok, Auke-jan H <auke-jan.h@intel.com> 
> wrote:
>> On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo <gdarre...@gmail.com> wrote:
>>> "You probably want to use [Service] instead."
>>>
>>> Thanks for the suggestion, Auke.  Unfortunately, Service and
>>> DefaultEnvironment don't go together:
>>>
>>> [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown
>>> lvalue 'DefaultEnvironment' in section 'Service'
>>
>> I just reread the man page for that. DefaultEnvironment is valid only
>> for user.conf, not any conf.d* file associated with a specific unit
>> (obviously, since those are not variants of "user.conf", but instead
>> are variants of unit files).
>>
>> The [Manager] section is only valid in:
>>
>>/etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf,
>> /run/systemd/user.conf.d/*.conf,
>>/usr/lib/systemd/user.conf.d/*.conf
>>
>> The manual page systemd-user.conf(5) does not mention at all being
>> able to use ~/.config/systemd/. This seems like a shortcoming to me,
>> though.
>>
>> Auke
>
>
> Is this a feature which never happened or should it work?

I'm fairly sure it just never happened.

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

Re: [systemd-devel] Can't make local user.conf work

[Kok, Auke-jan H]

On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo  wrote:
> "You probably want to use [Service] instead."
>
> Thanks for the suggestion, Auke.  Unfortunately, Service and
> DefaultEnvironment don't go together:
>
> [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown
> lvalue 'DefaultEnvironment' in section 'Service'
I just reread the man page for that. DefaultEnvironment is valid only
for user.conf, not any conf.d* file associated with a specific unit
(obviously, since those are not variants of "user.conf", but instead
are variants of unit files).

The [Manager] section is only valid in:

   /etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf,
/run/systemd/user.conf.d/*.conf,
   /usr/lib/systemd/user.conf.d/*.conf

The manual page systemd-user.conf(5) does not mention at all being
able to use ~/.config/systemd/. This seems like a shortcoming to me,
though.

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

Re: [systemd-devel] Can't make local user.conf work

[Kok, Auke-jan H]

On Thu, Feb 25, 2016 at 7:06 PM, Guido D'Arezzo  wrote:
> Hello, I’m trying to run user systemd services with DefaultEnvironment set
> in a user.conf under $HOME/.config/systemd/ but it isn't being read.
> The only .conf files I have seen being read are /etc/systemd/user.conf and
> /etc/systemd/user.conf.d/*.conf
>
> It should work, according to this page (under Environment Variables):
> https://wiki.archlinux.org/index.php/Systemd/User
>
> and these words (though I can't find many other references to its use):
>
> "You can use DefaultEnvironment in user.conf, and place that either in
> /etc/systemd/user.conf, or in ~/.config/systemd/user.conf."
>
> 
> https://lists.freedesktop.org/archives/systemd-devel/2014-March/017514.html
>
>
> This doesn't mention user.conf but does it mean any .conf files in or under
> there should be read?

no, this path contains config files with a special format only, and
arbitrary files in here are not read. Consider this the user
equivalent of /etc/systemd/

> "Additionally, --user also adds the home-directory of the user as
> source: ~/.config/systemd/user/"
>
> 
> https://lists.freedesktop.org/archives/systemd-devel/2014-August/022745.html
>
> but the suggestion later on
>
> "to create a file in:
>   ~/.config/systemd/user/your_service.conf.d/your_drop_in_file.conf"
>
> and in man systemd.unit
>
> Along with a unit file foo.service, a directory
>foo.service.d/ may exist. All files with the suffix ".conf"
>from this directory will be parsed after the file itself is
>parsed. This is useful to alter or add configuration settings
>to a unit, without having to modify their unit files. Make
>sure that the file that is included has the appropriate
>section headers before any directive.
>
> fails with systemctl complaining about the .conf file heading:
> Unknown section 'Manager'

You probably want to use [Service] instead.

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

Re: [systemd-devel] Bootchart speeding up boot time

[Kok, Auke-jan H]

On Mon, Feb 22, 2016 at 11:51 AM, Martin Townsend
 wrote:
> Hi,
>
> Thanks for your reply.  I wouldn't really call this system stripped down, it
> has an nginx webserver, DHCP server, postgresql-server, sftp server, a few
> mono (C#) daemons running, loads quite a few kernel modules during boot,
> dbus, sshd, avahi, and a bunch of other stuff I can't quite remember.  I
> would imagine glibc will be a tiny portion of what gets loaded during boot.
> I have another arm system which has a similar boot time with systemd, it's
> only a single cortex A9 core, it's running a newer 4.1 kernel with a new
> version of systemd as it's built with the Jethro version of Yocto so
> probably a newer version of glibc and this doesn't speed up when using
> bootchart and in fact slows down slightly (which is what I would expect).
> So my current thinking is that it's either be down to the fact that it's a
> dual core and only one core is being used during boot unless a fork/execl
> occurs? Or it's down to the newer kernel/systemd/glibc or some other
> component.
>
> Is there anyway of seeing what the CPU usage for each core is for systemd on
> boot without using bootchart then I can rule in/out the first idea.

Not that I know of, but, to work around the issue of dynamic linking,
one can link systemd-bootchartd statically. It'll become larger, but
you can then clearly ascern that the impact of glibc bits being loaded
are properly recorded by bootchart. And, it's fairly trivial link it
statically.

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

Re: [systemd-devel] Bootchart speeding up boot time

[Kok, Auke-jan H]

On Fri, Feb 19, 2016 at 7:15 AM, Martin Townsend
 wrote:
> Hi,
>
> I'm new to systemd and have just enabled it for my Xilinx based dual core
> cortex A-9 platform.  The linux system is built using Yocto (Fido branch)
> which is using version 219 of systemd.
>
> The main reason for moving over to systemd was to see if we could improve
> boot times and the good news was that by just moving over to systemd we
> halved the boot time.  So I read that I could analyse the boot times in
> detail using bootchart so I set init=//bootchart in my kernel command
> line and was really suprised to see my boot time halved again.  Thinking
> some weird caching must have occurred on the first boot I reverted back to
> normal systemd boot and boot time jumped back to normal (around 17/18
> seconds), putting bootchart back in again reduced it to ~9/10 seconds.
>
> So I created my own init using bootchart as a template that just slept for
> 20 seconds using nanosleep and this also had the same effect of speeding up
> the boot time.
>
> So the only difference I can see is that the kernel is not starting
> /sbin/init -> /lib/systemd/systemd directly but via another program that is
> performing a fork and then in the parent an execl to run
> /lib/systemd/systemd.  What I would really like to understand is why it runs
> faster when started this way?


systemd-bootchart is a dynamically linked binary. In order for it to
run, it needs to dynamically link and load much of glibc into memory.

If your system is really stripped down, then the portion of data
that's loaded from disk that is coming from glibc is relatively large,
as compared to the rest of the system. In an absolute minimal system,
I expect it to be well over 75% of the total data loaded from disk.

It seems in your system, glibc is about 50% of the stuff that needs to
be paged in from disk, hence, by starting systemd-bootchart before
systemd, you've "removed" 50% of the total data to be loaded from the
vision of bootchart, since, bootchart cannot start logging data until
it's loaded all those glibc bits.

Ultimately, your system isn't likely booting faster, you're just
forcing it to load glibc before systemd starts.

systemd-analyze may actually be a much better way of looking at the
problem: it reports CLOCK_MONOTONIC timestamps for the various parts
involved, including, possibly, firmware, kernel time, etc.. In
conjunction with bootchart, this should give a full picture.

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

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

[Kok, Auke-jan H]

On Wed, Feb 17, 2016 at 4:49 PM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
> On Wed, Feb 17, 2016 at 09:17:51AM -0800, Kok, Auke-jan H wrote:
>> Splitting it out increases that potential and will allow
>> systemd-bootchart to evolve out of cycle again, and look a bit over
>> the fence. I've reviewed most of the changes to it, and noticed a bit
>> of a drop of risky commits, and those are the ones that are going to
>> be needed for this project to make it a useful tool in the future.
>>
>> So, I think this is a great move, one that certainly will motivate me
>> to engage more deeply again :)
> Hi Auke,
>
> what kind of big changes would you have in mind?
> Just the fact of being in one repo with systemd should not have
> much effect on changes to bootchart which is mostly standalone...

I have been asked on several occasions to make bootchart more
palatable for other OS's, including ChromeOS and even Android. This
has previously been shelved entirely, and I don't know if it's
currently even feasible, but at least logistically it should be a lot
easier to attempt.

The rest of the things I was looking at were items that being in-tree
did not affect, like new ways of grouping the process bars, better IO
visualization, etc.

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

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

[Kok, Auke-jan H]

On Wed, Feb 17, 2016 at 9:03 AM, Jóhann B. Guðmundsson
 wrote:
> On 02/17/2016 04:51 PM, Daniel Mack wrote:
>> [I've put all people in Cc who have had more than one commit related to
>> systemd-bootchart in the past]
>>
>> As part of our spring cleaning, we've been thinking about giving
>> systemd-bootchart a new home, in a new repository of its own. I've been
>> working on this and put the result here:
>
> What's the reason for splitting it out into it's own repository as what's
> the criteria you used to determine that which may or may not be applicable
> to other bits of systemd?+

When this code was merged into systemd originally it was by itself
already a fairly useful tool, and the potential to benefit systemd as
a project was enormous. That potential has subsided in the last two
years significantly as the community pushing systemd has (I think)
learned to be critical about additions to the code and the impact. As
such the beneficial component of synergy has faded a bit, and it may
actually hinder other projects from adopting systemd-bootchart.

Splitting it out increases that potential and will allow
systemd-bootchart to evolve out of cycle again, and look a bit over
the fence. I've reviewed most of the changes to it, and noticed a bit
of a drop of risky commits, and those are the ones that are going to
be needed for this project to make it a useful tool in the future.

So, I think this is a great move, one that certainly will motivate me
to engage more deeply again :)

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

Re: [systemd-devel] Improve boot-time of systemd-based device, revisited

[Kok, Auke-jan H]

On Mon, Jun 15, 2015 at 5:44 AM, Harald Hoyer harald.ho...@gmail.com
wrote:

 On 14.06.2015 15:17, cee1 wrote:

  BTW, systemd-bootchart has a option to chart entropy, how is the
  entropy involved in boot up procedure?

 Well, if daemons need bytes from /dev/random (think sshd key generation), I
 guess they will have to wait for enough entropy, and so does the boot
 process
 in the end.


​I added the option since we discovered that the entropy pool can take a
very long time to fill, and while this generally doesn't affect startup
(sshd etc. are usually started on demand) it may be problematic for
services like kerberos, an SSL enabled web server.

It's largely irrelevant for the basic OS components, though.

Cheers,

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

Re: [systemd-devel] [PATCH 1/2] bootchart: don't parse /proc/uptime, use CLOCK_BOOTTIME

[Kok, Auke-jan H]

thumbs up from me, thanks for sending this.

Auke



On Thu, Jul 31, 2014 at 1:15 AM, Karel Zak k...@redhat.com wrote:

 * systemd-bootchart always parses /proc/uptime, although the
   information is unnecessary when --rel specified

 * use /proc/uptime is overkill, since Linux 2.6.39 we have
   clock_gettime(CLOCK_BOOTTIME, ...). The backend on kernel side is
   get_monotonic_boottime() in both cases.

 * main() uses if (graph_start = 0.0) to detect that /proc is
   available.

   This is fragile solution as graph_start is always smaller than zero
   on all systems after suspend/resume (e.g. laptops), because in this
   case the system uptime includes suspend time and uptime is always
   greater number than monotonic time. For example right now difference
   between uptime and monotonic time is 37 hours on my laptop.

   Note that main() calls log_uptime() (to parse /proc/uptime) for each
   sample when it believes that /proc is not available. So on my laptop
   systemd-boochars spends all live with /proc/uptime parsing +
   nanosleep(), try

 strace  /usr/lib/systemd/systemd-bootchart

   to see the never ending loop.

   This patch uses access(/proc/vmstat, F_OK) to detect procfs.
 ---
  man/systemd-bootchart.xml |  4 +++-
  src/bootchart/bootchart.c | 11 +++
  src/bootchart/store.c | 29 -
  3 files changed, 22 insertions(+), 22 deletions(-)

 diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml
 index e19bbc1..150ca48 100644
 --- a/man/systemd-bootchart.xml
 +++ b/man/systemd-bootchart.xml
 @@ -131,7 +131,9 @@
  not graph the time elapsed since boot
  and before systemd-bootchart was
  started, as it may result in extremely
 -large graphs.  /para/listitem
 +large graphs. The time elapsed since boot
 +might also include any time that the
 system
 +was suspended./para/listitem
  /varlistentry
  /variablelist
  /refsect1
 diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
 index cbfc28d..909ef46 100644
 --- a/src/bootchart/bootchart.c
 +++ b/src/bootchart/bootchart.c
 @@ -310,6 +310,7 @@ int main(int argc, char *argv[]) {
  time_t t = 0;
  int r;
  struct rlimit rlim;
 +bool has_procfs = false;

  parse_conf();

 @@ -349,6 +350,8 @@ int main(int argc, char *argv[]) {

  log_uptime();

 +has_procfs = access(/proc/vmstat, F_OK) == 0;
 +
  LIST_HEAD_INIT(head);

  /* main program loop */
 @@ -385,11 +388,11 @@ int main(int argc, char *argv[]) {
  parse_env_file(/usr/lib/os-release,
 NEWLINE, PRETTY_NAME, build, NULL);
  }

 -/* wait for /proc to become available, discarding samples
 */
 -if (graph_start = 0.0)
 -log_uptime();
 -else
 +if (has_procfs)
  log_sample(samples, sampledata);
 +else
 +/* wait for /proc to become available, discarding
 samples */
 +has_procfs = access(/proc/vmstat, F_OK) == 0;

  sample_stop = gettime_ns();

 diff --git a/src/bootchart/store.c b/src/bootchart/store.c
 index e071983..cedcba8 100644
 --- a/src/bootchart/store.c
 +++ b/src/bootchart/store.c
 @@ -57,27 +57,22 @@ double gettime_ns(void) {
  return (n.tv_sec + (n.tv_nsec / 10.0));
  }

 -void log_uptime(void) {
 -_cleanup_fclose_ FILE *f = NULL;
 -char str[32];
 -double uptime;
 -
 -f = fopen(/proc/uptime, re);
 -
 -if (!f)
 -return;
 -if (!fscanf(f, %s %*s, str))
 -return;
 -
 -uptime = strtod(str, NULL);
 +static double gettime_up(void) {
 +struct timespec n;

 -log_start = gettime_ns();
 +clock_gettime(CLOCK_BOOTTIME, n);
 +return (n.tv_sec + (n.tv_nsec / 10.0));
 +}

 -/* start graph at kernel boot time */
 +void log_uptime(void) {
  if (arg_relative)
 -graph_start = log_start;
 -else
 +graph_start = log_start = gettime_ns();
 +else {
 +double uptime = gettime_up();
 +
 +log_start = gettime_ns();
  graph_start = log_start - uptime;
 +}
  }

  static char *bufgetline(char *buf) {
 --
 1.9.3

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

Re: [systemd-devel] [PATCH 2/2] bootchart: ask for --rel when failed to initialize graph start time

[Kok, Auke-jan H]

thanks!

Auke



On Sat, Aug 2, 2014 at 10:17 PM, Zbigniew Jędrzejewski-Szmek 
zbys...@in.waw.pl wrote:

 On Thu, Jul 31, 2014 at 10:15:40AM +0200, Karel Zak wrote:
  This patch uses access(/proc/vmstat, F_OK) to detect procfs.

  We always read system uptime before log start time. So the uptime
  should be always smaller number, except it includes system suspend
  time. It seems better to ask for --rel and exit() than try to be
  smart and try to recovery from this situation or generate huge
  messy graphs.
 Applied both.

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

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

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

[Kok, Auke-jan H]

On Thu, Aug 14, 2014 at 10:16 AM, Lennart Poettering lenn...@poettering.net
 wrote:

 Heya,

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

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

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

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

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


heh, ouch  X_X

I can understand your sentiment, though. I've identified plenty of cases
where readahead just isn't working out well at all, and the constant
tweaking has left it ... quite a bit messy.

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

Re: [systemd-devel] PATCH: fix systemd-bootchart svg background

[Kok, Auke-jan H]

On Mon, Jun 16, 2014 at 9:52 AM, Frederic Crozat fcro...@suse.com wrote:
 Hi all,

 attached is a fix for SVG generated by systemd-bootchart, similar to a
 fix already done in systemd-analyze.

yeah, that's a nice change. Looks good to me.

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

Re: [systemd-devel] [RFC 2/2] bootchart: add cgroup option

[Kok, Auke-jan H]

On Wed, Apr 23, 2014 at 1:13 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 28.03.14 17:07, WaLyong Cho (walyong@samsung.com) wrote:

 Sounds useful.

Agreed - this looks highly useful. Would be nice maybe to see an
example output file somehere, but otherwise thumbs up (though, please
refactor as per Lennart's comments).

Thanks WaLyong, Kyungmin!

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

Re: [systemd-devel] systemd session mode

[Kok, Auke-jan H]

On Sun, Dec 1, 2013 at 12:33 PM, Kay Sievers k...@vrfy.org wrote:
 On Sun, Dec 1, 2013 at 8:25 PM, Hristo Venev hri...@venev.name wrote:
 I've implemented session mode for systemd. I am currently using it and it 
 works
 pretty okay. I just had to generate D-Bus user services for D-Bus activation 
 to
 work.

 A new variable, XDG_SESSION_DIR, has been added. It defaults to
 /run/session/$XDG_SESSION_ID and is to be used for session-specific files as 
 it
 is `rm -rf`-ed on logout. There, in ./systemd/private, the systemd socket is
 stored. Also, my implementation of session units stores the D-Bus socket in
 ./dbus/session_bus_socket.

 There is intentionally only support for systemd --user, no plan to
 support any sort of systemd session instance. The one instance for the
 user will be shared by all sessions of the same user.

right, my personal thoughts on this were to have
session@seat.service units that take care of spawing a graphical UX
to the user on that seat.

I see little reason to create yet another instance of systemd --user
as the one existing process should be able to handle everything for a
single user already.

Not sure what to do with this patch series, I fear it will risk
running into problems when you have multiple seats and other things
like that, but I haven't looked into details of the patches too
much...

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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Nov 12, 2013 6:16 AM, Karel Zak k...@redhat.com wrote:

 On Fri, Nov 01, 2013 at 09:19:27AM -0700, Kok, Auke-jan H wrote:
  On Fri, Nov 1, 2013 at 12:57 AM, Karel Zak k...@redhat.com wrote:
   On Thu, Oct 31, 2013 at 01:20:18PM -0700, Kok, Auke-jan H wrote:
 BTW, for SELinux we remove selinux specific mount options in
 userspace (in mount(8)) if the kernel does not support selinux.
   
 It help us to make command line or fstab setting independent on
the
 current kernel features.
   
 Maybe we can use the same for SMACK, is there any way how to
 determine that the system uses SMACK? (/proc/something or
so...).
 -- for selinux we check for /sys/fs/selinux or /selinux.
  
   Ohh yes that would be so nice.
  
   You've got your choice for detecting smack, but I like
   stat(/sys/fs/smackfs) == 0 the best so far. You can parse
   /proc/filesystems for smackfs too, but that's obviously more complex.
   This method works with 3.9 and above, as that's when we made sysfs
   hold the mount point for smackfs.
  
   I assume we're talking about this code here:
  
  
https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181
  
Yes, the se_rem code (with SELinux is it tricky, because old
kernels don't support selinux options remount, options duplication is
problem etc.. I guess that for SMACK it will be less complex :-).
  
Do you have somewhere list of the smack mount options? I'll prepare
the patch.
 
  Yes, the authoritative documentation is the code:
 
 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smack.h#n143


  OK, implemented:

https://github.com/karelzak/util-linux/commit/b8095d25bae0588dfce8a62169f6db5496cf45c5

  You have to compile util-linux with --with-smack.

  It's trivial change, so I can backport it to the next stable release
  v2.24.1 (at the end of this year). OK?

Awesome - looks good (with the typo fix) and we'll get this tested.

Thanks again!

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

Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon

[Kok, Auke-jan H]

On Wed, Nov 6, 2013 at 1:32 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Kok, Auke-jan H at 06/11/13 02:08 did gyre and gimble:
 alright, I'll comment, but it took me 5 minutes to clear the coffee
 off my monitor...

 Looking at the feature list, why are you not contributing to connman
 instead?

 AFAIK, Tom has had plenty discussions with Marcel and Daniel on the
 connman side. I actually made sure Tom met Daniel in Edinburgh a couple
 weeks ago for this reason!

I guess I'm at fault for not attending those conferences ...

 So I don't think you need to worry too much about conman vs.
 systemd-networkd rather think of it as a rather collaborative effort in
 general. Quite where all the code and shared bits live in the end I
 don't know but I think this process is going about things in the right
 way to come to a good end-solution.

Sorry if my post seemed out of line - I'm happy to see the thread here
with comments from everyone that answer my concern and questions, and
knowing that this was well coordinated now makes me quite positive
about this effort.

Marcel and me have certainly struggled with the problem that happens
when you attempt to bring connman into a more server-like environment,
so, I'm very pleased to see that there is a significant effort to
bring an appropriate solution in this space that actually involves
connman as well.



Thanks!

Auke

PS Marcel - Now we just need to figure out what to do with that
JavaScript engine for pacrunner and get it working ;^)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon

[Kok, Auke-jan H]

On Tue, Nov 5, 2013 at 4:33 PM, Tom Gundersen t...@jklm.no wrote:
 This daemon listens for and configures network devices tagged with
 'systemd-networkd'. By default, no devices are tagged so this daemon
 can safely run in parallel with existing network daemons/scripts.

 Networks are configured in /etc/systemd/network/*.network. The first .network
 file that matches a given link is applied. The matching logic is similar to
 the one for .link files, but additionally supports matching on interface name.

 The mid-term aim is to provide an alternative to ad-hoc scripts currently used
 in initrd's and for wired setups that don't change much (e.g., as seen on
 servers/and some embedded systems).

 Currently, static addresses and a gateway can be configured, mostly as a proof
 of concept. I expect to expand on this as soon as we are agreed on the basic
 design.

 Comments, testing and contributions greatly appreciated!

alright, I'll comment, but it took me 5 minutes to clear the coffee
off my monitor...

Looking at the feature list, why are you not contributing to connman
instead? It seems you're going to be duplicating a ton of code And
connman does what your goal is, meaning you can pre-provision static
configurations without any of the more involved dependencies. It has a
DBus interface for status, configuration etc

I'm frankly shocked a bit, not sure what to say. Maybe this is a great
thing, but, without a doubt someone will want to convert this code
long term into connman / NM, and at that point we have 3 standards,
not 2. Best to try and stick to 2 standards and fix the one that has
the best long-term prospective value.

Cheers,

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

Re: [systemd-devel] Linux kernel API

[Kok, Auke-jan H]

On Mon, Nov 4, 2013 at 2:10 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Mon, Nov 04, 2013 at 10:54:26PM +0100, ScotXW wrote:
 Hi,

 On 11/02/2013 12:15 AM, Greg KH wrote:
  On Sat, Nov 02, 2013 at 12:05:23AM +0100, ScotXW wrote:
  On 11/01/2013 06:51 PM, Greg KH wrote:
  On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote:
  systemd is written exclusively for the Linux kernel because this
  offers advantages over the POSIX API. To illustrate the difference
  between Linux kernel API and POSIX API I created a diagram, see [1].
 
  Linux doesn't implement all of the POSIX api in the kernel, other
  portions of it are in other userspace pieces.
 
  Would you please name a couple beside the libc?
 
  Why, this is your research, not mine :)

 This is //not// a recherche, I was looking for some fast answer from the
 off the top of ones head. Besides the scheme, there is now an article [1].

 I still fail to understand how _any_ of this pertains to this mailing
 list...

Thanks Greg.

Scot, I find your messages not appropriate for this list. Please
remember that the list is named systemd-devel for a reason. Your
requests are clearly not in the interest, or promote the development
of systemd (if they are, you failed terribly at making a case that
that is the case... and please do not attempt to do so further).

So please don't post this kind of stuff to this list. There are far
better places to post these requests.

Sorry,

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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Fri, Nov 1, 2013 at 12:57 AM, Karel Zak k...@redhat.com wrote:
 On Thu, Oct 31, 2013 at 01:20:18PM -0700, Kok, Auke-jan H wrote:
   BTW, for SELinux we remove selinux specific mount options in
   userspace (in mount(8)) if the kernel does not support selinux.
 
   It help us to make command line or fstab setting independent on the
   current kernel features.
 
   Maybe we can use the same for SMACK, is there any way how to
   determine that the system uses SMACK? (/proc/something or so...).
   -- for selinux we check for /sys/fs/selinux or /selinux.

 Ohh yes that would be so nice.

 You've got your choice for detecting smack, but I like
 stat(/sys/fs/smackfs) == 0 the best so far. You can parse
 /proc/filesystems for smackfs too, but that's obviously more complex.
 This method works with 3.9 and above, as that's when we made sysfs
 hold the mount point for smackfs.

 I assume we're talking about this code here:

 https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181

  Yes, the se_rem code (with SELinux is it tricky, because old
  kernels don't support selinux options remount, options duplication is
  problem etc.. I guess that for SMACK it will be less complex :-).

  Do you have somewhere list of the smack mount options? I'll prepare
  the patch.

Yes, the authoritative documentation is the code:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smack.h#n143

/*
 * Mount options
 */
#define SMK_FSDEFAULT smackfsdef=
#define SMK_FSFLOOR smackfsfloor=
#define SMK_FSHAT smackfshat=
#define SMK_FSROOT smackfsroot=
#define SMK_FSTRANS smackfstransmute=

  BTW, the options should be also documented in mount.8 man page :-)

nod

Thanks,

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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Thu, Oct 31, 2013 at 12:00 PM, Karel Zak k...@redhat.com wrote:
 On Tue, Oct 29, 2013 at 01:27:07PM +0100, Lennart Poettering wrote:
 On Tue, 29.10.13 16:02, WaLyong Cho (walyong@samsung.com) wrote:

   Hmm, here's an idea: there has been a long standig feature request to
   add a configurable boolean to mount unit files that controls
   /bin/mount's -s switch. Let's say we call it
   SloppyOptions=yes/no, or so. Then, we could set this for this unit
   file and apply the rest of the patch and things should work, and where
   they don't we can easily reassign to the kernel to respect the -s flag
   properly.
  
   Doing a patch that allows -s to be controlled should be fairly easy,
   would be happy to merge a patch for that!
   ahhh I hadn't even seen -s in /bin/mount yet, so I can see this
   helping out a lot.
  
   I'd be okay with a solution like that, it would certainly simplify
   things a lot, but we need to be careful not to overload mount options
   with all sorts of nonstandard options - it will make problems harder
   to debug and for some of these security enabled systems we will most
   likely want to actually _not_ use -s. After all, we want to make sure
   we're actually booting with properly setup Smack options e.g. a typo
   in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate).
  
   Auke
  
  I am not sure we can use the -s option. First I tried that in my fedora
  machine.
 
  # mount -t tmpfs -s -o mode=1777,strictatime,smackfsroot=* tmpfs /test


  BTW, for SELinux we remove selinux specific mount options in
  userspace (in mount(8)) if the kernel does not support selinux.

  It help us to make command line or fstab setting independent on the
  current kernel features.

  Maybe we can use the same for SMACK, is there any way how to
  determine that the system uses SMACK? (/proc/something or so...).
  -- for selinux we check for /sys/fs/selinux or /selinux.

Ohh yes that would be so nice.

You've got your choice for detecting smack, but I like
stat(/sys/fs/smackfs) == 0 the best so far. You can parse
/proc/filesystems for smackfs too, but that's obviously more complex.
This method works with 3.9 and above, as that's when we made sysfs
hold the mount point for smackfs.

I assume we're talking about this code here:

https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181
?

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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Tue, Oct 29, 2013 at 12:02 AM, WaLyong Cho walyong@samsung.com wrote:
 How about add specific options for smack? According to
 http://schaufler-ca.com/description_from_the_linux_source_tree

 Smack supports some mount options:

 smackfsdef=label: specifies the label to give files that lack
 the Smack label extended attribute.

 smackfsroot=label: specifies the label to assign the root of the
 file system if it lacks the Smack extended attribute.

 smackfshat=label: specifies a label that must have read access to
 all labels set on the filesystem. Not yet enforced.

 smackfsfloor=label: specifies a label to which all labels set on the
 filesystem must have read access. Not yet enforced.

 If we support 'SmackFsRoot=label' option and append the 'smackfsroot' option
 after checking the smack by test_security(smack), then I think we can
 solve most problems.(with Auke's worry)

Adding config options for optional mount options that aren't even
standard sorry, that just sounds like a terrible idea.

Let's see why the -s option in mount isn't working. For Tizen, I'd
rather see a ConditionSecurity=!smack / ConditionSecurity=smack pair
of complementary unit files since that is a method that should aready
work and even cover the case where you boot with security=none or even
a kernel with smack disabled. Again a solution I would not recommend
carrying upstream but it solves the problem for Tizen well and would
be a 20-line patch or so.

Cheers,

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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Mon, Oct 28, 2013 at 3:44 AM, WaLyong Cho walyong@samsung.com wrote:
 At the same reason of /run and /dev/shm, when systemd is running with
 SMACK, countless tasks are failed by missed privilege.
 To avoid, /tmp is assigned '*' label.

We discussed this problem earlier in our office last week as we're
looking in to the same issues here, but the solution in this patch is
very problematic:

 +m4_ifdef(`HAVE_SMACK',
 +`Options=mode=1777,strictatime,smackfsroot=*',
 +`Options=mode=1777,strictatime')

The issue is here - the way you pass these options into tmp.mount make
it so that everyone who has compiled systemd with Smack enabled cause
them to attempt to mount tmpfs with these smack option.

This is a problem since:

1) mount fails if the option smackfsroot=* is not known, and because
2) if the kernel was not booted with Smack, the option is not known/invalid

and most importantly:

3) everyone who compiles systemd with xattr support will have Smack
enabled too, even if they did not pass --enable-smack to configure.

In short, you'd break everyone's tmp.mount with this patch.

Patches like this need to stay out of the upstream tree, until we
figure out how to automatically retry without these Smack specific
options, or some other more elegant solution that doesn't break
everyone else.

Cheers,


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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 28.10.13 19:44, WaLyong Cho (walyong@samsung.com) wrote:

 At the same reason of /run and /dev/shm, when systemd is running with
 SMACK, countless tasks are failed by missed privilege.
 To avoid, /tmp is assigned '*' label.

 Won't this break if people compile systemd with SMACK enabled but
 run a kernel that has it disabled?

 We had a similar problem for the other mounts like /run, where we found
 a somewhat nice solution, but I am not sure how we can make the same
 work here...

Our posts intersected, badly. Yes, as I said in my mail, this sadly
does a bad job for those folks running with smack enabled in systemd
but with it disabled in the kernel.

For Tizen, we're thinking of just keeping this patch out of tree (and
it will just be a one-liner).

We could do a ConditionSecurity=Smack, or something like that (ottomh)
but we'd get duplicate tmp mounts, which is bad due to the way we name
mount units. ick.

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

Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.

[Kok, Auke-jan H]

On Mon, Oct 28, 2013 at 1:09 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 28.10.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:


 On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Mon, 28.10.13 19:44, WaLyong Cho (walyong@samsung.com) wrote:
 
  At the same reason of /run and /dev/shm, when systemd is running with
  SMACK, countless tasks are failed by missed privilege.
  To avoid, /tmp is assigned '*' label.
 
  Won't this break if people compile systemd with SMACK enabled but
  run a kernel that has it disabled?
 
  We had a similar problem for the other mounts like /run, where we found
  a somewhat nice solution, but I am not sure how we can make the same
  work here...

 Our posts intersected, badly. Yes, as I said in my mail, this sadly
 does a bad job for those folks running with smack enabled in systemd
 but with it disabled in the kernel.

 For Tizen, we're thinking of just keeping this patch out of tree (and
 it will just be a one-liner).

 We could do a ConditionSecurity=Smack, or something like that (ottomh)
 but we'd get duplicate tmp mounts, which is bad due to the way we name
 mount units. ick.

 Hmm, here's an idea: there has been a long standig feature request to
 add a configurable boolean to mount unit files that controls
 /bin/mount's -s switch. Let's say we call it
 SloppyOptions=yes/no, or so. Then, we could set this for this unit
 file and apply the rest of the patch and things should work, and where
 they don't we can easily reassign to the kernel to respect the -s flag
 properly.

 Doing a patch that allows -s to be controlled should be fairly easy,
 would be happy to merge a patch for that!

ahhh I hadn't even seen -s in /bin/mount yet, so I can see this
helping out a lot.

I'd be okay with a solution like that, it would certainly simplify
things a lot, but we need to be careful not to overload mount options
with all sorts of nonstandard options - it will make problems harder
to debug and for some of these security enabled systems we will most
likely want to actually _not_ use -s. After all, we want to make sure
we're actually booting with properly setup Smack options e.g. a typo
in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate).

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

Re: [systemd-devel] Can apps ship their own copy of libudev?

[Kok, Auke-jan H]

On Thu, Oct 24, 2013 at 6:39 AM, Kay Sievers k...@vrfy.org wrote:
 On Thu, Oct 24, 2013 at 3:15 PM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Oct 24, 2013 at 2:09 PM, Kay Sievers k...@vrfy.org wrote:

 No, you cannot really ship your own libudev, it is coupled with the
 daemon. They speak a non-trivial wire protocol and write udev database
 files which are a private implementation only; they changed in the
 past, and might change at any time again. Libudev and udevd can only
 be used in the same version.

 Do you provide some compatibility for a reasonable time to accommodate the
 existing users to switch onto the changed wired protocol?

 No, the daemon and the lib need to be updated at the same time, there
 is no promise about compat in any direction, they just belong
 together.

 Failing that, what
 would you suggest for the Qt developers? Is there an alternative solution to
 keep udev in the loop without building two separate packages, or
 distribution dependent packages?

 Libudev0 and libudev1 are almost API compatible, only a few pointless
 functions are no longer provided by the new library. There should be
 no problem at compilation time, both versions should work fine. Things
 built by distributions should not notice anything, but for binary
 compatibility across different versions of libraries, I have no
 sensible idea, sorry.

One of the places I encountered this problem is Steam - it links
against libudev0 while most non-pleistocene distributions are well
into libudev1... Symlinking them allows me to waste time playing games
:^)

I can't recompile Steam, sadly.

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

Re: [systemd-devel] [PATCH] Smack enabled systems need /dev special devices correctly labeled

[Kok, Auke-jan H]

On Mon, Oct 14, 2013 at 3:54 PM, Kay Sievers k...@vrfy.org wrote:
 On Mon, Oct 14, 2013 at 11:58 PM, Michael Demeter
 michael.deme...@intel.com wrote:

 +KERNEL==tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*,
 +GROUP=dialout, SECLABEL{smack}=*

 The SECLABEL{} instruction in a separate line? What is that supposed
 to do? Have you tested any of this?

looks like the patch got munged in the process here (wrapped).

 Also, I'm not convinced that this belongs into the upstream repo. This
 seems like a very specific policy, similar to the selinux policy,
 which does not necessarily belong into systemd. Where is the policy
 defined for the apps and other stuff, isn't that the better place?

We had a discussion about this in the office here, because I was
hesitant about merging this upstream at first as well.

However, the rules above (or, at least what they intend to do) are
useful irregardless of whether you actually have created a Smack
policy or not. Creating a Smack policy can be complex or simple, but
there are a few basic things that should be tweaked even without any
existing policy in place, hence, it makes sense to merge this
upstream. After all, no matter the policy, these rules here are going
to be needed.

In short, setting '*' here as label is useful for all implementations
of Smack, policy present or not.

This basically boils down to the built-in set of rules that Smack has
in the kernel - without these rules basic operation will stop working
once you create a Smack policy. We want to make it easy for Smack
users to create their Smack policy without having to hunt down all
sorts of really low level Smack effects, and this is part of that.

Cheers,

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

Re: [systemd-devel] [PATCH] Smack enabled systems need /dev special devices correctly labeled

[Kok, Auke-jan H]

On Fri, Oct 11, 2013 at 4:47 PM, Michael Demeter
michael.deme...@intel.com wrote:
 - Add AC_DEFINE for HAVE_SMACK to configure.ac
 - Add Check for smack in Makefile.am to include smack default rules
 - Add smack default rules to label /dev/xxx correctly for access

 Change-Id: Iab07eb632b487b9ac4567cd08d0da6879709d44f
 Signed-off-by: Michael Demeter michael.deme...@intel.com
 ---
  Makefile.am   |  5 +
  configure.ac  |  1 +
  rules/55-udev-smack-default.rules | 18 ++
  3 files changed, 24 insertions(+)
  create mode 100644 rules/55-udev-smack-default.rules

 diff --git a/Makefile.am b/Makefile.am
 index e8be76b..bd397c4 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -1943,6 +1943,11 @@ dist_udevrules_DATA += \
 rules/80-net-name-slot.rules \
 rules/95-udev-late.rules

 +if HAVE_SMACK
 +dist_udevrules_DATA += \
 +   rules/55-udev-smack-default.rules
 +endif
 +
  dist_udevhwdb_DATA = \
 hwdb/20-pci-vendor-model.hwdb \
 hwdb/20-pci-classes.hwdb \
 diff --git a/configure.ac b/configure.ac
 index 091fe20..facd931 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -472,6 +472,7 @@ AS_HELP_STRING([--with-smack-run-label=STRING],

  if test x${have_smack} = xyes ; then
  AC_DEFINE(HAVE_SMACK, 1, [Define if SMACK is available])
 +AM_CONDITIONAL([HAVE_SMACK], [true])
  fi

  # 
 --
 diff --git a/rules/55-udev-smack-default.rules 
 b/rules/55-udev-smack-default.rules
 new file mode 100644
 index 000..6df90bb
 --- /dev/null
 +++ b/rules/55-udev-smack-default.rules
 @@ -0,0 +1,18 @@
 +# do not edit this file, it will be overwritten on update
 +
 +KERNEL==null,SMACK=*
 +KERNEL==zero,SMACK=*
 +KERNEL==console,SMACK=*
 +KERNEL==kmsg,SMACK=*
 +KERNEL==video0,SMACK=*
 +KERNEL==card0,SMACK=*

shouldn't these be card* and video* ?

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

Re: [systemd-devel] [PATCH 2/2] core: require $XDG_RUNTIME_DIR to be set for user instances

[Kok, Auke-jan H]

On Wed, Oct 9, 2013 at 4:57 AM, Mantas Mikulėnas graw...@gmail.com wrote:
 It seems that some places use /run otherwise, which isn't going to work.
 ---
  src/core/main.c | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/src/core/main.c b/src/core/main.c
 index fe291f8..36543c6 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1404,6 +1404,12 @@ int main(int argc, char *argv[]) {
  goto finish;
  }

 +if (arg_running_as == SYSTEMD_USER 
 +!getenv(XDG_RUNTIME_DIR)) {
 +log_error(Trying to run as user instance, but 
 \$XDG_RUNTIME_DIR is not set.);
 +goto finish;
 +}
 +

This is good, hopefully it will help folks debug user session usage better.

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

Re: [systemd-devel] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.

[Kok, Auke-jan H]

On Wed, Oct 9, 2013 at 9:18 AM, Kay Sievers k...@vrfy.org wrote:
 On Wed, Oct 2, 2013 at 8:12 PM, Auke Kok auke-jan.h@intel.com wrote:

 These 2 mounts are allowed to fail, which will happen if the
 system is not running a SMACK enabled kernel or security=none is
 passed to the kernel.

 The kernel throws errors for this at the console:
   tmpfs: Bad mount option smackfsroot

 Please conditionalize the mount calls with is_smack_enabled() or
 something similar.

thanks for the note - I realize that smack support will be enabled for
almost all builds since people have xattr support almost anywhere and
that is the prereq.

Churning on a patch as we speak...

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

Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).

[Kok, Auke-jan H]

On Tue, Oct 8, 2013 at 3:29 PM, Schaufler, Casey
casey.schauf...@intel.com wrote:
 -Original Message-
 From: Lennart Poettering [mailto:lenn...@poettering.net]
 Sent: Tuesday, October 08, 2013 3:17 PM
 To: Kok, Auke-jan H
 Cc: Zbigniew Jędrzejewski-Szmek; Schaufler, Casey; systemd-devel
 Subject: Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain
 (label).

 On Mon, 07.10.13 10:30, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:

   Hi,
   the patches look OK. I dont' have a system with smack support at
   hand, but I tested them on Fedora, and didn't notice any adverse effects.
   I you've tested them with smack, then they should be applied, imo.
 
  Thanks, I just applied them myself - I just wanted to give folks a bit
  of time to read and test - so thanks for doing so!

 Hmm, the patches as they are merged now try to mount the SMACK version
 of /run and /dev/shm also in containers. Will this work?

 So long as the cgroup filesystem propagates the xattrs to and from the real
 filesystem it won't be a problem. If the cgroup filesystem is not doing that
 there will be a problem.


 So far (at least for SELinux) we tried to turn off all security layers in
 containers, since the policies are not virtualized.

 I don't know what you mean by virtualized in this context.

 Due to that it sounds more
 appropriate not to mount these SMACK versions in a container. More
 specifically, I'd like to remove the MNT_IN_CONTAINER flags from the lines
 you just added?

 That does sound like the safest approach. I would be fine with that.


 Does that make sense to you?


yes, that makes sense. I'll include this in the patch that makes the
smack-specific mounts not throw errors since that touches these lines
as well.

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

Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)

[Kok, Auke-jan H]

On Mon, Oct 7, 2013 at 7:53 PM, Andrey Borzenkov arvidj...@gmail.com wrote:
 В Mon, 7 Oct 2013 12:58:16 -0700
 Kok, Auke-jan H auke-jan.h@intel.com пишет:


 Doing a `ln -sf /usr/lib/systemd/user/dbus.socket
 /etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or
 something like that maybe helps, but you're running into the basic
 problem that there's just not enough there for systemd --user to do
 anything useful (no default target defined, no dependencies installed
 to sane defaults, etc.).


 If there nothing to run as user session, why systemd starts user
 session?

 You probably misunderstand the problem. Stock systemd will start
 user@0.service when session for root opens (and I assume
 user@$UID.service for each other user). This service sometimes does not
 stop on shutdown causing timeout. If this service is not needed, it
 should not be started, right? So it is not we who are running in
 basic problem - it is systemd which is running into basic problem :)


I can't speak for others, but I have not yet reproduced the issue at
shutdown with just an empty user@0.service running.

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

Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)

[Kok, Auke-jan H]

On Mon, Oct 7, 2013 at 12:08 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Mon, Oct 07, 2013 at 10:03:22PM +0300, Toms Seisums wrote:
 On 7 October 2013 20:33, Kok, Auke-jan H auke-jan.h@intel.com wrote:
  On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums toms.seis...@gmail.com
  wrote:
   I got two systems having the exact same problem with similar symptoms.
  Both
   systems are upgraded to latest Arch Linux, and just recieved Linux Kernel
   3.11.4 upgrades also.
  
   One is running on Linode, one is a local machine.
  
   Apparently, the fix provided by Auke does not resolve the problem.
   Tom Gundersens' one, though, does it.
  
   Two problems still remain, though:
  
   1. The dbus notice message upon logging in (Failed to open private bus
   connection: Failed to connect to socket
  /run/user/0/dbus/user_bus_socket: No
   such file or directory).
 
  Why are you starting a session dbus for user root?
 I'm not, it's started automatically. Might be an issue in Arch Linux.
 I think that we (as in upstream) start user@0.service whenever a root
 session is opened by cron or whatever.

ahh yes, I see that here now too.

So, the reason that dbus.socket/dbus.service isn't setup or anything
is that there is no properly setup default.target that requires or
sets up dbus.socket for user sessions.

Doing a `ln -sf /usr/lib/systemd/user/dbus.socket
/etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or
something like that maybe helps, but you're running into the basic
problem that there's just not enough there for systemd --user to do
anything useful (no default target defined, no dependencies installed
to sane defaults, etc.).

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

Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)

[Kok, Auke-jan H]

On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums toms.seis...@gmail.com wrote:
 [object Object]

Look at Gmail failing flat on its face... lol

Aside from that, can you perhaps try this patch:

--- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700
+++ systemd-user-sessions.service 2013-10-04 11:53:37.02867 -0700
@@ -8,7 +8,7 @@
 [Unit]
 Description=Permit User Sessions
 Documentation=man:systemd-user-sessions.service(8)
-After=remote-fs.target
+After=remote-fs.target dbus.service

 [Service]
 Type=oneshot

some colleagues of mine identified that tasks in the user session that
attempt to contact the system bus during shutdown may hang doing so.
We can prevent this hang by making user sessions shut down entirely
first before dbus is destroyed.

It may or may not help. You can also insert After=dbus.service in to
user@.service, but I feel this is a better spot.


Thanks,

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

Re: [systemd-devel] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.

[Kok, Auke-jan H]

On Tue, Oct 1, 2013 at 4:40 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 01.10.13 16:11, Auke Kok (auke-jan.h@intel.com) wrote:

 Once system itself is running in a security domain for SMACK,
 it will fail to start countless tasks due to missing privileges
 for mounted and created directory structures. For /run and shm
 specifically, we grant all tasks access.

 Hmm, I am not convinced this patch is really desirable. So far we tried
 to make sure that a systemd that is compiled with selinux/smack/ima
 support works on kernels that lack it and vice versa. However, if I am
 not mistaken this patch will break this, as you set MNT_FATAL for the
 mounts but unconditionally add smackfsroot=* to the mount options --
 which if I am not mistaken will cause the mount to fail on kernels that
 lack SMACK, right?

thanks for replying - I was struggling to figure out if we really want to do
that or not.

 Something that might work is simply dropping the MNT_FATAL from the
 HAVE_SMACK lines. That way, it will be attempted to mount things with
 the specified parameters, and if that fails it will be retried
 immediately with the following line that lacks the smackfsdef= param?
 The mounting code is smart enough to detect if /run is mounted and will
 not actually try to mount things twice if something is found to be
 mounted there already...

I like that, that's totally reasonable. Will respin.

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

Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).

[Kok, Auke-jan H]

On Tue, Oct 1, 2013 at 4:42 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 01.10.13 16:11, Auke Kok (auke-jan.h@intel.com) wrote:

 index 1434dea..d7b8dce 100644
 --- a/src/core/smack-setup.c
 +++ b/src/core/smack-setup.c
 @@ -36,6 +36,7 @@
  #include macro.h
  #include smack-setup.h
  #include util.h
 +#include fileio.h
  #include log.h
  #include label.h

 @@ -138,6 +139,12 @@ int smack_setup(void) {
  return 0;
  }

 +#ifdef SMACK_RUN_LABEL
 +if (write_string_file(/proc/self/attr/current, SMACK_RUN_LABEL))
 +log_warning(Failed to set SMACK label \%s\ on self: %s,
 +SMACK_RUN_LABEL, strerror(abs(r)));
 +#endif

 Looks got in principle, but error handling is borked. You need to assign
 r first before you print it. Also, write_string_file returns negative
 errno, so you should just strerror(-r) instead of strerror(abs(r)).

derp prize. Apologies. Will fix.

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

Re: [systemd-devel] Patch for Smack labelling support in udev

[Kok, Auke-jan H]

On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote:
 On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
 auke-jan.h@intel.com wrote:
 On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena 
 elena.reshet...@intel.com wrote:

 For example, I can set a couple of smack-related xattrs in one go like
 XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
 Doesn't make sense from smack point of view (only smack64 is really 
 meaningful
 on device nodes), but proves that functionality works.

 right, but we could be setting other non-SMACK xattrs now all in one
 go - for example, SELINUX ones (security.selinux).

 Yeah, *looks* powerful, but also scary. :)

 And selinux is not managed by visible strings exposed to tools, it's
 all hidden in a library, and the database returns the stuff to apply.
 There should never be the need to set any string from selinux with a
 tool carrying static strings.

 This looks OK to me, can you take another look at it?

 I still can't wrap my head around the issue that we can use udev rules
 now to *add* things which will never get removed again. If we add a
 rule that set one of these attributes, and remove the rule again, the
 applied xattr will never be cleared.

 It all sounds not right to me, and I don't think we should go ahead
 with anything like this before we have sorted out the responsibilities
 and ownership of data we attach to device nodes. We do not do that for
 anything else, things just don't pile up, they are reset, cleared when
 the config goes away and an event is triggered.

 We probably need some concept of ownership, based on xattr names or
 namespaces, soemthing that  makes it clear who's responsible to
 reset/clear the attributes when the config changes.

 Not sure, maybe we can just reset all xattrs with an add event, and
 declare add as a form of reset to a prisitine state.

 The other issue is, that as nice as generic support for xattrs sounds,
 it might in the end not be what we should offer to random users.

 I really can't decide at this moment, I have to think it through.

well, for Tizen at least, we need this functionality. Too many nodes
appear in /dev/ that should only be accessible by certain services
alone, and this is exactly what SMACK adds.

A good example is that SMACK allows us to grant only camera
(/dev/video/*) privileges to approved camera applications, instead of
having every application for a user in a session have full access to
the camera. We get the best of both access control methods.

I realize that unsetting/removal is a concern, but I don't think it
should preclude merging code that is better at setting/adding :^)

The only alternative I see is to create another udev event listener
and have that process set smack labels. That would just duplicate a
lot of udev code... And it still doesn't solve the removal of rules -
that would be something only a e.g. %post script could consistently
do.

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

Re: [systemd-devel] [systemd-commits] configure.ac Makefile.am src/login units/u...@.service.in

[Kok, Auke-jan H]

On Wed, Sep 11, 2013 at 12:39 PM, Zbigniew Jędrzejewski-Szmek
zbys...@kemper.freedesktop.org wrote:
  Makefile.am|5 +
  configure.ac   |7 +++
  src/login/pam-module.c |4 ++--
  src/login/systemd-user |8 
  units/u...@.service.in |2 +-
  5 files changed, 23 insertions(+), 3 deletions(-)

 New commits:
 commit 5c390a4ae0d383b2003074ed011d47876c7e630c
 Author: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
 Date:   Wed Sep 11 14:31:14 2013 -0400

 Add pam configuration to allow user sessions to work out of the box

 systemd-logind will start user@.service. user@.service unit uses
 PAM with service name 'systemd-user' to perform account and session
 managment tasks. Previously, the name was 'systemd-shared', it is
 now changed to 'systemd-user'.

 Most PAM installations use one common setup for different callers.
 Based on a quick poll, distributions fall into two camps: those that
 have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia,
 Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE).
 Distributions that have system-auth have just one configuration file
 that contains auth, password, account, and session blocks, and
 distributions that have common-auth also have common-session,
 common-password, and common-account. It is thus impossible to use one
 configuration file which would work for everybody. systemd-user now
 refers to system-auth, because it seems that the approach with one
 file is more popular and also easier, so let's follow that.


+1

Thanks for doing this - it'll be good for folks implementing user
sessions to have a consistent approach.

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

Re: [systemd-devel] Convert Inittab-Entry to systemd

[Kok, Auke-jan H]

On Tue, Aug 27, 2013 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 Also I don't think this will properly handle session registration will
 it? There is nothing here that registers the session - no pam configs to
 include pam_systemd etc.

nope

 I think you would need some kind of PAMName= attribute here to also
 handle that (man systemd.exec(5)). Obviously the /etc/pam.d/ stuff would
 need to be configured accordingly with appropriate permissions (I
 presume) to allow autologin but also ensure the pam_systemd stuff is
 configured properly. Never tried this kind of autologin but I don't
 think I'm talking too much nonsense :D

PAMName=login should just work here.

Cheers,

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

Re: [systemd-devel] How to wait for a group of devices?

[Kok, Auke-jan H]

On Mon, Aug 19, 2013 at 10:37 AM, Greg KH gre...@linuxfoundation.org wrote:
 On Mon, Aug 19, 2013 at 05:35:35PM +0200, Manuel Reimer wrote:
 On 08/19/2013 04:53 PM, Greg KH wrote:
 The second one wants to access DVB devices.
 
 These could be connected via PCI, PCI express or USB. So here I need
 Wait until all possible, currently connected, DVB devices are
 initialized and drivers are loaded.
 
 Same here, there is no way to ever do this (PCI devices can be
 hotplugged at anytime, just like USB).
 
 Instead, just do something based on _when_ you see a specific type of
 USB device, that way everything will work properly, no need to wait
 for anything.

 I'm not the developer of that daemon. I just want to run it reliably
 on a distribution, using systemd.

 What happens to that daemon if a new device is plugged into the system
 while it is already running?  It has to handle that properly today, so
 there's no need in waiting around for some unknown amount of time for
 any reason.

 If it doesn't handle it properly, go poke upstream to get that fixed, as
 that's a major bug.

I've encountered the problem in e.g. mythtv - if your DVB adapter
takes a long time to initialize (40 seconds for my hauppauge cards,
for instance, due to some weird FW loading problem), then your system
will just boot and run mythbackend, which won't see any DVB tuners,
and none of your scheduled recordings will record.

This isn't something that can be fixed outside of MythTV. maybe it's
been already fixed upstream, but in 0.25.1 this was still a bug.

libudev should provide the methods needed to implement a proper fix.

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

Re: [systemd-devel] Patch for Smack labelling support in udev

[Kok, Auke-jan H]

On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
 -Original Message-
 From: Kay Sievers [mailto:k...@vrfy.org]
 Sent: Tuesday, July 16, 2013 10:12 PM
 To: Reshetova, Elena
 Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
 Schaufler, Casey; walyong@samsung.com
 Subject: Re: [systemd-devel] Patch for Smack labelling support in udev

 On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com
 wrote:
 -static int node_permissions_apply(struct udev_device *dev, bool
 apply, mode_t mode, uid_t uid, gid_t gid)
 +static int node_permissions_apply(struct udev_device *dev, bool
 +apply,
 mode_t mode,
 +  uid_t uid, gid_t gid, struct
 +udev_list xattr_list)

Guess we better pass the udev_list as a const pointer here.

 Ups, sorry, missed this one, of course it won't even work this way (I
 haven't tried to run it yet ...

It looks like it could work, but please test it and make sure it does the
right thing before we go ahead from here.

 OK, so now I have tested it and with one minor fix (passing a list entry and
 not the whole list in udev-node) it works just fine.
 I am able to setup one or more xattrs on device node using the syntax

 XATTR{attr_name}=value

 For example, I can set a couple of smack-related xattrs in one go like
 XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
 Doesn't make sense from smack point of view (only smack64 is really meaningful
 on device nodes), but proves that functionality works.

right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).

 I am attaching the patch.

Kay,

This looks OK to me, can you take another look at it?

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

Re: [systemd-devel] I wanna construct server-client model with systemd option.

[Kok, Auke-jan H]

On Mon, Jul 29, 2013 at 5:48 PM, Tony Seo tonys...@gmail.com wrote:
 I have aimed to construct server-client model.

 In order to build that mode, I supposed that there was X_server and
 A_client.

 I tried to do several time to operate that model properly, but I have failed
 to do that operation.

 In my view, I need to edit my service option which have been used for
 execution , but I'm not accustomed to using service option and confused a
 few option related with execution like Type=and Execstart=.

All of the options involving startup types and dependencies are
explained in the manual pages. You can view them online here:

http://www.freedesktop.org/software/systemd/man/systemd.service.html

If you need more help, or are troubleshooting, please post your unit
files here and a description of what you intend for these to do, and
we can look at solving your problems.

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

Re: [systemd-devel] Does systemd have points to spend many times to complete its process?

[Kok, Auke-jan H]

On Thu, Jul 25, 2013 at 4:58 AM, Tony Seo tonys...@gmail.com wrote:
  Hello

 I'm Tony Seo.

 I've analyzed a plot resulted in systemd-analyze plot.

 As you can see an attached image file, I got this image from my systemd.

 While I have analyzed it, I have several questions.


 1. what is -.mount ?

 when I first saw -.mout, I was confused how to configure it.



 2. I doubt that there are critical points which make systemd more delayed
 for several reasons.

 I have tried to test my systemd for optimization in  perspective of time
 consume.

 So, I changed the order of unit dependency and sequence among units.

 But I found that I may not reduce the time to activate getty.target,
 multi-user.target and graphical.target.

 And I doubt that there are critical points or span of stage to make the
 systemd more delayed.

 I want to know whether I'm wrong or not.

 what do you think about it?

 If you know some tip to improve a systemd in optimize perspective, could you
 give some tips to make my systemd more fast?

systemd is not the problem.

the picture you posted shows that some service is delaying
sysinit.target or basic.target.

Most likely the player.service is implemented incorrectly. You may
have entered the wrong Type in the service file.

Cheers,

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

Re: [systemd-devel] [PATCH] cgroups: chown user slices

[Kok, Auke-jan H]

On Wed, Jul 10, 2013 at 5:48 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Sat, 06.07.13 01:16, Marc-Antoine Perennou (marc-anto...@perennou.com) 
 wrote:

 When creating the cgroup hierarchy for a user slice,
 chown this slice to the user uid.

 Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
 ---
  src/shared/cgroup-label.c | 8 
  1 file changed, 8 insertions(+)

 diff --git a/src/shared/cgroup-label.c b/src/shared/cgroup-label.c
 index 574a7be..1891c9a 100644
 --- a/src/shared/cgroup-label.c
 +++ b/src/shared/cgroup-label.c
 @@ -41,6 +41,7 @@

  int cg_create(const char *controller, const char *path) {
  _cleanup_free_ char *fs = NULL;
 +uid_t uid = (uid_t) -1;
  int r;

  r = cg_get_path_and_check(controller, path, NULL, fs);
 @@ -59,6 +60,13 @@ int cg_create(const char *controller, const char *path) {
  return -errno;
  }

 +r = cg_path_get_owner_uid(path, uid);
 +if (r  0  r != -ENOENT)
 +return r;
 +
 +if (uid != (uid_t) -1)
 +chown(fs, uid, (gid_t) -1);
 +

 systemd in git will now grant access to the cgroup subtree in
 user@.service to the specific user. That should solve the issue. (Note
 that this means systemd --user will only work when run from
 user@.service, as access to the cgroup tree is *not* granted for normal
 sessions directly.)

can you elaborate what normal sessions are? Are we talking about
`PAMName=systemd-shared` being the part that distinguishes them?

Thanks,

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

Re: [systemd-devel] systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

[Kok, Auke-jan H]

On Sat, Jul 6, 2013 at 1:40 AM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 The patch I mailed a few hours ago about chowning cgroups solved this issue
 here.

but it's not a permanent solution - only a workaround. I believe from
the release notes that systemd --user shouldn't maintain the cgroups
itself anymore directly and instead delegate to systemd-run(?).

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

Re: [systemd-devel] [HEADSUP] cgroup changes

[Kok, Auke-jan H]

On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering
lenn...@poettering.net wrote:
 Heya,

 On monday I posted this mail:

 http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html

 Here's an update and a bit on the bigger picture:

Thanks for doing this - I am really looking forward to seeing this all
take shape, and I hope to be able to leverage this in the future :^)

All the points below are great, and problems that I've encountered in
the past have all hinted towards this being the right way forward.

#2 below has my interest - when you have some ideas about how the API
will look I'd like to review it and match against our use cases...

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

Re: [systemd-devel] [HEADSUP] cgroup changes

[Kok, Auke-jan H]

On Fri, Jun 21, 2013 at 1:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 21.06.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:

  http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
 
  Here's an update and a bit on the bigger picture:

 Thanks for doing this - I am really looking forward to seeing this all
 take shape, and I hope to be able to leverage this in the future :^)

 All the points below are great, and problems that I've encountered in
 the past have all hinted towards this being the right way forward.

 #2 below has my interest - when you have some ideas about how the API
 will look I'd like to review it and match against our use cases...

 Point #2 is precisely about not having APIs for this... ;-)

 So, in the future, when you have some service, and that service wants to
 alter some cgroup resource limits for itself (let's say: set its own cpu
 shares value to 1500), this is what should happen: the service should
 use a call like sd_pid_get_unit() to get its own unit name, and then use
 dbus to invoke SetCPUShares(1500) for that service. systemd will then do
 the rest. (*)

 Lennart

 (*) to make this even simpler we have been thinking of defining a new
 virtual bus object path /org/freedesktop/systemd1/self/ or so which
 will always points to the callers own unit. This would be similar to
 /proc/self/ which also points to its own PID dir for each
 process... With that in place you could then set any resource setting
 you want with a single bus method call.

This is fine for applications that manage themselves, but I'm seeing
more interest in use cases where we want external influence on cgroup
hierarchies, for instance:

- foreground/background priorities - a window manager marks background
applications and puts them in the freezer, changes oom_score_adj so
that old apps can get automatically cleaned up in case memory
availability is low.
- detecting runaway apps and taking cpu slices away from them.
- thermally constraining classes of applications

Those would be tasks that an external process would do by manipulating
properties of cgroups, not something each task would do on it's own.

Do you suggest these manipulations should be implemented without high
level systemd API's and the controller just manipulates the cgroups
directly?

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

Re: [systemd-devel] [HEADSUP] cgroup changes

[Kok, Auke-jan H]

On Fri, Jun 21, 2013 at 2:17 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 21.06.13 14:10, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:

  So, in the future, when you have some service, and that service wants to
  alter some cgroup resource limits for itself (let's say: set its own cpu
  shares value to 1500), this is what should happen: the service should
  use a call like sd_pid_get_unit() to get its own unit name, and then use
  dbus to invoke SetCPUShares(1500) for that service. systemd will then do
  the rest. (*)
 
  Lennart
 
  (*) to make this even simpler we have been thinking of defining a new
  virtual bus object path /org/freedesktop/systemd1/self/ or so which
  will always points to the callers own unit. This would be similar to
  /proc/self/ which also points to its own PID dir for each
  process... With that in place you could then set any resource setting
  you want with a single bus method call.

 This is fine for applications that manage themselves, but I'm seeing
 more interest in use cases where we want external influence on cgroup
 hierarchies, for instance:

 - foreground/background priorities - a window manager marks background
 applications and puts them in the freezer, changes oom_score_adj so
 that old apps can get automatically cleaned up in case memory
 availability is low.
 - detecting runaway apps and taking cpu slices away from them.
 - thermally constraining classes of applications

 Those would be tasks that an external process would do by manipulating
 properties of cgroups, not something each task would do on it's own.

 Do you suggest these manipulations should be implemented without high
 level systemd API's and the controller just manipulates the cgroups
 directly?

 All changes to cgroup attributes must go through systemd. If the WM
 wants to freeze or adjust OOM he needs to issue systemd bus calls for
 that.

 The run-away stuff I can't follow? the kernel will distribute CPU
 evenly among running apps if all want it, so not seeing why there's more
 monitoring needed.

 The thermal stuff is probably best done in-kernel i guess... Too
 dangerous/subject-to-latency for userspace, no?

Only userspace can distinguish between e.g. a foreground and
background application (WM) and decide that CPU consumption of certain
apps in the background is excessive, and throttle it down further,
which is somewhat similar to using freezer to just SIGSTOP them
entirely basically.

Thermal throttling from userspace allows you to distinguish between
never make my SETI turn the fan on and throttle the entire system
when I reach high fan speeds. You can't do that in the kernel. [1]
Arguably this could be done in-task and not by an external controller,
but you're still trusting the task to do the right thing, which may
not be something you want to do.


Auke


[1] Note that the new Intel P-state driver by Dirk Brandewie changes
how things work with nice(). The old behaviour was abused by folks
running bitcoin miners at nice values which caused ondemand to do
something irrational: nice-only tasks would keep the CPU in lowest
frequencies, which is terrible from a power perspective - now every
daemon running at nice value takes much longer to complete its task,
burning more power then when it had raced-to-idle.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADSUP] cgroup changes

[Kok, Auke-jan H]

On Fri, Jun 21, 2013 at 3:07 PM, Kay Sievers k...@vrfy.org wrote:
 On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H
 auke-jan.h@intel.com wrote:
 Only userspace can distinguish between e.g. a foreground and
 background application (WM) and decide that CPU consumption of certain
 apps in the background is excessive, and throttle it down further,

 This would probably be some bus call to the systemd --user instance
 managing the services in the session, if that's what you mean?

for instance, yes.

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

Re: [systemd-devel] We are working on trying to scale up to 1000 containers.

[Kok, Auke-jan H]

On Thu, Jun 20, 2013 at 12:23 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 18.06.13 09:11, Daniel J Walsh (dwa...@redhat.com) wrote:

 One concern we have is what will happen to systemd if we start 1000 services
 at boot.

 systemctl start httpd_sandbox.target

 For example.

 Is there anything we can do to throttle the start of so many unit files.  Or
 would systemd do something itself.

 So, we have rate limits on some things. We maintain per-service
 ratelimits, and a ratelimit in the main even loop. However, that's
 really just a last resort thing. Basically, if the event loop spins more
 often than 50.000 times per second we will just totally block execution
 for 1s. So things get awfully slow when we do too much stuff so that we
 don't consumer 100% CPU forever, and that's all.

 I have no experience with running this many services on a machine. I am
 sure we can add various bits here and there to make sure things scale
 nicely for this. But for that I'd really like some performance data
 first, i.e. what actually really happens with the current code.

I'd be very interested to see at least a bootchart and systemd-analyze
plot of this... please post them to share!

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

Re: [systemd-devel] Masking socket activated services is broken

[Kok, Auke-jan H]

On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl mbi...@gmail.com wrote:
 Hi,

 I've run systemctl mask rsyslog.service, but the service can still
 be started via
 systemctl start rsyslog.service or by generating a log message.

 Looks like a bug to me.

Why would it be? Masking just removes the unit from the dependency
tree of a target - I kinda prefer being able to mask and manually
start a unit. The alternative, which is what you suggest, is that the
administrator is prohibited from starting a unit - sounds much worse
to me.

Cheers,


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

Re: [systemd-devel] [PATCH] Describe handling of an AF_UNIX socket

[Kok, Auke-jan H]

On Wed, Jun 19, 2013 at 5:59 AM, Łukasz Stelmach l.stelm...@samsung.com wrote:
 Describe how to handle an AF_UNIX socket, with Accept set to false,
 received from systemd, upon exit.

 Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com
 ---
  man/systemd.socket.xml |   12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

Applied, thanks!

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

Re: [systemd-devel] [PATCH] Delay dbus connection for user session

[Kok, Auke-jan H]

On Tue, Jun 4, 2013 at 10:31 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 29.05.13 08:59, Yang Chengwei (chengwei.y...@intel.com) wrote:

   diff --git a/src/core/manager.c b/src/core/manager.c
   index 0508628..467b5ba 100644
   --- a/src/core/manager.c
   +++ b/src/core/manager.c
   @@ -503,7 +503,7 @@ int manager_new(SystemdRunningAs running_as, Manager 
   **_m) {
goto fail;
  
/* Try to connect to the busses, if possible. */
   -r = bus_init(m, running_as != SYSTEMD_SYSTEM);
   +r = bus_init(m, running_as != SYSTEMD_SYSTEM  running_as != 
   SYSTEMD_USER);
if (r  0)
goto fail;
 
  So, I've looked at this code again as I've spotted this problem over a
  year ago, and I'm wondering if this entire section should just be
  removed, since running_as only has 2 values (_SYSTEM and _USER)
  anyway...
 
  Would there be any objection to just dropping these 4 lines entirely?
  Lennart, Kay? I don't see how we'd have a 3rd manager type here.

 Yes, just in that case. If all of you agreed, I'd like submit a V2 to
 drop these lines.

 Hmm, this would break my usual testing routine, where i run user systemd
 against a bus daemon that is already running... I have no doubt that
 dropping the check entirely is the right way to go eventually, but maybe
 we can find a better way so that this continues to work for me until
 GNOME has switched over to systemd as service manager.

I'm kinda dumb for not thinking this over, but, if you already have a
dbus-daemon running, you have DBUS_SESSION_BUS_ADDRESS set.

So, the whole idea of connection to a session bus if
DBUS_SESSION_BUS_ADDRESS is unset makes no sense whatsoever.

Lennart, would you agree that we could just do something like:

if (getenv(DBUS_SESSION_BUS_ADDRESS))
// attempt to init dbus early
else
   // debug message printing out that an attempt to connect to an
existing session bus was not done

I think that solves your use case, and will remove the whole dbus init
attempt for folks running under a user session where this is not
needed.

Thanks,


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

Re: [systemd-devel] how to end a socket activated daemon

[Kok, Auke-jan H]

On Tue, Jun 18, 2013 at 3:04 AM, Łukasz Stelmach l.stelm...@samsung.com wrote:
 It was 2013-06-17 pon 20:51, when Lennart Poettering wrote:
 On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
 wrote:

 On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote:
 We are converting some daemons to socket activation. Most of them
 open unix sockets and manage incoming connections in a main-loop, so
 the easiest way to convert it is to create Accept=false socket with
 systemd.

 Now, it is quite well described how to start such daemon, however,
 there is little about shutting it down. Should the daemon close(2)
 the received sockets? Should it unlink(2) them from a filesystem?
 close() yes, unlink() no.

 Strictly speaking you don't even have to do that. The kernel will
 clean up left-over fds when your process exits, hence you don't have
 to close it explicitly.

 But you certainly should not unlink() the socket in the fs, because
 then the socket will not be accessible anymore.

 Maybe I've asked the wrong question. I should rather have asked: Can I
 close? Can I unlink? Because that's what the code does now and we wanted
 to know which parts are common for standalone and
 systemd-socket-activated paths.

The way I think about it is that if you are socket activated, you have
a .socket unit and a .service unit.

The .socket unit controls the socket. The .service unit does NOT
control the socket. Therefore, the .service daemon should NOT unlink
the socket.

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

Re: [systemd-devel] Patch for Smack labelling support in udev

[Kok, Auke-jan H]

On Mon, Jun 17, 2013 at 9:37 PM, Kyungmin Park kmp...@infradead.org wrote:
 Hi Elena,

 On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com) wrote:

 Hi,

 This is the patch for review for enabling smack labelling for device nodes.

 The functionality and reasoning is inside. I will be happy to answer any
 questions.

 So, this needs some HAVE_SMACK ifdeffery at least.

 That said, I wonder if we should instead make this a generic
 XATTR{foobar}=waldo thing. Kay?


 Any update for this? if we use SMACK for udev, it requires it.

Lennart's suggestion seems more than reasonable - it would make it
generic enough to do:

   XATTR{security.SMACK64}=label

which I think is all we need here. Elena, do you need help respinning this?

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

Re: [systemd-devel] Tuning A/V at Boot

[Kok, Auke-jan H]

On Sat, Jun 8, 2013 at 5:43 PM,  systemdki...@yopmail.com wrote:
 Where in boot sequence tune A/V latency? Is sound.target relevant?

anything device specific should be triggered from a udev rule, so that
you're not running this service while the device isn't actually
available yet to userspace...

systemd already installs a 99-systemd.rules file that has:

SUBSYSTEM==sound, KERNEL==card*, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=sound.target

So linking your service file into sound.target.wants should work.
(but, I haven't tested this particular case or taget myself).

you probably want to do:

# mkdir /etc/systemd/system/sound.target.wants
# ln -sf /path/to/your.service
/etc/systemd/system/sound.target.wants/your.service


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

Re: [systemd-devel] [PATCH 1/2] analyze: show generators on plot

[Kok, Auke-jan H]

On Sun, Jun 2, 2013 at 2:40 AM, Thomas H.P. Andersen pho...@gmail.com wrote:
 On Wed, May 15, 2013 at 5:09 PM, Kok, Auke-jan H
 auke-jan.h@intel.com wrote:
 On Wed, May 15, 2013 at 3:20 AM, Thomas H.P. Andersen pho...@gmail.com 
 wrote:
 For completeness here is also a screenshot of how the generators are
 shown in the plot. (The plot was generated on an old computer with a
 HDD)

 very nice!

 Do you think this is something we want to commit?

Absolutely - do you want to commit it yourself? If not, I'll be happy to do so.

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

Re: [systemd-devel] Automatic Reboot Protocol [SOLVED]

[Kok, Auke-jan H]

On Thu, May 30, 2013 at 9:34 PM,  systemdki...@yopmail.com wrote:
 Simple at did the trick from nightjanitor.sh

   echo systemctl start reboot.target | at now + 3 min

 If a more purist systemd method exists, I'd love to see it.

You can likely create a timer unit, and start that once...

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

Re: [systemd-devel] [PATCH] Delay dbus connection for user session

[Kok, Auke-jan H]

On Tue, May 28, 2013 at 3:00 AM, Chengwei Yang chengwei.y...@intel.com wrote:
 Currently, if we have a user session, when systemd user session start,
 just like the situation for it as PID 1, dbus-daemon isn't ready at that
 moment, so it always failed with below error.

 Feb 06 16:50:10 localhost.localdomain systemd[417]: Failed to open
 private bus connection: Failed to connect to socket
 /run/user/app/dbus/user_bus_socket: No such file or directory

 Signed-off-by: Chengwei Yang chengwei.y...@intel.com
 ---
  src/core/manager.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/core/manager.c b/src/core/manager.c
 index 0508628..467b5ba 100644
 --- a/src/core/manager.c
 +++ b/src/core/manager.c
 @@ -503,7 +503,7 @@ int manager_new(SystemdRunningAs running_as, Manager 
 **_m) {
  goto fail;

  /* Try to connect to the busses, if possible. */
 -r = bus_init(m, running_as != SYSTEMD_SYSTEM);
 +r = bus_init(m, running_as != SYSTEMD_SYSTEM  running_as != 
 SYSTEMD_USER);
  if (r  0)
  goto fail;

So, I've looked at this code again as I've spotted this problem over a
year ago, and I'm wondering if this entire section should just be
removed, since running_as only has 2 values (_SYSTEM and _USER)
anyway...

Would there be any objection to just dropping these 4 lines entirely?
Lennart, Kay? I don't see how we'd have a 3rd manager type here.


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

Re: [systemd-devel] [PATCH] [Fix] Do not handle SIGKILL since we can not

[Kok, Auke-jan H]

On Mon, May 20, 2013 at 12:22 AM, Chengwei Yang chengwei.y...@intel.com wrote:
 This is a minor fix because it's not a major issue, this fix just avoid
 to get EINVAL error from sigaction(2).

 There are two signals can not handled at user space, SIGKILL and
 SIGSTOP even we're PID 1, trying to handle these two signals will get
 EINVAL error.

 There are two kinds of systemd instance, running as system manager or
 user session manager, apparently, the latter is a general user space
 process which can not handle SIGKILL. The special pid 1 also can not
 do that refer to kernel/signal.c:do_sigaction().

 However, pid 1 is unkillable because the kernel did attach
 SIGNAL_UNKILLABLE to it at system boot up, refer to
 init/main.c:start_kernel()
 -- rest_init()
 -- kernel_thread()
 -- kernel_init()
 -- init_post()
 current-signal-flags |= SIGNAL_UNKILLABLE

 Signed-off-by: Chengwei Yang chengwei.y...@intel.com
 ---
  src/core/main.c  |1 -
  src/shared/def.h |2 +-
  2 files changed, 1 insertion(+), 2 deletions(-)

 diff --git a/src/core/main.c b/src/core/main.c
 index 7fc06be..8059f6a 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1408,7 +1408,6 @@ int main(int argc, char *argv[]) {
  /* Reset all signal handlers. */
  assert_se(reset_all_signal_handlers() == 0);

 -/* If we are init, we can block sigkill. Yay. */
  ignore_signals(SIGNALS_IGNORE, -1);

  if (parse_config_file()  0)
 diff --git a/src/shared/def.h b/src/shared/def.h
 index 5ba170f..5abb544 100644
 --- a/src/shared/def.h
 +++ b/src/shared/def.h
 @@ -32,4 +32,4 @@
  #define SYSTEMD_CGROUP_CONTROLLER name=systemd

  #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
 -#define SIGNALS_IGNORE SIGKILL,SIGPIPE
 +#define SIGNALS_IGNORE SIGPIPE

Ok, looks fine to me. Was there an error printed by user sessions?

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

Re: [systemd-devel] [PATCH] Make it possible to disable smack separately from xattr support

[Kok, Auke-jan H]

On Thu, May 16, 2013 at 1:40 AM, Karol Lewandowski
k.lewando...@samsung.com wrote:
 Additionally, compile out rule loading if feature is disabled.
 ---
  configure.ac   |   26 ++
  src/core/smack-setup.c |   10 ++
  src/core/socket.c  |4 ++--
  3 files changed, 38 insertions(+), 2 deletions(-)


Thanks, applied!

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

Re: [systemd-devel] [PATCH 1/2] analyze: show generators on plot

[Kok, Auke-jan H]

On Wed, May 15, 2013 at 3:20 AM, Thomas H.P. Andersen pho...@gmail.com wrote:
 For completeness here is also a screenshot of how the generators are
 shown in the plot. (The plot was generated on an old computer with a
 HDD)

very nice!

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

Re: [systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack

[Kok, Auke-jan H]

On Wed, May 8, 2013 at 8:20 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Wed, May 08, 2013 at 11:42:34AM -0700, Kok, Auke-jan H wrote:
 On Tue, May 7, 2013 at 5:29 AM, Karol Lewandowski
 k.lewando...@samsung.com wrote:
  On 05/07/2013 01:32 PM, Lennart Poettering wrote:
  On Tue, 07.05.13 13:21, Karol Lewandowski (k.lewando...@samsung.com) 
  wrote:
 
  Heya,
 
  Hmm, does that directory always exist? Or only if AppArmor is actually
  runtime enabled?
 
  /sys/fs/smackfs is only registered when smack lsm is actually enabled:
 

  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smackfs.c?id=e93072374112db9dc86635934ee761249be28370#n2179
 
  I.e. this check should ideally only return true if SMACK is not only
  built into the kernel, but actually really enabled during
  runtime. That's what the SELinux check does and what the most useful
  semantics are.
 
  Ok, I see that libselinux will consider selinux to be disabled also when
  policy is not loaded:
 

  http://userspace.selinuxproject.org/trac/browser/libselinux/src/enabled.c#L12
 
  I guess we could do something similar (inspect /proc/self/attr/current)
  but honestly, I don't think it's really needed.  Rafał, could you correct 
  me
  if I'm wrong?

 smack is different as in that it can function without any loaded
 policies, so looking at policies isn't the right thing for smack. So
 likely looking at the presence of smackfs is exactly the same as
 looking at the preference of /proc/self/attr/current, except the
 latter is more complex, so less desirable imho.
 Applied, with a commit message based on this explanation.

FYI, I just added similar code for IMA allowing ConditionSecurity=ima.

I will take the AR to ask our Intel security folks if we don't need to
do more - as in
verify that IMA actually has a policy loaded, but the policy interface for IMA
is write-only, so there is no way to find out if a policy was
previously written.

Cheers,

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

Re: [systemd-devel] [ANNOUNCE] systemd 204

[Kok, Auke-jan H]

On Thu, May 9, 2013 at 8:56 AM, Lennart Poettering
lenn...@poettering.net wrote:

 CHANGES WITH 204:
 * ConditionSecurity= gained support for detecting SMACK. Since
   this condition already supports SELinux and AppArmor we only
   miss IMA for this. Patches welcome!

I just merged a minimal patch to support this (in a similar way that
apparmor is done).

Cheers,

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

Re: [systemd-devel] systemd user instance

[Kok, Auke-jan H]

On Mon, May 6, 2013 at 2:44 PM, Kai Krakow hurikha...@gmail.com wrote:
 Hey list,

 I've built a server with systemd and it really worked out well. Fast booting
 (that means shorter maintenance times) and most important: Reliable service
 teardown and auto-restarts of crashed services. And yeah, I love the
 journal. I'm logging everything there.

 But now I want to (and need to) give some users cron-like abilities. I
 discovered that systemd supports user instances - perfect!

 So I enabled a session service for one user (actually, that's me):

 # sudo systemctl enable user@kakra.service

 But I cannot start it, and the user can neither. Starting it states in the
 journal:

 # sudo systemctl start user@kakra.service

 May 06 23:35:00 vweb002.jugendinfo.de systemd[1]: Starting User Manager for
 root...
 -- Subject: Unit user@kakra.service has begun with start-up
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 --
 -- Unit user@kakra.service has begun starting up.
 May 06 23:35:00 vweb002.jugendinfo.de systemd[4438]: Failed at step PAM
 spawning /usr/lib/systemd/systemd: Operation not permitted
 -- Subject: Process /usr/lib/systemd/systemd could not be executed
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 -- Documentation:
 http://www.freedesktop.org/wiki/Software/systemd/catalog/641257651c1b4ec9a8624d7a40a9e1e7
 --
 -- The process /usr/lib/systemd/systemd could not be executed and failed.
 --
 -- The error number returned while executing this process is 1.
 May 06 23:35:00 vweb002.xx.de systemd[1]: Started User Manager for root.
 -- Subject: Unit user@kakra.service has finished start-up
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 --
 -- Unit user@kakra.service has finished starting up.
 --
 -- The start-up result is done.

 Why does it say Starting user manager for root (and not my username) and
 why does it fail with pam? If I start systemd --user , then I can enable
 and run the user services defined in .config/systemd.

 The server is running Gentoo with systemd-201. Here's the systemd unit:

 kakra@vweb002 ~ $ cat /etc/systemd/system/user\@kakra.service
 #  This file is part of systemd.
 #
 #  systemd is free software; you can redistribute it and/or modify it
 #  under the terms of the GNU Lesser General Public License as published by
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.

 [Unit]
 Description=User Manager for %u
 After=systemd-user-sessions.service

 [Service]
 User=%I
 PAMName=systemd-shared

^^ this line is the cause of your problems, as the
/etc/pam.d/systemd-shared file does not exist.

 # in order to allow MEM_CG features to work, add memory:/ here
 ControlGroup=%R/user/%u/shared cpu:/
 ControlGroupModify=yes
 Type=notify
 ExecStart=-/usr/lib/systemd/systemd --user
 Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket

 [Install]
 Alias=user@%i.service


 # as user:
 # systemctl start user@kakra.service
 Failed to issue method call: Access denied


 kakra@vweb002 ~ $ cat /etc/pam.d/system-auth
 authrequiredpam_env.so
 authrequiredpam_unix.so try_first_pass likeauth nullok
 authoptionalpam_permit.so

 account requiredpam_unix.so
 account optionalpam_permit.so

 passwordrequiredpam_cracklib.so difok=2 minlen=8 dcredit=2
 ocredit=2 retry=3
 passwordrequiredpam_unix.so try_first_pass use_authtok
 nullok sha512 shadow
 passwordoptionalpam_permit.so

 session requiredpam_limits.so
 session requiredpam_env.so
 session requiredpam_unix.so
 session optionalpam_permit.so

 session optionalpam_loginuid.so
 session optionalpam_systemd.so


You can copy /etc/pam.d/login to /etc/pam.d/systemd-shared, and then
things should somewhat work. Additionally, you may want to copy the
dbus user session service files from
github.com/sofar/user-session-units to get user based dbus services
working.

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

Re: [systemd-devel] [PATCH] Dynamically allocate bootchart logs

[Kok, Auke-jan H]

On Fri, May 3, 2013 at 9:14 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 25.04.13 22:47, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:

 On Wed, Apr 24, 2013 at 5:20 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Wed, Apr 24, 2013 at 04:26:12PM -0700, Nathaniel Chen wrote:
  Instead of storing bootchart sample data in arrays, this patch moves
  storage to linked lists so that there is no more limit on samples.
 
  How does this approach compare to greedy_realloc?

 One of the problems with the static arrays is that it was inherently
 allocating way too much memory to begin with. Most tasks live much
 less time than (samples * interval), the rest of the array space is
 just wasted.

 The linked list approach drives down this memory requirement and makes
 navigating all the data much more straightforward. I also much prefer
 head pointers instead of having index numbers around.

 Still sounds like greedy_realloc() is what you want here. Storing sample
 data in a dynamically increasing array sounds much more natural than a
 linked list.

I admit I hadn't heard of greedy_realloc() unti Zbigniew mentioned it,
and I still fail to see why it would be so much better other than you
can access members by index. You're still doing an allocation each
time you extend the array (unless you're doing tricks and
preallocate).

The arrays are also sparse: most likely ps[0]...ps[N] will never be
used since at the start (0) only very few processes exist - can
greedy_realloc() handle large unallocated parts at the start of the
array? That doesn't seem likely. Unless we re-index them where 0 means
first sample found, but that means all sorts of extra math
determining where each sample lines up in time...

The lists are cross-linked, so even if one way we're making them an
array again, we'd be walking them as a linked list in the other way
for efficiency...

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

Re: [systemd-devel] [PATCH] Add help option to bootchart man page

[Kok, Auke-jan H]

On Fri, Apr 26, 2013 at 9:36 AM, Nathaniel Chen
nathaniel.c...@intel.com wrote:
 Bootchart has a help option. For the sake of consistency, this patch
 adds it to the man page.

 Also, the TODO is updated. Bootcharts were added to the journal in
 commit c4d58b0.

applied, thanks.

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

Re: [systemd-devel] [PATCH] Dynamically allocate bootchart logs

[Kok, Auke-jan H]

On Wed, Apr 24, 2013 at 4:26 PM, Nathaniel Chen
nathaniel.c...@intel.com wrote:
 Instead of storing bootchart sample data in arrays, this patch moves
 storage to linked lists so that there is no more limit on samples.

 This patch also fixes parsing of /proc/pid/smaps in kernels  3.7.
 ---
  src/bootchart/bootchart.c |  48 --
  src/bootchart/bootchart.h |  23 ++-
  src/bootchart/store.c |  96 ---
  src/bootchart/store.h |   3 +-
  src/bootchart/svg.c   | 410 
 +++---
  5 files changed, 437 insertions(+), 143 deletions(-)
  mode change 100644 = 100755 src/bootchart/store.c

Applied!

I added an extra commit cleaning up MAXSAMPLES and 2 structs from
bootchart.h. :^)

Thanks for being around for 4 months on your internship - it was fun
working with you!

Cheers,

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

Re: [systemd-devel] [PATCH] Dynamically allocate bootchart logs

[Kok, Auke-jan H]

On Wed, Apr 24, 2013 at 5:20 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Wed, Apr 24, 2013 at 04:26:12PM -0700, Nathaniel Chen wrote:
 Instead of storing bootchart sample data in arrays, this patch moves
 storage to linked lists so that there is no more limit on samples.

 How does this approach compare to greedy_realloc?

One of the problems with the static arrays is that it was inherently
allocating way too much memory to begin with. Most tasks live much
less time than (samples * interval), the rest of the array space is
just wasted.

The linked list approach drives down this memory requirement and makes
navigating all the data much more straightforward. I also much prefer
head pointers instead of having index numbers around.

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

Re: [systemd-devel] Question about the cross session dependence

[Kok, Auke-jan H]

On Sun, Apr 21, 2013 at 6:49 PM, Li, Min A min.a...@intel.com wrote:
 Hi systemd experts,



 I have a question about the dependence of user and system session. At system
 session, there is a service which need to be started after X(user session).

 At first I added “After=xorg.target” at this service, but It is said that
 the dependence of cross session is not work. Is that true?

The user session instance does not know anything about the state of
system services. So yes.

 If Yes, what’s the solution for this kind of issue?

If you start your xorg through systemd --system, you will have to find
an alternative way to tell the systemd --user how to determine that
the service is ready. You can make a hack with a path unit, or write a
user session service that uses IPC to communicate with the system
session in some way. Nobody has looked at that, afaik.

This is why user-session-units starts the X server from within the
systemd --user environment - it removes that problem entirely.

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

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

[Kok, Auke-jan H]

On Mon, Apr 22, 2013 at 3:26 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 22.04.2013 23:53, schrieb Josh Triplett:
 1) Leave only root in /etc/passwd and /etc/group

 why?

 2) Add passwd.d and group.d directories in /etc and under /usr, which
accept one record per file (with name given by the filename) and
which do not include UIDs or GIDs

 to break any compatibility?

 4) When the .d file goes away, and nothing uses the UID or GID anymore,
throw it at the back of the list of IDs to reuse

 oh yeah - break any known user management

 hence there are networks where admins since forever
 take care that user-id's uniqe all over the machine
 and you propose reuse?

 well, you have a solution in search of a problem

It's ok if you don't understand the proposal, but there's no reason to
post random uninformed criticism, now you're creating a rumor that
something like this, if implemented, would break all user management.
You don't know this. It doesn't exist yet. Maybe it will be 100%
backward compatible. Why wouldn't it be? Maybe it won't even go
anywhere because people who do understand the topic can assess it's
viability.

Can you please just wait and see if this goes anywhere concrete first?

Thanks,


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

Re: [systemd-devel] Fwd: [systemd-commits] Makefile.am src/bootchart - Make bootcharts go to the journal

[Kok, Auke-jan H]

On Tue, Apr 16, 2013 at 1:47 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Kok, Auke-jan H at 16/04/13 00:33 did gyre and gimble:
 FYI - this is a first pass to putting the bootcharts into the journal,
 exactly as coredump does. Ultimately, I will probably make bootcharts
 not go to disk other than the journal by default.

 A single one-liner can be used to get the latest bootchart automatically:

 $ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518
 --field=BOOTCHART  bootchart.svg

 Just out of curiosity, what is the rational behind doing this? I think
 it's really cool that we can store arbitrary things in the journal, but
 I have concerns about storing potentially large stuff in there. The
 bootchart is likely not that big, but especially with coredumps (which
 has patches now thankfully) a small period of dump frenzy can fill up
 your logs and cause rotation. This could be exploited at some point in
 the future by an attacker to cover their tracks making you think some
 software had just gone haywire when reviewing your (rotated) journals.

 Was there anything particularly wrong or problematic previously with
 writing out to a file? Other than a log of previous boots, what
 advantage does it have to keep them in the journal?

 I'm mostly playing devils advocate here. I do kinda like the fact it's
 in there personally, but then I like shiny things.

There's a few reasons why in this case I think it's good:

- bootchart is optional
- the value of comparing bootcharts to previous bootcharts is
extremely high (single bootcharts are of less value unless you can
compare them)
- it compresses well (it's not compressed right now, but it should be
easy to enable compression) and so it doesn't use that much space. My
100 bootcharts compressed from 75M to 5.9M with xz.
- you can only reboot that often. Even on my developer system that I
reboot often I still only had 100 bootcharts between june 2012 and
today (and that system generates a bootchart on every boot by default)

There's also the fact that the journal will rotate things away. If you
don't log persistently, your bootcharts also won't be retained, etc.

Ultimately, we don't want to put more files in /var/log or /run/log at
all, and the journal seems the best place to put things like this.

And that goes for a lot more things too.


Auke

PS: I would love to see a generic retreive attachment function to
journalctl - something where we can pre-define attachment types that
are known in an array (coredumps, bootcharts, the likes) and do
something like `journalctl extract --type=all|bootchart|coredump
`. It seems silly that we have coredumpctl implement this
generically but only for coredumps, and should just live in
journalctl.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to run *ctl command using systemd-nspawn

[Kok, Auke-jan H]

On Tue, Apr 16, 2013 at 12:11 AM, Koen Kooi k...@dominion.thruhere.net wrote:
 Hi,

 To help with flashing the onboard eMMC of a 10 boards I'm using 
 systemd-nspawn to run package postinstall scripts that generate UUIDs and 
 some other things and it's working great for that! Every board now has a 
 unique value in /etc/machine-id instead it being empty and systemd 
 randomizing it on startup.

 What doesn't work however is something like this:

 systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone 
 Europe/Paris

 or this:

 systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname 
 BeagleBoneBlack

 I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the 
 name into /etc/hostname, but I'd like to use the *ctl commands because they 
 work and have error handling built-in.
 it looks like I would need -b to get the *ctl commands to work, but -b 
 doesn't support running single commands and exiting.

 My goal is to be able to drop in a rootfs tarball and change timezone and 
 hostname settings in a config file for the flasher script and avoid 
 generating N different tarballs. For use in the office lab I use something 
 like [1] to generate the hostnames based on board revision and serial number.

 So, is there a way to *ctl command using systemd-nspawn in a rootfs that 
 wasn't specially prepared (e.g. helper units/targets) for that?

crazy thought, but, for completeness, there should probably be
equivalent handling of init=/path/to/alternative/init in
systemd-nspawn

also the man page shows what you want should just work:

SYNOPSIS
   systemd-nspawn [OPTIONS...] [COMMAND] [ARGS...]

but I guess there's some issues there.

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

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Sun, Apr 14, 2013 at 2:15 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 14.04.2013 23:06, schrieb Kok:

 [Unit]
 Description=Adaptive readahead daemon

 [Service]
 ExecStart=/usr/sbin/preload -f 1 -l 
 Restart=always
 RestartSec=1
 Nice=19
 IOSchedulingClass=3

 [Install]
 WantedBy=multi-user.target
 

 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.

The daemon doesn't need to do extra work to fork, and systemd won't
need to do all the work associated with tracking a forked process -
it's a lot less work, thus more efficient, and actually more robust.

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

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Mon, Apr 15, 2013 at 10:59 AM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 15.04.2013 19:53, schrieb Kok:
 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.

 The daemon doesn't need to do extra work to fork, and systemd won't
 need to do all the work associated with tracking a forked process -
 it's a lot less work, thus more efficient, and actually more robust

 hi

 does this mean in recent systemd-versions it is no longer needed
 to use Type=forking at all while it was a must for some servcies
 in early versions?

no, which is why I added the '-f' flag to the preload startup in the
service unit that I posted (it keeps preload running in the
foreground).

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

[systemd-devel] Fwd: [systemd-commits] Makefile.am src/bootchart - Make bootcharts go to the journal

[Kok, Auke-jan H]

FYI - this is a first pass to putting the bootcharts into the journal,
exactly as coredump does. Ultimately, I will probably make bootcharts
not go to disk other than the journal by default.

A single one-liner can be used to get the latest bootchart automatically:

$ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518
--field=BOOTCHART  bootchart.svg

Auke


-- Forwarded message --
From: Auke-Jan Kok a...@kemper.freedesktop.org
Date: Mon, Apr 15, 2013 at 4:29 PM
Subject: [systemd-commits] Makefile.am src/bootchart
To: systemd-comm...@lists.freedesktop.org


 Makefile.am   |3 +-
 src/bootchart/bootchart.c |   53 ++
 2 files changed, 55 insertions(+), 1 deletion(-)

New commits:
commit c4d58b0b6d238b955ece39a9dd9d3ca84b3408f3
Author: Auke Kok auke-jan.h@intel.com
Date:   Mon Apr 15 16:23:42 2013 -0700

bootchart: put the bootchart into the journal.

This bit of code is mostly stolen from coredump.c. We construct
a simple journal message and append the bootchart file in the
journal automatically.

You can extract the latest bootchart from the current boot with
something like:

$ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518
--field=BOOTCHART

which prints it to stdout.

None of the other logic is touched. The journal entry is created
even if bootchart was run manually, which is probably wrong.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Sun, Apr 14, 2013 at 9:13 AM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 14.04.2013 06:42, schrieb Kok:
 On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 - extend the collector to run much longer

 which scre to change in teh config?

 You can modify systemd-readahead-done.timer, basically change:

 OnActiveSec=10s

 to whatever value you like

 thanks, i give it a try with 3600 seconds what should cover
 also a long coffee and mostly powner on with WOL and sync
 work-data while drive to the office

take care that the new readahead file only gets written at the end of
the 3600s, it's not updated continuously.

 is there any way to get informations what is collected
 and where are the informations stored?

$ man systemd-readahead

you can run

$ /usr/lib/systemd/systemd-readahead analyze

to see what's in the readahead file.

 a reason i would love to define specific applications which should
 always get preloaded on boot independent what is collected at runtime
 what about starting the machine remove vis WOL and never login because
 some data sync and shutdown 2 hours later - will the desktop get lost
 from the readahead-collection - questions over questions...

feel free to contribute code or algorithm's to improve, I'll be more
than welcome to take concrete contributions as I've been trying to
improve on readahead for several years now. There is certainly room
for improvement, but the devil is in the details.

Cheers,

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

Re: [systemd-devel] systemd-readahead - stops after 2 minutes

[Kok, Auke-jan H]

On Sun, Apr 14, 2013 at 10:18 AM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 14.04.2013 18:13, schrieb Reindl Harald:
 Am 14.04.2013 06:42, schrieb Kok:
 You can modify systemd-readahead-done.timer, basically change:

 OnActiveSec=10s

 to whatever value you like

 thanks, i give it a try with 3600 seconds what should cover
 also a long coffee and mostly powner on with WOL and sync
 work-data while drive to the office

 seems like i covered a bug
 the collector stops after exactly 2 minutes

src/readahead/readahead.c has:

usec_t arg_timeout = 2*USEC_PER_MINUTE;

so, it's by design to stop after 2 minutes.

That's for a good reason, I'm not sure if changing it makes much sense
- most people will never want to use non-standard values, and 2
minutes helps everyone (it could help some non-standard cases more,
but it doesn't hurt anyone).

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

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 14.04.2013 20:49, schrieb Kok:
 a reason i would love to define specific applications which should
 always get preloaded on boot independent what is collected at runtime
 what about starting the machine remove vis WOL and never login because
 some data sync and shutdown 2 hours later - will the desktop get lost
 from the readahead-collection - questions over questions...

 feel free to contribute code or algorithm's to improve, I'll be more
 than welcome to take concrete contributions as I've been trying to
 improve on readahead for several years now. There is certainly room
 for improvement, but the devil is in the details

 if i only could C/C++ additionally to PHP/SQL and had time to
 work that out by 3 fulltime-jobs for one man :-(

 playing around with /usr/lib/systemd/systemd-readahead collect
 it looks like it re-creates /.readahead from scratch, meaning
 you lose also anything covered from the boot-run

 what about a dbus-triggered instance like cups and other services
 are fired up after login which creates a /.readahead-usersession
 proceeded at boot the same way as /.readahead

it does more damage to do excessive readahead at boot for services
that don't need to start until way, way after boot. The whole idea is
to only read things you are going to need, and not more. Otherwise you
could just read everything you can possibly read from disk into
memory.

 seems like i covered a bug
 the collector stops after exactly 2 minutes

 src/readahead/readahead.c has:

 usec_t arg_timeout = 2*USEC_PER_MINUTE;

 so, it's by design to stop after 2 minutes.

 That's for a good reason, I'm not sure if changing it makes much sense
 - most people will never want to use non-standard values, and 2
 minutes helps everyone (it could help some non-standard cases more,
 but it doesn't hurt anyone)

 well, but that makes systemd-readahead-done.timer useless as also
 extend how long the collector should run

most people won't ever need to have it run more than 10 seconds until
after the system is done booting, so it has good value. Longer isn't
better (see my earlier argument, which holds especially true for
rotating media).

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

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Sun, Apr 14, 2013 at 1:01 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 14.04.2013 21:18, schrieb Kok:
 On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 what about a dbus-triggered instance like cups and other services
 are fired up after login which creates a /.readahead-usersession
 proceeded at boot the same way as /.readahead

 it does more damage to do excessive readahead at boot for services
 that don't need to start until way, way after boot. The whole idea is
 to only read things you are going to need, and not more. Otherwise you
 could just read everything you can possibly read from disk into
 memory

 oh, now i realized that systemd-readahead covers any file-type
 surely it would be bad preloading anything including data

 please have a look at 
 http://koji.fedoraproject.org/koji/buildinfo?buildID=393183
 this is covering only libraries but seems to be in a bad maintaining-state
 because still no systemd-unit and all of te last updates where auto 
 mass-rebuilds

 i wrote a systemd-unit for my machine which starts after kdm.service
 https://bugzilla.redhat.com/show_bug.cgi?id=951956

that unit file should just go into the project upstream, I'd also
suggest removing the kdm dependency, running with -f, making log
output go to stdout and removing the Type=forking, so it becomes:



[Unit]
Description=Adaptive readahead daemon

[Service]
ExecStart=/usr/sbin/preload -f 1 -l 
Restart=always
RestartSec=1
Nice=19
IOSchedulingClass=3

[Install]
WantedBy=multi-user.target

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

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote:
 Hi

 as far as i understand systemd-readahead is catching what is
 loaded directly due boot and 10 seconds after, well that's fine

 but is there a possibility to feed it with additional applications?

 example of the real life here:

  * the machine get powered on in the morning
  * due this sitting in the kitchen with a coffee
  * after that login in KDE, plasma and kopete are started
  * finally Thunderbird and Firefox are started
  * mostly Eclipse is the next
  * the machine has 16 GB RAM

 it would make pretty much sense that Thunderbird, Firefox and
 so on are pre-loaded or at least their libraries after the
 login-manager appears to use the time between boot and login

A lot of things are possible and would help this:

- change your system to auto-logon your account and start the
applications for you. This is possible without any coding.

- do per-user readahead, so that when a user logs in readahead-collect
runs again but with a different pack, stored in the users home folder.
Most of this should be possible with little work, but you'd have to
write some xdg autostart files and possibly patch the readahead

- extend the collector to run much longer

- manually create a pack and disable the collector

one of the problems is that it's hard to create something that
generally works well for all situations, and autologon+lock desktop
benefits from simplicity since readahead catches almost all of it.

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

Re: [systemd-devel] systemd-readahead and often used applications

[Kok, Auke-jan H]

On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 13.04.2013 23:08, schrieb Kok:
 On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 it would make pretty much sense that Thunderbird, Firefox and
 so on are pre-loaded or at least their libraries after the
 login-manager appears to use the time between boot and login

 A lot of things are possible and would help this:

 - change your system to auto-logon your account and start the
 applications for you. This is possible without any coding.

 well, that's a no-go

 - do per-user readahead, so that when a user logs in readahead-collect
 runs again but with a different pack, stored in the users home folder.
 Most of this should be possible with little work, but you'd have to
 write some xdg autostart files and possibly patch the readahead

 - extend the collector to run much longer

 which scre to change in teh config?

You can modify systemd-readahead-done.timer, basically change:

OnActiveSec=10s

to whatever value you like.


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

Re: [systemd-devel] Socket is dying, how to automatically restart it?

[Kok, Auke-jan H]

On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi k...@dominion.thruhere.net wrote:

 Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas graw...@gmail.com het 
 volgende geschreven:

 On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi k...@dominion.thruhere.net 
 wrote:
 Hi,

 I have a bit of a heisenbug where dropbear.socket will just die and needs a 
 systemctl restart dropbear.socket. I can't tell why it's dying, just that 
 it does within 3 days of uptime. After restarting it it seems to be rock 
 solid again for at least some weeks.

 The real way to fix this is to find out why it dies,

 After death, does `systemctl status dropbear.socket` show any error
 messages in the status line?

 No, only that it's dead, so systemd knows that it's has failed somehow

dead isn't necessarily the same as failed... and I wonder if you
can use ExecStartPost= here to kick it - it's valid for [Socket]
sections.

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

Re: [systemd-devel] Socket is dying, how to automatically restart it?

[Kok, Auke-jan H]

On Wed, Apr 10, 2013 at 1:12 PM, David Strauss da...@davidstrauss.net wrote:
 Are you sure it's not the corresponding service that really failed?

actually, that's a good point, but if the socket unit is dead, I
assume that systemd no longer is bind()ed to the ports...

Koen, can you verify that that is the case?

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

Re: [systemd-devel] dbus user services using the session bus

[Kok, Auke-jan H]

On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson wstephen...@kde.org wrote:

 I'm joining the flock of desktop people investigating using systemd to start 
 a desktop session.  So far I've checked out user-session-units and have 
 created some more granular unit files that will do a native systemd start 
 rather than u-s-u's wrapper around the upstream start script.

As Tom asked, I'm interested in these changes as well - do you have
your code posted somewhere?

Also, you're saying there's a start script somewhere, can you tell
me what you mean by that?

I don't understand what you refer to by wrapper, either. Technically
user-session-units doesn't wrap anything, it just provides straight
unit files. One of them is derivative of user@.service from systemd,
sure.

 I'm stuck now, because I want to start a service with Type=dbus that puts a 
 service on the session bus, however, I can't see a way to specify the bus in 
 the unit file.

you can insert variables into the user session by `systemctl --user
set-environment DBUS_S`. This is the only way to globally assign a
dbus address to the session, but you'll have to do it before any
significant service runs in the first place, which includes before
dbus starts.

 I don't want to use dbus activation here to start the service as that invokes 
 the chicken-egg problem that the service in question (kdeinit) job is to 
 start all the processes that will be calling it via dbus later. Long term I 
 would like to do away with this and perform this task via systemd too, but 
 Type=dbus on the session bus seems like a valid use case that should work.

 I see there's a way to get the dbus session bus address into systemd because 
 of the patch to fix this in user-session-units; would the right approach be 
 to add a BusInstance= field to service and use the provided session bus 
 address when watching for Type=dbus services that depend on user/dbus.service?

all of this stuff seems to work just fine with user-session-units - of
course the login/DM integration is wholly missing right now, but could
you start with user-session-units and make modifications to get where
you want?

Cheers,


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

Re: [systemd-devel] dbus user services using the session bus

[Kok, Auke-jan H]

On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco m...@0x01b.net wrote:
 Here are my user session units. I have a few dbus activated examples

 https://github.com/mmonaco/systemd-user-session

 I have one target for an i3 session and another for an openbox/cairo-dock
 session. I can freely switch between them without losing my active windows. 
 I'll
 be testing gnome-3.8 soon so I'll be adding something that uses gnome-session.

Would you be willing to contribute some of these (the dbus activation
units for instance) back to user-session-units? There are quite a few
folks using work based on user-session-units (a few distro's package
it) and getting these in a central repository would help a lot of
folks.

Thanks,

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

Re: [systemd-devel] dbus user services using the session bus

[Kok, Auke-jan H]

On Wed, Apr 3, 2013 at 1:28 PM, Tom Gundersen t...@jklm.no wrote:
 On Wed, Apr 3, 2013 at 9:43 PM, Kok, Auke-jan H
 auke-jan.h@intel.com wrote:
 On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco m...@0x01b.net wrote:
 Here are my user session units. I have a few dbus activated examples

 https://github.com/mmonaco/systemd-user-session

 I have one target for an i3 session and another for an openbox/cairo-dock
 session. I can freely switch between them without losing my active windows. 
 I'll
 be testing gnome-3.8 soon so I'll be adding something that uses 
 gnome-session.

 Would you be willing to contribute some of these (the dbus activation
 units for instance) back to user-session-units? There are quite a few
 folks using work based on user-session-units (a few distro's package
 it) and getting these in a central repository would help a lot of
 folks.

 Auke,

 On a somewhat related note, any thoughts on merging
 user-session@.service back into user@.service upstream? Is there
 anything holding this back, except for lack of reviews?

two things I'd like to solve before they are basically identical:

1) setting DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR and friends,
if needed. We should probably have the xorg.service use `systemctl
--user set-environment DISPLAY ...` or use another method to feeding
the user session the proper DISPLAY (for e.g. gdm users, through
loginctl).

2) figure out what to put in /etc/pam.d/systemd-shared. This file is
currently not shipped at all by systemd but user@.service refers to
it, and without at least including pam_systemd.so things are going to
not work. Should we make this include pam_env.so? any others?

nothing is holding it back, really, just time and creativity to come
to good solutions.

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

Re: [systemd-devel] [PATCH] [RFCv4] Add Listen* to dbus properties

[Kok, Auke-jan H]

On Tue, Apr 2, 2013 at 6:29 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Apr 02, 2013 at 08:26:17AM +0200, Tomasz Torcz wrote:
 On Tue, Apr 02, 2013 at 05:54:32AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
  On Mon, Apr 01, 2013 at 11:09:45PM +0300, Oleksii Shevchuk wrote:
   sockets.socket - Test
   Loaded: loaded (/home/alxchk/.config/systemd/user/sockets.socket; 
   static)
   Active: inactive (dead)
   Listen: Stream: /tmp/stream1
   Stream: @stream4
  Pushed, but format changed to:
 
  listen1.socket - descr descr
   Loaded: loaded (/run/systemd/system/listen1.socket; 
  static)
   Active: failed (Result: resources)
 ListenStream: /tmp/stream1
   ListenDatagram: /tmp/stream2

   I must say I liked per-type grouping better.
 It *looked* better, but the ordering of sockets is important: it determines
 the order of fd's for the .service. For some applications it might not matter,
 but for simple ones it might, so it's better to preserve this information.

If ordering is important, the output should reflect the ordering. The
only way I can see that you could accomplish that unambiguously is by
numbering them. Sorting them will just leave people puzzled as to what
the order is.

So, consider adding some form of numbering to the list of listen
addresses. Perhaps something like:

 0: ListenStream: /tmp/stream1
 1: ListenDatagram: /tmp/stream2

Cheers,

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

Re: [systemd-devel] Optimizing systemd binaries for small deployments

[Kok, Auke-jan H]

On Wed, Mar 27, 2013 at 3:49 AM, Tino Breddin tbred...@tpip.net wrote:
 We are in the process of creating a very small image for devices with a 
 maximum of 4MB flash. Compared to a SysV variant which clocks in at ~1MB 
 using Systemd
 we are currently getting images sizes of ~10MB. At first glance the systemd 
 binaries seem quite large. Before diving into lots of optimization I wanted 
 to ask
 whether anybody has pointers we should follow or even experience using 
 systemd for bare minimum images.

Out of curiosity, but where does the consumed space actually sink
into? Could you post perhaps the equivalend of something like du or
list the top 20 largest items?

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

Re: [systemd-devel] A newbie question regarding ordering cycles

[Kok, Auke-jan H]

On Thu, Mar 28, 2013 at 7:07 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Belal, Awais at 28/03/13 12:22 did gyre and gimble:
 Hi Guys,

 Just a newbie question as I am not much familiar with systemd yet. While
 setting up a system I have systemd-195 running but some of the services
 are not launched properly. I get the following:

 *systemd[1]: Found ordering cycle on basic.target/start*
 *systemd[1]: Walked on cycle path to sockets.target/start*
 *systemd[1]: Walked on cycle path to dbus.socket/start*
 *systemd[1]: Walked on cycle path to sysinit.target/start*
 *systemd[1]: Walked on cycle path to run-postinsts.service/start*
 *systemd[1]: Walked on cycle path to basic.target/start*
 *systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start*
 *systemd[1]: Deleting job ofono.service/start as dependency of job
 dbus.socket/start*
 *systemd[1]: Deleting job dbus.service/start as dependency of job
 dbus.socket/start*
 *systemd[1]: Deleting job connman.service/start as dependency of job
 dbus.socket/start*

 Systemd is running in SysV compatibility mode. The odd thing here for me
 is once the system finishes booting I can see that dbus.service is up
 (through systemctl) but ofono and connman are never started although I
 can start them manually through systemctl.

  1. How can such problems be disected and is there a way for knowing the
 dependency graph?
  2. The ordering cycle was broken at dbus.socket/start, why aren't the
 other services tried out after that?

 BR,
 Awais


 As Frederic already said in his reply, I've found the most common case
 for ordering cycles is the lack of LSB headers in legacy sysvinit scripts.

 When there are no LSB headers systemd has to use the number in the
 symlink (the S??fooo bit) to determine the ordering.

 These orders frequently cause cycles.

 Another improvement to the cycle breaking logic could be to somehow boot
 out non-native units first (ideally non-LSB, followed by LSB, followed
 by native if sysvinit compatibility is compiled in).

 It's perhaps not overly clean to implement tho'.

 The cleanest solution is of course just to migrate away from sysvinit
 in any shape or form :)

BTW, both ofono and connman projects are systemd-enabled and will
install service files (check the configure flags) that should work
properly with systemd.

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

Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture

[Kok, Auke-jan H]

On Wed, Mar 27, 2013 at 12:22 AM, Tollef Fog Heen tfh...@err.no wrote:
 ]] Cristian Rodríguez

 El 26/03/13 15:17, Bill Nottingham escribió:
  Lukas Nykryn (lnyk...@redhat.com) said:
  ---
TODO  |  2 --
man/systemd.unit.xml.in   |  8 
src/core/condition.c  | 16 
src/core/condition.h  |  1 +
src/core/load-fragment-gperf.gperf.m4 |  1 +
5 files changed, 26 insertions(+), 2 deletions(-)
 
  Not that this seems wrong, but what is the usage case for this that
  can't be solved via package (de)installation?

 The patch looks fine to me, what it solves ? well.. there may be
 generic image deployments , who contain the same packages but one of
 them is only really useful in arch s390 or ppc.. etc..

 I think it should be kernel architecture if so, since you might very
 well have multiple userland architectures enabled and working at the
 same time.  (So it should be ConditionKernelArchitecture to make it
 clear.)

or should it?

on x86_64 one could have a kernel architecture supporting both x86_64
and i586, and running `setarch i586` does not change the kernel...

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

Re: [systemd-devel] [PATCHv2] man/os-release: Add BUILD_ID field

[Kok, Auke-jan H]

On Mon, Mar 25, 2013 at 2:07 PM, William Douglas
william.doug...@intel.com wrote:
 BUILD_ID is a fairly generic field used to identify the system image
 that was used to install the distribution.

 Signed-off-by: William Douglas william.doug...@intel.com
 ---
  man/os-release.xml | 22 ++
  1 file changed, 22 insertions(+)

merged, thanks.


I did remove the signed-off-by, which isn't needed.

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

Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media

[Kok, Auke-jan H]

On Wed, Mar 27, 2013 at 10:50 AM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
 On Wed, Mar 27, 2013 at 4:55 AM, Kay Sievers k...@vrfy.org wrote:
 On Sun, Mar 24, 2013 at 3:38 AM, Kok, Auke-jan H
 auke-jan.h@intel.com wrote:

 I don't see anything in udev code setting IOPRIO... perhaps elevating
 the few calls doing bklid and mount might be helpful?

 Maybe that really makes a difference, we should definitely try that.
 The blkid calls are really limited to a few bytes here and there, and
 will never loop for a long time, so that should be fine.

 Do you have a box, where you could you give it a quick try to bump the
 prio for the libblkid calls:
   ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...)
 in:
   src/udev/udev-builtin-blkid.c
 ?

 I left my non-ssd dev box in the office, so it'll be monday - but I'll
 absolutely give it a good test run.

 Could you still give that a simple try with current git and the
 chunking in place, so that we have some idea if the blkid calls would
 benefit from a higher priority?

 Even if we decide against doing that in the end, it would be nice to know ...

 I'm pretty sure it'll make a big dent, and I started looking at it already...

So, I just spent an hour or so playing around with some stuff, and
here are my thoughts: First off, it seems making the blkid parts run
at RT,0 prio (highest possible) does absolutely nothing, which
suggests that Lennart was right that almost all parts are already
cached.

However, while looking at the bootcharts I'm noticing `fsck` and
`systemd-fsck` is taking considerable time to complete:

before:
- all fsck's done around 5.5sec total (measured after kernel done booting)
- systemd-fsck's take ~ 2.4 secs
- fsck children run for 2.2-2.8 seconds

I then added RT,0 prio to systemd-fsck just before it forks it's children:

after:
- all fsck's done around 3.5secs total
- systemd-fsck's take ~0.8 secs
- fsck children run for 0.4-0.7 secs

All in all that's a big gain, and it immediately exposes that `lvm`
also is crazy slow (this is a vanilla fc18 install).

So, I'd be interested in making this the default. Maybe not RT,0 which
is a bit of a whammer, but certainly BE,0 or even RT,5 or something
like that.

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

Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media

[Kok, Auke-jan H]

On Mon, Mar 25, 2013 at 9:53 AM, Frederic Crozat fcro...@suse.com wrote:
 Le vendredi 22 mars 2013 à 15:22 -0700, Auke Kok a écrit
 For a comparison of how before/after bootcharts look (ext4 on a
 mobile 5400rpm 250GB drive) please look at:

 http://foo-projects.org/~sofar/blocked-tests/

 There are bootcharts in the before and after folders where you
 should be able to see that many low-level services finish 5-7
 seconds earlier with the patch applied (after).

 I've checked on my test netbook system and I can confirm your findings
 (with ext4 as fs), gain is around 3s, compared to the old readahead in
 systemd which was sometime slowing boot by 3s, compared to no
 readahead.

 I'd say commit it :)

I pushed this right after v199, so folks with ext4 on a spinning drive
have some extra time to compare the results.

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

Re: [systemd-devel] [systemd-commits] Makefile.am src/readahead

[Kok, Auke-jan H]

On Tue, Mar 26, 2013 at 10:38 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 26.03.13 10:33, Auke-Jan Kok (a...@kemper.freedesktop.org) wrote:

 Heyhey, wait.

 +clock_gettime(CLOCK_MONOTONIC, starttime);

 Could you please turn this into an usec_t? We generally use usec_t for
 everything, it's much simpler to use. We won't use the floating point
 stuff then either. usec_t is actually a uint64_t so you can do normal
 calculations with it, without involving floats or antyhing.

 usec_t starttime;
 starttime = now(CLOCK_MONOTONIC);

ahh yes, that'll be nice to get the float out of there!

Will fix asap - thanks!


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

Re: [systemd-devel] [ANNOUNCE] systemd 199

[Kok, Auke-jan H]

On Tue, Mar 26, 2013 at 10:32 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 26.03.13 10:06, Shawn (shawnland...@gmail.com) wrote:

 you could get a backtrace in gdb

 Yes, please provide a backtrace for this!

that's a helluva hard thing to do with systemd-coredump somehow not
working on my box. I ended up redirecting coredumps to a file manually
and got:




#0  0xb77c4424 in __kernel_vsyscall ()
(gdb) bt full
#0  0xb77c4424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb75a03af in raise () from /usr/lib/libc.so.6
No symbol table info available.
#2  0xb75a1c75 in abort () from /usr/lib/libc.so.6
No symbol table info available.
#3  0x080b3d4b in log_assert (text=optimized out, file=0x80c6023
src/test/test-unit-name.c, line=131,
func=0x80e1858 test_unit_printf, format=0x8110360 Assertion
'%s' failed at %s:%u, function %s(). Aborting.)
at src/shared/log.c:714
buffer = Assertion 'r == 0' failed at
src/test/test-unit-name.c:131, function test_unit_printf().
Aborting., '\000' repeats 1949 times
#4  0x080b4455 in log_assert_failed (text=0x80c61e3 r == 0,
file=0x80c6023 src/test/test-unit-name.c, line=131,
func=0x80e1858 test_unit_printf) at src/shared/log.c:719
No locals.
#5  0x08050699 in test_unit_printf () at src/test/test-unit-name.c:131
m = optimized out
mid = 0x8135008 7a3e74c61421e7d582e9c25e0016
root = 0xb76dcca8
u = optimized out
u2 = optimized out
r = optimized out
bid = 0x8135030 1ab28824da47480c85252d8ce90b5d1e
host = 0x8135058 hannah
root_uid = optimized out
#6  main (argc=1, argv=0xbfdce064) at src/test/test-unit-name.c:196
No locals.



Reading symbols from /home/sofar/git/systemd/.libs/lt-test-unit-name...done.

warning: core file may not match specified executable file.
[New LWP 20476]
Core was generated by `/home/sofar/git/systemd/.libs/lt-test-sched-prio'.
Program terminated with signal 6, Aborted.
#0  0xb777e424 in __kernel_vsyscall ()
(gdb) bt full
#0  0xb777e424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb755a3af in ?? ()
No symbol table info available.
#2  0xb7694ff4 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)



Reading symbols from /home/sofar/git/systemd/.libs/lt-test-unit-name...done.

warning: core file may not match specified executable file.
[New LWP 20532]
Core was generated by `./test-bus-marshal'.
Program terminated with signal 6, Aborted.
#0  0xb76fa424 in __kernel_vsyscall ()
(gdb) bt full
#0  0xb76fa424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb72383af in ?? ()
No symbol table info available.
#2  0xb7372ff4 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] units/u...@.service.in

[Kok, Auke-jan H]

On Mon, Mar 25, 2013 at 9:54 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 22.03.13 21:46, Auke-Jan Kok (a...@kemper.freedesktop.org) wrote:

  units/u...@.service.in |   10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 New commits:
 commit 3abcb6acedb588ca17f6374c1836f8a58396e520
 Author: Auke Kok auke-jan.h@intel.com
 Date:   Fri Mar 22 21:43:31 2013 -0700

 Update user session unit template.

 While most folks will be using the derivative from user-session-units,
 I'm updating this one to reflect some of the fixes and things to note
 about user sessions:

 - cgroup should be set with %u - username instead of %I
 - set dbus path with %U explicitly too
 - hint to folks that wish to use MEM_CG features in user sessions
 - allow unit to be enabled for instances with systemctl enable

 Hmm, with the old %I wouldn't it suffice to instantiate the unit via
 user@USERNAME.service rather than user@UID.service?

 I mean, I am not against this patch, just noticing this...

Right, it will just work regardless now, so, less chance for problems.

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

Re: [systemd-devel] [PATCH 1/2] systemd-analyze: refactor for more data collection

[Kok, Auke-jan H]

On Sun, Mar 24, 2013 at 11:23 AM, Umut Tezduyar u...@tezduyar.com wrote:
 ---
  src/analyze/systemd-analyze.c |  119 
 +++--
  1 files changed, 66 insertions(+), 53 deletions(-)

 diff --git a/src/analyze/systemd-analyze.c b/src/analyze/systemd-analyze.c
 index 01bf55e..3dcde30 100644
 --- a/src/analyze/systemd-analyze.c
 +++ b/src/analyze/systemd-analyze.c
 @@ -70,7 +70,7 @@ struct boot_times {
  usec_t userspace_time;
  usec_t finish_time;
  };
 -struct unit_times {
 +struct unit_stat {
  char *name;
  usec_t ixt;
  usec_t iet;

hey,

almost half of this patch is about just renaming this struct... is
there a reason to do this at all? it seems like the old name is
actually better at describing the content.

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

Re: [systemd-devel] [PATCH 2/2] systemd-analyze: --type cpuacct option for blame

[Kok, Auke-jan H]

On Sun, Mar 24, 2013 at 11:23 AM, Umut Tezduyar u...@tezduyar.com wrote:
 systemd-analyze blame --type cpuacct displays cpu time
 usage information of the cgroup. The information displayed
 is cpuacct.usage.

 ControlGroup=cpuacct:/foo/bar for a service would work.
 ControlGroupPersistent=yes for a oneshot service keeps
 cpuacct around so blame can retrieve it.
 DefaultControllers=cpuacct on system.conf can be set
 to have cpuacct same as systemd cgroup.
 ---
  src/analyze/systemd-analyze.c |  131 
 +
  1 files changed, 119 insertions(+), 12 deletions(-)

So, I'm not against this patch per se, but, I'm wondering if it's not
better to display this data in systemd-cgtop.

After all, systemd-analyze is a one-time snapshot and suffers from
data loss when services are restarted, etc.

Having a method to show cpuacct totals in systemd-cgtop seems much
more useful. You could modify the code to show totals instead of
percentages, etc.

Have you thought about doing that?


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

Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media

[Kok, Auke-jan H]

On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers k...@vrfy.org wrote:
 On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Sat, 23.03.13 23:42, Tom Gundersen (t...@jklm.no) wrote:


 On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering
 lenn...@poettering.net wrote:
  Then, I generally believe better than trying to be smart when reading
  things we should much rather try to place things properly on disk. We
  already defrag things based on the read order for btrfs, we should do
  the same for ext4. The API for that unfortunately awful, but e4rat has
  shown that this does work. Basically, this is what you do:

 Isn't the problem that reads by blkid and friends are not being caught
 by readahead-collect, and hence end up blocking until readahead-replay
 has finished? In that case reordering won't help (I think).

 Hmm, if root file system is mounted the file system's superblock should
 be cached in memory, I'd expect, so blkid shouldn't have to block...

 I guess it's more about ~30-40 tiny seek()/read() on the main block
 device, spread all over the place mainly the first 200 and the last
 few kilobyte of the disk, what blkid need to do.

 None of of that shares the cache with the mounted filesystem blocks,
 and I don't think any of that data is in any other cache at that time.

I don't see anything in udev code setting IOPRIO... perhaps elevating
the few calls doing bklid and mount might be helpful?

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

Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media

[Kok, Auke-jan H]

On Sat, Mar 23, 2013 at 4:37 PM, Kay Sievers k...@vrfy.org wrote:
 On Sun, Mar 24, 2013 at 12:02 AM, Kok, Auke-jan H
 auke-jan.h@intel.com wrote:
 On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers k...@vrfy.org wrote:
 On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Sat, 23.03.13 23:42, Tom Gundersen (t...@jklm.no) wrote:


 On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering
 lenn...@poettering.net wrote:
  Then, I generally believe better than trying to be smart when reading
  things we should much rather try to place things properly on disk. We
  already defrag things based on the read order for btrfs, we should do
  the same for ext4. The API for that unfortunately awful, but e4rat has
  shown that this does work. Basically, this is what you do:

 Isn't the problem that reads by blkid and friends are not being caught
 by readahead-collect, and hence end up blocking until readahead-replay
 has finished? In that case reordering won't help (I think).

 Hmm, if root file system is mounted the file system's superblock should
 be cached in memory, I'd expect, so blkid shouldn't have to block...

 I guess it's more about ~30-40 tiny seek()/read() on the main block
 device, spread all over the place mainly the first 200 and the last
 few kilobyte of the disk, what blkid need to do.

 None of of that shares the cache with the mounted filesystem blocks,
 and I don't think any of that data is in any other cache at that time.

 I don't see anything in udev code setting IOPRIO... perhaps elevating
 the few calls doing bklid and mount might be helpful?

 Maybe that really makes a difference, we should definitely try that.
 The blkid calls are really limited to a few bytes here and there, and
 will never loop for a long time, so that should be fine.

 Do you have a box, where you could you give it a quick try to bump the
 prio for the libblkid calls:
   ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...)
 in:
   src/udev/udev-builtin-blkid.c
 ?

I left my non-ssd dev box in the office, so it'll be monday - but I'll
absolutely give it a good test run.

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