[systemd-devel] [PATCH] cgroup: fix incorrectly setting memory cgroup

2013-09-13 Thread Gao feng 
If the memory_limit of unit is -1, we should write -1
to the file memory.limit_in_bytes. not the (unit64_t) -1.

otherwise the memory.limit_in_bytes will be set to zero.
---
 src/core/cgroup.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index aee93ba..244baff 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -257,14 +257,21 @@ void cgroup_context_apply(CGroupContext *c, 
CGroupControllerMask mask, const cha
 
 if (mask  CGROUP_MEMORY) {
 char buf[DECIMAL_STR_MAX(uint64_t) + 1];
+if (c-memory_limit != (uint64_t) -1) {
+sprintf(buf, % PRIu64 \n, c-memory_limit);
+r = cg_set_attribute(memory, path, 
memory.limit_in_bytes, buf);
+} else
+r = cg_set_attribute(memory, path, 
memory.limit_in_bytes, -1);
 
-sprintf(buf, % PRIu64 \n, c-memory_limit);
-r = cg_set_attribute(memory, path, memory.limit_in_bytes, 
buf);
 if (r  0)
 log_error(Failed to set memory.limit_in_bytes on %s: 
%s, path, strerror(-r));
 
-sprintf(buf, % PRIu64 \n, c-memory_soft_limit);
-r = cg_set_attribute(memory, path, 
memory.soft_limit_in_bytes, buf);
+if (c-memory_soft_limit != (uint64_t) -1) {
+sprintf(buf, % PRIu64 \n, c-memory_soft_limit);
+r = cg_set_attribute(memory, path, 
memory.soft_limit_in_bytes, buf);
+} else
+r = cg_set_attribute(memory, path, 
memory.soft_limit_in_bytes, -1);
+
 if (r  0)
 log_error(Failed to set memory.soft_limit_in_bytes on 
%s: %s, path, strerror(-r));
 }
-- 
1.8.3.1

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

Re: [systemd-devel] [HEADSUP] What to backport?

2013-09-13 Thread Frederic Crozat 
Le vendredi 13 septembre 2013 à 02:40 +0200, Lennart Poettering a
écrit :
 Heya!
 
 I'd like to announce a new service for systemd downstream packagers. In
 the upstream git repository we have started indicating with git notes
 which commits are particularly good candidates for backporting into the
 systemd packages f various distributions.
 
snip

 Any unanswered questions?

No, just two words: thanks you !

-- 
Frederic Crozat fcro...@suse.com
SUSE

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

Re: [systemd-devel] systemd shutdown vs ostree

2013-09-13 Thread Colin Guthrie 
'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
 On Thu, 12.09.13 23:31, Colin Guthrie (gm...@colin.guthr.ie) wrote:
 

 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and gimble:
 On Thu, 12.09.13 21:27, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 So, as mentioned in the other thread, /usr should probably be on some
 OS resource blacklist or so, and not attempted to be shutdown.

 But unmounting /var during shutdown should actually work. The only thing
 that currently stops this from working cleanly is that journald is
 configured to stay around until the last moment, but currently has not
 interface to tell it to move its logging back to /run from /var. When we
 have that then the /var issue should go away for you, no?

 It would be quite nice to have an easy way for a compliant initrd to say
 it can and will handle /var unmounting (perhaps by dropping a
 var.mount.d/ snippet in the /run/systemd/system/ folder at boot?). 

 Yeah, such a drop-in should just work. Just add DefaultDependencies=no
 in there, and maybe instead Before=local-fs.target, and you should be set.

 Nice, I'm sure dracut could implement that then.

 This will allow us to get persistent logs in which the initrd can
 report it's progress until the last possible moment. This might help
 debugging any problems in this particular link of the shutdown chain.

 I think the really late shutdown logs should more liekly end up in some
 EFI var and then flushed out on next boot or so...

 Nice plan. How would be able to trust that data tho'. Would it have to
 be signed in some way? Or could it be marked somehow as unreliable data?
 I'm not sure it really *matters* that much from a trust perspective as
 it's use would likely be 99% debugging, but all the same it would be
 nice if it were trustable.
 
 Trust?  I mean, if you managed to upload data into EFI vars you are so
 privileged you can fuck with us anyway, so not sure what you mean

Well I was originally thinking about other OS's etc. and knowing that
logs came from the right install, but then posed the question in a more
generic sense, in part due to the cryptographic guarantees given by FSS.
I just figured this was an interesting way in which someone could inject
false data at a point where you have zero way to know what went on
between the last shutdown and the current boot.

If is to be inherently trusted based on machine id then fine - just
seems odd to put all the effort into FSS and then blindly inject data
(possibly even core dumps which will be analysed later) and not mark it
as potentially untrustworthy in some way.

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] [HEADSUP] What to backport?

2013-09-13 Thread Colin Guthrie 
'Twas brillig, and Frederic Crozat at 13/09/13 08:32 did gyre and gimble:
 Le vendredi 13 septembre 2013 à 02:40 +0200, Lennart Poettering a
 écrit :
 Heya!

 I'd like to announce a new service for systemd downstream packagers. In
 the upstream git repository we have started indicating with git notes
 which commits are particularly good candidates for backporting into the
 systemd packages f various distributions.

 snip
 
 Any unanswered questions?
 
 No, just two words: thanks you !

Just echoing Fred's comment here. This is really useful! Thank you!


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] [PATCH 1/5] cgroup: add the setting memory.use_hierarchy support for systemd

