Re: [systemd-devel] [PATCH 2/2] systemctl: add systemctl cat

[Zbigniew Jędrzejewski-Szmek]

On Sat, Nov 23, 2013 at 07:52:53PM -0800, Shawn Landden wrote:
 ---
  TODO  |  2 --
  src/shared/fileio.c   | 73 -
  src/shared/fileio.h   |  1 +
  src/systemctl/systemctl.c | 91 
 +++
  4 files changed, 164 insertions(+), 3 deletions(-)
 
 diff --git a/TODO b/TODO
 index 6ba4b31..7c6003b 100644
 --- a/TODO
 +++ b/TODO
 @@ -125,8 +125,6 @@ Features:
  
  * optimize the cgroup propagation bits, especially unit_get_members_mask(), 
 cgroup_context_get_mask()
  
 -* systemctl cat or systemctl view command or or so, that cats the 
 backing unit file of a service, plus its drop-ins and shows them in a pager
 -
  * rfkill,backlight: we probably should run the load tools inside of the udev 
 rules so that the state is properly initialized by the time other software 
 sees it
  
  * tmpfiles: when applying ownership to /run/log/journal, also do this for 
 the journal fails contained in it
 diff --git a/src/shared/fileio.c b/src/shared/fileio.c
 index 733b320..ac1b409 100644
 --- a/src/shared/fileio.c
 +++ b/src/shared/fileio.c
 @@ -20,6 +20,7 @@
  ***/
  
  #include unistd.h
 +#include sys/sendfile.h
  #include fileio.h
  #include util.h
  #include strv.h
 @@ -117,6 +118,77 @@ int read_one_line_file(const char *fn, char **line) {
  return 0;
  }
  
 +ssize_t sendfile_full(int out_fd, const char *fn) {
 +_cleanup_fclose_ FILE *f;
 +struct stat st;
 +int r;
 +ssize_t s;
 +
 +size_t n, l;
 +_cleanup_free_ char *buf = NULL;
 +
 +assert(out_fd  0);
 +assert(fn);
 +
 +f = fopen(fn, r);
 +if (!f)
 +return -errno;
 +
 +r = fstat(fileno(f), st);
 +if (r  0)
 +return -errno;
 +
 +s = sendfile(out_fd, fileno(f), NULL, st.st_size);
 +if (s  0)
 +if (errno == EINVAL || errno == ENOSYS) {
 +/* continue below */
 +} else
 +return -errno;
 +else
 +return s;
 +
 +/* sendfile() failed, fall back to read/write */
 +
 +/* Safety check */
 +if (st.st_size  4*1024*1024)
 +return -E2BIG;
 +
 +n = st.st_size  0 ? st.st_size : LINE_MAX;
 +l = 0;
 +
 +while (true) {
 +char *t;
 +size_t k;
 +
 +t = realloc(buf, n);
 +if (!t)
 +return -ENOMEM;
Can you convert this to GREEDY_REALLOC? It should be a bit simpler then.

 +
 +buf = t;
 +k = fread(buf + l, 1, n - l, f);
 +
 +if (k = 0) {
 +if (ferror(f))
 +return -errno;
 +
 +break;
 +}
 +
 +l += k;
 +n *= 2;
 +
 +/* Safety check */
 +if (n  4*1024*1024)
 +return -E2BIG;
 +}
 +
 +r = write(out_fd, buf, l);
 +if (r  0)
 +return -errno;
 +
 +return (ssize_t) l;
 +}
 +
  int read_full_file(const char *fn, char **contents, size_t *size) {
  _cleanup_fclose_ FILE *f = NULL;
  size_t n, l;
 @@ -168,7 +240,6 @@ int read_full_file(const char *fn, char **contents, 
 size_t *size) {
  
  buf[l] = 0;
  *contents = buf;
 -buf = NULL;
  
  if (size)
  *size = l;
 diff --git a/src/shared/fileio.h b/src/shared/fileio.h
 index 59e4150..06c2887 100644
 --- a/src/shared/fileio.h
 +++ b/src/shared/fileio.h
 @@ -31,6 +31,7 @@ int write_string_file_atomic(const char *fn, const char 
 *line);
  
  int read_one_line_file(const char *fn, char **line);
  int read_full_file(const char *fn, char **contents, size_t *size);
 +ssize_t sendfile_full(int out_fd, const char *fn);
  
  int parse_env_file(const char *fname, const char *separator, ...) _sentinel_;
  int load_env_file(const char *fname, const char *separator, char ***l);
 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 6cb7a82..18d5e45 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -3665,6 +3665,95 @@ static int show_all(
  return 0;
  }
  
 +static int cat(sd_bus *bus, char **args) {
 +int r = 0;
 +char **name;
 +
 +_cleanup_free_ char *unit = NULL, *n = NULL;
 +
 +assert(bus);
 +assert(args);
 +
 +pager_open_if_enabled();
 +
 +STRV_FOREACH(name, args+1) {
 +_cleanup_free_ char *fragment_path = NULL;
 +_cleanup_strv_free_ char **dropin_paths = NULL;
 +sd_bus_error error;
 +FILE *stdout;
This variable appears unused.

 +char **path;
 +
 +n = unit_name_mangle(*name);
 +if (!n)
 +  

Re: [systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 11:44 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 Looks pretty good. Commented on the invidiaul patches, but mostly looks
 good.

 I am not sure about the whole approach of making this a potentially
 public library though... Especially the monitor stuff sounds so
 specific. Commiting to a stable API for that given that there are very
 few other projects who could ever make use of this sounds dangerous at
 best. Especially since the api exposes bit values for enums and things,
 which makes me especially afraid...

I have no short-term plan to export sd-gfx. It's just like the 3rd
time I happen to write a DRM abstraction and I really don't wanna do
that again. Hence, I thought putting it into sd-gfx would reduce the
burden to export it eventually. Furthermore, as there'll be like 5
daemons using it, it would be nice to have a clean API even if it's
only systemd-internal (it forces one to write better code, imho). Last
but not least, it makes debugging easier if there's a clean cut
between sd-gfx and each application.

But: the current API will never get exported as it is. Obviously, the
monitor (and probably font) is better kept internal. But I see no
reason to add sd-gfx-internal.h / sd-gfx-internal.la now. In case we
ever export it, we would have to decide which parts to split off
(which is a rather mechanical tasks, so no reason to account for it
right now).

So lets just say I hate camel-case object-names so I went for
libsystemd-gfx to have an excuse to use
lower-case-separated-by-underscore names, right? Lets treat sd-gfx as
internal library for now.

A few comments beforehand:
 - regarding logging in libraries: I *want* verbose errors/warnings in
sd-gfx. Especially if modesetting, keymap-compilation or bus-requests
fail, I want some rather verbose messages in the log. Considering that
if a single page-flip fails, I will not abort but continue the modeset
(you don't want your console to abort due to minor timing issues in
the DRM driver, right?), so the application might not even get an
-EXYZ error value. I tried adding a -log_fn() like libudev, but then
again, sd-gfx is internal so I skipped that and just called log_meta()
directly. Is that fine for now? If not, I can change all these to
log_debug() and make the applications more verbose.
- new0(), zero(), ..., yepp, kay already told me but I forgot.. I will
fix them up.
- moving out parameters to the end... will do so.

Thanks for the review. Few more comments on the individual patches.
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC 02/12] ring: add basic ring-buffer helper

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 10:53 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 +void ring_flush(Ring *r) {
 +r-start = 0;
 +r-end = 0;
 +}
 +
 +void ring_clear(Ring *r) {
 +free(r-buf);
 +memset(r, 0, sizeof(*r));

 zero(*r) is a tiny bit nicer.

 +}
 +
 +/*
 + * Resize ring-buffer to size @nsize. @nsize must be a power-of-2, otherwise
 + * ring operations will behave incorrectly.
 + */
 +static int ring_resize(Ring *r, size_t nsize) {
 +char *buf;

 Hmm, char suggests a bit that this is about text. But it's mostly raw
 bytes, right? So I'd always use uint8_t for these things, it feels so
 much rawer... Not that it would matter much...

Yepp, uint8_t it is.

 +
 +buf = malloc(nsize);
 +if (!buf)
 +return -ENOMEM;
 +
 +if (r-end == r-start) {
 +r-end = 0;
 +r-start = 0;

 Hmm, so if end and start match the buffer is empty? So you can never
 fill it entirely? Or am I missing something?

 I'd always maintain start index + fill level instead of a start
 index + end index, to avoid the confusion regarding the fill-level...

Well, start+end is how ring-buffers were implemented historically. I
think the reason is that wrapping over is easier to calculate for
indices than for lengths (you cannot do: r-len = (r-len + 1) 
RING_MASK). Even all examples on wikipedia use two indices
(http://en.wikipedia.org/wiki/Circular_buffer). And all kernel
ring-buffers use start/end..

Also note that the one special byte is not unused. It cannot be
filled, in case the buffer is full, that's right. But it's used during
normal buffer-operation if the occupied space moves along the
buffer.

If you can find me circular/ring-buffers that use start+len, I can fix
that up. Otherwise, I'd rather keep this close to existing
implementations. Besides, a lot of wrapping calculations get easier
if start/end are restricted by RING_MASK, which wouldn't be the case
for len.

 + * Push @len bytes from @u8 into the ring buffer. The buffer is resized if 
 it
 + * is too small. -ENOMEM is returned on OOM, 0 on success.
 + */
 +int ring_push(Ring *r, const char *u8, size_t len) {

 So, here you call the parameter u8 suggesting unsigned bytes, but you
 use char, which indicates a text string, and is
 signed... Confusing. I'd recommend using const void * here by default,
 since all types implicitly downgrade to const void* without casting...

I usually use u8 for utf8.. no idea where that came from. But yes,
void* makes sense for input/output and uint8_t* for internal
operations.

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

Re: [systemd-devel] [RFC 02/12] ring: add basic ring-buffer helper

[David Herrmann]

Hi

On Thu, Nov 28, 2013 at 1:27 AM, Lucas De Marchi
lucas.de.mar...@gmail.com wrote:
 On Wed, Nov 27, 2013 at 4:48 PM, David Herrmann dh.herrm...@gmail.com wrote:
 This adds a very straightforward ring-buffer implementation to
 libsystemd-shared. Ring-buffers allow pushing data to, and pulling data
 from, both ends of a buffer without modifying existing/remaining buffer
 content. This is very useful for network buffers and asynchronous writes.

 This implementation only contains the most basic functions to push data
 onto the end of the buffer and pull data from the front. More helpers may
 be added once needed.
 ---
  Makefile.am   |   2 +
  src/shared/ring.c | 213 
 ++
  src/shared/ring.h |  54 ++
  3 files changed, 269 insertions(+)
  create mode 100644 src/shared/ring.c
  create mode 100644 src/shared/ring.h

 diff --git a/Makefile.am b/Makefile.am
 index 0119751..4aa2bdf 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -768,6 +768,8 @@ libsystemd_shared_la_SOURCES = \
 src/shared/net-util.h \
 src/shared/errno-list.c \
 src/shared/errno-list.h \
 +   src/shared/ring.h \
 +   src/shared/ring.c \
 src/shared/syscall-list.c \
 src/shared/syscall-list.h

 diff --git a/src/shared/ring.c b/src/shared/ring.c
 new file mode 100644
 index 000..f60f098
 --- /dev/null
 +++ b/src/shared/ring.c
 @@ -0,0 +1,213 @@
 +/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
 +
 +/***
 +  This file is part of systemd.
 +
 +  Copyright 2013 David Herrmann dh.herrm...@gmail.com
 +
 +  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.
 +
 +  systemd 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
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public License
 +  along with systemd; If not, see http://www.gnu.org/licenses/.
 +***/
 +
 +#include errno.h
 +#include stdlib.h
 +#include string.h
 +#include sys/uio.h
 +
 +#include ring.h
 +#include util.h
 +
 +#define RING_MASK(_r, _v) ((_v)  ((_r)-size - 1))
 +
 +void ring_flush(Ring *r) {
 +r-start = 0;
 +r-end = 0;
 +}
 +
 +void ring_clear(Ring *r) {
 +free(r-buf);
 +memset(r, 0, sizeof(*r));
 +}
 +
 +/*
 + * Resize ring-buffer to size @nsize. @nsize must be a power-of-2, otherwise
 + * ring operations will behave incorrectly.
 + */
 +static int ring_resize(Ring *r, size_t nsize) {
 +char *buf;
 +
 +buf = malloc(nsize);
 +if (!buf)
 +return -ENOMEM;
 +
 +if (r-end == r-start) {
 +r-end = 0;
 +r-start = 0;
 +} else if (r-end  r-start) {
 +memcpy(buf, r-buf[r-start], r-end - r-start);
 +
 +r-end -= r-start;
 +r-start = 0;
 +} else {
 +memcpy(buf, r-buf[r-start], r-size - r-start);
 +memcpy(buf[r-size - r-start], r-buf, r-end);
 +
 +r-end += r-size - r-start;
 +r-start = 0;
 +}
 +
 +free(r-buf);
 +r-buf = buf;
 +r-size = nsize;
 +
 +return 0;
 +}
 +
 +/* Compute next higher power-of-2 of @v. Returns 4096 in case v is 0. */
 +static size_t ring_pow2(size_t v) {
 +size_t i;
 +
 +if (!v)
 +return 4096;
 +
 +--v;
 +
 +for (i = 1; i  8 * sizeof(size_t); i *= 2)
 +v |= v  i;
 +
 +return ++v;

 If you are interested, take a look in
 https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=3ba7f59e84857eb4dbe56a68fc7a3ffe8a650393
 for a shorter and faster version of this.

Yepp, that one looks good. Didn't know there was a builtin to count
leading zeros.

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

Re: [systemd-devel] [RFC 03/12] bus: add two new bus_*_map_*_properties() helpers

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 10:58 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 +/* skip interface, but allow callers to do that themselves */
 +sd_bus_message_skip(m, s);

 This feels a bit like taping over bugs. I'd suggest adding an additional
 parameter const char **interface to the function which if non-NULL is
 updated with the interface name. If it is NULL we'd just skip th
 interface as above...

 if (interface)
   r = sd_bus_message_read(s, interface);
 else
   r = sd_bus_message_skip(m, s);

That doesn't work. The caller wants interface before calling this
helper. You usually pass a different map-array depending on the
interface, right?

I can just require the caller to do the skip/read themselves?

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

Re: [systemd-devel] [RFC 05/12] gfx: add sd-gfx library with unifont section

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 11:11 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 This patch introduces sd-gfx, a systemd-internal library dealing with all
 these things. Note that it is designed to be exported some day, but for
 now we keep it internal.
 While the library itself will be kept small and almost self-contained, it
 is designed to be extensible and can be used in rather complex graphics
 applications. For systemd, we plan to add a basic emergency-console, an
 initrd password-query, kernel-log-screen and a fallback login-screen.
 These allow booting without CONFIG_VT and provide a basic system for
 seats without VTs (either CONFIT_VT=n or seats != seat0).

 BTW, one more use of this I'd like to see: if we boot-up and detect that
 no AC and very low battery we should show a pretty screen and block the
 boot until AC is plugged in or the user hits some magic key...

Yepp, sounds good. Would be like 200 lines to write that, I guess.

 +static int gfx_glyph_render(gfx_glyph *g, unsigned int ppi, const struct 
 unifont_data *u) {
 +g-buf.width = u-cells * unifont_width;
 +g-buf.height = unifont_height;
 +g-buf.stride = u-cells * unifont_stride;
 +g-buf.format = SD_GFX_BUFFER_FORMAT_A1;
 +
 +g-buf.data = calloc(unifont_height, unifont_max_cells * 
 unifont_stride);
 +if (!g-buf.data)
 +return -ENOMEM;

 Nice, this must be the first use of alloc() I have ever seen that
 actually takes benefit of the weird parameters it takes ;-)

Do I get an award or something? :)

 +
 +gfx_glyph_blend(g, ppi, u);
 +return 0;
 +}
 +
 +int sd_gfx_font_new(sd_gfx_font **out, unsigned int ppi) {

 Hmm, so far we followed the rough rule that parameters we pass out are
 listed last on the function parameter list.

 int sd_gfx_font_new(unsigned ppi, sd_gfx_fond **out);



 +sd_gfx_font *font;
 +int r;
 +
 +ppi = CLAMP(ppi, 10U, 1000U);
 +
 +font = calloc(1, sizeof(*font));

 font = new0(sd_gfx_font, 1);

I actually dislike new0() to require the type. I'd prefer:
  font = new0(font);
But this is horrible to read, so I went with calloc(1, sizeof(*xyz));
But the systemd code-base seems to use new0() consistently so I can
adjust all my calloc()s if you want? I'm fine with keeping consistency
here.

 +font-glyphs = hashmap_new(trivial_hash_func, trivial_compare_func);
 +if (!font-glyphs) {
 +free(font);
 +return log_oom();

 Hmm, library code should never log. Please just return -ENOMEM
 here. log_oom() should be used in main programs only really...

 +void sd_gfx_font_free(sd_gfx_font *font) {
 +gfx_glyph *g;

 For public APIs we are pretty defensive and check all parameters we
 take. Given you kinda made this a public library it might make sense to
 follow that rule here, too. assert_return() is particularly useful for
 this. (Well, not for the instance above, bug if you return a negative
 errno it is super-useful).

I wanna avoid these in fast-paths (the blending/blitting functions)
but for all the other ones, I can add assert()s.

 Most destructors we have tend to accept NULL pointers too. It makes
 clean-up code a lot easier (especially in combination with gcc cleanup
 attributes). libc free() takes NULL pointers too, so this is a natural
 extension.

Oh, I know. This is presumably the only destructor where I somehow
forgot that. Fixed.

 +void sd_gfx_font_render(sd_gfx_font *font, uint32_t id, const uint32_t 
 *ucs4, size_t len, sd_gfx_buffer **out) {
 +const struct unifont_data *u;
 +gfx_glyph *g;
 +
 +if (!len)
 +goto error;
 +
 +if (!id)
 +id = *ucs4;
 +
 +g = hashmap_get(font-glyphs, INT_TO_PTR(id));
 +if (g)
 +goto out;
 +
 +g = calloc(1, sizeof(*g));

 g = new(gfx_glyph, 1);

 +if (!g) {
 +log_oom();
 +goto error;
 +}
 +
 +u = unifont_get(*ucs4);
 +if (gfx_glyph_render(g, font-ppi, u)  0) {
 +log_oom();
 +free(g);
 +goto error;
 +}
 +
 +while (--len) {
 +u = unifont_get(*++ucs4);
 +gfx_glyph_blend(g, font-ppi, u);
 +}
 +
 +if (hashmap_put(font-glyphs, INT_TO_PTR(id), g)  0) {
 +log_oom();
 +free(g-buf.data);
 +free(g);
 +goto error;
 +}
 +
 +goto out;
 +
 +error:
 +g = font-fallback;
 +out:
 +*out = g-buf;
 +}

 Hmm, we so far followed to rule to not clobber return parameters on
 failure. i.e. we try hard to fill any return values in until we know
 that nothing can fail anymore. This makes the contract for the caller
 much easier who can refrain from freeing/resetting any parameters if a
 call failed...

Re: [systemd-devel] [RFC 06/12] gfx: add keyboard layer

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 11:17 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 +
 +enum {
 +SD_GFX__LED_NUML,
 +SD_GFX__LED_CAPSL,
 +SD_GFX__LED_SCROLLL,
 +SD_GFX__LED_COUNT,
 +};

 Double underscores?

Yes.

 +
 +struct sd_gfx_kbd {
 +char *name;
 +struct libevdev *evdev;
 +int fd;
 +struct xkb_state *state;
 +sd_event *ev;
 +sd_event_source *fd_source;
 +sd_event_source *timer;
 +sd_gfx_kbd_event_fn event_fn;
 +void *data;
 +void *fn_data;
 +
 +unsigned int delay;
 +unsigned int rate;
 +
 +unsigned int sym_count;
 +sd_gfx_kbd_event event;
 +sd_gfx_kbd_event repeat;
 +
 +xkb_mod_index_t xkb_mods[SD_GFX__MOD_COUNT];
 +xkb_led_index_t xkb_leds[SD_GFX__LED_COUNT];
 +
 +unsigned int awake : 1;
 +unsigned int need_sync : 1;
 +unsigned int repeating : 1;

 If these are bools, then make them bools! C99 bools (i.e. the type
 bool from stdbool.h) are awesome for bit fields! [ Please use C99 bools
 everywhere in internal code, and int as bool type for public APIs,
 since that's what pre-C99 code usually did, despite the stupidity this
 results in when people use bit fields ]

You can use _Bool/bool for bitfields? Didn't know that. I always use
bool for boolean values, I only thought they don't work for
bitfields. Will fix that up.

Thanks
David

 +if (r  0) {
 +if (r == -EACCES)
 +log_debug(kbd %s: EACCES on led-update, 
 kbd-name);
 +else
 +log_error(kbd %s: cannot update leds: %d,
 +  kbd-name, r);

 Please do not log from libraries. (Well, except when that's the primary
 purpose of your function, or when you do so on LOG_DEBUG level, since
 that is not visible normally anyway.)

 Lennart

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

Re: [systemd-devel] [RFC 07/12] gfx: add graphics layer

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 11:24 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 +typedef struct gfx_config_pipe gfx_config_pipe;
 +typedef struct gfx_connector gfx_connector;
 +typedef struct gfx_encoder gfx_encoder;
 +
 +/* clock-wise framebuffer rotation */
 +enum {
 +GFX_ROTATE_0,
 +GFX_ROTATE_90,
 +GFX_ROTATE_180,
 +GFX_ROTATE_270,
 +};
 +
 +struct gfx_config_pipe {
 +unsigned int config_id;
 +char **connectors;
 +char *mode;
 +unsigned int rotate;
 +
 +unsigned int disable : 1;

 C99 bool plz! (here and everywhere else...)

 +memset(handles, 0, sizeof(handles));
 +memset(strides, 0, sizeof(strides));
 +memset(offsets, 0, sizeof(offsets));

 zero(handles) is so much nicer... (here and everywhere...)

 +static int gfx_pipe_new(sd_gfx_pipe **out, sd_gfx_card *card, drmModeCrtc 
 *crtc, unsigned int connector_count) {
 +sd_gfx_pipe *pipe;
 +int r;
 +
 +pipe = calloc(1, sizeof(*pipe));
 +if (!pipe)
 +return log_oom();
 +
 +pipe-ref = 1;
 +pipe-card = card;
 +pipe-id = card-pipe_ids;
 +pipe-crtc_id = crtc-crtc_id;
 +pipe-page_flip_cnt = 1;
 +
 +pipe-connectors = calloc(connector_count, 
 sizeof(*pipe-connectors));
 +if (!pipe-connectors) {
 +r = log_oom();
 +goto err_pipe;
 +}
 +
 +pipe-want_connectors = calloc(connector_count, 
 sizeof(*pipe-want_connectors));
 +if (!pipe-want_connectors) {
 +r = log_oom();
 +goto err_connectors;
 +}
 +
 +pipe-connector_ids = calloc(connector_count, 
 sizeof(*pipe-connector_ids));
 +if (!pipe-connector_ids) {
 +r = log_oom();
 +goto err_want_connectors;
 +}
 +
 +pipe-want_connector_ids = calloc(connector_count, 
 sizeof(*pipe-want_connector_ids));
 +if (!pipe-want_connector_ids) {
 +r = log_oom();
 +goto err_connector_ids;
 +}
 +
 +r = gfx_plane_new_primary(pipe-primary, pipe);
 +if (r  0)
 +goto err_want_connector_ids;
 +
 +gfx_pipe_refresh(pipe, crtc);
 +
 +*out = pipe;
 +return 0;
 +
 +err_want_connector_ids:
 +free(pipe-want_connector_ids);
 +err_connector_ids:
 +free(pipe-connector_ids);
 +err_want_connectors:
 +free(pipe-want_connectors);
 +err_connectors:
 +free(pipe-connectors);
 +err_pipe:
 +free(pipe);
 +return r;
 +}
 +

 For clean-up code like this I usually find it nicer to simply have a
 destructor function that is robust to destruct half-initialized objects
 and then just invoke this here.

Ouh, indeed. I use calloc() anyway, so I could just make this one
single goto. Or make the destructor robust and call it instead, yepp.
Fixed.

 +/* framebuffer */
 +
 +typedef void (*sd_gfx_fb_unlink_fn) (sd_gfx_fb *fb, void *fn_data);
 +typedef void (*sd_gfx_fb_unpin_fn) (sd_gfx_fb *fb, void *fn_data);

 For the types that actually feel like primitive types (in contrast to
 objects), we usually appended a libc style _t to our names.

Ouh, libudev uses udev_log_fn so I followed that style. I thought
that's what we use for callback-prototypes. Is that just a left-over
from pre-systemd times? I can change it all to _t, if it is.

Thanks
David

 I can't really say much about the actual drm stuff going on here, just
 my usualy whining about logging from lib code, C99 bools, zero()...

 Lennart

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

Re: [systemd-devel] [RFC 08/12] gfx: add monitor

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 11:34 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 While all previous sd-gfx interfaces are self-contained and can be used
 directly on selected devices, this adds an interface to connect them all
 together. The sd_gfx_monitor can be used to monitor a session for device
 hotplugging and other device events. It is optional but is supposed to be
 the foundation of all systemd-helpers that use sd-gfx.

 The main function of sd_gfx_monitor is to watch the system for udev-events
 of gpus and keyboards. For each of them, an sd_gfx_card or sd_gfx_kbd
 device is created and advertised to the application. Furthermore,
 systemd-localed integration is provided so keymap changes are immediately
 noticed and applied to active sd_gfx_kbd devices.

 An sd_gfx_monitor can run in two modes:
  - system mode: In system mode, no dbus, no logind and localed are assumed
 to be running and seat-information is ignored. This mode
 allows to run applications in initrds or emergency
 situations. It simply takes all devices it can find and
 tries to use them. However, this obviously requires to be
 root, otherwise, devices cannot be accessed.
  - session mode: In session mode, the monitor assumes to be running in an
  logind session. If not, it returns an error. The monitor
  will call TakeControl on the active session and get
  device-access via logind. Only devices attached to the
  session will be used and no you're not required to be
  root. The caller is responsible of setting up the session
  before spawning the monitor.

 Note that monitor setup is a blocking call as it is usually called during
 application setup (and making that async would have no gain). But at
 runtime, the monitor runs all dbus-calls and other calls asynchronously.

 The sd_gfx_monitor interface is designed for fallbacks and basic system
 applications. It does not allow per-device configurations or any advanced
 eye-candy. It is trimmed for usability and simplicity, and it is optimized
 for fallback/emergency situations. Thus, the monitor provides some basic
 configuration options via the kernel command-line. systemd.gpus= allows to
 filter the GPUs to be used (by default, *all* connected GPUs are used
 together). systemd.keymap= allows to change the keymap in case localed is
 configured incorrectly.

 The sd_gfx_monitor interfaces has the nice side-effect that all
 applications using it will share the same configuration. They will have
 the same monitor-setup, the same keymap setup and use the same devices. So
 if you system-boot fails, you can set systemd.XY= to boot with a working
 configuration and all systemd-internal applications will just work.

 If we ever export sd-gfx, most users probably want more configurability
 (like per-device keymaps) and thus will not use sd_gfx_monitor. However,
 for all fallbacks, it is the perfect base.

 Hmm, this bit sounds a bit too high-level for including it in a library,
 no? I mean, we can certainly share this bit inside of systemd, but this
 sounds too specialized to ever become a public lib, no?

Yepp. As said in my comment on 0/12, I squashed it all in a single
header for now. If we export it, this will get moved into gfx-util.h
or similar.

 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_UNIX_FD, fd);
 +if (r  0)
 +goto error;
 +
 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_BOOLEAN, paused);
 +if (r  0)
 +goto error;

 Why in two steps? sd_bus_message_read(m, hb, fd, paused) should work too?

Sweet! Fixed.

 +static int gfx_logind_resume_fn(sd_bus *bus, sd_bus_message *m, void *data, 
 sd_bus_error *err) {
 +sd_gfx_monitor *mon = data;
 +gfx_device *dev;
 +int r, fd;
 +uint32_t major, minor;
 +dev_t devt;
 +
 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_UINT32, major);
 +if (r  0)
 +goto error;
 +
 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_UINT32, minor);
 +if (r  0)
 +goto error;
 +
 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_UNIX_FD, fd);
 +if (r  0)
 +goto error;

 Same here... One call should suffice...

 +static int gfx_logind_pause_fn(sd_bus *bus, sd_bus_message *m, void *data, 
 sd_bus_error *err) {
 +sd_gfx_monitor *mon = data;
 +gfx_device *dev;
 +int r;
 +const char *type;
 +uint32_t major, minor;
 +dev_t devt;
 +
 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_UINT32, major);
 +if (r  0)
 +goto error;
 +
 +r = sd_bus_message_read_basic(m, SD_BUS_TYPE_UINT32, minor);
 +if (r  0)
 +goto error;
 +
 +

Re: [systemd-devel] [RFC 12/12] console: add systemd-consoled

[David Herrmann]

Hi

On Wed, Nov 27, 2013 at 11:39 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 27.11.13 19:48, David Herrmann (dh.herrm...@gmail.com) wrote:

 +
 +pid_t pty_new(unsigned short term_width, unsigned short term_height, 
 Terminal *t, Pty **out) {
 +Pty *pty;
 +pid_t pid;
 +int fd, comm[2], slave, r;
 +char d;
 +
 +pty = calloc(1, sizeof(*pty));
 +if (!pty)
 +return -ENOMEM;
 +
 +fd = posix_openpt(O_RDWR | O_NOCTTY | O_CLOEXEC | O_NONBLOCK);
 +if (fd  0) {
 +free(pty);
 +return -errno;
 +}
 +
 +r = sd_event_add_io(t-m-event,
 +fd,
 +EPOLLHUP | EPOLLERR | EPOLLIN | EPOLLOUT | 
 EPOLLET,
 +pty_io_fn,
 +pty,
 +pty-fd_source);
 +if (r  0) {
 +close(fd);
 +free(pty);
 +return r;
 +}
 +
 +r = sd_event_add_defer(t-m-event, pty_idle_fn, pty, 
 pty-idle_source);
 +if (r  0) {
 +sd_event_source_set_enabled(pty-fd_source, SD_EVENT_OFF);
 +sd_event_source_unref(pty-fd_source);
 +close(fd);
 +free(pty);
 +return r;
 +}
 +
 +r = pipe2(comm, O_CLOEXEC);
 +if (r  0) {
 +r = -errno;
 +sd_event_source_set_enabled(pty-idle_source, SD_EVENT_OFF);
 +sd_event_source_unref(pty-idle_source);
 +sd_event_source_set_enabled(pty-fd_source, SD_EVENT_OFF);
 +sd_event_source_unref(pty-fd_source);
 +close(fd);
 +free(pty);
 +return r;
 +}
 +
 +pid = fork();
 +if (pid  0) {
 +/* error */
 +pid = -errno;
 +close(comm[0]);
 +close(comm[1]);
 +sd_event_source_set_enabled(pty-idle_source, SD_EVENT_OFF);
 +sd_event_source_unref(pty-idle_source);
 +sd_event_source_set_enabled(pty-fd_source, SD_EVENT_OFF);
 +sd_event_source_unref(pty-fd_source);
 +close(fd);
 +free(pty);
 +return pid;

 Grr. Just define a label to jump to to clean everything up that is
 initialized, and skip over the bits that isn't. Duplicating the
 destruction logic on every if block is just wrong...

Closed-source developers get paid by number of lines, why don't get
open-source developers honored by number of lines? I would excel in
that category!

Fixed.

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

Re: [systemd-devel] [systemd-bugs] Russian translation for systemd

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 18, 2013 at 07:57:41AM +0600, Alexander E. Patrakov wrote:
 2013/11/18 Sergey Ptashnick 0comff...@inbox.ru:
  On 17.11.2013 16:34, Alexander E. Patrakov wrote:
  You translate host name as имя компьютера, both GDM and KDM translators
  use имя узла.
 
  In this case, IMHO, evidence and intuitivity have priority over consistency.
  Please tell if you think I'm wrong.
 
  You translate seat as терминал (which I already objected to), GDM
  translators use рабочее место, KDM is not seat-aware.
 
  Fixed.
 
  You translate authentication is required as необходимо пройти
  идентификацию, GDM translators use the word аутентификация, KDM 
  translators
  are inconsistent (use both terms).
 
  I have changed аутентификация-идентификация mainly for Julia.
  Reverted now.
 
 I don't have any objections now.
Hi,
I'm pushing this version now. Juliette's version doesn't include the catalog
translations (and was sent a bit later). Systemd hasn't really been used with
localisation before, so further fixes are propably required, and welcome.

Zbyszek

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

Re: [systemd-devel] French translation for systemd

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 27, 2013 at 08:43:09PM +0100, Sylvain Plantefeve wrote:
 Hi Gentlemen,
 
 Just a little ping to get fixed the few typos in the french translation
 of the journal's catalog.
 
 See the patch in attachment.
 
 Thanks!
Applied, thanks.

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

Re: [systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats

[David Herrmann]

Hi

On Tue, Nov 26, 2013 at 2:33 PM, Laércio de Sousa lbsous...@gmail.com wrote:
 David,

 Looking at GDM debug and gdm-simple-slave.c source file, as well as
 loginctl show-seat output. I guess that GDM only requests user session
 activation for seats with CanMultiSession=yes, but currently systemd-logind
 still sets CanMultiSession=no for my non-seat0 seats.

 Does seat_can_multi_session() heuristics need some improvement since generic
 multi-session was introduced?

 I've applied your last patch. I confirm it solves my problem for now.

Thanks for the confirmation. I pushed the revert to systemd-git so 209
will contain the fix. I will take care that it gets marked as fix for
208, too.

Regarding gdm: I guess we cannot rely on CanMultiSession here. It's to
risky that we break some other application. But maybe we can allow
desktop-managers to modify the CanMultiSession property. So if they
explicitly set it to 1 (which we don't do for seats without VTs), we
activate the new logic.

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

[systemd-devel] 'udevadm test' removes/adds by-id/by-path links

[Robert Milasan]

Hello,
  when running 'udevadm test /sys/block/sdb --action=remove' then links
  to the device node in /dev/disk/{by-id,by-path} are being removed and
  running udevadm test with action=add, the links are re-added.

robert@viper:~ ls -l /dev/disk/by-id/|grep sdb
lrwxrwxrwx 1 root root  9 Nov 28 11:13
usb-Corsair_Flash_Voyager_002557-0:0 - ../../sdb
lrwxrwxrwx 1 root root 10 Nov 28 10:50
usb-Corsair_Flash_Voyager_002557-0:0-part1 - ../../sdb1

robert@viper:~ sudo udevadm test /sys/block/sdb --action=remove
/dev/null 21
robert@viper:~ ls -l /dev/disk/by-id/|grep sdb
lrwxrwxrwx 1 root root 10 Nov 28 10:50
usb-Corsair_Flash_Voyager_002557-0:0-part1 - ../../sdb1

robert@viper:~ sudo udevadm test /sys/block/sdb --action=add
/dev/null 21
robert@viper:~ ls -l /dev/disk/by-id/|grep sdb
lrwxrwxrwx 1 root root  9 Nov 28 11:34
usb-Corsair_Flash_Voyager_002557-0:0 - ../../sdb
lrwxrwxrwx 1 root root 10 Nov 28 10:50
usb-Corsair_Flash_Voyager_002557-0:0-part1 - ../../sdb1

 As you can see on action=remove, the link to sdb device node has been
 removed and on action=add, the link as been re-added.

 As I am running 'udevadm test', I would think, that this is only a test
 and the links or anything related to this test suppose to be fake,
 meaning nothing really should be removed/added.

 Is this a known functionality of 'udevadm test' or it's a bug?

-- 
Robert Milasan

L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402  6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] man/crypttab.xml

[Kay Sievers]

On Thu, Nov 28, 2013 at 8:41 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Mon, Nov 25, 2013 at 12:31:24AM -0800, Lukas Nykryn wrote:
  man/crypttab.xml |2 --
  1 file changed, 2 deletions(-)

 New commits:
 commit 517dcac840fe8d5bf30a05c0084eff219af10a4a
 Author: Lukas Nykryn lnyk...@redhat.com
 Date:   Mon Nov 25 09:31:09 2013 +0100

 Revert man: suggest using hash= atribut for swap in example

 This reverts commit fa7abba2328eb2d23a7e27708f86f5013059ddcf.
 Reason?

Systemd upstream will not mention outdated and weak cryptography, or
broken standards.

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

Re: [systemd-devel] 'udevadm test' removes/adds by-id/by-path links

[Kay Sievers]

On Thu, Nov 28, 2013 at 11:36 AM, Robert Milasan rmila...@suse.com wrote:
 Hello,
   when running 'udevadm test /sys/block/sdb --action=remove' then links
   to the device node in /dev/disk/{by-id,by-path} are being removed and
   running udevadm test with action=add, the links are re-added.

 robert@viper:~ ls -l /dev/disk/by-id/|grep sdb
 lrwxrwxrwx 1 root root  9 Nov 28 11:13
 usb-Corsair_Flash_Voyager_002557-0:0 - ../../sdb
 lrwxrwxrwx 1 root root 10 Nov 28 10:50
 usb-Corsair_Flash_Voyager_002557-0:0-part1 - ../../sdb1

 robert@viper:~ sudo udevadm test /sys/block/sdb --action=remove
/dev/null 21
 robert@viper:~ ls -l /dev/disk/by-id/|grep sdb
 lrwxrwxrwx 1 root root 10 Nov 28 10:50
 usb-Corsair_Flash_Voyager_002557-0:0-part1 - ../../sdb1

 robert@viper:~ sudo udevadm test /sys/block/sdb --action=add
/dev/null 21
 robert@viper:~ ls -l /dev/disk/by-id/|grep sdb
 lrwxrwxrwx 1 root root  9 Nov 28 11:34
 usb-Corsair_Flash_Voyager_002557-0:0 - ../../sdb
 lrwxrwxrwx 1 root root 10 Nov 28 10:50
 usb-Corsair_Flash_Voyager_002557-0:0-part1 - ../../sdb1

  As you can see on action=remove, the link to sdb device node has been
  removed and on action=add, the link as been re-added.

  As I am running 'udevadm test', I would think, that this is only a test
  and the links or anything related to this test suppose to be fake,
  meaning nothing really should be removed/added.

  Is this a known functionality of 'udevadm test' or it's a bug?

Sure, test does what a real event would do, so it changes the
content of /dev; that's expected and intentional.

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

[systemd-devel] systemd-multi-seat-x deprecation is near...

[Laércio de Sousa]

Hi there!

I've submitted some patches to xorg-devel to fill the remaining gaps which
make current sytemd-multi-seat-x wrapper still needed in some multiseat
setups.

One of these patches was already merged into upstream and should be
released in xorg-server v1.15 (see
http://cgit.freedesktop.org/xorg/xserver/commit/?id=c73c36b537f996574628e69681833ea37dec2b6e
).

There are other two alternative patches, that fill the other gap, currently
waiting for review:

This one: http://lists.x.org/archives/xorg-devel/2013-November/038748.html

OR

This one (preferrable):
http://lists.x.org/archives/xorg-devel/2013-November/038765.html

If/when these patches are released, then systemd-multi-seat-x, in its
current form, will be no longer necessary. So, unless you have another
plans for this wrapper, I would like to suggest that you make its build
optional in future releases of systemd (if it's not already optional).

CANTATE DOMINO CANTICUM NOVUM
QUIA MIRABILIA FECIT

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

[systemd-devel] Optionally save core dumps as plain files

[Umut Tezduyar Lindskog]

Hi,

I can’t find the last word on Oleksii’s coredump patch 
http://lists.freedesktop.org/archives/systemd-devel/2013-May/010991.html. Was 
there a decision about not taking it in?

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

Re: [systemd-devel] [systemd-commits] man/crypttab.xml

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 28, 2013 at 12:48:51PM +0100, Kay Sievers wrote:
 On Thu, Nov 28, 2013 at 8:41 AM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Mon, Nov 25, 2013 at 12:31:24AM -0800, Lukas Nykryn wrote:
   man/crypttab.xml |2 --
   1 file changed, 2 deletions(-)
 
  New commits:
  commit 517dcac840fe8d5bf30a05c0084eff219af10a4a
  Author: Lukas Nykryn lnyk...@redhat.com
  Date:   Mon Nov 25 09:31:09 2013 +0100
 
  Revert man: suggest using hash= atribut for swap in example
 
  This reverts commit fa7abba2328eb2d23a7e27708f86f5013059ddcf.
  Reason?
 
 Systemd upstream will not mention outdated and weak cryptography, or
 broken standards.
Oh, OK, I guess I could have figured this out OK.

@Lukas: nevertheless, a commit message would still be useful, both on
the original commit, and on the revert. Commiters from Brno are too
often economical with words :)

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

Re: [systemd-devel] Thread level resource management

[Umut Tezduyar Lindskog]

On Nov 25, 2013, at 6:59 PM, Kay Sievers k...@vrfy.org wrote:

 On Mon, Nov 25, 2013 at 5:28 PM, Umut Tezduyar Lindskog
 umut.tezdu...@axis.com wrote:
 On Nov 24, 2013, at 4:39 PM, Kay Sievers k...@vrfy.org wrote:
 On Sun, Nov 24, 2013 at 12:33 PM, Umut Tezduyar Lindskog
 umut.tezdu...@axis.com wrote:
 How do we support thread level resource management with the new cgroup 
 abstraction?
 How do we do it in the process level then. Lets say a service has 5 
 processes under and 1 of them needs to be in a different slice. Any example?
Can someone explain the process level management?
 
 Can we use scopes with task ids of threads? If so, what is the API to put 
 the task id into its own scope unit?
 
 There is no plan at the moment to support thread-granular resource
 settings. The feature is expected to be removed from the kernel too,
 when we switch to the unified cgroup hierarchy.
 Any plans to support existing applications that are making use of thread 
 level resource management?
 
 No, the current idea is that there will be no replacement.
 
 If not, what are we left with then, posix thread priorities?
 
 Something else than cgroups, yes. Thread prios could work if it fits
 the way your tool works. And there are some ideas of adding new
 interfaces to /proc/$PID/, to provide these thread-level knobs.
 
 We will see when we get there. Only one thing seems clear, threads are
 to be managed by the process, not by cgroups.
 
 Is there an announcement of dropping thread level resource management 
 support from kernel somewhere?
 
 Nothing official, there are just discussions about the unified hierarchy.
 
 Kay

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

[systemd-devel] [PATCH] systemctl: add systemctl cat

[Shawn Landden]

---
 TODO  |  2 -
 src/shared/fileio.c   | 73 ++-
 src/shared/fileio.h   |  1 +
 src/shared/util.c |  2 +
 src/systemctl/systemctl.c | 97 +++
 5 files changed, 172 insertions(+), 3 deletions(-)

diff --git a/TODO b/TODO
index 6ba4b31..7c6003b 100644
--- a/TODO
+++ b/TODO
@@ -125,8 +125,6 @@ Features:
 
 * optimize the cgroup propagation bits, especially unit_get_members_mask(), 
cgroup_context_get_mask()
 
-* systemctl cat or systemctl view command or or so, that cats the backing 
unit file of a service, plus its drop-ins and shows them in a pager
-
 * rfkill,backlight: we probably should run the load tools inside of the udev 
rules so that the state is properly initialized by the time other software sees 
it
 
 * tmpfiles: when applying ownership to /run/log/journal, also do this for the 
journal fails contained in it
diff --git a/src/shared/fileio.c b/src/shared/fileio.c
index 733b320..ac1b409 100644
--- a/src/shared/fileio.c
+++ b/src/shared/fileio.c
@@ -20,6 +20,7 @@
 ***/
 
 #include unistd.h
+#include sys/sendfile.h
 #include fileio.h
 #include util.h
 #include strv.h
@@ -117,6 +118,77 @@ int read_one_line_file(const char *fn, char **line) {
 return 0;
 }
 
+ssize_t sendfile_full(int out_fd, const char *fn) {
+_cleanup_fclose_ FILE *f;
+struct stat st;
+int r;
+ssize_t s;
+
+size_t n, l;
+_cleanup_free_ char *buf = NULL;
+
+assert(out_fd  0);
+assert(fn);
+
+f = fopen(fn, r);
+if (!f)
+return -errno;
+
+r = fstat(fileno(f), st);
+if (r  0)
+return -errno;
+
+s = sendfile(out_fd, fileno(f), NULL, st.st_size);
+if (s  0)
+if (errno == EINVAL || errno == ENOSYS) {
+/* continue below */
+} else
+return -errno;
+else
+return s;
+
+/* sendfile() failed, fall back to read/write */
+
+/* Safety check */
+if (st.st_size  4*1024*1024)
+return -E2BIG;
+
+n = st.st_size  0 ? st.st_size : LINE_MAX;
+l = 0;
+
+while (true) {
+char *t;
+size_t k;
+
+t = realloc(buf, n);
+if (!t)
+return -ENOMEM;
+
+buf = t;
+k = fread(buf + l, 1, n - l, f);
+
+if (k = 0) {
+if (ferror(f))
+return -errno;
+
+break;
+}
+
+l += k;
+n *= 2;
+
+/* Safety check */
+if (n  4*1024*1024)
+return -E2BIG;
+}
+
+r = write(out_fd, buf, l);
+if (r  0)
+return -errno;
+
+return (ssize_t) l;
+}
+
 int read_full_file(const char *fn, char **contents, size_t *size) {
 _cleanup_fclose_ FILE *f = NULL;
 size_t n, l;
@@ -168,7 +240,6 @@ int read_full_file(const char *fn, char **contents, size_t 
*size) {
 
 buf[l] = 0;
 *contents = buf;
-buf = NULL;
 
 if (size)
 *size = l;
diff --git a/src/shared/fileio.h b/src/shared/fileio.h
index 59e4150..06c2887 100644
--- a/src/shared/fileio.h
+++ b/src/shared/fileio.h
@@ -31,6 +31,7 @@ int write_string_file_atomic(const char *fn, const char 
*line);
 
 int read_one_line_file(const char *fn, char **line);
 int read_full_file(const char *fn, char **contents, size_t *size);
+ssize_t sendfile_full(int out_fd, const char *fn);
 
 int parse_env_file(const char *fname, const char *separator, ...) _sentinel_;
 int load_env_file(const char *fname, const char *separator, char ***l);
diff --git a/src/shared/util.c b/src/shared/util.c
index deb74c4..e6a32b9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5904,6 +5904,8 @@ void* greedy_realloc(void **p, size_t *allocated, size_t 
need) {
 size_t a;
 void *q;
 
+assert(allocated);
+
 if (*allocated = need)
 return *p;
 
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 6cb7a82..633c07d 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3665,6 +3665,101 @@ static int show_all(
 return 0;
 }
 
+static int cat(sd_bus *bus, char **args) {
+int r = 0;
+char **name;
+
+_cleanup_free_ char *unit = NULL, *n = NULL;
+
+assert(bus);
+assert(args);
+
+pager_open_if_enabled();
+
+STRV_FOREACH(name, args+1) {
+_cleanup_free_ char *fragment_path = NULL;
+_cleanup_strv_free_ char **dropin_paths = NULL;
+sd_bus_error error;
+FILE *stdout;
+char **path;
+
+n = unit_name_mangle(*name);

Re: [systemd-devel] [PATCH 2/2] systemctl: add systemctl cat

[Shawn Landden]

On Wed, Nov 27, 2013 at 11:59 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Sat, Nov 23, 2013 at 07:52:53PM -0800, Shawn Landden wrote:
 ---
  TODO  |  2 --
  src/shared/fileio.c   | 73 -
  src/shared/fileio.h   |  1 +
  src/systemctl/systemctl.c | 91 
 +++
  4 files changed, 164 insertions(+), 3 deletions(-)

 diff --git a/TODO b/TODO
 index 6ba4b31..7c6003b 100644
 --- a/TODO
 +++ b/TODO
 @@ -125,8 +125,6 @@ Features:

  * optimize the cgroup propagation bits, especially unit_get_members_mask(), 
 cgroup_context_get_mask()

 -* systemctl cat or systemctl view command or or so, that cats the 
 backing unit file of a service, plus its drop-ins and shows them in a pager
 -
  * rfkill,backlight: we probably should run the load tools inside of the 
 udev rules so that the state is properly initialized by the time other 
 software sees it

  * tmpfiles: when applying ownership to /run/log/journal, also do this for 
 the journal fails contained in it
 diff --git a/src/shared/fileio.c b/src/shared/fileio.c
 index 733b320..ac1b409 100644
 --- a/src/shared/fileio.c
 +++ b/src/shared/fileio.c
 @@ -20,6 +20,7 @@
  ***/

  #include unistd.h
 +#include sys/sendfile.h
  #include fileio.h
  #include util.h
  #include strv.h
 @@ -117,6 +118,77 @@ int read_one_line_file(const char *fn, char **line) {
  return 0;
  }

 +ssize_t sendfile_full(int out_fd, const char *fn) {
 +_cleanup_fclose_ FILE *f;
 +struct stat st;
 +int r;
 +ssize_t s;
 +
 +size_t n, l;
 +_cleanup_free_ char *buf = NULL;
 +
 +assert(out_fd  0);
 +assert(fn);
 +
 +f = fopen(fn, r);
 +if (!f)
 +return -errno;
 +
 +r = fstat(fileno(f), st);
 +if (r  0)
 +return -errno;
 +
 +s = sendfile(out_fd, fileno(f), NULL, st.st_size);
 +if (s  0)
 +if (errno == EINVAL || errno == ENOSYS) {
 +/* continue below */
 +} else
 +return -errno;
 +else
 +return s;
 +
 +/* sendfile() failed, fall back to read/write */
 +
 +/* Safety check */
 +if (st.st_size  4*1024*1024)
 +return -E2BIG;
 +
 +n = st.st_size  0 ? st.st_size : LINE_MAX;
 +l = 0;
 +
 +while (true) {
 +char *t;
 +size_t k;
 +
 +t = realloc(buf, n);
 +if (!t)
 +return -ENOMEM;
 Can you convert this to GREEDY_REALLOC? It should be a bit simpler then.
GREEDY_REALLOC isn't appropriate here, (or read_full_file() which this
code is from), as in general stat is going to succeed and we are going
to read
the whole file in one run.

 +
 +buf = t;
 +k = fread(buf + l, 1, n - l, f);
 +
 +if (k = 0) {
 +if (ferror(f))
 +return -errno;
 +
 +break;
 +}
 +
 +l += k;
 +n *= 2;
 +
 +/* Safety check */
 +if (n  4*1024*1024)
 +return -E2BIG;
 +}
 +
 +r = write(out_fd, buf, l);
 +if (r  0)
 +return -errno;
 +
 +return (ssize_t) l;
 +}
 +
  int read_full_file(const char *fn, char **contents, size_t *size) {
  _cleanup_fclose_ FILE *f = NULL;
  size_t n, l;
 @@ -168,7 +240,6 @@ int read_full_file(const char *fn, char **contents, 
 size_t *size) {

  buf[l] = 0;
  *contents = buf;
 -buf = NULL;

  if (size)
  *size = l;
 diff --git a/src/shared/fileio.h b/src/shared/fileio.h
 index 59e4150..06c2887 100644
 --- a/src/shared/fileio.h
 +++ b/src/shared/fileio.h
 @@ -31,6 +31,7 @@ int write_string_file_atomic(const char *fn, const char 
 *line);

  int read_one_line_file(const char *fn, char **line);
  int read_full_file(const char *fn, char **contents, size_t *size);
 +ssize_t sendfile_full(int out_fd, const char *fn);

  int parse_env_file(const char *fname, const char *separator, ...) 
 _sentinel_;
  int load_env_file(const char *fname, const char *separator, char ***l);
 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 6cb7a82..18d5e45 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -3665,6 +3665,95 @@ static int show_all(
  return 0;
  }

 +static int cat(sd_bus *bus, char **args) {
 +int r = 0;
 +char **name;
 +
 +_cleanup_free_ char *unit = NULL, *n = NULL;
 +
 +assert(bus);
 +assert(args);
 +
 +pager_open_if_enabled();
 +
 +STRV_FOREACH(name, args+1) {
 +_cleanup_free_ char *fragment_path = NULL;
 +_cleanup_strv_free_ char 

[systemd-devel] [PATCH] systemctl: add systemctl cat

[Shawn Landden]

v3: log_warning() inserts a trailing newline
---
 TODO  |  2 -
 src/shared/fileio.c   | 73 ++-
 src/shared/fileio.h   |  1 +
 src/shared/util.c |  2 +
 src/systemctl/systemctl.c | 97 +++
 5 files changed, 172 insertions(+), 3 deletions(-)

diff --git a/TODO b/TODO
index 6ba4b31..7c6003b 100644
--- a/TODO
+++ b/TODO
@@ -125,8 +125,6 @@ Features:
 
 * optimize the cgroup propagation bits, especially unit_get_members_mask(), 
cgroup_context_get_mask()
 
-* systemctl cat or systemctl view command or or so, that cats the backing 
unit file of a service, plus its drop-ins and shows them in a pager
-
 * rfkill,backlight: we probably should run the load tools inside of the udev 
rules so that the state is properly initialized by the time other software sees 
it
 
 * tmpfiles: when applying ownership to /run/log/journal, also do this for the 
journal fails contained in it
diff --git a/src/shared/fileio.c b/src/shared/fileio.c
index 733b320..ac1b409 100644
--- a/src/shared/fileio.c
+++ b/src/shared/fileio.c
@@ -20,6 +20,7 @@
 ***/
 
 #include unistd.h
+#include sys/sendfile.h
 #include fileio.h
 #include util.h
 #include strv.h
@@ -117,6 +118,77 @@ int read_one_line_file(const char *fn, char **line) {
 return 0;
 }
 
+ssize_t sendfile_full(int out_fd, const char *fn) {
+_cleanup_fclose_ FILE *f;
+struct stat st;
+int r;
+ssize_t s;
+
+size_t n, l;
+_cleanup_free_ char *buf = NULL;
+
+assert(out_fd  0);
+assert(fn);
+
+f = fopen(fn, r);
+if (!f)
+return -errno;
+
+r = fstat(fileno(f), st);
+if (r  0)
+return -errno;
+
+s = sendfile(out_fd, fileno(f), NULL, st.st_size);
+if (s  0)
+if (errno == EINVAL || errno == ENOSYS) {
+/* continue below */
+} else
+return -errno;
+else
+return s;
+
+/* sendfile() failed, fall back to read/write */
+
+/* Safety check */
+if (st.st_size  4*1024*1024)
+return -E2BIG;
+
+n = st.st_size  0 ? st.st_size : LINE_MAX;
+l = 0;
+
+while (true) {
+char *t;
+size_t k;
+
+t = realloc(buf, n);
+if (!t)
+return -ENOMEM;
+
+buf = t;
+k = fread(buf + l, 1, n - l, f);
+
+if (k = 0) {
+if (ferror(f))
+return -errno;
+
+break;
+}
+
+l += k;
+n *= 2;
+
+/* Safety check */
+if (n  4*1024*1024)
+return -E2BIG;
+}
+
+r = write(out_fd, buf, l);
+if (r  0)
+return -errno;
+
+return (ssize_t) l;
+}
+
 int read_full_file(const char *fn, char **contents, size_t *size) {
 _cleanup_fclose_ FILE *f = NULL;
 size_t n, l;
@@ -168,7 +240,6 @@ int read_full_file(const char *fn, char **contents, size_t 
*size) {
 
 buf[l] = 0;
 *contents = buf;
-buf = NULL;
 
 if (size)
 *size = l;
diff --git a/src/shared/fileio.h b/src/shared/fileio.h
index 59e4150..06c2887 100644
--- a/src/shared/fileio.h
+++ b/src/shared/fileio.h
@@ -31,6 +31,7 @@ int write_string_file_atomic(const char *fn, const char 
*line);
 
 int read_one_line_file(const char *fn, char **line);
 int read_full_file(const char *fn, char **contents, size_t *size);
+ssize_t sendfile_full(int out_fd, const char *fn);
 
 int parse_env_file(const char *fname, const char *separator, ...) _sentinel_;
 int load_env_file(const char *fname, const char *separator, char ***l);
diff --git a/src/shared/util.c b/src/shared/util.c
index deb74c4..e6a32b9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5904,6 +5904,8 @@ void* greedy_realloc(void **p, size_t *allocated, size_t 
need) {
 size_t a;
 void *q;
 
+assert(allocated);
+
 if (*allocated = need)
 return *p;
 
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 6cb7a82..284020c 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3665,6 +3665,101 @@ static int show_all(
 return 0;
 }
 
+static int cat(sd_bus *bus, char **args) {
+int r = 0;
+char **name;
+
+_cleanup_free_ char *unit = NULL, *n = NULL;
+
+assert(bus);
+assert(args);
+
+pager_open_if_enabled();
+
+STRV_FOREACH(name, args+1) {
+_cleanup_free_ char *fragment_path = NULL;
+_cleanup_strv_free_ char **dropin_paths = NULL;
+sd_bus_error error;
+FILE *stdout;
+char **path;
+

Re: [systemd-devel] Optionally save core dumps as plain files

[Kay Sievers]

On Thu, Nov 28, 2013 at 4:44 PM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:

 I can’t find the last word on Oleksii’s coredump patch 
 http://lists.freedesktop.org/archives/systemd-devel/2013-May/010991.html. Was 
 there a decision about not taking it in?

So far we planned to have a minidump integration instead of storing
more files in the filesystem which nobody will track.

Minidumps will strip the coredump down, so that it should fit
conveniently into the journal as data.

There is an unfinished libminidump for that, but we are busy with
other stuff so it has to wait.

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

Re: [systemd-devel] [PATCH] util: don't consider trailing whitespaces as an empty string in split_quoted

[Tom Gundersen]

On Wed, Nov 27, 2013 at 7:12 PM, Dave Reisner d...@falconindy.com wrote:
 On Wed, Nov 27, 2013 at 06:45:06PM +0100, Tom Gundersen wrote:
 On Wed, Nov 27, 2013 at 6:00 PM, Lukas Nykryn lnyk...@redhat.com wrote:
  ---
   src/shared/util.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/src/shared/util.c b/src/shared/util.c
  index 3a4d196..c68ab09 100644
  --- a/src/shared/util.c
  +++ b/src/shared/util.c
  @@ -383,7 +383,9 @@ char *split_quoted(const char *c, size_t *l, char 
  **state) {
 
   current += strspn(current, WHITESPACE);
 
  -if (*current == '\'') {
  +if (*current == 0)
  +return NULL;
  +else if (*current == '\'') {
   current ++;
 
   for (e = current; *e; e++) {
  --
  1.8.3.1

 Dave,

 Is this the proper fix to the /proc/cmdline bug you told me about some
 time ago? What happened to that in the end?

 -t

 Oh, interesting... Yeah, this looks like it would. I suppose da66338e1
 could be reverted if this is merged.

Done.

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

Re: [systemd-devel] systemd-multi-seat-x deprecation is near...

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 28, 2013 at 01:33:29PM -0200, Laércio de Sousa wrote:
 If/when these patches are released, then systemd-multi-seat-x, in its
 current form, will be no longer necessary. So, unless you have another
 plans for this wrapper, I would like to suggest that you make its build
 optional in future releases of systemd (if it's not already optional).
It can now be disabled with --disable-multi-seat-x.

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

Re: [systemd-devel] [PATCH] systemctl: add systemctl cat

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 28, 2013 at 10:34:10AM -0800, Shawn Landden wrote:
 v3: log_warning() inserts a trailing newline
 ---
  TODO  |  2 -
  src/shared/fileio.c   | 73 ++-
  src/shared/fileio.h   |  1 +
  src/shared/util.c |  2 +
  src/systemctl/systemctl.c | 97 
 +++
  5 files changed, 172 insertions(+), 3 deletions(-)

Hm, this seems to still need some more work:

% build/systemctl cat session-1.scope
Failed to cat : No such file or directory
# 

session-1.scope has no fragment path, just an override:
% build/systemctl show session-1.scope|grep -E 'Frag|Drop'
DropInPaths=/run/systemd/system/session-1.scope.d/90-After-systemd-user-sessions\x2eservice.conf
 /run/systemd/system/session-1.scope.d/90-Description.conf 
/run/systemd/system/session-1.scope.d/90-KillMode.conf 
/run/systemd/system/session-1.scope.d/90-SendSIGHUP.conf 
/run/systemd/system/session-1.scope.d/90-Slice.conf 
/run/systemd/system/session-1.scope.d/90-TimeoutStopUSec.conf

Also, manpage should be updated and shell completion scripts
would be nice to update too.

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

[systemd-devel] Is restart gracefull?

[Cecil Westerhof]

I have done a trial presentation about systemd. One of the questions 
there was: when a restart of for example apache is doen, is this restart 
done graceful?



Met vriendelijke groet,



Cecil Westerhof
Engineer
mobiel +31 - 6 - 25 00 38 81

--

Snow B.V.
Unix Specialists
De Ooyen 11
4191 PB Geldermalsen

http://www.snow.nl
tel. +31 - 345 - 65 66 66
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeing logging as user

[Cecil Westerhof]

On 11/28/2013 12:37 AM, Kay Sievers wrote:

I have to give a presentation about systemd/journald. One of the things I
want to show is that you do not need an administrator to see the log
messages that are generated by you.

I did:
- makedir /var/log/journal
- systemctl kill -s SIGUSR1 systemd-journald

As user cecil I did:
 printf Create an error\n | logger

When I as root do:
 journalctl _UID=uid

I see:
 Nov 27 23:26:38 Equus.Decebal.nl cecil[25091]: Create an error

But when I do the same as cecil, I see nothing. What is going wrong here?


http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html#Access%20Control


What if I want this user to also see the log of for example cron?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] What if a service is started manually

[Cecil Westerhof]

In a trial presentation I used the following service file:
[Unit]
Description=Virtual Distributed Ethernet
After=syslog.target

[Service]
Type=forking
PIDFile=/var/run/vde.pid
# Note the -f: don't fail if there is no PID file
ExecStartPre=/bin/rm -f /var/run/vde.pid
ExecStart=/usr/bin/vde_switch --tap tap0 --mode 0660 \
 --dirmode 0750 --group qemu \
 --daemon --pidfile /var/run/vde.pid
Restart=on-abort

[Install]
WantedBy=multi-user.target

Here the PID file is removed before the service is started.

This brought up two questions.
- What happens is you start a service that you already started? Nothing, 
or is the service first stopped and then again started?
- What happens if someone started the service manually? So bypassing 
systemd and running directly /usr/bin/vde_switch.



Met vriendelijke groet,



Cecil Westerhof
Engineer
mobiel +31 - 6 - 25 00 38 81

--

Snow B.V.
Unix Specialists
De Ooyen 11
4191 PB Geldermalsen

http://www.snow.nl
tel. +31 - 345 - 65 66 66
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] QOS

[Cecil Westerhof]

I was asked if you could use systemd for QOS?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] xnitd

[Cecil Westerhof]

How does systemd compare to xinitd?


Met vriendelijke groet,



Cecil Westerhof
Engineer
mobiel +31 - 6 - 25 00 38 81

--

Snow B.V.
Unix Specialists
De Ooyen 11
4191 PB Geldermalsen

http://www.snow.nl
tel. +31 - 345 - 65 66 66
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What if a service is started manually

[Cecil Westerhof]

On 11/29/2013 12:23 AM, Cecil Westerhof wrote:

In a trial presentation I used the following service file:
[Unit]
Description=Virtual Distributed Ethernet
After=syslog.target

[Service]
Type=forking
PIDFile=/var/run/vde.pid
# Note the -f: don't fail if there is no PID file
ExecStartPre=/bin/rm -f /var/run/vde.pid
ExecStart=/usr/bin/vde_switch --tap tap0 --mode 0660 \
  --dirmode 0750 --group qemu \
  --daemon --pidfile /var/run/vde.pid
Restart=on-abort

[Install]
WantedBy=multi-user.target

Here the PID file is removed before the service is started.

This brought up two questions.
- What happens is you start a service that you already started? Nothing,
or is the service first stopped and then again started?
- What happens if someone started the service manually? So bypassing
systemd and running directly /usr/bin/vde_switch.


I was not clear here. What I mend: someone starts the service manually 
and after this starts the service with systemctl.

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

[systemd-devel] Check from several machines on one machine

[Cecil Westerhof]

With rsyslog you can send everything to one machine and evaluate the 
logs of several machines on that one machine. As I understand it, 
journald is mend to work locally. Is there a way to centralize the usage 
of journals? This could be done with rsyslog, but then you lose all the 
benefits of journald.


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

Re: [systemd-devel] Check from several machines on one machine

[Amit Saha]

- Original Message -
 From: Cecil Westerhof cecil.wester...@snow.nl
 To: systemd-devel@lists.freedesktop.org
 Sent: Friday, November 29, 2013 9:40:18 AM
 Subject: [systemd-devel] Check from several machines on one machine
 
 With rsyslog you can send everything to one machine and evaluate the
 logs of several machines on that one machine. As I understand it,
 journald is mend to work locally. Is there a way to centralize the usage
 of journals? This could be done with rsyslog, but then you lose all the
 benefits of journald.

If you can live with a pulling solution, you may find systemd-journal-gateway 
service [1] useful.
It allows you to browse the journal of a system via HTTP, which means you can 
pull logs from different
systems into a centralized log storage.

[1] 
http://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.service.html

I am just a systemd enthusiast, learning a lot about it myself, so my advice 
may not be the 
correct/optimal solution.

Hope that helps.
-Amit.

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

Re: [systemd-devel] xnitd

[Mantas Mikulėnas]

On Nov 29, 2013 1:30 AM, Cecil Westerhof cecil.wester...@snow.nl wrote:

 How does systemd compare to xinitd?

Did you mean inetd/xinetd?

systemd's .socket units are very similar (many existing programs, like
sshd, can be moved directly from inetd to systemd -- Accept=yes corresponds
to the 'nowait' type, and Accept=no to 'wait'), but since each . socket
unit starts a corresponding . service unit, you get the same systemd
features as with regular services -- dependencies, resource limits, process
tracking, etc.

On the other hand, there is no support for things like TCPMUX, SunRPC
services (though Avahi integration was planned once), or some more obscure
xinetd options.

While both systems support both methods, systemd's socket activation is
more often used to pass the *listener* socket to the service, which still
does all accepting itself (e.g. both DBus and udev start this way);
meanwhile, I see inetd more often used to start one instance per connection.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Check from several machines on one machine

[Mantas Mikulėnas]

On Nov 29, 2013 1:41 AM, Cecil Westerhof cecil.wester...@snow.nl wrote:

 With rsyslog you can send everything to one machine and evaluate the logs
of several machines on that one machine. As I understand it, journald is
mend to work locally. Is there a way to centralize the usage of journals?
This could be done with rsyslog, but then you lose all the benefits of
journald.

You don't lose /all/ of them. rsyslog supports both reading from, and
writing to, the journal with complete metadata, using imjournal and
omjournal.


 Cecil
 ___
 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] What if a service is started manually

[Mantas Mikulėnas]

On Nov 29, 2013 1:36 AM, Cecil Westerhof cecil.wester...@snow.nl wrote:

 Thanks for the speedy reply.


 On 11/29/2013 12:30 AM, Mantas Mikulėnas wrote:

 On Nov 29, 2013 1:24 AM, Cecil Westerhof cecil.wester...@snow.nl
 mailto:cecil.wester...@snow.nl wrote:
  
   In a trial presentation I used the following service file:
   [Unit]
   Description=Virtual Distributed Ethernet
   After=syslog.target
  
   [Service]
   Type=forking
   PIDFile=/var/run/vde.pid
   # Note the -f: don't fail if there is no PID file
   ExecStartPre=/bin/rm -f /var/run/vde.pid
   ExecStart=/usr/bin/vde_switch --tap tap0 --mode 0660 \
--dirmode 0750 --group qemu \
--daemon --pidfile /var/run/vde.pid
   Restart=on-abort
  
   [Install]
   WantedBy=multi-user.target
  
   Here the PID file is removed before the service is started.
  
   This brought up two questions.
   - What happens is you start a service that you already started?
 Nothing, or is the service first stopped and then again started?

 'systemctl start' only starts services, therefore it will do nothing if
 the service is already started.

 'systemctl restart' would stop it and start it again.

   - What happens if someone started the service manually? So bypassing
 systemd and running directly /usr/bin/vde_switch.

 As far as systemd is concerned, nothing happens - the manually started
 vde_switch is just another process inside your login session. It will
 *not* be automatically pulled into a service just because the program
 name or something happens to match...


 I should learn to ask my questions better. T_T

 What I mend to ask. Someone starts /usr/bin/vde_switch manually and after
that uses systemctl to start it.


If the second vde_switch instance is configured to listen on the same
sockets, etc., then... Well, it depends on the daemon itself:

* most will consider this a fatal error, and exit with non-zero status,
causing the systemd .service to fail as well;

* but some will think that the existing socket is stale, will remove it,
and happily start on top of the first instance. (Only happens with Unix
sockets, of course; if the daemon uses TCP or tries to grab the same 'tap0'
interface or such, then it can only fail.)

I don't know how vde behaves. It will probably refuse to start.

The best way to find out, of course, is to try systemd yourself.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] xnitd

[Amit Saha]

- Original Message -
 From: Mantas Mikulėnas graw...@gmail.com
 To: Cecil Westerhof cecil.wester...@snow.nl
 Cc: systemd Mailing List systemd-devel@lists.freedesktop.org
 Sent: Friday, November 29, 2013 9:57:04 AM
 Subject: Re: [systemd-devel] xnitd
 
 On Nov 29, 2013 1:30 AM, Cecil Westerhof cecil.wester...@snow.nl wrote:
 
  How does systemd compare to xinitd?
 
 Did you mean inetd/xinetd?
 
 systemd's .socket units are very similar (many existing programs, like
 sshd, can be moved directly from inetd to systemd -- Accept=yes corresponds
 to the 'nowait' type, and Accept=no to 'wait'), but since each . socket
 unit starts a corresponding . service unit, you get the same systemd
 features as with regular services -- dependencies, resource limits, process
 tracking, etc.
 
 On the other hand, there is no support for things like TCPMUX, SunRPC
 services (though Avahi integration was planned once), or some more obscure
 xinetd options.
 
 While both systems support both methods, systemd's socket activation is
 more often used to pass the *listener* socket to the service, which still
 does all accepting itself (e.g. both DBus and udev start this way);
 meanwhile, I see inetd more often used to start one instance per connection.

This document may prove useful: http://0pointer.de/blog/projects/inetd.html

Best,
Amit

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

Re: [systemd-devel] What if a service is started manually

[Cecil Westerhof]

On 11/29/2013 12:59 AM, Mantas Mikulėnas wrote:

In a trial presentation I used the following service file:
[Unit]
Description=Virtual Distributed Ethernet
After=syslog.target
   
[Service]
Type=forking
PIDFile=/var/run/vde.pid
# Note the -f: don't fail if there is no PID file
ExecStartPre=/bin/rm -f /var/run/vde.pid
ExecStart=/usr/bin/vde_switch --tap tap0 --mode 0660 \
 --dirmode 0750 --group qemu \
 --daemon --pidfile /var/run/vde.pid
Restart=on-abort
   
[Install]
WantedBy=multi-user.target
   
Here the PID file is removed before the service is started.
   
This brought up two questions.
- What happens is you start a service that you already started?
  Nothing, or is the service first stopped and then again started?
 
  'systemctl start' only starts services, therefore it will do nothing if
  the service is already started.
 
  'systemctl restart' would stop it and start it again.
 
- What happens if someone started the service manually? So bypassing
  systemd and running directly /usr/bin/vde_switch.
 
  As far as systemd is concerned, nothing happens - the manually started
  vde_switch is just another process inside your login session. It will
  *not* be automatically pulled into a service just because the program
  name or something happens to match...
 
 
  I should learn to ask my questions better. T_T
 
  What I mend to ask. Someone starts /usr/bin/vde_switch manually and
after that uses systemctl to start it.
 

If the second vde_switch instance is configured to listen on the same
sockets, etc., then... Well, it depends on the daemon itself:

* most will consider this a fatal error, and exit with non-zero status,
causing the systemd .service to fail as well;

* but some will think that the existing socket is stale, will remove it,
and happily start on top of the first instance. (Only happens with
Unix sockets, of course; if the daemon uses TCP or tries to grab the
same 'tap0' interface or such, then it can only fail.)

I don't know how vde behaves. It will probably refuse to start.

The best way to find out, of course, is to try systemd yourself.


I need only a generic answer. So if this question is asked I can answer 
with it depends on the service. Making sure that when they ask further I 
remember your explanation.


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

Re: [systemd-devel] Is restart gracefull?

[Cristian Rodríguez]

El 28/11/13 20:11, Cecil Westerhof escribió:
 I have done a trial presentation about systemd. One of the questions
 there was: when a restart of for example apache is doen, is this restart
 done graceful?
 

It depends on what the person writting the unit files intends to do, in
most distributions, apache server restart is done by calling
graceful-stop then start.. reload is also graceful.

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

Re: [systemd-devel] QOS

[Cristian Rodríguez]

El 28/11/13 20:27, Cecil Westerhof escribió:
 I was asked if you could use systemd for QOS?

Not directly with systemd.

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

Re: [systemd-devel] Seeing logging as user

[Mantas Mikulėnas]

On Nov 29, 2013 2:18 AM, Cecil Westerhof cecil.wester...@snow.nl wrote:

 On 11/29/2013 12:43 AM, Garry T. Williams wrote:

 On 11-29-13 00:15:47 Cecil Westerhof wrote:


http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html#Access%20Control


 What if I want this user to also see the log of for example cron?


 According to that link, you need to add the user to the
 systemd-journal group.


 Then the user will see all messages I think. I mean its own messages and
cron, but nothing else.

The journal has two modes of separating messages - by login session's
owner, and by the uid of the process itself.

Your cronjobs do not run in a systemd-logind session (though they could),
but they /do/ run with your uid, so you would be able to see them in the
split-by-uid mode at least.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] 4 commits - configure.ac Makefile.am src/core src/network src/shared

[Lennart Poettering]

On Thu, 28.11.13 11:40, Zbigniew Jędrzejewski-Szmek 
(zbys...@kemper.freedesktop.org) wrote:

 commit bd441fa27a22b7c6e11d9330560e0622fb69f297
 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
 Date:   Thu Nov 28 12:07:29 2013 -0500
 
 build-sys: make multi-seat-x optional
 
 At some point it should become disabled by default.
 

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014869.html

I think we already are at the point where we can just drop it. Instead
of making this optional we should check with the X guys of we can drop
it now and kill it. I'd really prefer if we didn't let this bitrot but
just kill it if we can.

Lennart

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

Re: [systemd-devel] [systemd-commits] 4 commits - catalog/systemd-fr.catalog catalog/systemd-ru.catalog configure.ac Makefile.am po/.gitignore po/LINGUAS po/ru.po

[Lennart Poettering]

On Thu, 28.11.13 00:54, Zbigniew Jędrzejewski-Szmek 
(zbys...@kemper.freedesktop.org) wrote:

 commit f1a1264d13b31b9f5521f482d9a5a9d78da55efb
 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
 Date:   Thu Nov 28 03:41:33 2013 -0500
 
 build-sys: avoid warnings from assert_cc
 
 diff --git a/configure.ac b/configure.ac
 index c0656f4..f1b00c5 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -128,7 +128,6 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
  -Wold-style-definition \
  -Wpointer-arith \
  -Winit-self \
 --Wdeclaration-after-statement \
  -Wfloat-equal \
  -Wmissing-prototypes \
  -Wstrict-prototypes \
 

I reverted this bit. Newer GCC versions don't suffer by this problem,
and I think the warning makes a lot of sense on those.

Instead we should add some code to macro.h which turns off the the
warning with the #pragma stuff only if it detects it is being run on an
old gcc.

I would have just added this on my own, but I can't test this, since my
gcc is new enough to not need this.

gcc 4.8.2 (which is what Fedora 20 is using) works fine. So I would
suggest some ifdef check in macro.h that uses #pragma to globally turn
off the warning if anything  4.8.2 i used...

Lennart

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

Re: [systemd-devel] Is restart gracefull?

[Lennart Poettering]

On Fri, 29.11.13 00:11, Cecil Westerhof (cecil.wester...@snow.nl) wrote:

 I have done a trial presentation about systemd. One of the questions
 there was: when a restart of for example apache is doen, is this
 restart done graceful?

For systemd a restart is actually exactly what the name says: a stop
plus a start. reload otoh is up to the implementer of the unit file,
whatever he chooses.

Lennart

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

Re: [systemd-devel] Seeing logging as user

[Lennart Poettering]

On Fri, 29.11.13 01:32, Cecil Westerhof (cecil.wester...@snow.nl) wrote:

 Your cronjobs do not run in a systemd-logind session (though they
 could), but they /do/ run with your uid, so you would be able to see
 them in the split-by-uid mode at least.
 
 Is not what I mend. I want user cecil to see all his own messages
 and all cron messages (so not only his own) but nothing else (so for
 example not sshd).

The journal is not supposed to be a super-flexible routing daemon that
can pipe your logs into arbitrary place with arbitrary filters
implementing arbitrary acess control. That already exists, it's
rsyslog or a similar project. It's explicitly not what we try to cover
with journald.

That said you can make this work by setting journald to split things up
by uid (SplitMode=uid), and then playing games with FS ACLs...

Lennart

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

Re: [systemd-devel] What if a service is started manually

[Lennart Poettering]

On Fri, 29.11.13 00:23, Cecil Westerhof (cecil.wester...@snow.nl) wrote:

 In a trial presentation I used the following service file:
 [Unit]
 Description=Virtual Distributed Ethernet
 After=syslog.target

In curretn systemd versions the After=syslog.target is unnecessary. 

 
 [Service]
 Type=forking
 PIDFile=/var/run/vde.pid
 # Note the -f: don't fail if there is no PID file
 ExecStartPre=/bin/rm -f /var/run/vde.pid
 ExecStart=/usr/bin/vde_switch --tap tap0 --mode 0660 \
  --dirmode 0750 --group qemu \
  --daemon --pidfile /var/run/vde.pid
 Restart=on-abort
 
 [Install]
 WantedBy=multi-user.target
 
 Here the PID file is removed before the service is started.
 
 This brought up two questions.
 - What happens is you start a service that you already started?
 Nothing, or is the service first stopped and then again started?

A started service is unaffected by yet another start request.

If two clients request the same service to start and wait for it to
complete, then the two start jobs are coalesced and only one instance is
started with both clients waiting for the startup of that same instance
to finish.

 - What happens if someone started the service manually? So bypassing
 systemd and running directly /usr/bin/vde_switch.

If you start things on the shell, then systemd won't know about it. It's
exactly the same as if you ran the daemon binary twice on a classic
sysvinit system: it's up to the daemon how it deals with that. Most
daemons will check for PID files and refuse starting twice...

Lennart

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

Re: [systemd-devel] [systemd-commits] 4 commits - configure.ac Makefile.am src/core src/network src/shared

[poma]

On 29.11.2013 02:35, Lennart Poettering wrote:
 On Thu, 28.11.13 11:40, Zbigniew Jędrzejewski-Szmek 
 (zbys...@kemper.freedesktop.org) wrote:
 
 commit bd441fa27a22b7c6e11d9330560e0622fb69f297
 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
 Date:   Thu Nov 28 12:07:29 2013 -0500

 build-sys: make multi-seat-x optional
 
 At some point it should become disabled by default.
 

 http://lists.freedesktop.org/archives/systemd-devel/2013-November/014869.html
 
 I think we already are at the point where we can just drop it. Instead
 of making this optional we should check with the X guys of we can drop
 it now and kill it. I'd really prefer if we didn't let this bitrot but
 just kill it if we can.
 

Unless we are not imagining,
http://lists.x.org/archives/xorg-devel/2013-November/038748.html ain't
applied, yet.
What's the rush.

Bee awesome.:!


poma


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

Re: [systemd-devel] [systemd-commits] 4 commits - configure.ac Makefile.am src/core src/network src/shared

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 29, 2013 at 02:35:47AM +0100, Lennart Poettering wrote:
 On Thu, 28.11.13 11:40, Zbigniew Jędrzejewski-Szmek 
 
  commit bd441fa27a22b7c6e11d9330560e0622fb69f297
  Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
  Date:   Thu Nov 28 12:07:29 2013 -0500
  
  build-sys: make multi-seat-x optional
  
  At some point it should become disabled by default.
  
 
 http://lists.freedesktop.org/archives/systemd-devel/2013-November/014869.html
 
 I think we already are at the point where we can just drop it. Instead
 of making this optional we should check with the X guys of we can drop
 it now and kill it. I'd really prefer if we didn't let this bitrot but
 just kill it if we can.
I think it is still useful until Xorg is released, which could
be a while. We can keep it optional without any effort for now.

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

Re: [systemd-devel] QOS

[Cecil Westerhof]

On 11/29/2013 04:10 AM, Lennart Poettering wrote:

On Fri, 29.11.13 00:27, Cecil Westerhof (cecil.wester...@snow.nl) wrote:


I was asked if you could use systemd for QOS?


Depends on what specifically you mean by QOS...


I'll ask the questioner.



(Any chance you can combine your questions in fewer emails, instead of
one question per mail? I'd really like to keep the traffic low...)


No problem at all. I'll do that. In the past I got comments when I did 
this. (On other mailing lists.) I prefer this way also. ;-)



I must say I am impressed with the feedback of this list. This will 
improve the quality of my presentation manifold.



Met vriendelijke groet,



Cecil Westerhof
Engineer
mobiel +31 - 6 - 25 00 38 81

--

Snow B.V.
Unix Specialists
De Ooyen 11
4191 PB Geldermalsen

http://www.snow.nl
tel. +31 - 345 - 65 66 66
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Thread level resource management

[David Timothy Strauss]

On Fri, Nov 29, 2013 at 1:58 AM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
 Can someone explain the process level management?

Right now, it's possible to do directly in the cgroups file system,
but we're eventually moving away from anything manipulating that but
systemd. I think that there will still be a way to move around
processes via systemd, but it's speculation at this point.

Your best best, overall, is to break up the program into separate
*services*. This is hardly a neutral answer, given that you're asking
on the systemd mailing list. Of course some of us here will advise you
to break it up into services; systemd is a service-management tool.
:-)

Using services will allow you to easily configure resources in a way
that will continue working through 2014 and beyond as systemd and the
kernel update. Even with separate services, you can still use
multithreaded-style (shared memory) techniques by mmapping the same
paths with MAP_SHARED. There are a bunch of other, standard IPC
mechanisms, too [1]. It's generally best to decouple the program into
services that communicate at a high level.

[1] http://www.tldp.org/LDP/lpg/node7.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel