Re: [systemd-devel] system shutdown: what unit is taking so long?

2013-04-16 Thread Andrey Borzenkov 
On Wed, Apr 17, 2013 at 9:17 AM, Jan Engelhardt  wrote:
>
> I think systemd should print some status message -- like "Shutdown of
> xendomains.service still running" every 5sec, maybe? -- when shutting
> down some service takes longer than expected. If a login shell on
> console was not killed until the really last moment (right before
> umount), that would be even better.

Does this commit work for you?

http://cgit.freedesktop.org/systemd/systemd/commit/?id=03b717a3c4f9348807fc56e7a7d711d72d4ec0cb
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] system shutdown: what unit is taking so long?

2013-04-16 Thread Jan Engelhardt 
Hi,


I have some hosts with Xen VMs running, and on shutdown, the classic LSB 
script /etc/init.d/xendomains is used to start and stop the "service" on 
openSUSE. There is intricate logic in there to stop/migrate/suspend 
these VMs according to user preferences.

In any case, the shutdown process may take considerably longer than your 
usual signalling-killing of a process.

Under sysvinit, the LSB script would output a status line and update it 
every second to show it was waiting for the VM to complete shutdown.

In systemd, this is no longer the case because LSB output is suppressed 
and written to the journal instead. That in itself would be fine, but 
the problem is that on _system_ shutdown, since any login processes will 
have already be stopped by systemd, there is no way for the admin to 
check what is going on, and the system just practically sits there as 
though it would hang.

I think systemd should print some status message -- like "Shutdown of 
xendomains.service still running" every 5sec, maybe? -- when shutting 
down some service takes longer than expected. If a login shell on 
console was not killed until the really last moment (right before 
umount), that would be even better.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Lid close event delivered delayed

2013-04-16 Thread Jan Engelhardt 
Hi,


something I observed with systemd-195 is that the LidClose event is 
delivered when switching from X to console while the lid is closed. This 
is unexpected, and what I expected is instead that nothing occurs.
Approximate steps to reproduce, IIRC:
1. Plug in external monitor
2. Boot machine. By way of KMS, output will be cloned to the big screen.
3. When the X desktop is finally running, close laptop lid.
   (Because the picture is also cloned in this case)
   In XFCE's power settings, I have set that LidClose does not 
   do anything - for obvious reason.

4. Switch to tty1
5. systemd does an S2RAM.

So in other words, if you worked for an hour in X and then switch, you 
get a suspend event out of nowhere without warning notice.

# journalctl -n ...
Apr 17 06:41:30 nakamura.inai.de systemd-logind[502]: Suspending...
Apr 17 06:41:30 nakamura.inai.de systemd[1]: Starting Sleep.
Apr 17 06:41:30 nakamura.inai.de systemd[1]: Reached target Sleep.
Apr 17 06:41:30 nakamura.inai.de systemd[1]: Starting Suspend...
Apr 17 06:41:30 nakamura.inai.de systemd-sleep[5315]: Suspending 
system...

(Now I also need to find the knob to turn off suspend in systemd; this 
was not here before in systemd-44.)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] Report about syntax error in extended format

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Apr 05, 2013 at 08:51:39PM +0200, Lennart Poettering wrote:
> On Tue, 02.04.13 07:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > > +return log_struct(error ? LOG_ERR : LOG_WARNING,
> > > +  "MESSAGE=[%s:%d]: %s", file, line, buf,
> > > +  "MESSAGE_ID=%s\n", error ? CONF_PARSER_ERROR : 
> > > CONF_PARSER_WARNING,
> > > +  "FILE=%s\n", file,
> > > +  "LINE=%u\n", line,
> > > +  "ERROR=%s\n", buf,
> > > +  NULL);
> > Hi,
> > what we really need, is getting a proper SYSTEMD_UNIT tag
> > for those messages. Then they'll appear in systemctl output,
> > without further work.
> 
> Fully agree. We already have log_struct_unit() maybe we should extend on
> that and have log_syntax_unit() as a macro that adds in the fields?
I have now pushed a change that adds UNIT= or USER_UNIT= to most
syntax error messages. This patch mostly follows Oleksii's approach,
but extends it to all syntax parsing functions.

The 'issues' patch can now easily go on top, by hooking into
log_syntax_internal.

> > The working assumption in systemd is that the journal is available,
> > can can be used. So it storing messages in systemd (patch 2/2) goes against
> > current design.
> 
> Well, I think Oleksii has a point. It might make sense to attach a set
> of "issues" to each unit, that are displayed on all "systemctl status"
> outputs, whcih need to be resolved before they go away. i.e. unlike
> logging about state changes this "issue" logic would stay around until
> you resolved it. It's of course difficult to draw the line here between
> logging and these "issues", but their persistent nature and that they
> require resolving might be a worthwile distinction from normal logging.
> 
> In this sense "issues" would be something like a generalization of
> "Syntax errors" that are of this sticky, resolving-required style.
> 
> Also, I think these issues are probably something that is never stored
> on disk, but simply determined on each daemon-reload again. Which also
> makes it very different from logging.
> 
> If we do this, I am not entirely sure about the name "issue" though. If
> we do this I'd like a good name that expresses that this requires
> resolving by the admin, and sufficiently makes clear that this is not
> logging but more of a "list of current problems", "todo checklist" or
> so... Ideas? Any native speakers?

I still think that 'issues' sounds nicest.

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

Re: [systemd-devel] [PATCH] configure: use AC_CHECK_TOOL for objcopy, strings and gperf

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 16, 2013 at 02:26:30PM +0200, Martin Jansa wrote:
> * using AC_PATH_TOOL does not allow to override it from shell environment
>   which is useful when cross-compiling
> * with external toolchain I have different HOST_PREFIX and HOST_SYS
>   AC_PATH_TOOL is using HOST_SYS as prefix and fails to find objcopy
>   which is available only as ${TARGET_PREFIX}objcopy then it tries
>   objcopy without prefix which is found on host, but that objcopy
>   does not work for !host (e.g. arm when building on x86) libs
Applied. Thanks.

> Signed-off-by: Martin Jansa 
We don't use that.

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