2013-09-13 Thread Gao feng 
Some programs need to set the memory.use_hierarchy(such as libvirt),
Add this feature.
---
 src/core/cgroup.c |  9 +
 src/core/cgroup.h |  1 +
 src/core/dbus-cgroup.c| 16 
 src/core/load-fragment-gperf.gperf.m4 |  1 +
 4 files changed, 27 insertions(+)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 244baff..336d394 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -274,6 +274,14 @@ void cgroup_context_apply(CGroupContext *c, 
CGroupControllerMask mask, const cha
 
 if (r  0)
 log_error(Failed to set memory.soft_limit_in_bytes on 
%s: %s, path, strerror(-r));
+
+if (c-memory_hierarchy)
+r = cg_set_attribute(memory, path, 
memory.use_hierarchy, 1);
+else
+r = cg_set_attribute(memory, path, 
memory.use_hierarchy, 0);
+
+if (r  0)
+log_error(Failed to set memory.use_hierarchy on %s: 
%s, path, strerror(-r));
 }
 
 if (mask  CGROUP_DEVICE) {
@@ -336,6 +344,7 @@ CGroupControllerMask cgroup_context_get_mask(CGroupContext 
*c) {
 mask |= CGROUP_BLKIO;
 
 if (c-memory_accounting ||
+c-memory_hierarchy ||
 c-memory_limit != (uint64_t) -1 ||
 c-memory_soft_limit != (uint64_t) -1)
 mask |= CGROUP_MEMORY;
diff --git a/src/core/cgroup.h b/src/core/cgroup.h
index 786bd71..c35eea5 100644
--- a/src/core/cgroup.h
+++ b/src/core/cgroup.h
@@ -69,6 +69,7 @@ struct CGroupContext {
 bool cpu_accounting;
 bool blockio_accounting;
 bool memory_accounting;
+bool memory_hierarchy;
 
 unsigned long cpu_shares;
 
diff --git a/src/core/dbus-cgroup.c b/src/core/dbus-cgroup.c
index 1f2a396..20a913c 100644
--- a/src/core/dbus-cgroup.c
+++ b/src/core/dbus-cgroup.c
@@ -132,6 +132,7 @@ const BusProperty bus_cgroup_context_properties[] = {
 { BlockIOReadBandwidth,bus_cgroup_append_device_bandwidths, 
a(st), 0   },
 { BlockIOWriteBandwidth,   bus_cgroup_append_device_bandwidths, 
a(st), 0   },
 { MemoryAccounting,bus_property_append_bool,b, 
offsetof(CGroupContext, memory_accounting)  },
+{ MemoryHierarchy, bus_property_append_bool,b, 
offsetof(CGroupContext, memory_hierarchy)   },
 { MemoryLimit, bus_property_append_uint64,  t, 
offsetof(CGroupContext, memory_limit)   },
 { MemorySoftLimit, bus_property_append_uint64,  t, 
offsetof(CGroupContext, memory_soft_limit)  },
 { DevicePolicy,bus_cgroup_append_device_policy, s, 
offsetof(CGroupContext, device_policy)  },
@@ -438,6 +439,21 @@ int bus_cgroup_set_property(
 
 return 1;
 
+} else if (streq(name, MemoryHierarchy)) {
+
+if (dbus_message_iter_get_arg_type(i) != DBUS_TYPE_BOOLEAN)
+return -EINVAL;
+
+if (mode != UNIT_CHECK) {
+dbus_bool_t b;
+dbus_message_iter_get_basic(i, b);
+
+c-memory_hierarchy = b;
+unit_write_drop_in_private(u, mode, name, b ? 
MemoryHierarchy=yes : MemoryHierarchy=no);
+}
+
+return 1;
+
 } else if (streq(name, DevicePolicy)) {
 const char *policy;
 CGroupDevicePolicy p;
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index 33c6880..bc57780 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -88,6 +88,7 @@ m4_define(`CGROUP_CONTEXT_CONFIG_ITEMS',
 $1.CPUAccounting,config_parse_bool,  0,
 offsetof($1, cgroup_context.cpu_accounting)
 $1.CPUShares,config_parse_cpu_shares,0,
 offsetof($1, cgroup_context)
 $1.MemoryAccounting, config_parse_bool,  0,
 offsetof($1, cgroup_context.memory_accounting)
+$1.MemoryHierarchy,  config_parse_bool,  0,
 offsetof($1, cgroup_context.memory_hierarchy)
 $1.MemoryLimit,  config_parse_memory_limit,  0,
 offsetof($1, cgroup_context)
 $1.MemorySoftLimit,  config_parse_memory_limit,  0,
 offsetof($1, cgroup_context)
 $1.DeviceAllow,  config_parse_device_allow,  0,
 offsetof($1, cgroup_context)
-- 
1.8.3.1

___
systemd-devel mailing list

[systemd-devel] [PATCH 2/5] cgroup: show MemoryHierarchy in cgroup_context_dump

2013-09-13 Thread Gao feng 
Show MemoryHierarchy in cgroup_context_dump.
---
 src/core/cgroup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 336d394..2c8aa22 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -91,6 +91,7 @@ void cgroup_context_dump(CGroupContext *c, FILE* f, const 
char *prefix) {
 %sCPUAccounting=%s\n
 %sBlockIOAccounting=%s\n
 %sMemoryAccounting=%s\n
+%sMemoryHierarchy=%s\n
 %sCPUShares=%lu\n
 %sBlockIOWeight%lu\n
 %sMemoryLimit=% PRIu64 \n
@@ -99,6 +100,7 @@ void cgroup_context_dump(CGroupContext *c, FILE* f, const 
char *prefix) {
 prefix, yes_no(c-cpu_accounting),
 prefix, yes_no(c-blockio_accounting),
 prefix, yes_no(c-memory_accounting),
+prefix, yes_no(c-memory_hierarchy),
 prefix, c-cpu_shares,
 prefix, c-blockio_weight,
 prefix, c-memory_limit,
-- 
1.8.3.1

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

[systemd-devel] [PATCH 3/5] systemctl: support setting MemoryHierarchy through systemctl

2013-09-13 Thread Gao feng 
support setting MemoryHierarchy of unit through systemctl.
---
 src/systemctl/systemctl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 57e5bb9..87388bb 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3643,6 +3643,7 @@ static int append_assignment(DBusMessageIter *iter, const 
char *assignment) {
 
 if (streq(field, CPUAccounting) ||
 streq(field, MemoryAccounting) ||
+streq(field, MemoryHierarchy) ||
 streq(field, BlockIOAccounting)) {
 dbus_bool_t b;
 
-- 
1.8.3.1

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

[systemd-devel] [PATCH 5/5] machine.slice: enable MemoryHierarchy by default

2013-09-13 Thread Gao feng 
We can simply limit the total memory usage of machines
through setting the memory usage limit of machine.slice.
---
 units/machine.slice | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/units/machine.slice b/units/machine.slice
index 3d40dfd..c959598 100644
--- a/units/machine.slice
+++ b/units/machine.slice
@@ -9,3 +9,6 @@
 Description=Virtual Machine and Container Slice
 Documentation=man:systemd.special(7)
 Before=slices.target
+
+[Slice]
+MemoryHierarchy=yes
-- 
1.8.3.1

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

[systemd-devel] [PATCH 4/5] man: add manpage for MemoryHierarchy

2013-09-13 Thread Gao feng 
add the manpage for MemoryHierarchy.
---
 man/systemd.cgroup.xml | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/man/systemd.cgroup.xml b/man/systemd.cgroup.xml
index cc0eb15..80fc2e2 100644
--- a/man/systemd.cgroup.xml
+++ b/man/systemd.cgroup.xml
@@ -135,6 +135,17 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   /varlistentry
 
   varlistentry
+termvarnameMemoryHierarchy=/varname/term
+
+listitem
+  paraTurn on hierarchical accounting and reclaim for this
+  unit. Takes a boolean argument. Note that turning on hierarchical
+  accounting for one unit will also implicitly turn it on for
+  all units contained therein./para
+/listitem
+  /varlistentry
+
+  varlistentry
 
termvarnameMemoryLimit=replaceablebytes/replaceable/varname/term
 
termvarnameMemorySoftLimit=replaceablebytes/replaceable/varname/term
 
-- 
1.8.3.1

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

Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline

2013-09-13 Thread Tom Gundersen 
On Thu, Sep 12, 2013 at 12:10 PM, Harald Hoyer harald.ho...@gmail.com wrote:
 On 09/11/2013 05:35 PM, Lennart Poettering wrote:
 On Mon, 19.08.13 00:15, Tom Gundersen (t...@jklm.no) wrote:

 The main usecase for this is to make it possible to use cryptsetup in
 the initrd without it having to include a host-specific /etc/crypttab.

 Hmm, I contrast to Harald I think adding luks.options= would actually be
 OK.

 I don't think we really strictly need something here that can cover
 everything. I think it is OK if we have a minimal, easy,
 reduced-functionality way to configure luks disks via the kernel cmdline
 and a full-blown one with /etc/crypttab. It's a bit weird but I think
 not totally incomprehensible to users. Hence adding luks.options= and
 rd.luks.options= sounds like a very simple minimal addition here.

 If people really want per-device options, then one day we could on top
 of this just extend the preexisting luks.uuid= syntax to also take a key
 file and an option string via some ; based syntax (i.e. taking up
 Harald's idea, but voerloading it into luks.uuid=).

 Or in other words, have this syntax now:

luks.uuid=UUID
luks.key=KEY
luks.options=OPTIONS

 (and the allow discards thing would be subsumed under luks.options)

 And then one day maybe optionally allow this syntax too:

luks.uuid=UUID;KEY;OPTIONS

 Does that make sense?

 So yeah, Tom, I think you patch looks good and should go in (but please
 update kernel-command-line(7) too), unless Harald violently opposes? ;-)

 Lennart


 I do not violently oppose. Only pointing out, that, if we extend luks, we also
 might want have one option instead to rule them all.

Ok, so I pushed this for now. Let's get back to a fully generic
version in the future if it turns out we need that...

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

[systemd-devel] [PATCH] build: check for build/link flags harder

2013-09-13 Thread David Herrmann 
Use AC_LINK_IFELSE instead of AC_COMPILE_IFELSE to test for flags that
might succeed during compilation but not during linking. An example is gcc
compiled with libssp support but gnu-ld without it. In this case
-fstack-protector works fine during compilation but fails during linking
as several internal helpers are missing.
---
 m4/attributes.m4 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/m4/attributes.m4 b/m4/attributes.m4
index 7e080da..aa53ef2 100644
--- a/m4/attributes.m4
+++ b/m4/attributes.m4
@@ -42,9 +42,9 @@ AC_DEFUN([CC_CHECK_FLAG_APPEND], [
  AS_TR_SH([cc_cv_$2_$3]),
   [eval AS_TR_SH([cc_save_$2])='${$2}'
eval AS_TR_SH([$2])='-Werror $3'
-   AC_COMPILE_IFELSE([AC_LANG_SOURCE([int a = 0; int main(void) { 
return a; } ])],
-[eval AS_TR_SH([cc_cv_$2_$3])='yes'],
-[eval AS_TR_SH([cc_cv_$2_$3])='no'])
+   AC_LINK_IFELSE([AC_LANG_SOURCE([int a = 0; int main(void) { return 
a; } ])],
+  [eval AS_TR_SH([cc_cv_$2_$3])='yes'],
+  [eval AS_TR_SH([cc_cv_$2_$3])='no'])
eval AS_TR_SH([$2])='$cc_save_$2'])
 
   AS_IF([eval test x$]AS_TR_SH([cc_cv_$2_$3])[ = xyes],
-- 
1.8.4

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

[systemd-devel] [RFC] mount/automount/swap: unify the remaining default dependency handling

2013-09-13 Thread Tom Gundersen 
This moves the last bits of the default dependency handling from the fstab
generator to core, and uses it also in the gpt-auto generator; making the
logic the same no matter how you set up your mount points.

The first patch may be controversial as it changes the semantics of automount
points quite a bit. I think it makes more sense this way, but coments welcome.

Cheers,

Tom

 src/core/automount.c|  14 ++
 src/core/mount.c|  53 
++---
 src/fstab-generator/fstab-generator.c   | 111 
++-
 src/gpt-auto-generator/gpt-auto-generator.c |  28 
 4 files changed, 86 insertions(+), 120 deletions(-)

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

[systemd-devel] [PATCH 1/3] [RFC] automount: decouple from corresponding mount unit

2013-09-13 Thread Tom Gundersen 
Also, move all the default dependency logic into core, this introduces a
functional change compared to the fstab generator:

We no longer care about the type (network or local) or options (nofail)
of filesystem corresponding to the automount, but consider an automount
unit as a local mount point which is not allowed to fail.

In the initrd the automount is unconditionally Before and RequiredBy
both initrd-root-fs.target and initrd-fs.target. In the real root the
automount is unconditionally Before and RequiredBy local-fs.target.
---
 src/core/automount.c  | 14 ++
 src/fstab-generator/fstab-generator.c | 23 +++
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/src/core/automount.c b/src/core/automount.c
index a20d534..27d96ce 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
@@ -163,6 +163,20 @@ static int automount_add_default_dependencies(Automount 
*a) {
 if (UNIT(a)-manager-running_as != SYSTEMD_SYSTEM)
 return 0;
 
+if (in_initrd()) {
+r = unit_add_two_dependencies_by_name(UNIT(a), UNIT_BEFORE, 
UNIT_REQUIRED_BY, SPECIAL_INITRD_ROOT_FS_TARGET, NULL, true);
+if (r  0)
+return r;
+
+r = unit_add_two_dependencies_by_name(UNIT(a), UNIT_BEFORE, 
UNIT_REQUIRED_BY, SPECIAL_INITRD_FS_TARGET, NULL, true);
+if (r  0)
+return r;
+} else {
+r = unit_add_two_dependencies_by_name(UNIT(a), UNIT_BEFORE, 
UNIT_REQUIRED_BY, SPECIAL_LOCAL_FS_TARGET, NULL, true);
+if (r  0)
+return r;
+}
+
 r = unit_add_two_dependencies_by_name(UNIT(a), UNIT_BEFORE, 
UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true);
 if (r  0)
 return r;
diff --git a/src/fstab-generator/fstab-generator.c 
b/src/fstab-generator/fstab-generator.c
index 6ebe8aa..02052ea 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -252,17 +252,11 @@ static int add_mount(
 fprintf(f,
 # Automatically generated by 
systemd-fstab-generator\n\n
 [Unit]\n
-SourcePath=%s\n,
-source);
-
-if (post)
-fprintf(f,
-Before= %s\n,
-post);
-
-fprintf(f,
+SourcePath=%s\n
+\n
 [Automount]\n
 Where=%s\n,
+source,
 where);
 
 fflush(f);
@@ -270,17 +264,6 @@ static int add_mount(
 log_error(Failed to write unit file %s: %m, 
automount_unit);
 return -errno;
 }
-
-free(lnk);
-lnk = strjoin(arg_dest, /, post, nofail ? .wants/ : 
.requires/, automount_name, NULL);
-if (!lnk)
-return log_oom();
-
-mkdir_parents_label(lnk, 0755);
-if (symlink(automount_unit, lnk)  0) {
-log_error(Failed to create symlink %s: %m, lnk);
-return -errno;
-}
 }
 
 return 0;
-- 
1.8.4

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

[systemd-devel] [PATCH 1/2] libudev: fix move_later comparison

2013-09-13 Thread Lukas Nykryn 
At the beginning move_later is set to -1, but it is set to different
value only if expression !move_later is true.
---
 src/libudev/libudev-enumerate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/libudev/libudev-enumerate.c b/src/libudev/libudev-enumerate.c
index bc1e37d..8146f27 100644
--- a/src/libudev/libudev-enumerate.c
+++ b/src/libudev/libudev-enumerate.c
@@ -300,7 +300,7 @@ _public_ struct udev_list_entry 
*udev_enumerate_get_list_entry(struct udev_enume
 /* skip to be delayed devices, and move the to
  * the point where the prefix changes. We can
  * only move one item at a time. */
-if (!move_later) {
+if (move_later == -1) {
 move_later_prefix = 
devices_delay_later(udev_enumerate-udev, entry-syspath);
 
 if (move_later_prefix  0) {
-- 
1.8.3.1

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

[systemd-devel] [PATCH 2/2] random-seed: we should return errno of failed loop_write

2013-09-13 Thread Lukas Nykryn 
---
 src/random-seed/random-seed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/random-seed/random-seed.c b/src/random-seed/random-seed.c
index 4776c07..afbd500 100644
--- a/src/random-seed/random-seed.c
+++ b/src/random-seed/random-seed.c
@@ -157,7 +157,7 @@ int main(int argc, char *argv[]) {
 r = loop_write(seed_fd, buf, (size_t) k, false);
 if (r = 0) {
 log_error(Failed to write new random seed file: %s, 
r  0 ? strerror(-r) : short write);
-r = k == 0 ? -EIO : (int) k;
+r = r == 0 ? -EIO : r;
 }
 }
 
-- 
1.8.3.1

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

Re: [systemd-devel] [PATCH 1/5] cgroup: add the setting memory.use_hierarchy support for systemd

2013-09-13 Thread Lennart Poettering 
On Fri, 13.09.13 17:49, Gao feng (gaof...@cn.fujitsu.com) wrote:

 Some programs need to set the memory.use_hierarchy(such as libvirt),
 Add this feature.

Hmm, should this really be an option? Shouldn't we much rather turn this
on unconditionally if the memory controller is used for a unit?

This appears like an option that would go a way in Tejun's new sane
cgroup tree logic anyway, no?

Lennart

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

[systemd-devel] [PATCH] core/cgroup: first print then free

2013-09-13 Thread Lukas Nykryn 
---
 src/core/cgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 3eeb475..513450a 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -395,8 +395,8 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 is_in_hash = true;
 
 if (r  0) {
-free(path);
 log_error(cgroup %s exists already: %s, path, strerror(-r));
+free(path);
 return r;
 }
 
-- 
1.8.3.1

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

Re: [systemd-devel] [PATCH] automount: rename repeat_unmont to repeat_unmount

2013-09-13 Thread Lennart Poettering 
On Thu, 12.09.13 19:45, David Mackey (tdmac...@booleanhaiku.com) wrote:

 - Trivial cleanup of repeat_unmount() spelling.

Thanks! Applied!

 
 Signed-off-by: David Mackey tdmac...@booleanhaiku.com
 ---
  src/core/automount.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/core/automount.c b/src/core/automount.c
 index a20d534..6762392 100644
 --- a/src/core/automount.c
 +++ b/src/core/automount.c
 @@ -66,7 +66,7 @@ static void automount_init(Unit *u) {
  UNIT(a)-ignore_on_isolate = true;
  }
  
 -static void repeat_unmout(const char *path) {
 +static void repeat_unmount(const char *path) {
  assert(path);
  
  for (;;) {
 @@ -100,7 +100,7 @@ static void unmount_autofs(Automount *a) {
  if (a-where 
  (UNIT(a)-manager-exit_code != MANAGER_RELOAD 
   UNIT(a)-manager-exit_code != MANAGER_REEXECUTE))
 -repeat_unmout(a-where);
 +repeat_unmount(a-where);
  }
  
  static void automount_done(Unit *u) {
 @@ -575,7 +575,7 @@ fail:
  close_nointr_nofail(ioctl_fd);
  
  if (mounted)
 -repeat_unmout(a-where);
 +repeat_unmount(a-where);
  
  log_error_unit(UNIT(a)-id,
 Failed to initialize automounter: %s, strerror(-r));


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] [PATCH 2/2] cgroup: correct the log information

2013-09-13 Thread Lennart Poettering 
On Fri, 13.09.13 11:17, Gao feng (gaof...@cn.fujitsu.com) wrote:

 it should be memory.soft_limit_in_bytes.

Thanks! Applied both!

 ---
  src/core/cgroup.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/core/cgroup.c b/src/core/cgroup.c
 index fba0b2f..aee93ba 100644
 --- a/src/core/cgroup.c
 +++ b/src/core/cgroup.c
 @@ -266,7 +266,7 @@ void cgroup_context_apply(CGroupContext *c, 
 CGroupControllerMask mask, const cha
  sprintf(buf, % PRIu64 \n, c-memory_soft_limit);
  r = cg_set_attribute(memory, path, 
 memory.soft_limit_in_bytes, buf);
  if (r  0)
 -log_error(Failed to set memory.limit_in_bytes on 
 %s: %s, path, strerror(-r));
 +log_error(Failed to set memory.soft_limit_in_bytes 
 on %s: %s, path, strerror(-r));
  }
  
  if (mask  CGROUP_DEVICE) {


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] [PATCH] cgroup: fix incorrectly setting memory cgroup

2013-09-13 Thread Lennart Poettering 
On Fri, 13.09.13 14:43, Gao feng (gaof...@cn.fujitsu.com) wrote:

 If the memory_limit of unit is -1, we should write -1
 to the file memory.limit_in_bytes. not the (unit64_t) -1.
 
 otherwise the memory.limit_in_bytes will be set to zero.

Thanks! Applied!
 ---
  src/core/cgroup.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)
 
 diff --git a/src/core/cgroup.c b/src/core/cgroup.c
 index aee93ba..244baff 100644
 --- a/src/core/cgroup.c
 +++ b/src/core/cgroup.c
 @@ -257,14 +257,21 @@ void cgroup_context_apply(CGroupContext *c, 
 CGroupControllerMask mask, const cha
  
  if (mask  CGROUP_MEMORY) {
  char buf[DECIMAL_STR_MAX(uint64_t) + 1];
 +if (c-memory_limit != (uint64_t) -1) {
 +sprintf(buf, % PRIu64 \n, c-memory_limit);
 +r = cg_set_attribute(memory, path, 
 memory.limit_in_bytes, buf);
 +} else
 +r = cg_set_attribute(memory, path, 
 memory.limit_in_bytes, -1);
  
 -sprintf(buf, % PRIu64 \n, c-memory_limit);
 -r = cg_set_attribute(memory, path, 
 memory.limit_in_bytes, buf);
  if (r  0)
  log_error(Failed to set memory.limit_in_bytes on 
 %s: %s, path, strerror(-r));
  
 -sprintf(buf, % PRIu64 \n, c-memory_soft_limit);
 -r = cg_set_attribute(memory, path, 
 memory.soft_limit_in_bytes, buf);
 +if (c-memory_soft_limit != (uint64_t) -1) {
 +sprintf(buf, % PRIu64 \n, c-memory_soft_limit);
 +r = cg_set_attribute(memory, path, 
 memory.soft_limit_in_bytes, buf);
 +} else
 +r = cg_set_attribute(memory, path, 
 memory.soft_limit_in_bytes, -1);
 +
  if (r  0)
  log_error(Failed to set memory.soft_limit_in_bytes 
 on %s: %s, path, strerror(-r));
  }


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] [PATCH 2/2] random-seed: we should return errno of failed loop_write

2013-09-13 Thread Lennart Poettering 
On Fri, 13.09.13 14:12, Lukas Nykryn (lnyk...@redhat.com) wrote:

Thanks! Applied this one!
 ---
  src/random-seed/random-seed.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/random-seed/random-seed.c b/src/random-seed/random-seed.c
 index 4776c07..afbd500 100644
 --- a/src/random-seed/random-seed.c
 +++ b/src/random-seed/random-seed.c
 @@ -157,7 +157,7 @@ int main(int argc, char *argv[]) {
  r = loop_write(seed_fd, buf, (size_t) k, false);
  if (r = 0) {
  log_error(Failed to write new random seed file: 
 %s, r  0 ? strerror(-r) : short write);
 -r = k == 0 ? -EIO : (int) k;
 +r = r == 0 ? -EIO : r;
  }
  }
  


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] [PATCH 1/2] libudev: fix move_later comparison

2013-09-13 Thread Harald Hoyer 
On 09/13/2013 02:12 PM, Lukas Nykryn wrote:
 At the beginning move_later is set to -1, but it is set to different
 value only if expression !move_later is true.
 ---
  src/libudev/libudev-enumerate.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/libudev/libudev-enumerate.c b/src/libudev/libudev-enumerate.c
 index bc1e37d..8146f27 100644
 --- a/src/libudev/libudev-enumerate.c
 +++ b/src/libudev/libudev-enumerate.c
 @@ -300,7 +300,7 @@ _public_ struct udev_list_entry 
 *udev_enumerate_get_list_entry(struct udev_enume
  /* skip to be delayed devices, and move the to
   * the point where the prefix changes. We can
   * only move one item at a time. */
 -if (!move_later) {
 +if (move_later == -1) {
  move_later_prefix = 
 devices_delay_later(udev_enumerate-udev, entry-syspath);
  
  if (move_later_prefix  0) {
 

looks good! please push
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] libudev: fix move_later comparison

2013-09-13 Thread Harald Hoyer 
On 09/13/2013 03:25 PM, Harald Hoyer wrote:
 On 09/13/2013 02:12 PM, Lukas Nykryn wrote:
 At the beginning move_later is set to -1, but it is set to different
 value only if expression !move_later is true.
 ---
  src/libudev/libudev-enumerate.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/libudev/libudev-enumerate.c 
 b/src/libudev/libudev-enumerate.c
 index bc1e37d..8146f27 100644
 --- a/src/libudev/libudev-enumerate.c
 +++ b/src/libudev/libudev-enumerate.c
 @@ -300,7 +300,7 @@ _public_ struct udev_list_entry 
 *udev_enumerate_get_list_entry(struct udev_enume
  /* skip to be delayed devices, and move the to
   * the point where the prefix changes. We can
   * only move one item at a time. */
 -if (!move_later) {
 +if (move_later == -1) {
  move_later_prefix = 
 devices_delay_later(udev_enumerate-udev, entry-syspath);
  
  if (move_later_prefix  0) {

 
 looks good! please push
 

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

Re: [systemd-devel] [PATCH] core: get rid the start job when transitioning to deactivating

2013-09-13 Thread Michal Sekletar 
On Thu, Sep 12, 2013 at 06:51:49PM +0200, Lennart Poettering wrote:
 On Fri, 19.07.13 09:17, Lukáš Nykrýn (lnyk...@redhat.com) wrote:
 
  Hi,
  when service has StopWhenUnneeded=yes and it is requested by forking
  service, which fails during initialization, the first unit is not
  stopped.

Hi Lennart,

 
 I have added this to the TODO list for now, so that we don't
 forget. I'll look into it after the next release.
 

Thank you for taking the time to look into this.

 (Sorry for the delay)

No worries. :)

 
  
  Reproducer:
  
  -bash-4.2# more /etc/systemd/system/test*
  ::
  /etc/systemd/system/test.service
  ::
  [Unit]
  Description=aaa
  Requires=testb.service
  
  [Service]
  Type=forking
  ExecStart=/bin/sleep 50
  TimeoutStartSec=3
  
  ::
  /etc/systemd/system/testb.service
  ::
  [Unit]
  Description=aaa
  StopWhenUnneeded=yes
  
  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/bin/echo hej
  ExecStop=/bin/echo hou
  
  -bash-4.2# systemctl status testb test
  testb.service - aaa
 Loaded: loaded (/etc/systemd/system/testb.service; static)
 Active: inactive (dead)
  
  
  test.service - aaa
 Loaded: loaded (/etc/systemd/system/test.service; static)
 Active: inactive (dead)
  
  -bash-4.2# systemctl start test
  Job for test.service failed. See 'systemctl status test.service' and
  'journalctl -xn' for details.
  
  -bash-4.2# systemctl status testb test
  testb.service - aaa
 Loaded: loaded (/etc/systemd/system/testb.service; static)
 Active: active (exited) since Thu 2013-07-18 15:34:34 CEST; 7s ago
Process: 45 ExecStart=/bin/echo hej (code=exited, status=0/SUCCESS)
  
  Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
  Jul 18 15:34:34 mycontainer systemd[1]: Started aaa.
  
  test.service - aaa
 Loaded: loaded (/etc/systemd/system/test.service; static)
 Active: failed (Result: timeout) since Thu 2013-07-18 15:34:37
  CEST; 4s ago
Process: 46 ExecStart=/bin/sleep 50 (code=killed, signal=TERM)
  
  Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
  Jul 18 15:34:37 mycontainer systemd[1]: test.service operation timed
  out. Terminating.
  Jul 18 15:34:37 mycontainer systemd[1]: Failed to start aaa.
  Jul 18 15:34:37 mycontainer systemd[1]: Unit test.service entered
  failed state.
 
 
 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] [ANNOUNCE] systemd 207

2013-09-13 Thread Colin Guthrie 
'Twas brillig, and Lennart Poettering at 13/09/13 03:16 did gyre and gimble:
 * The option discard (as known from Debian) is now
   synonymous to allow-discards in /etc/crypttab. In fact,
   the latter is preferred now (since it is easier to remember
   and type).

I think you mean the *former* is preferred now? (I cannot see how
allow-discards is easier to type than discard ;)


 * The systemd-sysctl tool no longer natively reads the
   file /etc/sysctl.conf. If desired, the file should be
   symlinked from /etc/sysctl.d/99-sysctl.conf. Apart from
   providing legacy support by a symlink rather than built-in
   code, it also makes the otherwise hidden order of application
   of the different files visible.

It's also worth noting here that sysctl.d files are processed
differently now.

Up to and including v197 (or fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda),
sysctl.d files had to be named higher than the 50-default.conf file to
override something. e.g. if you wanted to override kernel.sysrq = 16
then you needed to put it in a file named 51-i-know-better.conf in the
appropriate location.

From v198+ the order changed, and you had to name the file *lower* than
50-default.conf, e.g. 49-i-know-better.conf.

Now from v207 onwards the ordering has reverted back to the v197 logic
(which I agree feels more natural).

If you have distro tools and/or have deployed updates which adapted to
this change in behaviour, you should undo those changes with this release.

It may make sense to update the NEWS file in git to include a note about
this (albeit very minor) API breakage (although the v198 NEWS didn't
mention it's change in behaviour so perhaps it's fine to leave it out!).

All the best


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] [PATCH 1/2] util, utf8: make ellipsize and ellipsize_mem take into account multi-byte characters

2013-09-13 Thread Shawn Landden 
rename old versions to ascii_*

Do not take into account zerowidth characters, but do consider double-wide 
characters.
Import needed utf8 helper code from glib.
---
 TODO  |   4 --
 src/shared/utf8.c | 120 ++
 src/shared/utf8.h | 100 +
 src/shared/util.c |  70 ++-
 src/shared/util.h |   3 ++
 5 files changed, 292 insertions(+), 5 deletions(-)

diff --git a/TODO b/TODO
index 08d4914..509b31f 100644
--- a/TODO
+++ b/TODO
@@ -19,10 +19,6 @@ Bugfixes:
 
 * properly handle .mount unit state tracking when two mount points are stacked 
one on top of another on the exact same mount point.
 
-* ellipsize_mem must take into account multi-byte unicode characters, and
-  - make the resulting line the requested number of *characters*, not *bytes*,
-  - avoid truncuating multi-byte sequences in the middle.
-
 * When we detect invalid UTF-8, we cant't use it in an error message:
   log...(Path is not UTF-8 clean, ignoring assignment: %s, rvalue);
 
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 655cc77..a9308b5 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -22,6 +22,11 @@
 /* This file is based on the GLIB utf8 validation functions. The
  * original license text follows. */
 
+/* gunicode.h - Unicode manipulation functions
+ *
+ *  Copyright (C) 1999, 2000 Tom Tromey
+ *  Copyright 2000, 2005 Red Hat, Inc.
+ */
 /* gutf8.c - Operations on UTF-8 strings.
  *
  * Copyright (C) 1999 Tom Tromey
@@ -317,3 +322,118 @@ char *utf16_to_utf8(const void *s, size_t length) {
 
 return r;
 }
+
+/**
+ * g_utf8_prev_char:
+ * @p: a pointer to a position within a UTF-8 encoded string
+ *
+ * Finds the previous UTF-8 character in the string before @p.
+ *
+ * @p does not have to be at the beginning of a UTF-8 character. No check
+ * is made to see if the character found is actually valid other than
+ * it starts with an appropriate byte. If @p might be the first
+ * character of the string, you must use g_utf8_find_prev_char() instead.
+ *
+ * Return value: a pointer to the found character.
+ **/
+char *
+utf8_prev_char (const char *p)
+{
+  while (1)
+{
+  p--;
+  if ((*p  0xc0) != 0x80)
+   return (char *)p;
+}
+}
+
+/**
+ * g_utf8_get_char:
+ * @p: a pointer to Unicode character encoded as UTF-8
+ *
+ * Converts a sequence of bytes encoded as UTF-8 to a Unicode character.
+ * If @p does not point to a valid UTF-8 encoded character, results are
+ * undefined. If you are not sure that the bytes are complete
+ * valid Unicode characters, you should use g_utf8_get_char_validated()
+ * instead.
+ *
+ * Return value: the resulting character
+ **/
+unichar
+utf8_get_char (const char *p)
+{
+  int i, mask = 0, len;
+  unichar result;
+  unsigned char c = (unsigned char) *p;
+
+  UTF8_COMPUTE (c, mask, len);
+  if (len == -1)
+return (unichar)-1;
+  UTF8_GET (result, p, i, mask, len);
+
+  return result;
+}
+
+struct Interval
+{
+  unichar start, end;
+};
+
+static int
+interval_compare (const void *key, const void *elt)
+{
+  unichar c = (unichar) (long) (key);
+  struct Interval *interval = (struct Interval *)elt;
+
+  if (c  interval-start)
+return -1;
+  if (c  interval-end)
+return +1;
+
+  return 0;
+}
+
+/*
+ * NOTE:
+ *
+ * The tables for g_unichar_iswide() and g_unichar_iswide_cjk() are
+ * generated from the Unicode Character Database's file
+ * extracted/DerivedEastAsianWidth.txt using the gen-iswide-table.py
+ * in this way:
+ *
+ *   ./gen-iswide-table.py  path/to/ucd/extracted/DerivedEastAsianWidth.txt | 
fmt
+ *
+ * Last update for Unicode 6.0.
+ */
+
+/**
+ * g_unichar_iswide:
+ * @c: a Unicode character
+ *
+ * Determines if a character is typically rendered in a double-width
+ * cell.
+ *
+ * Return value: %TRUE if the character is wide
+ **/
+bool
+unichar_iswide (unichar c)
+{
+  /* See NOTE earlier for how to update this table. */
+  static const struct Interval wide[] = {
+{0x1100, 0x115F}, {0x2329, 0x232A}, {0x2E80, 0x2E99}, {0x2E9B, 0x2EF3},
+{0x2F00, 0x2FD5}, {0x2FF0, 0x2FFB}, {0x3000, 0x303E}, {0x3041, 0x3096},
+{0x3099, 0x30FF}, {0x3105, 0x312D}, {0x3131, 0x318E}, {0x3190, 0x31BA},
+{0x31C0, 0x31E3}, {0x31F0, 0x321E}, {0x3220, 0x3247}, {0x3250, 0x32FE},
+{0x3300, 0x4DBF}, {0x4E00, 0xA48C}, {0xA490, 0xA4C6}, {0xA960, 0xA97C},
+{0xAC00, 0xD7A3}, {0xF900, 0xFAFF}, {0xFE10, 0xFE19}, {0xFE30, 0xFE52},
+{0xFE54, 0xFE66}, {0xFE68, 0xFE6B}, {0xFF01, 0xFF60}, {0xFFE0, 0xFFE6},
+{0x1B000, 0x1B001}, {0x1F200, 0x1F202}, {0x1F210, 0x1F23A}, {0x1F240,
+0x1F248}, {0x1F250, 0x1F251}, {0x2, 0x2FFFD}, {0x3, 0x3FFFD}
+  };
+
+  if (bsearch ((long *)c, wide, (sizeof (wide) / sizeof ((wide)[0])), sizeof 
wide[0],
+  interval_compare))
+return true;
+
+  return false;
+}
diff --git a/src/shared/utf8.h b/src/shared/utf8.h
index f805ea6..f1be180 100644
--- a/src/shared/utf8.h
+++

[systemd-devel] [PATCH 2/2] test: test for new ellipsize_mem (requires user)

2013-09-13 Thread Shawn Landden 
---
 Makefile.am   |  7 +++
 src/test/test-ellipsize.c | 42 ++
 2 files changed, 49 insertions(+)
 create mode 100644 src/test/test-ellipsize.c

diff --git a/Makefile.am b/Makefile.am
index 7b7539a..0e4f58c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1125,6 +1125,7 @@ tests += \
test-unit-file \
test-util \
test-date \
+   test-ellipsize \
test-sleep \
test-replace-var \
test-sched-prio \
@@ -1303,6 +1304,12 @@ test_date_SOURCES = \
 test_date_LDADD = \
libsystemd-core.la
 
+test_ellipsize_SOURCES = \
+src/test/test-wellipsize.c
+
+test_ellipsize_LDADD = \
+libsystemd-core.la
+
 test_sleep_SOURCES = \
src/test/test-sleep.c
 
diff --git a/src/test/test-ellipsize.c b/src/test/test-ellipsize.c
new file mode 100644
index 000..f6db82c
--- /dev/null
+++ b/src/test/test-ellipsize.c
@@ -0,0 +1,42 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2013 Shawn Landden
+
+  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 stdio.h
+
+#include util.h
+#include utf8.h
+
+static void test_one(const char *p) {
+   _cleanup_free_ char *t = NULL;
+   t = ellipsize(p, 80, 70);
+   puts(t);
+}
+
+int main(int argc, char *argv[]) {
+
test_one(s??);
+
test_one(?);
+
test_one(??);
+
test_one(?);
+
test_one();
+
test_one(asdfnjaskdfnklasdgnjaskdghnkasdgfklasdfjkasdfjaksdfaskldfnaskldfnaskldfnaklsdfnaklsdfnklnaskjgdknl);
+
+return 0;
+}
-- 
1.8.4.rc3

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

[systemd-devel] [PATCH 1/2] util, utf8: make ellipsize and ellipsize_mem take into account multi-byte characters

2013-09-13 Thread Shawn Landden 
rename old versions to ascii_*

Do not take into account zerowidth characters, but do consider double-wide 
characters.
Import needed utf8 helper code from glib.
---
 TODO  |   4 --
 src/shared/utf8.c | 120 ++
 src/shared/utf8.h | 100 +
 src/shared/util.c |  77 +--
 src/shared/util.h |   3 ++
 5 files changed, 296 insertions(+), 8 deletions(-)

diff --git a/TODO b/TODO
index 08d4914..509b31f 100644
--- a/TODO
+++ b/TODO
@@ -19,10 +19,6 @@ Bugfixes:
 
 * properly handle .mount unit state tracking when two mount points are stacked 
one on top of another on the exact same mount point.
 
-* ellipsize_mem must take into account multi-byte unicode characters, and
-  - make the resulting line the requested number of *characters*, not *bytes*,
-  - avoid truncuating multi-byte sequences in the middle.
-
 * When we detect invalid UTF-8, we cant't use it in an error message:
   log...(Path is not UTF-8 clean, ignoring assignment: %s, rvalue);
 
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 655cc77..a9308b5 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -22,6 +22,11 @@
 /* This file is based on the GLIB utf8 validation functions. The
  * original license text follows. */
 
+/* gunicode.h - Unicode manipulation functions
+ *
+ *  Copyright (C) 1999, 2000 Tom Tromey
+ *  Copyright 2000, 2005 Red Hat, Inc.
+ */
 /* gutf8.c - Operations on UTF-8 strings.
  *
  * Copyright (C) 1999 Tom Tromey
@@ -317,3 +322,118 @@ char *utf16_to_utf8(const void *s, size_t length) {
 
 return r;
 }
+
+/**
+ * g_utf8_prev_char:
+ * @p: a pointer to a position within a UTF-8 encoded string
+ *
+ * Finds the previous UTF-8 character in the string before @p.
+ *
+ * @p does not have to be at the beginning of a UTF-8 character. No check
+ * is made to see if the character found is actually valid other than
+ * it starts with an appropriate byte. If @p might be the first
+ * character of the string, you must use g_utf8_find_prev_char() instead.
+ *
+ * Return value: a pointer to the found character.
+ **/
+char *
+utf8_prev_char (const char *p)
+{
+  while (1)
+{
+  p--;
+  if ((*p  0xc0) != 0x80)
+   return (char *)p;
+}
+}
+
+/**
+ * g_utf8_get_char:
+ * @p: a pointer to Unicode character encoded as UTF-8
+ *
+ * Converts a sequence of bytes encoded as UTF-8 to a Unicode character.
+ * If @p does not point to a valid UTF-8 encoded character, results are
+ * undefined. If you are not sure that the bytes are complete
+ * valid Unicode characters, you should use g_utf8_get_char_validated()
+ * instead.
+ *
+ * Return value: the resulting character
+ **/
+unichar
+utf8_get_char (const char *p)
+{
+  int i, mask = 0, len;
+  unichar result;
+  unsigned char c = (unsigned char) *p;
+
+  UTF8_COMPUTE (c, mask, len);
+  if (len == -1)
+return (unichar)-1;
+  UTF8_GET (result, p, i, mask, len);
+
+  return result;
+}
+
+struct Interval
+{
+  unichar start, end;
+};
+
+static int
+interval_compare (const void *key, const void *elt)
+{
+  unichar c = (unichar) (long) (key);
+  struct Interval *interval = (struct Interval *)elt;
+
+  if (c  interval-start)
+return -1;
+  if (c  interval-end)
+return +1;
+
+  return 0;
+}
+
+/*
+ * NOTE:
+ *
+ * The tables for g_unichar_iswide() and g_unichar_iswide_cjk() are
+ * generated from the Unicode Character Database's file
+ * extracted/DerivedEastAsianWidth.txt using the gen-iswide-table.py
+ * in this way:
+ *
+ *   ./gen-iswide-table.py  path/to/ucd/extracted/DerivedEastAsianWidth.txt | 
fmt
+ *
+ * Last update for Unicode 6.0.
+ */
+
+/**
+ * g_unichar_iswide:
+ * @c: a Unicode character
+ *
+ * Determines if a character is typically rendered in a double-width
+ * cell.
+ *
+ * Return value: %TRUE if the character is wide
+ **/
+bool
+unichar_iswide (unichar c)
+{
+  /* See NOTE earlier for how to update this table. */
+  static const struct Interval wide[] = {
+{0x1100, 0x115F}, {0x2329, 0x232A}, {0x2E80, 0x2E99}, {0x2E9B, 0x2EF3},
+{0x2F00, 0x2FD5}, {0x2FF0, 0x2FFB}, {0x3000, 0x303E}, {0x3041, 0x3096},
+{0x3099, 0x30FF}, {0x3105, 0x312D}, {0x3131, 0x318E}, {0x3190, 0x31BA},
+{0x31C0, 0x31E3}, {0x31F0, 0x321E}, {0x3220, 0x3247}, {0x3250, 0x32FE},
+{0x3300, 0x4DBF}, {0x4E00, 0xA48C}, {0xA490, 0xA4C6}, {0xA960, 0xA97C},
+{0xAC00, 0xD7A3}, {0xF900, 0xFAFF}, {0xFE10, 0xFE19}, {0xFE30, 0xFE52},
+{0xFE54, 0xFE66}, {0xFE68, 0xFE6B}, {0xFF01, 0xFF60}, {0xFFE0, 0xFFE6},
+{0x1B000, 0x1B001}, {0x1F200, 0x1F202}, {0x1F210, 0x1F23A}, {0x1F240,
+0x1F248}, {0x1F250, 0x1F251}, {0x2, 0x2FFFD}, {0x3, 0x3FFFD}
+  };
+
+  if (bsearch ((long *)c, wide, (sizeof (wide) / sizeof ((wide)[0])), sizeof 
wide[0],
+  interval_compare))
+return true;
+
+  return false;
+}
diff --git a/src/shared/utf8.h b/src/shared/utf8.h
index f805ea6..f1be180 100644
--- a/src/shared/utf8.h
+++

Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit

2013-09-13 Thread Michal Sekletar 
On Wed, Sep 11, 2013 at 08:04:38PM +0200, Lennart Poettering wrote:
 On Fri, 09.08.13 16:00, Michal Sekletar (msekl...@redhat.com) wrote:
 
 Heya,

Hi Lennart,

 
 Hmm, so what I don't really like about this patch is that the stop might
 have caused the triggering units also to go away via some deps. If we
 check the triggers before executing the operations we will never take
 that into account. (Note that so far the trigger message is delayed
 after the job succeeded in order to make sure we can take the full
 a-posteriori state into account).

I understand your point, however I thought that displaying a message before
issuing stop job is better than presenting user with no information in case when
job gets canceled.

 
 So not sure, Zbigniew, do you have an opinion on this?

I think that Zbigniew's proposal might be the right thing to do here, i.e. we
would leave check for triggers as it is right now, but in case that stop job 
gets
canceled we would query for triggers anyway and present this information to the
user.

 
 (Also, Michal, what about the other patches from this series, are they
 still relevant? I amnot sure if you pulled them back or not, the thread
 confused me)

Second patch was about disallowing to enable template units, arguably there are
still use cases for this as presented by Tom. That makes the patch not
applicable. We need to come up with the scheme how to handle installation of
template units. Tom already proposed some solution in this thread, it'd be great
if you could comment on this.

 
 Lennart

Michal

 
  
  From a62d3668fb2513b1ece827520d44d5b7cd560407 Mon Sep 17 00:00:00 2001
  From: Michal Sekletar msekl...@redhat.com
  Date: Thu, 8 Aug 2013 13:26:56 +0200
  Subject: [PATCH 1/3] systemctl: check for triggering units before calling
   StopUnit
  
  Rearranging the code in a way that we always check for triggers before
  we issue StopUnit D-Bus call. This will make behavior consistent,
  because triggers are always checked.
  
  https://bugzilla.redhat.com/show_bug.cgi?id=908690
  ---
   src/systemctl/systemctl.c | 20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)
  
  diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
  index 8ec1824..ee47841 100644
  --- a/src/systemctl/systemctl.c
  +++ b/src/systemctl/systemctl.c
  @@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char 
  **args) {
   return log_oom();
   }
   
  +/* When stopping units, warn if they can still be triggered by
  + * another active unit (socket, path, timer) */
  +if (!arg_quiet  streq(method, StopUnit)) {
  +if (one_name)
  +check_triggering_units(bus, one_name);
  +else
  +STRV_FOREACH(name, args+1)
  +check_triggering_units(bus, *name);
  +}
  +
   if (one_name) {
   ret = start_unit_one(bus, method, one_name, mode, error, 
  s);
   if (ret  0)
  @@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char 
  **args) {
   r = wait_for_jobs(bus, s);
   if (r  0)
   return r;
  -
  -/* When stopping units, warn if they can still be 
  triggered by
  - * another active unit (socket, path, timer) */
  -if (!arg_quiet  streq(method, StopUnit)) {
  -if (one_name)
  -check_triggering_units(bus, one_name);
  -else
  -STRV_FOREACH(name, args+1)
  -check_triggering_units(bus, *name);
  -}
   }
   
   return ret;
 
 
 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] systemd shutdown vs ostree

2013-09-13 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
 'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
  On Thu, 12.09.13 23:31, Colin Guthrie (gm...@colin.guthr.ie) wrote:
  
 
  'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and 
  gimble:
  On Thu, 12.09.13 21:27, Colin Guthrie (gm...@colin.guthr.ie) wrote:
 
  So, as mentioned in the other thread, /usr should probably be on some
  OS resource blacklist or so, and not attempted to be shutdown.
 
  But unmounting /var during shutdown should actually work. The only thing
  that currently stops this from working cleanly is that journald is
  configured to stay around until the last moment, but currently has not
  interface to tell it to move its logging back to /run from /var. When we
  have that then the /var issue should go away for you, no?
 
  It would be quite nice to have an easy way for a compliant initrd to say
  it can and will handle /var unmounting (perhaps by dropping a
  var.mount.d/ snippet in the /run/systemd/system/ folder at boot?). 
 
  Yeah, such a drop-in should just work. Just add DefaultDependencies=no
  in there, and maybe instead Before=local-fs.target, and you should be 
  set.
 
  Nice, I'm sure dracut could implement that then.
 
  This will allow us to get persistent logs in which the initrd can
  report it's progress until the last possible moment. This might help
  debugging any problems in this particular link of the shutdown chain.
 
  I think the really late shutdown logs should more liekly end up in some
  EFI var and then flushed out on next boot or so...
 
  Nice plan. How would be able to trust that data tho'. Would it have to
  be signed in some way? Or could it be marked somehow as unreliable data?
  I'm not sure it really *matters* that much from a trust perspective as
  it's use would likely be 99% debugging, but all the same it would be
  nice if it were trustable.
  
  Trust?  I mean, if you managed to upload data into EFI vars you are so
  privileged you can fuck with us anyway, so not sure what you mean
 
 Well I was originally thinking about other OS's etc. and knowing that
 logs came from the right install, but then posed the question in a more
 generic sense, in part due to the cryptographic guarantees given by FSS.
 I just figured this was an interesting way in which someone could inject
 false data at a point where you have zero way to know what went on
 between the last shutdown and the current boot.
 
 If is to be inherently trusted based on machine id then fine - just
 seems odd to put all the effort into FSS and then blindly inject data
 (possibly even core dumps which will be analysed later) and not mark it
 as potentially untrustworthy in some way.
FSS doesn't protect against fake data, it only allows you to detect when
data has been removed. So if I break into a machine with f-s-sealed logs,
I am still able to log anything I want, but the messages about my break-in
will be there, unless I remove some messages, in which case it will be visible
that there are no messages since some point. The same guarantee holds for
messages from pstore: you need root rights to write there. Even if there's
a second OS on the machine, if you have root right in that *other* OS, you
can write whatever you want to the logs in *this* OS, either through pstore
or directly by mounting /var. So pstore doesn't really change anything here.

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

Re: [systemd-devel] systemd shutdown vs ostree

2013-09-13 Thread Colin Guthrie 
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 13/09/13 16:33 did
gyre and gimble:
 On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
 'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
 On Thu, 12.09.13 23:31, Colin Guthrie (gm...@colin.guthr.ie) wrote:


 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and 
 gimble:
 On Thu, 12.09.13 21:27, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 So, as mentioned in the other thread, /usr should probably be on some
 OS resource blacklist or so, and not attempted to be shutdown.

 But unmounting /var during shutdown should actually work. The only thing
 that currently stops this from working cleanly is that journald is
 configured to stay around until the last moment, but currently has not
 interface to tell it to move its logging back to /run from /var. When we
 have that then the /var issue should go away for you, no?

 It would be quite nice to have an easy way for a compliant initrd to say
 it can and will handle /var unmounting (perhaps by dropping a
 var.mount.d/ snippet in the /run/systemd/system/ folder at boot?). 

 Yeah, such a drop-in should just work. Just add DefaultDependencies=no
 in there, and maybe instead Before=local-fs.target, and you should be 
 set.

 Nice, I'm sure dracut could implement that then.

 This will allow us to get persistent logs in which the initrd can
 report it's progress until the last possible moment. This might help
 debugging any problems in this particular link of the shutdown chain.

 I think the really late shutdown logs should more liekly end up in some
 EFI var and then flushed out on next boot or so...

 Nice plan. How would be able to trust that data tho'. Would it have to
 be signed in some way? Or could it be marked somehow as unreliable data?
 I'm not sure it really *matters* that much from a trust perspective as
 it's use would likely be 99% debugging, but all the same it would be
 nice if it were trustable.

 Trust?  I mean, if you managed to upload data into EFI vars you are so
 privileged you can fuck with us anyway, so not sure what you mean

 Well I was originally thinking about other OS's etc. and knowing that
 logs came from the right install, but then posed the question in a more
 generic sense, in part due to the cryptographic guarantees given by FSS.
 I just figured this was an interesting way in which someone could inject
 false data at a point where you have zero way to know what went on
 between the last shutdown and the current boot.

 If is to be inherently trusted based on machine id then fine - just
 seems odd to put all the effort into FSS and then blindly inject data
 (possibly even core dumps which will be analysed later) and not mark it
 as potentially untrustworthy in some way.

 FSS doesn't protect against fake data, it only allows you to detect when
 data has been removed. So if I break into a machine with f-s-sealed logs,
 I am still able to log anything I want, but the messages about my break-in
 will be there, unless I remove some messages, in which case it will be visible
 that there are no messages since some point. The same guarantee holds for
 messages from pstore: you need root rights to write there. Even if there's
 a second OS on the machine, if you have root right in that *other* OS, you
 can write whatever you want to the logs in *this* OS, either through pstore
 or directly by mounting /var. So pstore doesn't really change anything here.

Hmm, yeah, I guess the point about writing invalid new data is probably
moot - as you say any $OTHEROS could do the same - assuming of course
the disk is not encrypted...

There would be some theoretical risk of a machine, with pstore and
encrypted disks where some attacker who has limited physical access
could plant a pstore bomb and then waits for the user to boot and
enter their encryption keys at which point the fake data is logged.
But I'm sure there are many more interesting things the attacker could
do if they were to have even limited physical access, so my argument is
almost certainly invalid in practically all circumstances :)

That said, if it's possible to somehow do the FSS of the pstore data and
verify it before incorporating it on the next boot, it seems like that
would be the most sensible approach by design (theoretically, in
principle etc. etc.) Practically useful... probably not much :)

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 shutdown vs ostree

2013-09-13 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 13, 2013 at 04:48:37PM +0100, Colin Guthrie wrote:
 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 13/09/13 16:33 did
 gyre and gimble:
  On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
  'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and 
  gimble:
  On Thu, 12.09.13 23:31, Colin Guthrie (gm...@colin.guthr.ie) wrote:
 
 
  'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and 
  gimble:
  On Thu, 12.09.13 21:27, Colin Guthrie (gm...@colin.guthr.ie) wrote:
 
  So, as mentioned in the other thread, /usr should probably be on some
  OS resource blacklist or so, and not attempted to be shutdown.
 
  But unmounting /var during shutdown should actually work. The only 
  thing
  that currently stops this from working cleanly is that journald is
  configured to stay around until the last moment, but currently has not
  interface to tell it to move its logging back to /run from /var. When 
  we
  have that then the /var issue should go away for you, no?
 
  It would be quite nice to have an easy way for a compliant initrd to 
  say
  it can and will handle /var unmounting (perhaps by dropping a
  var.mount.d/ snippet in the /run/systemd/system/ folder at boot?). 
 
  Yeah, such a drop-in should just work. Just add DefaultDependencies=no
  in there, and maybe instead Before=local-fs.target, and you should be 
  set.
 
  Nice, I'm sure dracut could implement that then.
 
  This will allow us to get persistent logs in which the initrd can
  report it's progress until the last possible moment. This might help
  debugging any problems in this particular link of the shutdown chain.
 
  I think the really late shutdown logs should more liekly end up in some
  EFI var and then flushed out on next boot or so...
 
  Nice plan. How would be able to trust that data tho'. Would it have to
  be signed in some way? Or could it be marked somehow as unreliable data?
  I'm not sure it really *matters* that much from a trust perspective as
  it's use would likely be 99% debugging, but all the same it would be
  nice if it were trustable.
 
  Trust?  I mean, if you managed to upload data into EFI vars you are so
  privileged you can fuck with us anyway, so not sure what you mean
 
  Well I was originally thinking about other OS's etc. and knowing that
  logs came from the right install, but then posed the question in a more
  generic sense, in part due to the cryptographic guarantees given by FSS.
  I just figured this was an interesting way in which someone could inject
  false data at a point where you have zero way to know what went on
  between the last shutdown and the current boot.
 
  If is to be inherently trusted based on machine id then fine - just
  seems odd to put all the effort into FSS and then blindly inject data
  (possibly even core dumps which will be analysed later) and not mark it
  as potentially untrustworthy in some way.
 
  FSS doesn't protect against fake data, it only allows you to detect when
  data has been removed. So if I break into a machine with f-s-sealed logs,
  I am still able to log anything I want, but the messages about my break-in
  will be there, unless I remove some messages, in which case it will be 
  visible
  that there are no messages since some point. The same guarantee holds for
  messages from pstore: you need root rights to write there. Even if there's
  a second OS on the machine, if you have root right in that *other* OS, you
  can write whatever you want to the logs in *this* OS, either through pstore
  or directly by mounting /var. So pstore doesn't really change anything here.
 
 Hmm, yeah, I guess the point about writing invalid new data is probably
 moot - as you say any $OTHEROS could do the same - assuming of course
 the disk is not encrypted...
 
 There would be some theoretical risk of a machine, with pstore and
 encrypted disks where some attacker who has limited physical access
 could plant a pstore bomb and then waits for the user to boot and
 enter their encryption keys at which point the fake data is logged.
 But I'm sure there are many more interesting things the attacker could
 do if they were to have even limited physical access, so my argument is
 almost certainly invalid in practically all circumstances :)
 
 That said, if it's possible to somehow do the FSS of the pstore data and
 verify it before incorporating it on the next boot, it seems like that
 would be the most sensible approach by design (theoretically, in
 principle etc. etc.) Practically useful... probably not much :)
I think we need a new _TRANSPORT=pstore tag.

We currently don't do any verificiation for normal logs either: it is up
to the reader to notice that fields don't match. But it would be nice to
have an external tool like this.

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

Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline

2013-09-13 Thread Lennart Poettering 
On Fri, 13.09.13 11:52, Tom Gundersen (t...@jklm.no) wrote:

 
 On Thu, Sep 12, 2013 at 12:10 PM, Harald Hoyer harald.ho...@gmail.com wrote:
  On 09/11/2013 05:35 PM, Lennart Poettering wrote:
  On Mon, 19.08.13 00:15, Tom Gundersen (t...@jklm.no) wrote:
 
  The main usecase for this is to make it possible to use cryptsetup in
  the initrd without it having to include a host-specific /etc/crypttab.
 
  Hmm, I contrast to Harald I think adding luks.options= would actually be
  OK.
 
  I don't think we really strictly need something here that can cover
  everything. I think it is OK if we have a minimal, easy,
  reduced-functionality way to configure luks disks via the kernel cmdline
  and a full-blown one with /etc/crypttab. It's a bit weird but I think
  not totally incomprehensible to users. Hence adding luks.options= and
  rd.luks.options= sounds like a very simple minimal addition here.
 
  If people really want per-device options, then one day we could on top
  of this just extend the preexisting luks.uuid= syntax to also take a key
  file and an option string via some ; based syntax (i.e. taking up
  Harald's idea, but voerloading it into luks.uuid=).
 
  Or in other words, have this syntax now:
 
 luks.uuid=UUID
 luks.key=KEY
 luks.options=OPTIONS
 
  (and the allow discards thing would be subsumed under luks.options)
 
  And then one day maybe optionally allow this syntax too:
 
 luks.uuid=UUID;KEY;OPTIONS
 
  Does that make sense?
 
  So yeah, Tom, I think you patch looks good and should go in (but please
  update kernel-command-line(7) too), unless Harald violently opposes? ;-)
 
  Lennart
 
 
  I do not violently oppose. Only pointing out, that, if we extend luks, we 
  also
  might want have one option instead to rule them all.
 
 Ok, so I pushed this for now. Let's get back to a fully generic
 version in the future if it turns out we need that...

Please also update kernel-command-line(7) when you add new kernel
command line options!

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] [HEADSUP] What to backport?

2013-09-13 Thread Gabriel de Perthuis 
   -- You need to pull the notes from the git repo using a command like
   the following:
 
   $ git fetch fetch origin refs/notes/*:refs/notes/*
 
   I added an alias to my ~/.gitconfig for this:
 
   [alias]
   pullnotes = fetch origin refs/notes/*:refs/notes/*
 
   That way I can just do:
 
   $ git pullnotes

You can fetch origin notes automatically with this:

git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'

The idea comes from http://git-scm.com/blog/2010/08/25/notes.html



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

Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline

2013-09-13 Thread Tom Gundersen 
On Fri, Sep 13, 2013 at 6:18 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 13.09.13 11:52, Tom Gundersen (t...@jklm.no) wrote:


 On Thu, Sep 12, 2013 at 12:10 PM, Harald Hoyer harald.ho...@gmail.com 
 wrote:
  On 09/11/2013 05:35 PM, Lennart Poettering wrote:
  On Mon, 19.08.13 00:15, Tom Gundersen (t...@jklm.no) wrote:
 
  The main usecase for this is to make it possible to use cryptsetup in
  the initrd without it having to include a host-specific /etc/crypttab.
 
  Hmm, I contrast to Harald I think adding luks.options= would actually be
  OK.
 
  I don't think we really strictly need something here that can cover
  everything. I think it is OK if we have a minimal, easy,
  reduced-functionality way to configure luks disks via the kernel cmdline
  and a full-blown one with /etc/crypttab. It's a bit weird but I think
  not totally incomprehensible to users. Hence adding luks.options= and
  rd.luks.options= sounds like a very simple minimal addition here.
 
  If people really want per-device options, then one day we could on top
  of this just extend the preexisting luks.uuid= syntax to also take a key
  file and an option string via some ; based syntax (i.e. taking up
  Harald's idea, but voerloading it into luks.uuid=).
 
  Or in other words, have this syntax now:
 
 luks.uuid=UUID
 luks.key=KEY
 luks.options=OPTIONS
 
  (and the allow discards thing would be subsumed under luks.options)
 
  And then one day maybe optionally allow this syntax too:
 
 luks.uuid=UUID;KEY;OPTIONS
 
  Does that make sense?
 
  So yeah, Tom, I think you patch looks good and should go in (but please
  update kernel-command-line(7) too), unless Harald violently opposes? ;-)
 
  Lennart
 
 
  I do not violently oppose. Only pointing out, that, if we extend luks, we 
  also
  might want have one option instead to rule them all.

 Ok, so I pushed this for now. Let's get back to a fully generic
 version in the future if it turns out we need that...

 Please also update kernel-command-line(7) when you add new kernel
 command line options!

Sorry about that, forgot to commit the change :-S Pushed it out now.

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