Re: [systemd-devel] [PATCH] fileio: also escape $ and ` when writing out env vars

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Apr 14, 2013 at 02:54:09PM +0300, Mantas Mikulėnas wrote:
> These are also considered special by sh and bash.
> ---
>  src/shared/fileio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/shared/fileio.c b/src/shared/fileio.c
> index 400a416..617afea 100644
> --- a/src/shared/fileio.c
> +++ b/src/shared/fileio.c
> @@ -529,11 +529,11 @@ static void write_env_var(FILE *f, const char *v) {
>  p++;
>  fwrite(v, 1, p-v, f);
>  
> -if (string_has_cc(p) || chars_intersect(p, WHITESPACE "\'\"\\")) {
> +if (string_has_cc(p) || chars_intersect(p, WHITESPACE "\'\"\\`$")) {
>  fputc('\"', f);
>  
>  for (; *p; p++) {
> -if (strchr("\'\"\\", *p))
> +if (strchr("\'\"\\`$", *p))
>  fputc('\\', f);
>  
>  fputc(*p, f);
Applied.

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

Re: [systemd-devel] [PATCH] python-systemd: Reader return special fields and _Reader changes

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Apr 14, 2013 at 08:55:08PM +0100, Steven Hiscocks wrote:
> From: Steven Hiscocks 
> 
> Changes to _Reader make it match closer to C API, by removing `get_next`
> and `get_previous`. A `get_all` method added, which returns dictionary
> of fields using C API SD_JOURNAL_FOREACH_DATA macro, which can be used
> in conjunction with `next`.
> 
> _Reader `get`, `next`, `get_{realtime,monotonic,cursor}` and new
> `previous` methods are made private. This is so the traversal and
> getting of journal fields can be made transparent in the python
> interface.
> 
> Reader now solely implements `get_next` and `get_previous`, returning a
> standard dictionary (future: other mapping types?) with all standard and
> special fields through the converters. This makes the output the same as
> journalctl json/export format output.
> 
> Iterator methods also moved to Reader, as they do not function as intend
> with changes to _Reader.
> 
> These changes also mean that more optimised journal interfaces can be
> made more easily from _Reader, by avoiding getting of unrequired fields
> by using the `_get` method, and avoiding field conversions.
Applied. Thanks!

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

Re: [systemd-devel] recursive dispatching of va_list (was: Re: [ANNOUNCE] systemd 200)

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 09, 2013 at 09:37:33PM +0200, Lennart Poettering wrote:
> On Mon, 08.04.13 14:30, Lennart Poettering (lenn...@poettering.net) wrote:
> 
> > On Fri, 05.04.13 23:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > wrote:
> > 
> > > > I had a go at debugging this... I think that the is the "return of the
> > > > va_arg and undefined aps" horror. The result is that in 
> > > > test-bus-marshall.c:133
> > > > and test-bus-marshall.c:139 (at least), some of the output arguments 
> > > > are not
> > > > initialized at all and segfault happens. Under gdb I see that 
> > > > va_arg(ap, void*)
> > > > returns &y twice.
> > > > 
> > > > According to va_arg(3), "If ap is passed to a function that uses
> > > > va_arg(ap,type) then the value of ap is undefined after the return of
> > > > that function." So message_read_ap calling itself recursively is not an
> > > > option.
> > > ...unless we implement DBUS_FORMAT_FORMAT_ADVANCE, which calls itself
> > > recursively (yuck), and use va_copy (yuck). But maybe that's the way.
> > 
> > Ah, grmbl, yuck, g... 
> > 
> > I will try to rewrite bus_message_read_ap() in a non-recurisve
> > fashion. It should be possible to do that by more or less just using a
> > hand-written stack of signature strings... I will look into it. Gonna be
> > hard making this readable...
> 
> This is now in git. Would be cool if somebody could test if the tests
> now pass on a 32bit arch! Philip? 
Seems to work.

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

Re: [systemd-devel] [PATCH] bash-completion: --property support

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 16, 2013 at 01:57:47PM -0400, Dave Reisner wrote:
> On Tue, Apr 16, 2013 at 01:48:14PM -0400, Zbigniew Jędrzejewski-Szmek wrote:
> > ---
> > It turns out that simply fetching the list is fast enough.
> > At least on my relatively beefy machine. And this approach
> > is quite easy. So I think we can do that.
> >
> > Zbyszek
> >
> >  shell-completion/bash/systemctl | 25 ++---
> >  1 file changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/shell-completion/bash/systemctl 
> > b/shell-completion/bash/systemctl
> > index f24a145..2c004d9 100644
> > --- a/shell-completion/bash/systemctl
> > +++ b/shell-completion/bash/systemctl
> > @@ -22,6 +22,17 @@ __systemctl() {
> >  systemctl $mode --full --no-legend "$@"
> >  }
> >
> > +__systemd_properties() {
> > +local mode=$1; shift 1
> 
> The shift seems superfluous here -- you never reference any positional
> params in this function.
> 
> > +{ __systemctl $mode show;
> > + systemd --dump-configuration-items; } |
> > +while read -r line; do
> > +if [[ "$line" =~ .*= ]]; then
> > +echo ${line%%=*}
> > +fi
> 
> I'd skip the regex and just split in the while loop:
> 
>   while IFS='=' read -r key value; do
> [[ $value ]] && echo "$key"
>   done
Thanks. I'll apply the patch with your suggestions.

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

Re: [systemd-devel] [PATCH v3] tools: add static-nodes tool

2013-04-16 Thread Tom Gundersen 
On Tue, Apr 16, 2013 at 3:49 PM, Thomas Bächler  wrote:
> Am 16.04.2013 15:12, schrieb Tom Gundersen:
>> +static void write_human(FILE *out, char module[], char devname[], char 
>> type, unsigned int maj, unsigned int min)
>
> [...]
>
>> +static void write_tmpfile(FILE *out, char devname[], char type, unsigned 
>> int maj, unsigned int min)
>
> [...]
>
>> +static int do_static_nodes(int argc, char *argv[])
>> +{
>> +struct utsname kernel;
>> +char modules[PATH_MAX];
>> +FILE *in = NULL, *out = stdout;
>> +bool human_readable = 1;
>
> This code emphasizes that there is actually only one format available
> and needs to be changed again when another one is added. Why not
>
> void (*write_output)((FILE *, char[], char[], char, unsigned int,
> unsigned int) = write_human;
>
> ? Then ...
>
>> +case 'f':
>> +if (!streq(optarg, "tmpfiles")) {
>> +fprintf(stderr, "Unknown format: '%s'.\n", 
>> argv[1]);
>> +help();
>> +ret = EXIT_FAILURE;
>> +goto finish;
>> +}
>> +human_readable = 0;
>> +break;
>
> case 'f':
> if (streq(optarg, "tmpfiles")) {
>  write_output = write_tmpfiles;
> }
> else {
> fprintf(stderr, "Unknown format: '%s'.\n", argv[1]);
> [...]
> }
> break;
>
> And in the end:
>
>> +if (human_readable)
>> +write_human(out, module, devname, type, maj, min);
>> +else
>> +write_tmpfile(out, devname, type, maj, min);
>
> write_output(out, module, devname, type, maj, min);
>
> Maybe even add an array with output name and function pointer pairs, so
> that we could get a list of available formats using --format=?. For
> consistency, --format=human should also work. Just seems nicer to me, in
> case someone actually plans to extend this later.

Thanks for the suggestions Thomas. I implemented most of them, so now
it should be a lot simpler to extend this in the future.

The only thing I skipped was the --format=? idea, as this info is
already in the help output, and I'm not sure how useful it is to
parse. That said, it could easily be added follow-up patch if there is
a need for it.

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

Re: [systemd-devel] [PATCH v3] tools: add static-nodes tool

2013-04-16 Thread Kay Sievers 
On Tue, Apr 16, 2013 at 8:51 PM, Lucas De Marchi
 wrote:

> Kay, what's your opinion regarding this command? Is this sufficient to
> drop CAP_MKNOD from udev?

Sounds all good to me.

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

2013-04-16 Thread Koen Kooi 

Op 16 apr. 2013, om 20:14 heeft Zbigniew Jędrzejewski-Szmek  
het volgende geschreven:

> On Tue, Apr 16, 2013 at 09:11:51AM +0200, Koen Kooi 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  /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?
> 
> With very recent systemd just run:
> 
> PID=$(head -n1 /sys/fs/cgroup/systemd/machine/$NAME/system/tasks)
> nsenter -m -u -i -n -p -t $PID /usr/bin/timedatectl set-timezone Europe/Paris
> ...
> nsenter -m -u -i -n -p -t $PID systemctl halt
> 
> where NAME is either speicified with -M or the name of the tree root.


I'll update my util-linux to get nsenter and give that a try, thanks!


___
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

2013-04-16 Thread Koen Kooi 

Op 16 apr. 2013, om 20:00 heeft "Kok, Auke-jan H"  
het volgende geschreven:

> On Tue, Apr 16, 2013 at 12:11 AM, Koen Kooi  
> 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  /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.

No commands allowed with -b :(
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v3] tools: add static-nodes tool

2013-04-16 Thread Lucas De Marchi 
On Tue, Apr 16, 2013 at 10:49 AM, Thomas Bächler  wrote:
> Am 16.04.2013 15:12, schrieb Tom Gundersen:
>> +static void write_human(FILE *out, char module[], char devname[], char 
>> type, unsigned int maj, unsigned int min)
>
> [...]
>
>> +static void write_tmpfile(FILE *out, char devname[], char type, unsigned 
>> int maj, unsigned int min)
>
> [...]
>
>> +static int do_static_nodes(int argc, char *argv[])
>> +{
>> +struct utsname kernel;
>> +char modules[PATH_MAX];
>> +FILE *in = NULL, *out = stdout;
>> +bool human_readable = 1;
>
> This code emphasizes that there is actually only one format available
> and needs to be changed again when another one is added. Why not
>
> void (*write_output)((FILE *, char[], char[], char, unsigned int,
> unsigned int) = write_human;
>
> ? Then ...
>
>> +case 'f':
>> +if (!streq(optarg, "tmpfiles")) {
>> +fprintf(stderr, "Unknown format: '%s'.\n", 
>> argv[1]);
>> +help();
>> +ret = EXIT_FAILURE;
>> +goto finish;
>> +}
>> +human_readable = 0;
>> +break;
>
> case 'f':
> if (streq(optarg, "tmpfiles")) {
>  write_output = write_tmpfiles;
> }
> else {
> fprintf(stderr, "Unknown format: '%s'.\n", argv[1]);
> [...]
> }
> break;
>
> And in the end:
>
>> +if (human_readable)
>> +write_human(out, module, devname, type, maj, min);
>> +else
>> +write_tmpfile(out, devname, type, maj, min);
>
> write_output(out, module, devname, type, maj, min);
>
> Maybe even add an array with output name and function pointer pairs, so
> that we could get a list of available formats using --format=?. For
> consistency, --format=human should also work. Just seems nicer to me, in
> case someone actually plans to extend this later.
>

Agree. Otherwise looks good.

Kay, what's your opinion regarding this command? Is this sufficient to
drop CAP_MKNOD from udev?


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

Re: [systemd-devel] Per-instance override with foobar.service.d

2013-04-16 Thread John Lane 

On 12/04/13 14:00, Zbigniew Jędrzejewski-Szmek wrote:

foobar@.service and foobar@.service.d/myinstance.conf
foobar@.service and foobar@myinstance.service.d/myinstance.conf

This would be possible, if somebody implements it.


which don't work so I guess this isn't implemented. If so, would something
like that be a reasonable request to be considered ?

I was thinking...
foobar@.service
foobar@.service.d/myfirstinstance.conf
foobar@.service.d/mysecondinstance.conf

The idea is that different sources (rpms, administrator, whatever)
provide snippets that are then merged. So there's no central "registration"
of snippet names, and the namespace cannot be reused for instances.

What about this though?

 foobar@myfirstinstance.service.d/...
 foobar@mysecondinstance.service./...

where the relevant .conf would be selected based on the instance name.

I was also wondering why the need for a separate sub-directory when there's
only one file inside it. Could a file like "foobar.service.conf" be
considered as an alternative  (and, perhaps, foo...@myinstance.service.conf)

There can be multiple files.
Sure there can be multiple files, but I did suggest this as an 
alternative when there is only one file.
I'm finding that I have lots of examples where I have a directory 
containing one file and it seems like an unnecessary complexity in that 
scenario.


Zbyszek



___
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

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 16, 2013 at 09:11:51AM +0200, Koen Kooi 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  /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?

With very recent systemd just run:

PID=$(head -n1 /sys/fs/cgroup/systemd/machine/$NAME/system/tasks)
nsenter -m -u -i -n -p -t $PID /usr/bin/timedatectl set-timezone Europe/Paris
...
nsenter -m -u -i -n -p -t $PID systemctl halt

where NAME is either speicified with -M or the name of the tree root.

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

2013-04-16 Thread Kok, Auke-jan H 
On Tue, Apr 16, 2013 at 12:11 AM, Koen Kooi  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  /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] [PATCH] bash-completion: --property support

2013-04-16 Thread Dave Reisner 
On Tue, Apr 16, 2013 at 01:48:14PM -0400, Zbigniew Jędrzejewski-Szmek wrote:
> ---
> It turns out that simply fetching the list is fast enough.
> At least on my relatively beefy machine. And this approach
> is quite easy. So I think we can do that.
>
> Zbyszek
>
>  shell-completion/bash/systemctl | 25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/shell-completion/bash/systemctl b/shell-completion/bash/systemctl
> index f24a145..2c004d9 100644
> --- a/shell-completion/bash/systemctl
> +++ b/shell-completion/bash/systemctl
> @@ -22,6 +22,17 @@ __systemctl() {
>  systemctl $mode --full --no-legend "$@"
>  }
>
> +__systemd_properties() {
> +local mode=$1; shift 1

The shift seems superfluous here -- you never reference any positional
params in this function.

> +{ __systemctl $mode show;
> + systemd --dump-configuration-items; } |
> +while read -r line; do
> +if [[ "$line" =~ .*= ]]; then
> +echo ${line%%=*}
> +fi

I'd skip the regex and just split in the while loop:

  while IFS='=' read -r key value; do
[[ $value ]] && echo "$key"
  done

> +done
> +}
> +
>  __contains_word () {
>  local word=$1; shift
>  for w in $*; do [[ $w = $word ]] && return 0; done
> @@ -67,6 +78,12 @@ _systemctl () {
>[ARG]='--host -H --kill-mode --kill-who --property -p 
> --signal -s --type -t --root'
>  )
>
> +if __contains_word "--user" ${COMP_WORDS[*]}; then
> +mode=--user
> +else
> +mode=--system
> +fi
> +
>  if __contains_word "$prev" ${OPTS[ARG]}; then
>  case $prev in
>  --signal|-s)
> @@ -89,7 +106,7 @@ _systemctl () {
>  comps=$(compgen -A hostname)
>  ;;
>  --property|-p)
> -comps=''
> +comps=$(__systemd_properties $mode)
>  ;;
>  esac
>  COMPREPLY=( $(compgen -W '$comps' -- "$cur") )
> @@ -101,12 +118,6 @@ _systemctl () {
>  return 0
>  fi
>
> -if __contains_word "--user" ${COMP_WORDS[*]}; then
> -mode=--user
> -else
> -mode=--system
> -fi
> -
>  local -A VERBS=(
>  [ALL_UNITS]='is-active is-failed is-enabled status show mask 
> preset'
>  [ENABLED_UNITS]='disable'
> --
> 1.8.2
>
> ___
> 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

[systemd-devel] [PATCH] bash-completion: --property support

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
---
It turns out that simply fetching the list is fast enough.
At least on my relatively beefy machine. And this approach
is quite easy. So I think we can do that.

Zbyszek

 shell-completion/bash/systemctl | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/shell-completion/bash/systemctl b/shell-completion/bash/systemctl
index f24a145..2c004d9 100644
--- a/shell-completion/bash/systemctl
+++ b/shell-completion/bash/systemctl
@@ -22,6 +22,17 @@ __systemctl() {
 systemctl $mode --full --no-legend "$@"
 }
 
+__systemd_properties() {
+local mode=$1; shift 1
+{ __systemctl $mode show;
+ systemd --dump-configuration-items; } |
+while read -r line; do
+if [[ "$line" =~ .*= ]]; then
+echo ${line%%=*}
+fi
+done
+}
+
 __contains_word () {
 local word=$1; shift
 for w in $*; do [[ $w = $word ]] && return 0; done
@@ -67,6 +78,12 @@ _systemctl () {
   [ARG]='--host -H --kill-mode --kill-who --property -p 
--signal -s --type -t --root'
 )
 
+if __contains_word "--user" ${COMP_WORDS[*]}; then
+mode=--user
+else
+mode=--system
+fi
+
 if __contains_word "$prev" ${OPTS[ARG]}; then
 case $prev in
 --signal|-s)
@@ -89,7 +106,7 @@ _systemctl () {
 comps=$(compgen -A hostname)
 ;;
 --property|-p)
-comps=''
+comps=$(__systemd_properties $mode)
 ;;
 esac
 COMPREPLY=( $(compgen -W '$comps' -- "$cur") )
@@ -101,12 +118,6 @@ _systemctl () {
 return 0
 fi
 
-if __contains_word "--user" ${COMP_WORDS[*]}; then
-mode=--user
-else
-mode=--system
-fi
-
 local -A VERBS=(
 [ALL_UNITS]='is-active is-failed is-enabled status show mask 
preset'
 [ENABLED_UNITS]='disable'
-- 
1.8.2

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

Re: [systemd-devel] systemd release agent

2013-04-16 Thread Kevin Wilson 
Hello,
Thanks a lot for your answer.
Something is not clear to me with this test I made (on Fedora 18).
I hope that someone can explain.
I ran:
cat /sys/fs/cgroup/systemd/release_agent
/usr/lib/systemd/systemd-cgroups-agent

No I moved /usr/lib/systemd/systemd-cgroups-agent to some backup.
and made sure that:

ls /usr/lib/systemd/systemd-cgroups-agent
ls: cannot access /usr/lib/systemd/systemd-cgroups-agent: No such file
or directory

Now I tried killing two services that I know are under systemd cgroups:
cat  /sys/fs/cgroup/systemd/system/bluetooth.service/tasks
671

Apr 16 20:40:05 localhost systemd[1]: bluetooth.service: main process
exited, code=killed, status=9/KILL
Apr 16 20:40:05 localhost systemd[1]: Unit bluetooth.service entered
failed state

And with mcelog it was the same:

...
Apr 16 20:33:46 localhost systemd[1]: mcelog.service: main process
exited, code=killed, status=9/KILL
Apr 16 20:33:46 localhost systemd[1]: Unit mcelog.service entered failed state
...

both folders, bluetooth.service and mcelog.service (under
 /sys/fs/cgroup/systemd/system/) were removed.

How come ? could it be that the messages to the DBus are not sent
by systemd-cgroups-agent?
I also made sure, and
ps aux | g systemd-cgroups-agent
returns nothing.

Any ideas?

rgs
Kevin

















On Tue, Apr 9, 2013 at 6:07 PM, Lennart Poettering
 wrote:
> On Tue, 09.04.13 16:39, Kevin Wilson (wkev...@gmail.com) wrote:
>
>> Hello,
>> On Fedora 18, running:
>> mount | grep release
>> gives:
>> cgroup on /sys/fs/cgroup/systemd type cgroup
>> (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
>>
>> I know and have tried cgroup release_agent;
>>
>> I also noticed that  notify_on_release is enabled in systemd cgroups:
>> cat  /sys/fs/cgroup/systemd/notify_on_release
>> gives 1
>> (also in the children, user and system cgroups)
>>
>> what does /usr/lib/systemd/systemd-cgroups-agent do ? what it is for ?
>> What does it do when it is invoked ?
>
> it's how the kernel notifies about cgroups running empty. The kernel
> forks the specified binary out. We install a binary there that simply
> sends a message on the bus about the cgroup running empty.
>
> It's an awful kernel API, but the only one there is for this.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
___
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

2013-04-16 Thread Kok, Auke-jan H 
On Tue, Apr 16, 2013 at 1:47 AM, Colin Guthrie  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] [PATCH] shell-completion/bash/systemctl: add completion for properties

2013-04-16 Thread Kay Sievers 
On Tue, Apr 16, 2013 at 6:00 PM, Zbigniew Jędrzejewski-Szmek
 wrote:

>> Perhaps we can come up with a way of creating this list dynamically so
>> that we're not forever indebted to keeping this list up to date.
> My thoughts exactly. Would be best if we created it at compilation time.
> Hm, we have systemd --dump-configuration-items!
>
> /me goes of to write a patch

Keep in mind, that cross-compile environments cannot run the compiled
binary on the host.

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

Re: [systemd-devel] [PATCH] shell-completion/bash/systemctl: add completion for properties

2013-04-16 Thread Andrey Borzenkov 
В Tue, 16 Apr 2013 19:06:28 +0200
Kay Sievers  пишет:

> On Tue, Apr 16, 2013 at 6:00 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> 
> >> Perhaps we can come up with a way of creating this list dynamically so
> >> that we're not forever indebted to keeping this list up to date.
> > My thoughts exactly. Would be best if we created it at compilation time.
> > Hm, we have systemd --dump-configuration-items!
> >
> > /me goes of to write a patch
> 
> Keep in mind, that cross-compile environments cannot run the compiled
> binary on the host.
> 

I would expect completion to fetch this list when it is run on target
system.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] shell-completion/bash/systemctl: add completion for properties

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 16, 2013 at 11:28:27AM -0400, Dave Reisner wrote:
> On Tue, Apr 16, 2013 at 04:16:56PM +0200, har...@redhat.com wrote:
> > From: Harald Hoyer 
> >
> > ---
> >  TODO|  2 --
> >  shell-completion/bash/systemctl | 13 -
> >  2 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/TODO b/TODO
> > index f90c66b..22c26a3 100644
> > --- a/TODO
> > +++ b/TODO
> > @@ -1,8 +1,6 @@
> >  Bugfixes:
> >  * timedatectl: NTP enabled: n/a
> >
> > -* systemctl --system show -p Fr default.target doesn't show anything
> > -
> >  * check systemd-tmpfiles for selinux context hookup for mknod(), symlink() 
> > and similar
> >
> >  * swap units that are activated by one name but shown in the kernel under 
> > another are semi-broken
> > diff --git a/shell-completion/bash/systemctl 
> > b/shell-completion/bash/systemctl
> > index f24a145..c854f86 100644
> > --- a/shell-completion/bash/systemctl
> > +++ b/shell-completion/bash/systemctl
> > @@ -89,7 +89,18 @@ _systemctl () {
> >  comps=$(compgen -A hostname)
> >  ;;
> >  --property|-p)
> > -comps=''
> > +comps='ActiveEnterTimestamp 
> > ActiveEnterTimestampMonotonic ActiveExitTimestamp
> > +   ActiveExitTimestampMonotonic 
> > ActiveState After AllowIsolate Before BindsTo BoundBy
> > +   CanIsolate CanReload CanStart 
> > CanStop ConditionResult ConditionTimestamp
> > +   ConditionTimestampMonotonic 
> > ConflictedBy Conflicts ConsistsOf ControlGroupAttributes
> > +   ControlGroups DefaultControlGroup 
> > DefaultDependencies Description Documentation DropInPaths
> > +   Following FragmentPath Id 
> > IgnoreOnIsolate IgnoreOnSnapshot InactiveEnterTimestamp
> > +   InactiveEnterTimestampMonotonic 
> > InactiveExitTimestamp InactiveExitTimestampMonotonic
> > +   Job JobTimeoutUSec LoadError 
> > LoadState Names NeedDaemonReload OnFailure OnFailureIsolate
> > +   PartOf PropagatesReloadTo 
> > RefuseManualStart RefuseManualStop ReloadPropagatedFrom
> > +   RequiredBy RequiredByOverridable 
> > Requires RequiresMountsFor RequiresOverridable Requisite
> > +   RequisiteOverridable SourcePath 
> > StopWhenUnneeded SubState TriggeredBy Triggers
> > +   UnitFileState WantedBy Wants'
> 
> Perhaps we can come up with a way of creating this list dynamically so
> that we're not forever indebted to keeping this list up to date.
My thoughts exactly. Would be best if we created it at compilation time.
Hm, we have systemd --dump-configuration-items!

/me goes of to write a patch

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

Re: [systemd-devel] systemd-nspawn

2013-04-16 Thread Chir0n 
I forgot to say the system is halting normally with the audit=0 thing.


On Tue, Apr 16, 2013 at 9:22 AM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Apr 16, 2013 at 09:54:29AM +0100, Colin Guthrie wrote:
> > 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 19:48 did
> > gyre and gimble:
> > > On Mon, Apr 15, 2013 at 08:36:33PM +0200, Zbigniew Jędrzejewski-Szmek
> wrote:
> > >> On Mon, Apr 15, 2013 at 02:31:56PM -0300, Chir0n wrote:
> > >>> # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer
> > >>> --disablerepo='*' --enablerepo=fedora install systemd passwd yum
> > >>> fedora-release vim-minimal
> > >>> # systemd-nspawn -bD
> > >>> /srv/mycontainer
> > >>
> > >>   sudo nsenter -t $PID -m -u -i -n -p /bin/bash
> > > Hm, if I say 'halt' in this bash window, I see
> > >
> > > bash-4.2# halt
> > > bash-4.2# [1]  + 14306 suspended (signal)  sudo nsenter -t 13221 -m -u
> -i -n -p /bin/bash
> > >
> > > and the container's init hangs after 'All filesystems unmounted.'.
> > >
> > > Only when I do 'fg', halt resume and systemd-nspawn quits.
> > >
> > > Apparrently only happens rarely (1/5 so far).
> > >
> > > What's going on?
> >
> > Isn't "halt" meant to, well, halt? Perhaps it behaves differently under
> > nspawn but I thought that was the primary difference between "halt" and
> > "poweroff"
> Ee, yeah, the system is supposed to halt and it's not doing that :)
>
> 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] [PATCH] shell-completion/bash/systemctl: add completion for properties

2013-04-16 Thread Dave Reisner 
On Tue, Apr 16, 2013 at 04:16:56PM +0200, har...@redhat.com wrote:
> From: Harald Hoyer 
>
> ---
>  TODO|  2 --
>  shell-completion/bash/systemctl | 13 -
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/TODO b/TODO
> index f90c66b..22c26a3 100644
> --- a/TODO
> +++ b/TODO
> @@ -1,8 +1,6 @@
>  Bugfixes:
>  * timedatectl: NTP enabled: n/a
>
> -* systemctl --system show -p Fr default.target doesn't show anything
> -
>  * check systemd-tmpfiles for selinux context hookup for mknod(), symlink() 
> and similar
>
>  * swap units that are activated by one name but shown in the kernel under 
> another are semi-broken
> diff --git a/shell-completion/bash/systemctl b/shell-completion/bash/systemctl
> index f24a145..c854f86 100644
> --- a/shell-completion/bash/systemctl
> +++ b/shell-completion/bash/systemctl
> @@ -89,7 +89,18 @@ _systemctl () {
>  comps=$(compgen -A hostname)
>  ;;
>  --property|-p)
> -comps=''
> +comps='ActiveEnterTimestamp 
> ActiveEnterTimestampMonotonic ActiveExitTimestamp
> +   ActiveExitTimestampMonotonic 
> ActiveState After AllowIsolate Before BindsTo BoundBy
> +   CanIsolate CanReload CanStart CanStop 
> ConditionResult ConditionTimestamp
> +   ConditionTimestampMonotonic 
> ConflictedBy Conflicts ConsistsOf ControlGroupAttributes
> +   ControlGroups DefaultControlGroup 
> DefaultDependencies Description Documentation DropInPaths
> +   Following FragmentPath Id 
> IgnoreOnIsolate IgnoreOnSnapshot InactiveEnterTimestamp
> +   InactiveEnterTimestampMonotonic 
> InactiveExitTimestamp InactiveExitTimestampMonotonic
> +   Job JobTimeoutUSec LoadError 
> LoadState Names NeedDaemonReload OnFailure OnFailureIsolate
> +   PartOf PropagatesReloadTo 
> RefuseManualStart RefuseManualStop ReloadPropagatedFrom
> +   RequiredBy RequiredByOverridable 
> Requires RequiresMountsFor RequiresOverridable Requisite
> +   RequisiteOverridable SourcePath 
> StopWhenUnneeded SubState TriggeredBy Triggers
> +   UnitFileState WantedBy Wants'

Perhaps we can come up with a way of creating this list dynamically so
that we're not forever indebted to keeping this list up to date.

>  ;;
>  esac
>  COMPREPLY=( $(compgen -W '$comps' -- "$cur") )
> --
> 1.8.2
>
> ___
> 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

[systemd-devel] [PATCH] shell-completion/bash/systemctl: add completion for properties

2013-04-16 Thread harald 
From: Harald Hoyer 

---
 TODO|  2 --
 shell-completion/bash/systemctl | 13 -
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/TODO b/TODO
index f90c66b..22c26a3 100644
--- a/TODO
+++ b/TODO
@@ -1,8 +1,6 @@
 Bugfixes:
 * timedatectl: NTP enabled: n/a
 
-* systemctl --system show -p Fr default.target doesn't show anything
-
 * check systemd-tmpfiles for selinux context hookup for mknod(), symlink() and 
similar
 
 * swap units that are activated by one name but shown in the kernel under 
another are semi-broken
diff --git a/shell-completion/bash/systemctl b/shell-completion/bash/systemctl
index f24a145..c854f86 100644
--- a/shell-completion/bash/systemctl
+++ b/shell-completion/bash/systemctl
@@ -89,7 +89,18 @@ _systemctl () {
 comps=$(compgen -A hostname)
 ;;
 --property|-p)
-comps=''
+comps='ActiveEnterTimestamp 
ActiveEnterTimestampMonotonic ActiveExitTimestamp
+   ActiveExitTimestampMonotonic 
ActiveState After AllowIsolate Before BindsTo BoundBy
+   CanIsolate CanReload CanStart CanStop 
ConditionResult ConditionTimestamp
+   ConditionTimestampMonotonic 
ConflictedBy Conflicts ConsistsOf ControlGroupAttributes
+   ControlGroups DefaultControlGroup 
DefaultDependencies Description Documentation DropInPaths
+   Following FragmentPath Id 
IgnoreOnIsolate IgnoreOnSnapshot InactiveEnterTimestamp
+   InactiveEnterTimestampMonotonic 
InactiveExitTimestamp InactiveExitTimestampMonotonic
+   Job JobTimeoutUSec LoadError LoadState 
Names NeedDaemonReload OnFailure OnFailureIsolate
+   PartOf PropagatesReloadTo 
RefuseManualStart RefuseManualStop ReloadPropagatedFrom
+   RequiredBy RequiredByOverridable 
Requires RequiresMountsFor RequiresOverridable Requisite
+   RequisiteOverridable SourcePath 
StopWhenUnneeded SubState TriggeredBy Triggers
+   UnitFileState WantedBy Wants'
 ;;
 esac
 COMPREPLY=( $(compgen -W '$comps' -- "$cur") )
-- 
1.8.2

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

Re: [systemd-devel] [PATCH v3] tools: add static-nodes tool

2013-04-16 Thread Thomas Bächler 
Am 16.04.2013 15:12, schrieb Tom Gundersen:
> +static void write_human(FILE *out, char module[], char devname[], char type, 
> unsigned int maj, unsigned int min)

[...]

> +static void write_tmpfile(FILE *out, char devname[], char type, unsigned int 
> maj, unsigned int min)

[...]

> +static int do_static_nodes(int argc, char *argv[])
> +{
> +struct utsname kernel;
> +char modules[PATH_MAX];
> +FILE *in = NULL, *out = stdout;
> +bool human_readable = 1;

This code emphasizes that there is actually only one format available
and needs to be changed again when another one is added. Why not

void (*write_output)((FILE *, char[], char[], char, unsigned int,
unsigned int) = write_human;

? Then ...

> +case 'f':
> +if (!streq(optarg, "tmpfiles")) {
> +fprintf(stderr, "Unknown format: '%s'.\n", 
> argv[1]);
> +help();
> +ret = EXIT_FAILURE;
> +goto finish;
> +}
> +human_readable = 0;
> +break;

case 'f':
if (streq(optarg, "tmpfiles")) {
 write_output = write_tmpfiles;
}
else {
fprintf(stderr, "Unknown format: '%s'.\n", argv[1]);
[...]
}
break;

And in the end:

> +if (human_readable)
> +write_human(out, module, devname, type, maj, min);
> +else
> +write_tmpfile(out, devname, type, maj, min);

write_output(out, module, devname, type, maj, min);

Maybe even add an array with output name and function pointer pairs, so
that we could get a list of available formats using --format=?. For
consistency, --format=human should also work. Just seems nicer to me, in
case someone actually plans to extend this later.




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

Re: [systemd-devel] [PATCH v2] tools: add static-nodes tool

2013-04-16 Thread Tom Gundersen 
On Tue, Apr 16, 2013 at 1:20 AM, Lucas De Marchi
 wrote:
> Hi Tom,

Hi Lucas,

Thanks for your review!

> On Fri, Apr 12, 2013 at 9:15 PM, Tom Gundersen  wrote:
>> This tool reads modules.devname from the current kernel directory and outputs
>> the information.
>>
>> For now only the tmpfiles.d(5) format is supported, but more could easily be
>> added in the future if there is a need.
>>
>> When booting with systemd, the new tool is called at boot to instruct
>> systemd-tmpfiles to create the necessary static modules before starting
>> systemd-udevd.
>>
>> This means nothing but kmod needs to reads the private files under 
>> /lib/modules/.
>
> For me this would be the main goal of this patch or anything similar to this.

Yeah, I agree.

>> Cc: 
>> Cc: 
>> ---
>>
>> v2: adressed concerns raised by Dave, and made the tool a bit more generic so
>> more output formats may be added in the future as suggested by Lucas. Also
>> included the systemd unit file to hook this up with systemd.
>>
>>  Makefile.am|  20 -
>>  configure.ac   |   8 ++
>>  tools/kmod-static-nodes.service.in |  16 
>>  tools/kmod.c   |   1 +
>>  tools/kmod.h   |   1 +
>>  tools/static-nodes.c   | 163 
>> +
>>  6 files changed, 207 insertions(+), 2 deletions(-)
>>  create mode 100644 tools/kmod-static-nodes.service.in
>>  create mode 100644 tools/static-nodes.c
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 9feaf96..333e861 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -36,6 +36,9 @@ SED_PROCESS = \
>>  %.pc: %.pc.in Makefile
>> $(SED_PROCESS)
>>
>> +%.service: %.service.in Makefile
>> +   $(SED_PROCESS)
>> +
>>  LIBKMOD_CURRENT=4
>>  LIBKMOD_REVISION=2
>>  LIBKMOD_AGE=2
>> @@ -88,6 +91,17 @@ pkgconfig_DATA = libkmod/libkmod.pc
>>  EXTRA_DIST += libkmod/libkmod.pc.in
>>  CLEANFILES += libkmod/libkmod.pc
>>
>> +if HAVE_SYSTEMD
>> +systemdsystemunit_DATA = tools/kmod-static-nodes.service
>> +EXTRA_DIST += tools/kmod-static-nodes.service.in
>> +CLEANFILES += tools/kmod-static-nodes.service
>> +
>> +install-data-hook:
>> +   $(MKDIR_P) $(DESTDIR)$(systemdsystemunitdir)/sysinit.target.wants
>> +   ln -sf ../kmod-static-nodes.service \
>> +   
>> $(DESTDIR)$(systemdsystemunitdir)/sysinit.target.wants/kmod-static-nodes.service
>> +endif
>> +
>>  install-exec-hook:
>> if test "$(libdir)" != "$(rootlibdir)"; then \
>> $(MKDIR_P) $(DESTDIR)$(rootlibdir) && \
>> @@ -109,7 +123,8 @@ noinst_SCRIPTS = tools/insmod tools/rmmod tools/lsmod \
>>  tools_kmod_SOURCES = tools/kmod.c tools/kmod.h tools/lsmod.c \
>>  tools/rmmod.c tools/insmod.c \
>>  tools/modinfo.c tools/modprobe.c \
>> -tools/depmod.c tools/log.h tools/log.c
>> +tools/depmod.c tools/log.h tools/log.c \
>> +tools/static-nodes.c
>>  tools_kmod_LDADD = libkmod/libkmod-util.la \
>>libkmod/libkmod.la
>>
>> @@ -211,7 +226,8 @@ testsuite-distclean:
>>  DISTCLEAN_LOCAL_HOOKS += testsuite-distclean
>>  EXTRA_DIST += testsuite/rootfs-pristine
>>
>> -DISTCHECK_CONFIGURE_FLAGS=--enable-gtk-doc --sysconfdir=/etc --with-zlib
>> +DISTCHECK_CONFIGURE_FLAGS=--enable-gtk-doc --sysconfdir=/etc --with-zlib \
>> + 
>> --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
>>
>>  distclean-local: $(DISTCLEAN_LOCAL_HOOKS)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 566b317..af5ed52 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -76,6 +76,13 @@ AS_IF([test "x$with_zlib" != "xno"], [
>> AC_MSG_NOTICE([zlib support not requested])
>>  ])
>>
>> +AC_ARG_WITH([systemdsystemunitdir],
>> +AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory 
>> for systemd service files]),
>> +[], [with_systemdsystemunitdir=$($PKG_CONFIG 
>> --variable=systemdsystemunitdir systemd)])
>> +if test "x$with_systemdsystemunitdir" != xno; then
>> +AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])
>> +fi
>> +AM_CONDITIONAL(HAVE_SYSTEMD, [test -n "$with_systemdsystemunitdir" -a 
>> "x$with_systemdsystemunitdir" != xno ])
>>
>>  #
>>  # --enable-
>> @@ -200,6 +207,7 @@ AC_MSG_RESULT([
>> compiler:   ${CC}
>> cflags: ${with_cflags} ${CFLAGS}
>> ldflags:${with_ldflags} ${LDFLAGS}
>> +   systemdsystemunitdir:   ${with_systemdsystemunitdir}
>>
>> tools:  ${enable_tools}
>> logging:${enable_logging}
>> diff --git a/tools/kmod-static-nodes.service.in 
>> b/tools/kmod-static-nodes.service.in
>> new file mode 100644
>> index 000..be8482e
>> --- /dev/null
>> +++ b/tools/kmod-static-nodes.service.in
>
> I'm not sure we want th

[systemd-devel] [PATCH v3] tools: add static-nodes tool

2013-04-16 Thread Tom Gundersen 
This tool reads modules.devname from the current kernel directory and outputs
the information. By default in a human-readable format, and optionally in
machine-readable formats.

For now only the tmpfiles.d(5) format is supported, but more could easily be
added in the future if there is a need.

This means nothing but kmod needs to reads the private files under
/lib/modules/. In particular systemd-udevd can stop reading modules.devname.

Cc: 
Cc: tools: static-nodes
---

v3: dropped the systemd integration for now, we can decide on that separately
added human-readable format and use this by default
added a --format= switch to get the tmpfiles format

 Makefile.am  |   3 +-
 tools/kmod.c |   1 +
 tools/kmod.h |   1 +
 tools/static-nodes.c | 176 +++
 4 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 tools/static-nodes.c

diff --git a/Makefile.am b/Makefile.am
index fe4c769..b1bfd59 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -110,7 +110,8 @@ noinst_SCRIPTS = tools/insmod tools/rmmod tools/lsmod \
 tools_kmod_SOURCES = tools/kmod.c tools/kmod.h tools/lsmod.c \
 tools/rmmod.c tools/insmod.c \
 tools/modinfo.c tools/modprobe.c \
-tools/depmod.c tools/log.h tools/log.c
+tools/depmod.c tools/log.h tools/log.c \
+tools/static-nodes.c
 tools_kmod_LDADD = libkmod/libkmod-util.la \
   libkmod/libkmod.la
 
diff --git a/tools/kmod.c b/tools/kmod.c
index ebb8875..347bb7d 100644
--- a/tools/kmod.c
+++ b/tools/kmod.c
@@ -37,6 +37,7 @@ static const struct kmod_cmd kmod_cmd_help;
 static const struct kmod_cmd *kmod_cmds[] = {
&kmod_cmd_help,
&kmod_cmd_list,
+   &kmod_cmd_static_nodes,
 };
 
 static const struct kmod_cmd *kmod_compat_cmds[] = {
diff --git a/tools/kmod.h b/tools/kmod.h
index 80fa4c2..68a646a 100644
--- a/tools/kmod.h
+++ b/tools/kmod.h
@@ -35,5 +35,6 @@ extern const struct kmod_cmd kmod_cmd_compat_modprobe;
 extern const struct kmod_cmd kmod_cmd_compat_depmod;
 
 extern const struct kmod_cmd kmod_cmd_list;
+extern const struct kmod_cmd kmod_cmd_static_nodes;
 
 #include "log.h"
diff --git a/tools/static-nodes.c b/tools/static-nodes.c
new file mode 100644
index 000..3d0582a
--- /dev/null
+++ b/tools/static-nodes.c
@@ -0,0 +1,176 @@
+/*
+ * kmod-static-nodes - manage modules.devname
+ *
+ * Copyright (C) 2004-2012 Kay Sievers 
+ * Copyright (C) 2011-2013  ProFUSION embedded systems
+ * Copyright (C) 2013 Tom Gundersen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "libkmod-util.h"
+
+#include "kmod.h"
+
+static const char cmdopts_s[] = "o:f:h";
+static const struct option cmdopts[] = {
+{ "output", required_argument, 0, 'o'},
+{ "format", required_argument, 0, 'f'},
+{ "help", no_argument, 0, 'h'},
+{ },
+};
+
+static void help(void)
+{
+printf("Usage:\n"
+"\t%s static-nodes [options]\n"
+"\n"
+"kmod static-nodes outputs the static-node information of the 
currently running kernel.\n"
+"\n"
+"Options:\n"
+"\t-f, --format=FORMAT  use a machine-readable format\n"
+"\t-o, --output=FILEwrite output to file\n"
+"\t-h, --help   show this help\n"
+"\n"
+"Formats:\n"
+"  tmpfilesthe tmpfiles.d(5) format used by 
systemd-tmpfiles.\n",
+program_invocation_short_name);
+}
+
+static void write_human(FILE *out, char module[], char devname[], char type, 
unsigned int maj, unsigned int min)
+{
+fprintf(out,
+"Module: %s\n"
+"\tDevice node: /dev/%s\n"
+"\t\tType: %s device\n"
+"\t\tMajor: %u\n"
+"\t\tMinor: %u\n",
+module, devname, (type == 'c') ? "character" : 
"block", maj, min);
+return;
+}
+
+static void write_tmpfile(FILE *out, char devname[], char type, unsigned int 
maj, unsigned int min)
+{
+fprintf(out, "%c /dev/%s 0600 - - - %u:%u\n

Re: [systemd-devel] [PATCH 2/2] journal: get rid of LINE_MAX in sd_journal_printv*()

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 16, 2013 at 10:01:02AM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 22:30 did
> gyre and gimble:
> > Hm, I've now read the wikipedia page ;), and I see
> > that it's not possible. So I guess that's not a valid concern.
> 
> Wikipedia
> /Wi-key-pee-dia/
> 
> Noun
> 1. Repository of erroneous history information
> 2. Cyber-bullying web portal
> 3. The birthplace of the "socially engineered buffer overflow" where
> fake articles on defensive programming techniques lured developers into
> a false sense of security.
Apparently there's a homonym /wee-kee-pee-dia/:

4. The place where one can gather interesting facts about early
computing history, including 32bit machines and pae /pee-eh-ee/.

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

[systemd-devel] [PATCH] configure: use AC_CHECK_TOOL for objcopy, strings and gperf

2013-04-16 Thread Martin Jansa 
* using AC_PATH_TOOL does not allow to override it from shell environment
  which is useful when cross-compiling
* with external toolchain I have different HOST_PREFIX and HOST_SYS
  AC_PATH_TOOL is using HOST_SYS as prefix and fails to find objcopy
  which is available only as ${TARGET_PREFIX}objcopy then it tries
  objcopy without prefix which is found on host, but that objcopy
  does not work for !host (e.g. arm when building on x86) libs

Signed-off-by: Martin Jansa 
---
 configure.ac | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 33b0ca9..519f1a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -86,9 +86,9 @@ GOBJECT_INTROSPECTION_CHECK([1.31.1])
AM_CONDITIONAL([HAVE_INTROSPECTION], [false])
enable_introspection=no])
 
-AC_PATH_TOOL(OBJCOPY, objcopy)
-AC_PATH_TOOL(STRINGS, strings)
-AC_PATH_TOOL(GPERF, gperf)
+AC_CHECK_TOOL(OBJCOPY, objcopy)
+AC_CHECK_TOOL(STRINGS, strings)
+AC_CHECK_TOOL(GPERF, gperf)
 if test -z "$GPERF" ; then
 AC_MSG_ERROR([*** gperf not found])
 fi
-- 
1.8.1.5

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

Re: [systemd-devel] systemd-nspawn

2013-04-16 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Apr 16, 2013 at 09:54:29AM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 19:48 did
> gyre and gimble:
> > On Mon, Apr 15, 2013 at 08:36:33PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Mon, Apr 15, 2013 at 02:31:56PM -0300, Chir0n wrote:
> >>> # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer
> >>> --disablerepo='*' --enablerepo=fedora install systemd passwd yum
> >>> fedora-release vim-minimal
> >>> # systemd-nspawn -bD
> >>> /srv/mycontainer
> >>
> >>   sudo nsenter -t $PID -m -u -i -n -p /bin/bash
> > Hm, if I say 'halt' in this bash window, I see
> > 
> > bash-4.2# halt
> > bash-4.2# [1]  + 14306 suspended (signal)  sudo nsenter -t 13221 -m -u -i 
> > -n -p /bin/bash
> > 
> > and the container's init hangs after 'All filesystems unmounted.'.
> > 
> > Only when I do 'fg', halt resume and systemd-nspawn quits.
> > 
> > Apparrently only happens rarely (1/5 so far).
> > 
> > What's going on?
> 
> Isn't "halt" meant to, well, halt? Perhaps it behaves differently under
> nspawn but I thought that was the primary difference between "halt" and
> "poweroff"
Ee, yeah, the system is supposed to halt and it's not doing that :)

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

Re: [systemd-devel] [PATCH 2/2] journal: get rid of LINE_MAX in sd_journal_printv*()

2013-04-16 Thread Colin Guthrie 
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 22:30 did
gyre and gimble:
> Hm, I've now read the wikipedia page ;), and I see
> that it's not possible. So I guess that's not a valid concern.

Wikipedia
/Wi-key-pee-dia/

Noun
1. Repository of erroneous history information
2. Cyber-bullying web portal
3. The birthplace of the "socially engineered buffer overflow" where
fake articles on defensive programming techniques lured developers into
a false sense of security.

:p

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Boot Service on Select Motherboard Only

2013-04-16 Thread Colin Guthrie 
'Twas brillig, and systemdki...@yopmail.com at 15/04/13 23:03 did gyre
and gimble:
> Question: how to boot ntpd.service on one PC and not others from the
> same USB stick.
> 
> Network Time Service computes clock tweaks for a motherboard. The idea
> is to run it on just one motherboard brand/model, or maybe serial
> number. If the USB stick boots another PC, then ntpd is bypassed,
> because the recorded values on disk are irrelevant and wrong.
> 
> The issues may well have more to do with udev than systemd, but I'd
> appreciate guidance. It would be nice to use stock ntpd.service, but I
> don't know if systemd can manage, or how a custom service may look if
> not.

Looks like something you could detect with a udev rule somewhere (i.e.
matching on some hw identifier) which in turn spawns the systemd unit.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

Re: [systemd-devel] systemd-nspawn

2013-04-16 Thread Colin Guthrie 
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 15/04/13 19:48 did
gyre and gimble:
> On Mon, Apr 15, 2013 at 08:36:33PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Apr 15, 2013 at 02:31:56PM -0300, Chir0n wrote:
>>> # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer
>>> --disablerepo='*' --enablerepo=fedora install systemd passwd yum
>>> fedora-release vim-minimal
>>> # systemd-nspawn -bD
>>> /srv/mycontainer
>>
>>   sudo nsenter -t $PID -m -u -i -n -p /bin/bash
> Hm, if I say 'halt' in this bash window, I see
> 
> bash-4.2# halt
> bash-4.2# [1]  + 14306 suspended (signal)  sudo nsenter -t 13221 -m -u -i -n 
> -p /bin/bash
> 
> and the container's init hangs after 'All filesystems unmounted.'.
> 
> Only when I do 'fg', halt resume and systemd-nspawn quits.
> 
> Apparrently only happens rarely (1/5 so far).
> 
> What's going on?

Isn't "halt" meant to, well, halt? Perhaps it behaves differently under
nspawn but I thought that was the primary difference between "halt" and
"poweroff"

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
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

2013-04-16 Thread Colin Guthrie 
'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.


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2013-04-16 Thread Koen Kooi 
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  /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?

regards,

Koen

[1] https://plus.google.com/100242854243155306943/posts/ddoZgvLnixa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel