Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
Am 08.07.2014 02:55 schrieb Kay Sievers k...@vrfy.org: Shouldn't we possibly we find a word for environment which explains itself a bit better? Environment we usually call the numerous variables of a process or service. Just TAG maybe? It's unfortunate, but ENVIRONMENT is the most widespread term for this, overloaded as it is. Other ideas: CONFIG_TAG ENVIRONMENT_TAG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] Add ENVIRONMENT to hostnamed
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamed.c | 49
+---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 514554d..b5ed3e9 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -41,6 +41,7 @@ enum {
PROP_PRETTY_HOSTNAME,
PROP_ICON_NAME,
PROP_CHASSIS,
+PROP_ENVIRONMENT,
PROP_KERNEL_NAME,
PROP_KERNEL_RELEASE,
PROP_KERNEL_VERSION,
@@ -100,6 +101,7 @@ static int context_read_data(Context *c) {
PRETTY_HOSTNAME, c-data[PROP_PRETTY_HOSTNAME],
ICON_NAME, c-data[PROP_ICON_NAME],
CHASSIS, c-data[PROP_CHASSIS],
+ ENVIRONMENT, c-data[PROP_ENVIRONMENT],
NULL);
if (r 0 r != -ENOENT)
return r;
@@ -148,6 +150,18 @@ static bool valid_chassis(const char *chassis) {
chassis);
}
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
+
+
Double newline.
static const char* fallback_chassis(void) {
int r;
char *type;
@@ -257,6 +271,7 @@ static char* context_fallback_icon_name(Context *c) {
return strdup(computer);
}
+
static bool hostname_is_useful(const char *hn) {
return !isempty(hn) !is_localhost(hn);
}
@@ -311,7 +326,8 @@ static int context_write_data_machine_info(Context *c) {
static const char * const name[_PROP_MAX] = {
[PROP_PRETTY_HOSTNAME] = PRETTY_HOSTNAME,
[PROP_ICON_NAME] = ICON_NAME,
-[PROP_CHASSIS] = CHASSIS
+[PROP_CHASSIS] = CHASSIS,
+[PROP_ENVIRONMENT] = ENVIRONMENT,
};
_cleanup_strv_free_ char **l = NULL;
@@ -323,7 +339,7 @@ static int context_write_data_machine_info(Context *c) {
if (r 0 r != -ENOENT)
return r;
-for (p = PROP_PRETTY_HOSTNAME; p = PROP_CHASSIS; p++) {
+for (p = PROP_PRETTY_HOSTNAME; p = PROP_ENVIRONMENT; p++) {
char *t, **u;
assert(name[p]);
@@ -401,6 +417,23 @@ static int property_get_chassis(
return sd_bus_message_append(reply, s, name);
}
+static int property_get_environment(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error) {
+
+Context *c = userdata;
+const char *name;
+
+name = c-data[PROP_ENVIRONMENT];
+
+return sd_bus_message_append(reply, s, name);
+}
+
static int method_set_hostname(sd_bus *bus, sd_bus_message *m, void
*userdata, sd_bus_error *error) {
Context *c = userdata;
const char *name;
@@ -554,6 +587,8 @@ static int set_machine_info(Context *c, sd_bus *bus,
sd_bus_message *m, int prop
return sd_bus_error_setf(error,
SD_BUS_ERROR_INVALID_ARGS, Invalid pretty host name '%s', name);
if (prop == PROP_CHASSIS !valid_chassis(name))
return sd_bus_error_setf(error,
SD_BUS_ERROR_INVALID_ARGS, Invalid chassis '%s', name);
+if (prop == PROP_ENVIRONMENT !valid_environment(name))
+return sd_bus_error_setf(error,
SD_BUS_ERROR_INVALID_ARGS, Invalid environment '%s', name);
h = strdup(name);
if (!h)
@@ -571,11 +606,13 @@ static int set_machine_info(Context *c, sd_bus *bus,
sd_bus_message *m, int prop
log_info(Changed %s to '%s',
prop == PROP_PRETTY_HOSTNAME ? pretty host name :
+prop == PROP_ENVIRONMENT ? environment :
prop == PROP_CHASSIS ? chassis : icon name,
strna(c-data[prop]));
sd_bus_emit_properties_changed(bus, /org/freedesktop/hostname1,
org.freedesktop.hostname1,
prop == PROP_PRETTY_HOSTNAME ?
PrettyHostname :
- prop == PROP_CHASSIS ? Chassis :
IconName, NULL);
+ prop == PROP_ENVIRONMENT ?
Environment :
+ prop == PROP_CHASSIS ? Chassis :
IconName , NULL);
return sd_bus_reply_method_return(m, NULL);
}
@@ -592,6 +629,10 @@ static int method_set_chassis(sd_bus *bus,
sd_bus_message *m, void *userdata, sd
return
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
Patches look good. Only found one tiny nit. We should come up with a
better name though, feels wrong that the name is very generic (and
clashes with other uses), whilst the usage is quite specific (limited
to testing, staging, production).
Cheers,
Tom
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
strna(i-icon_name),
- strna(i-chassis));
+ strna(i-chassis),
+ strna(i-environment));
r = sd_id128_get_machine(mid);
if (r = 0)
@@ -157,6 +160,7 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo,
icon_name) },
{ Chassis,s, NULL, offsetof(StatusInfo, chassis)
},
+{ Environment,s, NULL, offsetof(StatusInfo,
environment) },
{ KernelName, s, NULL, offsetof(StatusInfo,
kernel_name) },
{ KernelRelease, s, NULL, offsetof(StatusInfo,
kernel_release) },
{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
@@ -194,6 +198,7 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.environment);
free(info.kernel_name);
free(info.kernel_release);
free(info.os_pretty_name);
@@ -309,6 +314,13 @@ static int set_chassis(sd_bus *bus, char **args,
unsigned n) {
return set_simple_string(bus, SetChassis, args[1]);
}
+static int set_environment(sd_bus *bus, char **args, unsigned n) {
+assert(args);
+assert(n == 2);
+
+return set_simple_string(bus, SetEnvironment, args[1]);
+}
+
static int help(void) {
printf(%s [OPTIONS...] COMMAND ...\n\n
@@ -325,7 +337,8 @@ static int help(void) {
status Show current hostname settings\n
set-hostname NAME Set system hostname\n
set-icon-name NAME Set icon name for host\n
- set-chassis NAME Set chassis type for host\n,
+ set-chassis NAME Set chassis type for host\n
+ set-environment NAME Set environment for host\n,
program_invocation_short_name);
return 0;
@@ -423,6 +436,7 @@ static int hostnamectl_main(sd_bus *bus, int argc, char
*argv[]) {
{ set-hostname, EQUAL, 2, set_hostname },
{ set-icon-name, EQUAL, 2, set_icon_name },
{ set-chassis, EQUAL, 2, set_chassis },
+{ set-environment, EQUAL, 2, set_environment },
};
int left;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading udev error messages regarding virtual interfaces
On Mon, Jul 7, 2014 at 5:21 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, On Mon, Jul 07, 2014 at 03:02:47PM +0200, Tom Gundersen wrote: On Sun, Jul 6, 2014 at 6:43 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, Sorry for a delayed reply. On Thu, Jul 03, 2014 at 01:46:53PM +0200, Lennart Poettering wrote: it would be good to know what the precise error output is you get now with this new change... With systemd-215 udevd still complains (and segfaults) about the virtual interface: -- $ journalctl | grep udevd Jul 06 12:21:05 hermes systemd-udevd[46]: starting version 215 Jul 06 12:21:05 hermes systemd-udevd[226]: starting version 215 Jul 06 12:21:06 hermes systemd-udevd[234]: renamed network interface wlan0 to wlp1s0 Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] terminated by signal 11 (Segmentation fault) Jul 06 12:21:09 hermes kernel: systemd-udevd[233]: segfault at 0 ip 7ff524a0571a sp 7fffc8a69540 error 4 in libc-2.19.so[7ff524907000+1a4000] Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] failed while handling '/devices/virtual/net/veth7DH07K' -- The original problem (with the error message) should be fixed now in git, please let me know if that is not the case. Great, thanks -- I'll test it as soon as I get back to my build machine. This seems to be a different issue though. One that I am not able to reproduce. Could you get the backtrace for this? You mean the segmentation fault? Yeah. This is very irregular (it occurs approx. every 3nd boot), so I'll have to chase it... Maybe the journal caught the coredump? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/08/2014 12:55 AM, Kay Sievers wrote: Shouldn't we possibly we find a word for environment which explains itself a bit better? Environment we usually call the numerous variables of a process or service. I was aware of that but decided to move forward since people should be able to make the distinction vs introduces an new word with added learning curve but yeah sure I will resubmit with atmosphere instead. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd service start/stop conditions
I have the following problem: There are 3 (or more) systemd targets. Each of the three targets starts a number of systemd services. It can be switched back and forth between the systemd targets. As a limitation, it is necessary that the services of a target start only if the services of actual target are already stopped. Because there have resources to be released, such as a serial port. The problem is solved with Unit paramter Conflicts. Starting a target will stop the other. The following systemd units demonstrate the problem. 3 systemd targets, 3 services and a dummy-program mode-1.target [Unit] Description=mode 1 Conflicts=mode-2.target Conflicts=mode-3.target [Install] WantedBy=multi-user.target mode-2.target [Unit] Description=mode 2 Conflicts=mode-1.target Conflicts=mode-3.target After=mode-1.target [Install] WantedBy=multi-user.target mode-3.target [Unit] Description=mode 3 Conflicts=mode-1.target Conflicts=mode-2.target After=mode-1.target After=mode-2.target [Install] WantedBy=multi-user.target unit-a-resource-1.service --- [Unit] Description=Unit A use resource 1 After=mode-1.target Conflicts=mode-2.target Conflicts=mode-3.target [Service] ExecStart=/usr/bin/dummy_unit.sh Unit A use resource 1 TimeoutSec=10 [Install] WantedBy=mode-1.target unit-b-resource-1.service --- [Unit] Description=Unit B use resource 1 After=mode-2.target Conflicts=mode-1.target Conflicts=mode-3.target [Service] ExecStart=/usr/bin/dummy_unit.sh Unit B use resource 1 [Install] WantedBy=mode-2.target unit-c-resource-2.service [Unit] Description=Unit C use resource 2 After=mode-3.target Conflicts=mode-1.target Conflicts=mode-2.target [Service] ExecStart=/usr/bin/dummy_unit.sh Unit C use resource 2 [Install] WantedBy=mode-3.target dummy_unit.sh -- #!/bin/bash running=true trap 'echo got signal TERMinated; running=false' TERM echo $1 # do something while $running do sleep 1 done # simulate longer shutdown sleep 1 sleep 1 sleep 1 sleep 1 sleep 1 echo $1 done # Switch from mode-2.target to mode-1.target systemctl start mode-1.target systemd[1]: Stopping Unit B use resource 1... dummy_unit.sh[3303]: Terminated dummy_unit.sh[3303]: got signal TERMinated dummy_unit.sh[3303]: Terminated systemd[1]: Stopped Unit B use resource 1. dummy_unit.sh[3303]: Unit B use resource 1 done systemd[1]: Stopping mode 2. systemd[1]: Stopped target mode 2. systemd[1]: Starting mode 1. systemd[1]: Reached target mode 1. systemd[1]: Starting Unit A use resource 1... systemd[1]: Started Unit A use resource 1. dummy_unit.sh[3322]: Unit A use resource 1 systemd service service unit-b-resource-1.service is stopped an than service unit-a-resource-1.service starts. This all works only if the line After=mode-1.target exist in mode-2.target and the lines After=mode-1.target After=mode-2.target exists in mode-3.target. === Without these lines, it looks like this: Switch from mode-2.target to mode-1.target systemctl start mode-1.target systemd[1]: Stopping Unit B use resource 1... dummy_unit.sh[1009]: Terminated dummy_unit.sh[1009]: got signal TERMinated systemd[1]: Starting mode 1. systemd[1]: Reached target mode 1. systemd[1]: Starting Unit A use resource 1... dummy_unit.sh[1009]: Terminated systemd[1]: Started Unit A use resource 1. dummy_unit.sh[2873]: Unit A use resource 1 dummy_unit.sh[1009]: Unit B use resource 1 done systemd[1]: Stopped Unit B use resource 1. systemd[1]: Stopping mode 2. systemd[1]: Stopped target mode 2. systemd service unit-a-resource-1.service starts before the other service unit-b-resource-1.service is stopped. Can anyone explain this behavior? (The parameter After= in mode-2.target and mode-3.target but not in mode-1.target) Can someone give a hint or a reference to the appropriate documentation? Or is this all working by change? I use systemd version 211. Is there a better solution? I hope I could describe the problem understandable. Regards, Mario ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] readahead: add option to create pack in directory other than root
From: Alison Chaiken alison_chai...@mentor.com
Add support for creating a readahead pack in a runtime-specified
directory. Users may want the feature if they their rootfs is
read-only at boot or if they maintain more than one pack file. The
new pack-file location is specified by a --pack-location command-line
switch. Default behavior is retained if the switch is absent.
Signed-off-by: Alison Chaiken alison_chai...@mentor.com
---
man/systemd-readahead-replay.service.xml | 10 +-
src/readahead/readahead-collect.c| 16 ++--
src/readahead/readahead-common.h | 1 +
src/readahead/readahead-replay.c | 6 +-
src/readahead/readahead.c| 18 +++---
5 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/man/systemd-readahead-replay.service.xml
b/man/systemd-readahead-replay.service.xml
index 669fe78..a8b9a03 100644
--- a/man/systemd-readahead-replay.service.xml
+++ b/man/systemd-readahead-replay.service.xml
@@ -84,7 +84,7 @@
to end data collection. On this signal, this service
will then sort the collected disk accesses and store
information about them in
-filename/.readahead/filename./para
+filename/.readahead/filename by default./para
paraNormally, both
filenamesystemd-readahead-collect.service/filename
@@ -144,6 +144,14 @@
command./para/listitem
/varlistentry
+varlistentry
+termoption--pack-location=/option/term
+listitemparaDirectory where .readahead
+will be created, different from the root
+whose accesses are the basis of pack
+formation./para/listitem
+/varlistentry
+
xi:include href=standard-options.xml
xpointer=help /
xi:include href=standard-options.xml
xpointer=version /
/variablelist
diff --git a/src/readahead/readahead-collect.c
b/src/readahead/readahead-collect.c
index c1afd0d..f63c078 100644
--- a/src/readahead/readahead-collect.c
+++ b/src/readahead/readahead-collect.c
@@ -253,7 +253,13 @@ static int collect(const char *root) {
assert(root);
-if (asprintf(pack_fn, %s/.readahead, root) 0) {
+if (strlen(arg_pack_loc)) {
+if (asprintf(pack_fn, %s/.readahead, arg_pack_loc) 0) {
+r = log_oom();
+goto finish;
+}
+}
+else if (asprintf(pack_fn, %s/.readahead, root) 0) {
r = log_oom();
goto finish;
}
@@ -507,7 +513,13 @@ done:
on_btrfs = statfs(root, sfs) = 0 F_TYPE_EQUAL(sfs.f_type,
BTRFS_SUPER_MAGIC);
log_debug(On btrfs: %s, yes_no(on_btrfs));
-if (asprintf(pack_fn_new, %s/.readahead.new, root) 0) {
+if (strlen(arg_pack_loc)) {
+if (asprintf(pack_fn_new, %s/.readahead.new, arg_pack_loc)
0) {
+r = log_oom();
+goto finish;
+}
+}
+else if (asprintf(pack_fn_new, %s/.readahead.new, root) 0) {
r = log_oom();
goto finish;
}
diff --git a/src/readahead/readahead-common.h b/src/readahead/readahead-common.h
index b34f3aa..d26ad30 100644
--- a/src/readahead/readahead-common.h
+++ b/src/readahead/readahead-common.h
@@ -34,6 +34,7 @@
extern unsigned arg_files_max;
extern off_t arg_file_size_max;
extern usec_t arg_timeout;
+extern char arg_pack_loc[LINE_MAX];
int file_verify(int fd, const char *fn, off_t file_size_max, struct stat *st);
diff --git a/src/readahead/readahead-replay.c b/src/readahead/readahead-replay.c
index f46dc3b..852747d 100644
--- a/src/readahead/readahead-replay.c
+++ b/src/readahead/readahead-replay.c
@@ -136,7 +136,11 @@ static int replay(const char *root) {
block_bump_request_nr(root);
-if (asprintf(pack_fn, %s/.readahead, root) 0)
+if (strlen(arg_pack_loc)) {
+if (asprintf(pack_fn, %s/.readahead, arg_pack_loc) 0)
+return log_oom();
+}
+else if (asprintf(pack_fn, %s/.readahead, root) 0) {
return log_oom();
pack = fopen(pack_fn, re);
diff --git a/src/readahead/readahead.c b/src/readahead/readahead.c
index 73cf538..3c45982 100644
--- a/src/readahead/readahead.c
+++ b/src/readahead/readahead.c
@@ -35,6 +35,7 @@
unsigned arg_files_max = 16*1024;
off_t arg_file_size_max = READAHEAD_FILE_SIZE_MAX;
usec_t arg_timeout = 2*USEC_PER_MINUTE;
+char arg_pack_loc[LINE_MAX];
static int help(void) {
@@ -44,14 +45,16 @@ static int help(void) {
--version Show package
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
Am 08.07.2014 12:22, schrieb Jon Severinsson: Am 06.07.2014 21:47, schrieb Lennart Poettering: BTW, have you checked whether reuseing the XZ context might make the XZ more competitive? On Sun Jul 6 15:01:11 PDT 2014 Reindl Harald wrote: please try a simple test compress 50 MB with XZ and GZ, LZO, LZ4 or BZIP2 - XZ is *magnitudes* slower in any case Actually it is not, or rather, it is only that if you want it to be that. I did a quick comparison using the systemd 214 tar (30 MiB): xz -0 was 28% slower than lz4c -hc, but the result was 19% smaller. xz -0 was even 44% faster than gzip -9, and the result was still 5% smaller. XZ is the wrong compression for anything where user feedback in time matters No, xz -6 is the wrong compression *setting* for that use-case, but at a lower setting xz is quite suitable even for that. even with no care about memory usage which also is part of the game finally xz -0 needs about 3 MiB for compression, hardly a prohibitive requirement you simply missed the benchmarks see topic compress: add benchmark-style test yesterday With 0: XZ: compressed decompressed 2535300963 bytes in 33.01s (73.25MiB/s), ... LZ4: compressed decompressed 2535303543 bytes in 1.31s (1838.75MiB/s), .. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, Jul 8, 2014 at 9:31 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/08/2014 12:55 AM, Kay Sievers wrote: Shouldn't we possibly we find a word for environment which explains itself a bit better? Environment we usually call the numerous variables of a process or service. I was aware of that but decided to move forward since people should be able to make the distinction vs introduces an new word with added learning curve but yeah sure I will resubmit with atmosphere instead. How about MachineRole? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
2014-07-08 12:22 GMT+02:00 Jon Severinsson j...@severinsson.net: Am 06.07.2014 21:47, schrieb Lennart Poettering: BTW, have you checked whether reuseing the XZ context might make the XZ more competitive? On Sun Jul 6 15:01:11 PDT 2014 Reindl Harald wrote: please try a simple test compress 50 MB with XZ and GZ, LZO, LZ4 or BZIP2 - XZ is *magnitudes* slower in any case Actually it is not, or rather, it is only that if you want it to be that. I did a quick comparison using the systemd 214 tar (30 MiB): xz -0 was 28% slower than lz4c -hc, but the result was 19% smaller. xz -0 was even 44% faster than gzip -9, and the result was still 5% smaller. XZ is the wrong compression for anything where user feedback in time matters No, xz -6 is the wrong compression *setting* for that use-case, but at a lower setting xz is quite suitable even for that. even with no care about memory usage which also is part of the game finally xz -0 needs about 3 MiB for compression, hardly a prohibitive requirement. For comparison, this is what I get when running it on my laptop for 210 (a tarball which I had lieing around): xz == $ time xz -6 systemd_210.orig.tar real 0m9.573s user 0m9.520s sys 0m0.044s $ du -hs systemd_210.orig.tar.xz 2,6M systemd_210.orig.tar.xz $ time xz -0 systemd_210.orig.tar real 0m0.951s user 0m0.948s sys 0m0.004s $ du -hs systemd_210.orig.tar.xz 3,8M systemd_210.orig.tar.xz gzip === $ time gzip systemd_210.orig.tar real 0m0.590s user 0m0.580s sys 0m0.012s $ du -hs systemd_210.orig.tar.gz 4,1M systemd_210.orig.tar.gz lz4 == $ time lz4 systemd_210.orig.tar Compressed filename will be : systemd_210.orig.tar.lz4 Compressed 28917760 bytes into 6667707 bytes == 23.06% real 0m0.097s user 0m0.080s sys 0m0.012s $ du -hs systemd_210.orig.tar.lz4 6,4M systemd_210.orig.tar.lz4 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, 08.07.14 02:55, Kay Sievers (k...@vrfy.org) wrote:
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
Shouldn't we possibly we find a word for environment which explains
itself a bit better? Environment we usually call the numerous
variables of a process or service.
Yeah, I don't really like environment as name for this either. This is
already used quite commonly in the environment variable sense, we
shouldn't redefine this in this comment.
I'd go for something generic like description or comment or so. Or
maybe purpose. I think simply description appears to be the best
option for me.
BTW, something I also wanted to see for a long time, was a location
field, that can be freely configured by the admin, but is initially
filled in from geoip or so. In many setups it's quite relevant to know
where a server is located. Depending on the usecase ot could be as
generic as Berlin, Germany or maybe as specific as 3rd shelf, left
cabinet or so, whatever people need. (Of course, on laptops it makes
little sense...)
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
2014-07-08 13:40 GMT+02:00 Lennart Poettering lenn...@poettering.net: I'd go for something generic like description or comment or so. Or maybe purpose. I think simply description appears to be the best option for me. BTW, something I also wanted to see for a long time, was a location field, that can be freely configured by the admin, but is initially filled in from geoip or so. In many setups it's quite relevant to know where a server is located. Depending on the usecase ot could be as generic as Berlin, Germany or maybe as specific as 3rd shelf, left cabinet or so, whatever people need. (Of course, on laptops it makes little sense...) This information looks like local state, i.e. can't be part of /usr/lib/os-release. So, will this create a copy of /usr/lib/os-release at /etc/os-release if this additional information is added? If so, what happens if the os itself is upgraded and /usr/lib/os-release get's an update? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, Jul 8, 2014 at 1:47 PM, Michael Biebl mbi...@gmail.com wrote: 2014-07-08 13:40 GMT+02:00 Lennart Poettering lenn...@poettering.net: I'd go for something generic like description or comment or so. Or maybe purpose. I think simply description appears to be the best option for me. BTW, something I also wanted to see for a long time, was a location field, that can be freely configured by the admin, but is initially filled in from geoip or so. In many setups it's quite relevant to know where a server is located. Depending on the usecase ot could be as generic as Berlin, Germany or maybe as specific as 3rd shelf, left cabinet or so, whatever people need. (Of course, on laptops it makes little sense...) This information looks like local state, i.e. can't be part of /usr/lib/os-release. machine-info So, will this create a copy of /usr/lib/os-release at /etc/os-release if this additional information is added? If so, what happens if the os itself is upgraded and /usr/lib/os-release get's an update? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
On Tue, 23.07.13 08:05, Steffen Sledz (sl...@dresearch-fe.de) wrote: We like to implement the following behaviour using systemd. We have some exclusive so called operating modes. Each modes has a few associated services which should run in this mode. Yeah, this should work. You should be able to define target units and then use isolate to switch between them. Or you define the targets and add Conflicts= to all the other units you want to kick out, which allows you to use start on the target, instead of isolate. Our idea is to define some conflicting targets representing the operation modes. But we found no way to guarantee that *all* services of the formerly active operation mode (except the ones which should run in the new mode too) are *completely terminated* before the services of the new mode *begin to start*. This is not available as global switch. You'd have to order the units individually against each other, with After= or Before=. Note that After= and Before= would actually have the *same* effect here, as the general rule how they are executed is like this: With two units, A and B where B has After=A set: 1) If the two units are started up, then B is started after A. 2) If the two units are shut down, then A is stopped after B. (The rule is: the shutdown order is the inverse of the startup order). 3) If A is stopped, and B is started, then A is stopped first, and then B is started. 4) If B is stopped, and A is started, then A is also stopped first, and then B is started. (The rule is: when two units are ordered against each other, and one is started the other stopped, then the stop is *always* executed before the start, regardless in which way they are ordered). But yeah, I can see that you are look for a simple global option here, but this doesn't exist, and I am not sure how we could implement that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, 08.07.14 13:47, Michael Biebl (mbi...@gmail.com) wrote: 2014-07-08 13:40 GMT+02:00 Lennart Poettering lenn...@poettering.net: I'd go for something generic like description or comment or so. Or maybe purpose. I think simply description appears to be the best option for me. BTW, something I also wanted to see for a long time, was a location field, that can be freely configured by the admin, but is initially filled in from geoip or so. In many setups it's quite relevant to know where a server is located. Depending on the usecase ot could be as generic as Berlin, Germany or maybe as specific as 3rd shelf, left cabinet or so, whatever people need. (Of course, on laptops it makes little sense...) This information looks like local state, i.e. can't be part of /usr/lib/os-release. Oh, yeah, both Description= and Location= should be saved in /etc/machine-info, not /usr/lib/os-release. See machine-info(5). 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 service start/stop conditions
On Tue, 08.07.14 13:00, Mario Schuknecht (mario.schukne...@dresearch-fe.de) wrote: I have the following problem: There are 3 (or more) systemd targets. Each of the three targets starts a number of systemd services. It can be switched back and forth between the systemd targets. As a limitation, it is necessary that the services of a target start only if the services of actual target are already stopped. Because there have resources to be released, such as a serial port. The problem is solved with Unit paramter Conflicts. Starting a target will stop the other. I figure your colleague already asked the same question. But long story short: you cannot solve this purely by ordereing only the targets. You need Conflicts= and After= (or Before=) between the actual service units that shall be exclusive to each other. More specifically, if you have two units accessing the same serial port, then they should have Conflicts= as well as After= (or Before=). Also see other mail for the more theoretic background of this. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/08/2014 11:28 AM, Peter Sztanojev wrote: On Tue, Jul 8, 2014 at 9:31 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/08/2014 12:55 AM, Kay Sievers wrote: Shouldn't we possibly we find a word for environment which explains itself a bit better? Environment we usually call the numerous variables of a process or service. I was aware of that but decided to move forward since people should be able to make the distinction vs introduces an new word with added learning curve but yeah sure I will resubmit with atmosphere instead. How about MachineRole? Machine role is different and define the purpose of the machine not the 3 tier environment it resides in. It was on my todo list to look at. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
2014-07-08 13:49 GMT+02:00 Kay Sievers k...@vrfy.org: This information looks like local state, i.e. can't be part of /usr/lib/os-release. machine-info Ah, k. Sorry for the noise. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
On 08.07.2014 13:53, Lennart Poettering wrote: On Tue, 23.07.13 08:05, Steffen Sledz (sl...@dresearch-fe.de) wrote: ... But we found no way to guarantee that *all* services of the formerly active operation mode (except the ones which should run in the new mode too) are *completely terminated* before the services of the new mode *begin to start*. This is not available as global switch. You'd have to order the units individually against each other, with After= or Before=. Note that After= and Before= would actually have the *same* effect here, as the general rule how they are executed is like this: With two units, A and B where B has After=A set: 1) If the two units are started up, then B is started after A. 2) If the two units are shut down, then A is stopped after B. (The rule is: the shutdown order is the inverse of the startup order). 3) If A is stopped, and B is started, then A is stopped first, and then B is started. 4) If B is stopped, and A is started, then A is also stopped first, and then B is started. (The rule is: when two units are ordered against each other, and one is started the other stopped, then the stop is *always* executed before the start, regardless in which way they are ordered). But yeah, I can see that you are look for a simple global option here, but this doesn't exist, and I am not sure how we could implement that. Thanx for this clarification. There is one more open question. We did not found a *clear* definition (e.g. a state diagram) of all the states a unit can have. e.g. What is the criteria for a service to change from *activating* to *active/started*? Regards, Steffen PS: Sorry for the overlapping request with my colleague. -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: add option to create pack in directory other than root
On Tue, 08.07.14 13:05, alison_chai...@mentor.com (alison_chai...@mentor.com) wrote: From: Alison Chaiken alison_chai...@mentor.com Add support for creating a readahead pack in a runtime-specified directory. Users may want the feature if they their rootfs is read-only at boot or if they maintain more than one pack file. The new pack-file location is specified by a --pack-location command-line switch. Default behavior is retained if the switch is absent. Hmm, how could this work? I mean, if that writable dir is writable, it probably means that it is not on the same disk as the root dir. But that also means that it is mounted later, which means readahead-replay couldn't access it, since readahead-reply runs as one of the first things at all? I am actually all for moving the file, though. But can't we find a more automatic solution for this, that doesn't require manual configuration. Maybe a scheme like this could work: a) readahead-reply would look for both /.readahead and /var/lib/systemd/readahead. If both files exist, it picks the newer one, if only one exists it picks that one. b) readahead-collect would check if /var/lib/systemd is on the same mount point as /. If so, it would store the file in /var/lib/systemd/readahead. Otherwise it would store the file in /.readahead, as before. This would move the file for most folks, while still allowing a split off /var -- but I figure this wouldn't solve your specific problem? 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] systemctl escaping of unit names
On Tue, 08.07.14 00:22, Michael Biebl (mbi...@gmail.com) wrote: 2014-07-07 23:50 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-07-07 22:54 GMT+02:00 Lennart Poettering lenn...@poettering.net: I have now committed your original patch and beefed it up considerably. Added Zbigniew's --template= switch, and a couple of other things. Also added docs, with a few examples. http://www.freedesktop.org/software/systemd/man/systemd-escape.html Very nice, thanks a lot! Would you object moving that helper to rootbindir so it can be used from within udev rules without having to worry if /usr is a separate partition. Not thrilled about moving more stuff to the root dir, but well... IIRC you have commit access: fix it! Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
On Tue, 08.07.14 14:11, Steffen Sledz (sl...@dresearch-fe.de) wrote: On 08.07.2014 13:53, Lennart Poettering wrote: On Tue, 23.07.13 08:05, Steffen Sledz (sl...@dresearch-fe.de) wrote: ... But we found no way to guarantee that *all* services of the formerly active operation mode (except the ones which should run in the new mode too) are *completely terminated* before the services of the new mode *begin to start*. This is not available as global switch. You'd have to order the units individually against each other, with After= or Before=. Note that After= and Before= would actually have the *same* effect here, as the general rule how they are executed is like this: With two units, A and B where B has After=A set: 1) If the two units are started up, then B is started after A. 2) If the two units are shut down, then A is stopped after B. (The rule is: the shutdown order is the inverse of the startup order). 3) If A is stopped, and B is started, then A is stopped first, and then B is started. 4) If B is stopped, and A is started, then A is also stopped first, and then B is started. (The rule is: when two units are ordered against each other, and one is started the other stopped, then the stop is *always* executed before the start, regardless in which way they are ordered). But yeah, I can see that you are look for a simple global option here, but this doesn't exist, and I am not sure how we could implement that. Thanx for this clarification. There is one more open question. We did not found a *clear* definition (e.g. a state diagram) of all the states a unit can have. Yeah, I tried to avoid documenting this in too much detail, since we wanted to have the freedom to still alter the state machine if we need to. e.g. What is the criteria for a service to change from *activating* to *active/started*? That depends on the service Type= you have chosen, and whether you have ExecStartPre= and/or ExecStartPost= commands for your service. Active is entered basically after everything needed to start up a service is executed plus the service has reported back that it is up. Everything needed means ExecStartPre= and ExecStartPost= having been executed. And the reporting back refers to the notification logic you chose with Type=. See systemd.service(5) for more information about that. Hope that makes some sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/08/2014 11:40 AM, Lennart Poettering wrote:
On Tue, 08.07.14 02:55, Kay Sievers (k...@vrfy.org) wrote:
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
Shouldn't we possibly we find a word for environment which explains
itself a bit better? Environment we usually call the numerous
variables of a process or service.
Yeah, I don't really like environment as name for this either. This is
already used quite commonly in the environment variable sense, we
shouldn't redefine this in this comment.
I hardly call this redefinition but OK
I'd go for something generic like description or comment or so. Or
maybe purpose. I think simply description appears to be the best
option for me.
This is very specific to deployment environment and to solve a very
specific long standing problem ( describe the operating environment ) so
the options can only be development,staging,production or if people see
the need to extend it further, it could include as well integration and
testing so an description ( which is even more generic than
environment) is a no go.
I think personally that atmosphere is the best synonym for
environment and should be used here since people are insisting using
something else then environment and are under the assumption that
administrators, developers and end users in in general will be confused
by this .
In the long run I think we should be working on an machine information
specificationand amongst other thing redefine Computer Chassis as
System Enclosure or even just drop it altogethersince it's usefulness
is limited to application which might behave differently based on the
System Enclosure type it's running on
For example M$ has 24 definition for chassis [1] while we have 5 (
vm,container,desktop,laptop,handset,server ) which we arguably could
simply reduce to 3 vm,container,hardware provided information ( limited
to the 29 bios standard only [2] ).
Anyway as I said in the long run I think we should be working on an
machine information specification
1. http://technet.microsoft.com/en-us/library/ee156537.aspx
2.
http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] coredump: display libdw fail string on stack trace fail
- systemd[1]: hello.service: main process exited, code= \
dumped, status=3/QUIT
- systemd-coredump[2541]: Failed to generate stack trac \
e: Unwinding not supported for this architecture
- systemd-coredump[2541]: Process 1024 (hello) of user \
154 dumped core.
---
src/journal/coredump.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index 59c6d4b..061e1dd 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -692,6 +692,8 @@ int main(int argc, char* argv[]) {
r = coredump_make_stack_trace(coredump_fd, exe, stacktrace);
if (r = 0)
core_message = strjoin(MESSAGE=Process ,
info[INFO_PID], (, comm, ) of user , info[INFO_UID], dumped core.\n\n,
stacktrace, NULL);
+else if (r == -EINVAL)
+log_warning(Failed to generate stack trace: %s,
dwfl_errmsg(dwfl_errno()));
else
log_warning(Failed to generate stack trace: %s,
strerror(-r));
}
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: add option to create pack in directory other than root
Commit message: Add support for creating a readahead pack in a runtime-specified directory. Users may want the feature if they their rootfs is read-only at boot or if they maintain more than one pack file. The new pack-file location is specified by a --pack-location command-line switch. Default behavior is retained if the switch is absent. Lennart asks: Hmm, how could this work? I mean, if that writable dir is writable, it probably means that it is not on the same disk as the root dir. But that also means that it is mounted later, which means readahead-replay couldn't access it, since readahead-reply runs as one of the first things at all? Some systems have multiple non-volatile storage devices. If the rootfs is read-only, another non-volatile filesystem (or even a VFS) can receive the pack.After boot, the pack can be moved over to the rootfs when it is remounted read-write. It's true that creating the pack outside the rootfs will delay the start of collection, but if several large files are read a few seconds into boot, the performance degradation associated with the delay may be minimal. We in fact have this situation and have tested this solution on v205 with success. I am actually all for moving the file, though. But can't we find a more automatic solution for this, that doesn't require manual configuration. Maybe a scheme like this could work: a) readahead-reply would look for both /.readahead and /var/lib/systemd/readahead. If both files exist, it picks the newer one, if only one exists it picks that one. b) readahead-collect would check if /var/lib/systemd is on the same mount point as /. If so, it would store the file in /var/lib/systemd/readahead. Otherwise it would store the file in /.readahead, as before. This would move the file for most folks, while still allowing a split off /var -- but I figure this wouldn't solve your specific problem? In our case, /var/lib/ is part of / partition that is unwritable, but /var/opt is not. How about a tristate option, where we implement the solution you suggest above, but also allow runtime specification to override the other two choices? -- Alison ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
On Thu, Jul 3, 2014 at 10:59 PM, Lennart Poettering lenn...@poettering.net wrote: Heya! A lot of work to make factory reset, stateless systems and disconnected updates working. A lot of networkd love (dhcp4 server!) and coredumpctl is now finally really really useful. http://www.freedesktop.org/software/systemd/systemd-215.tar.xz Enjoy! CHANGES WITH 215: * A new tool systemd-sysusers has been added. This tool creates system users and groups in /etc/passwd and /etc/group, based on static declarative system user/group definitions in /usr/lib/sysusers.d/. This is useful to enable factory resets and volatile systems that boot up with an empty /etc directory, and thus need system users and groups created during early boot. systemd now also ships with two default sysusers.d/ files for the most basic users and groups systemd and the core operating system require. * A new tmpfiles snippet has been added that rebuilds the essential files in /etc on boot, should they be missing. * A directive for ensuring automatic clean-up of /var/cache/man/ has been removed from the default configuration. This line should now be shipped by the man implementation. The necessary change has been made to the man-db implementation. Note that you need to update your man implementation to one that ships this line, otherwise no automatic clean-up of /var/cache/man will take place. * A new condition ConditionNeedsUpdate= has been added that may conditionalize services to only run when /etc or /var are older than the vendor operating system resources in /usr. This is useful for reconstructing or updating /etc after an offline update of /usr or a factory reset, on the next reboot. Services that want to run once after such an update or reset should use this condition and order themselves before the new systemd-update-done.service, which will mark the two directories as fully updated. A number of service files have been added making use of this, to rebuild the udev hardware database, the journald message catalog and dynamic loader cache (ldconfig). The systemd-sysusers tool described above also makes use of this now. With this in place it is now possible to start up a minimal operating system with /etc empty cleanly. For more information on the concepts involved see this recent blog story: http://0pointer.de/blog/projects/stateless.html * A new system group input has been introduced, and all input device nodes get this group assigned. This is useful for system-level software to get access to input devices. It complements what is already done for audio and video. * systemd-networkd learnt minimal DHCPv4 server support in addition to the existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6 Router Solicitation client support. The DHCPv4 client gained support for static routes passed in from the server. Note that the [DHCPv4] section known in older systemd-networkd versions has been renamed to [DHCP] and is now also used by the DHCPv6 client. Existing .network files using settings of this section should be updated, though compatibility is maintained. Optionally, the client hostname may now be sent to the DHCP server. * networkd gained support for vxlan virtual networks as well as tun/tap and dummy devices. * networkd gained support for automatic allocation of address ranges for interfaces from a system-wide pool of addresses. This is useful for dynamically managing a large number of interfaces with a single network configuration file. In particular this is useful to easily assign appropriate IP addresses to the veth links of a large number of nspawn instances. * RPM macros for processing sysusers, sysctl and binfmt drop-in snippets at package installation time have been added. * The /etc/os-release file should now be placed in /usr/lib/os-release. The old location is automatically created as symlink. /usr/lib is the more appropriate location of this file, since it shall actually describe the vendor operating system shipped in /usr, and not the configuration stored in /etc. * .mount units gained a new boolean SloppyOptions= setting that maps to mount(8)'s -s option which enables permissive parsing of unknown mount options. * tmpfiles learnt a new L+
Re: [systemd-devel] [ANNOUNCE] systemd 215
2014-07-08 16:41 GMT+02:00 Umut Tezduyar Lindskog u...@tezduyar.com: Are there any thoughts about natively sending coredumps over network? I guess it is possible now by mounting /var/lib/systemd/coredump to a network drive but dumps occuring before network is up need to be transferred too. How would you transfer the coredumps if network is not up? And if the network is up, you might just mount a network share. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] units: make ExecStopPost action part of ExecStart
Currently after exiting rescue shell we isolate default target. User might want to isolate to some other target than default one. However issuing systemctl isolate command to desired target would bring system to default target as a consequence of running ExecStopPost action. Having common ancestor for rescue shell and possible followup systemctl default command should fix this. If user exits rescue shell we will proceed with isolating default target, otherwise, on manual isolate, parent shell process is terminated and we don't isolate default target, but target chosen by user. Suggested-by: Michal Schmidt mschm...@redhat.com --- units/emergency.service.in | 3 +-- units/rescue.service.m4.in | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/units/emergency.service.in b/units/emergency.service.in index 94c090f..91fc1bb 100644 --- a/units/emergency.service.in +++ b/units/emergency.service.in @@ -17,8 +17,7 @@ Environment=HOME=/root WorkingDirectory=/root ExecStartPre=-/bin/plymouth quit ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, type journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, systemctl default to try again\\nto boot into default mode.' -ExecStart=-/sbin/sulogin -ExecStopPost=@SYSTEMCTL@ --fail --no-block default +ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default Type=idle StandardInput=tty-force StandardOutput=inherit diff --git a/units/rescue.service.m4.in b/units/rescue.service.m4.in index 552ef89..ef54369 100644 --- a/units/rescue.service.m4.in +++ b/units/rescue.service.m4.in @@ -18,8 +18,7 @@ Environment=HOME=/root WorkingDirectory=/root ExecStartPre=-/bin/plymouth quit ExecStartPre=-/bin/echo -e 'Welcome to rescue mode! Type systemctl default or ^D to enter default mode.\\nType journalctl -xb to view system logs. Type systemctl reboot to reboot.' -ExecStart=-/sbin/sulogin -ExecStopPost=-@SYSTEMCTL@ --fail --no-block default +ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default Type=idle StandardInput=tty-force StandardOutput=inherit -- 2.0.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
В Tue, 08 Jul 2014 14:37:19 +0200 Steffen Sledz sl...@dresearch-fe.de пишет: On 08.07.2014 14:22, Lennart Poettering wrote: On Tue, 08.07.14 14:11, Steffen Sledz (sl...@dresearch-fe.de) wrote: There is one more open question. We did not found a *clear* definition (e.g. a state diagram) of all the states a unit can have. Yeah, I tried to avoid documenting this in too much detail, since we wanted to have the freedom to still alter the state machine if we need to. e.g. What is the criteria for a service to change from *activating* to *active/started*? That depends on the service Type= you have chosen, and whether you have ExecStartPre= and/or ExecStartPost= commands for your service. Active is entered basically after everything needed to start up a service is executed plus the service has reported back that it is up. Everything needed means ExecStartPre= and ExecStartPost= having been executed. And the reporting back refers to the notification logic you chose with Type=. See systemd.service(5) for more information about that. Hope that makes some sense? Also this manpage is not fully clear. E.g. if we have to *simple* services A and B with an After= between them. What is the criteria that A changes from *activating* to *active* and B can start? If there are ExecStartPost - once they finish execution. If there are not - once program from ExecStart is launched (actually, once it is forked - I do not see how systemd can wait until it is actually execed). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
В Tue, 8 Jul 2014 14:22:01 +0200 Lennart Poettering lenn...@poettering.net пишет: There is one more open question. We did not found a *clear* definition (e.g. a state diagram) of all the states a unit can have. Yeah, I tried to avoid documenting this in too much detail, since we wanted to have the freedom to still alter the state machine if we need to. But it is better to change documentation then than not having any documentation at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Improve xz compression performance.
The new lzma2 compression options at the top of compress_blob_xz are
equivalent to using preset 0, exept for using a 1 MiB dictionary
(the same as preset 1). This makes the memory usage at most 7.5 MiB
in the compressor, and 1 MiB in the decompressor, instead of the
previous 92 MiB in the compressor and 8 MiB in the decompressor.
According to test-compress-benchmark this commit makes XZ compression
20 times faster, with no increase in compressed data size.
Using more realistic test data (an ELF binary rather than repeating
ASCII letters 'a' through 'z' in order) it only provides a factor 10
speedup, and at a cost if a 10% increase in compressed data size.
But that is still a worthwhile trade-off.
According to test-compress-benchmark XZ compression is still 25 times
slower than LZ4, but the compressed data is one eighth the size.
Using more realistic test data XZ compression is only 18 times slower
than LZ4, and the compressed data is only one quarter the size.
---
src/journal/compress.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/journal/compress.c b/src/journal/compress.c
index 49d694a..0bc6879 100644
--- a/src/journal/compress.c
+++ b/src/journal/compress.c
@@ -49,6 +49,8 @@ DEFINE_STRING_TABLE_LOOKUP(object_compressed, int);
int compress_blob_xz(const void *src, uint64_t src_size, void *dst, uint64_t
*dst_size) {
#ifdef HAVE_XZ
+const lzma_options_lzma opt = { 1u 20u, NULL, 0, LZMA_LC_DEFAULT,
LZMA_LP_DEFAULT, LZMA_PB_DEFAULT, LZMA_MODE_FAST, 128, LZMA_MF_HC3, 4};
+const lzma_filter filters[2] = { { LZMA_FILTER_LZMA2,
(lzma_options_lzma*) opt }, {LZMA_VLI_UNKNOWN, NULL} };
lzma_ret ret;
size_t out_pos = 0;
@@ -60,8 +62,11 @@ int compress_blob_xz(const void *src, uint64_t src_size,
void *dst, uint64_t *ds
/* Returns 0 if we couldn't compress the data or the
* compressed result is longer than the original */
-ret = lzma_easy_buffer_encode(LZMA_PRESET_DEFAULT, LZMA_CHECK_NONE,
NULL,
- src, src_size, dst, out_pos, src_size -
1);
+if (src_size 80)
+return -ENOBUFS;
+
+ret = lzma_stream_buffer_encode((lzma_filter*) filters,
LZMA_CHECK_NONE, NULL,
+src, src_size, dst, out_pos, src_size
- 1);
if (ret != LZMA_OK)
return -ENOBUFS;
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] accelerometer: Don't wait for new data from the sensor
Instead of waiting for new data from the sensor, which might be
a long time coming, depending on the sensor device, ask the kernel
for the last state for that particular input device.
---
src/udev/accelerometer/accelerometer.c | 33 ++---
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/src/udev/accelerometer/accelerometer.c
b/src/udev/accelerometer/accelerometer.c
index 925d38d..32adf27 100644
--- a/src/udev/accelerometer/accelerometer.c
+++ b/src/udev/accelerometer/accelerometer.c
@@ -180,7 +180,7 @@ get_prev_orientation(struct udev_device *dev)
return string_to_orientation(value);
}
-#define SET_AXIS(axis, code_) if (ev[i].code == code_) { if (got_##axis == 0)
{ axis = ev[i].value; got_##axis = true; } }
+#define READ_AXIS(axis, var) { memzero(abs_info, sizeof(abs_info)); r =
ioctl(fd, EVIOCGABS(axis), abs_info); if (r 0) return; var = abs_info.value;
}
/* accelerometers */
static void test_orientation(struct udev *udev,
@@ -189,10 +189,9 @@ static void test_orientation(struct udev *udev,
{
OrientationUp old, new;
_cleanup_close_ int fd = -1;
-struct input_event ev[64];
-bool got_syn = false;
-bool got_x = false, got_y = false, got_z = false;
+struct input_absinfo abs_info;
int x = 0, y = 0, z = 0;
+int r;
char text[64];
old = get_prev_orientation(dev);
@@ -201,30 +200,10 @@ static void test_orientation(struct udev *udev,
if (fd 0)
return;
-while (1) {
-int i, r;
-
-r = read(fd, ev, sizeof(struct input_event) * 64);
-
-if (r (int) sizeof(struct input_event))
-return;
-
-for (i = 0; i r / (int) sizeof(struct input_event); i++) {
-if (got_syn) {
-if (ev[i].type == EV_ABS) {
-SET_AXIS(x, ABS_X);
-SET_AXIS(y, ABS_Y);
-SET_AXIS(z, ABS_Z);
-}
-}
-if (ev[i].type == EV_SYN ev[i].code == SYN_REPORT)
-got_syn = true;
-if (got_x got_y got_z)
-goto read_dev;
-}
-}
+READ_AXIS(ABS_X, x);
+READ_AXIS(ABS_Y, y);
+READ_AXIS(ABS_Z, z);
-read_dev:
new = orientation_calc(old, x, y, z);
snprintf(text, sizeof(text),
ID_INPUT_ACCELEROMETER_ORIENTATION=%s,
orientation_to_string(new));
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] accelerometer: Don't wait for new data from the sensor
On Tue, Jul 8, 2014 at 6:29 PM, Bastien Nocera had...@hadess.net wrote: Instead of waiting for new data from the sensor, which might be a long time coming, depending on the sensor device, ask the kernel for the last state for that particular input device. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: make ExecStopPost action part of ExecStart
'Twas brillig, and Andrey Borzenkov at 08/07/14 17:18 did gyre and gimble: В Tue, 8 Jul 2014 18:01:12 +0200 Michal Sekletar msekl...@redhat.com пишет: Currently after exiting rescue shell we isolate default target. User might want to isolate to some other target than default one. However issuing systemctl isolate command to desired target would bring system to default target as a consequence of running ExecStopPost action. Having common ancestor for rescue shell and possible followup systemctl default command should fix this. If user exits rescue shell we will proceed with isolating default target, otherwise, on manual isolate, parent shell process is terminated and we don't isolate default target, but target chosen by user. Suggested-by: Michal Schmidt mschm...@redhat.com --- units/emergency.service.in | 3 +-- units/rescue.service.m4.in | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/units/emergency.service.in b/units/emergency.service.in index 94c090f..91fc1bb 100644 --- a/units/emergency.service.in +++ b/units/emergency.service.in @@ -17,8 +17,7 @@ Environment=HOME=/root WorkingDirectory=/root ExecStartPre=-/bin/plymouth quit ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, type journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, systemctl default to try again\\nto boot into default mode.' -ExecStart=-/sbin/sulogin -ExecStopPost=@SYSTEMCTL@ --fail --no-block default +ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default You do not really need /bin/sh here, right? Well according to the description, yes you do need it as you want it to be part of the same ExecStart... two commands in one is not supported natively by ExecStart, so it's wrapped in bash. Not ideal, but such is life. 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] [ANNOUNCE] systemd 215
On Tue, Jul 08, 2014 at 04:41:59PM +0200, Umut Tezduyar Lindskog wrote: * systemd-coredump may now optionally store coredumps directly on disk (in /var/lib/systemd/coredump, possibly compressed), instead of storing them unconditionally in the journal. This mode is the new default. A new configuration file /etc/systemd/coredump.conf has been added to configure this and other parameters of systemd-coredump. Are there any thoughts about natively sending coredumps over network? I guess it is possible now by mounting /var/lib/systemd/coredump to a network drive but dumps occuring before network is up need to be transferred too. Storing the coredumps in the journal and forwarding the logs to a different host, once that's available, might work. If that's too much overhead, than I think the option with mounting /var/lib/systemd/coredump over the network is the only option. Capacity of an embedded product might not be enough to store multiple dumps. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-detect-s390-virt: add virtualization detection on s390x
On Tue, Jul 08, 2014 at 02:53:22PM +0200, Thomas Blume wrote: In other words, PR/SM transforms physical resources into virtual resources so that many logical partitions can share the same physical resources. Still, from the OS point of view, the shared virtual resource is real hardware. So, I need to change the code and set ConditionVirtualization to false if the OS runs directly on PR/SM (e.g. in an LPAR). In this light, should we still use a common s390 _id string or would it make sense to keep the distinction between PR/SM and z/VM? PR/SM is the hypervisor, so it should be detected as *not* virtualized, which mean that it does not get any _id string. For the virtualized systems on top, yes, it'd be nice to be able to distinguish them, iff there are clear and unamigous distinction between virtualization approaches. So detecting one as kvm and the other as z/something things sounds fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
On Tue, 08.07.14 16:41, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: * systemd-coredump may now optionally store coredumps directly on disk (in /var/lib/systemd/coredump, possibly compressed), instead of storing them unconditionally in the journal. This mode is the new default. A new configuration file /etc/systemd/coredump.conf has been added to configure this and other parameters of systemd-coredump. Are there any thoughts about natively sending coredumps over network? I guess it is possible now by mounting /var/lib/systemd/coredump to a network drive but dumps occuring before network is up need to be transferred too. Capacity of an embedded product might not be enough to store multiple dumps. I'd enjoy if we have some component that usees the journal remote stuff to POST all log messages of level LOG_CRIT and above to some server or so, and then coredumps would just be payload for that. This would of course then mean to store the coredumps in the journal itself. Which is not the default anymore. To make this scheme more useful we should probably extend the local logging protocol of the journal to allow sending over compressed blobs which are stored as is in the journal. THis way, it wouldn't be journald that potentially compresses huge blobs, but the coredump hook. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-detect-s390-virt: add virtualization detection on s390x
On Tue, 08.07.14 19:59, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Jul 08, 2014 at 02:53:22PM +0200, Thomas Blume wrote: In other words, PR/SM transforms physical resources into virtual resources so that many logical partitions can share the same physical resources. Still, from the OS point of view, the shared virtual resource is real hardware. So, I need to change the code and set ConditionVirtualization to false if the OS runs directly on PR/SM (e.g. in an LPAR). In this light, should we still use a common s390 _id string or would it make sense to keep the distinction between PR/SM and z/VM? PR/SM is the hypervisor, so it should be detected as *not* virtualized, which mean that it does not get any _id string. For the virtualized systems on top, yes, it'd be nice to be able to distinguish them, iff there are clear and unamigous distinction between virtualization approaches. So detecting one as kvm and the other as z/something things sounds fine. I agree. Except for one thing: I'd prefer if we could keep the identifiers free of special chars. Hence zsomethhing rather than z/something, please... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, Jul 08, 2014 at 01:16:43PM +, Jóhann B. Guðmundsson wrote: This is very specific to deployment environment and to solve a very specific long standing problem ( describe the operating environment ) so the options can only be development,staging,production or if people see the need to extend it further, it could include as well integration and testing so an description ( which is even more generic than environment) is a no go. OK, so what about Deployment= (my 1st choice) or OperatingEnvironment= ? I too think Description and Environment are too generic and clash with other uses. Atmosphere is too artificial. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, 08.07.14 20:36, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Jul 08, 2014 at 01:16:43PM +, Jóhann B. Guðmundsson wrote: This is very specific to deployment environment and to solve a very specific long standing problem ( describe the operating environment ) so the options can only be development,staging,production or if people see the need to extend it further, it could include as well integration and testing so an description ( which is even more generic than environment) is a no go. OK, so what about Deployment= (my 1st choice) or OperatingEnvironment= ? I too think Description and Environment are too generic and clash with other uses. Atmosphere is too artificial. Deployment sounds OK to me. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: add option to create pack in directory other than root
Lennart suggest: I am actually all for moving the file, though. But can't we find a more automatic solution for this, that doesn't require manual configuration. Maybe a scheme like this could work: a) readahead-reply would look for both /.readahead and /var/lib/systemd/readahead. If both files exist, it picks the newer one, if only one exists it picks that one. Upon further consideration, do we want a SUID program that is active at early boot to *automatically* prefer a newer file on a writable partition to an older one on a read-only partition? Another aspect worth further consideration is, what is a graceful fallback strategy if for some reason the pack file gets corrupted? Might it prevent a board with systemd-readahead-replay enabled from coming all the way up? Has anyone ever observed a hang due to a corrupt pack? When a watchdog reboots a hung board, perhaps we want to use a dynamic mechanism to point the pack file to /dev/null if we don't come up far enough to run systemctl disable systemd-readahead-replay? Big props to the developers of systemd-readahead for the fact that such hangs due to corrupt pack files are obviously infrequent even when a developer tries inadvisable experiments with the code. -- Alison ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] arch: add crisv32
]] Lennart Poettering
On Fri, 04.07.14 20:30, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
On 03/07/14 14:27, Lennart Poettering wrote:
BTW, to clarify what this is about I will now rename the tupel macro
from ARCH_TUPLE to LIB_ARCH_TUPLE or so, since this is about locations
for shared libraries, nothing else.
Please consider calling it something with MULTIARCH in if you're using
Debian multiarch tuples, maybe LIB_MULTIARCH or LIB_MULTIARCH_TUPLE -
that's the consistent Debian/Ubuntu naming for these tuples (e.g.
DEB_{HOST,BUILD}_MULTIARCH in dpkg-architecture).
In particular, please avoid calling it multilib, which seems to be
fairly consistently used to refer to the lib/lib64/lib32 style of
naming.
Our understanding so far was more that multilib refers to the scheme
which allows you to run executables of different, but compatible archs
on the same system. In this scheme you would have your each executable
only of one arch around, but you can relatively freely combine
executables of different arches into one operating system. An individual
set of libraries would have to be around for every arch you want to run
executables of.
OTOH multiarch refers to a much more extensive scheme where the same
OS image shall be bootable on different (possibly even incompatible)
arches, which means you not only require the set of libraries for each
arch you want to support but also the executables.
multiarch vs multilib has nothing to do with booting the system. When
we started using the term, we did not want to talk about multilib, since
that was already in use for gcc's -m32 and -m64 support. Its scope has
later expanded, it seems.
Or with other words: on multilib your /usr/bin/ls binary can be i386 or
x86_64 but you have to chose one at a time, and can only installl one at
the same time. On multiarch you could have both binaries around, and
when you boot on an actual 32bit processor you get one, while if you
boot on a 64bit processor you would get the other.
This is an incompatible use of the term multiarch from what it means in
Debian and my master's thesis from 2005 (which the multiarch design in
Debian is largely based on).
Multiarch is a way for binaries for multiple architectures to co-exist
within a single file system hierarchy, principally by avoiding
overlapping paths. There is no requirement for the architectures to be
compatible in any way as long as the kernel is able to run binaries for
the given architectures (so i386/amd64 is fine, but so is amd64/powerpc
through the use of qemu and binfmt-misc or amd64-linux+amd64-win64
through wine).
Zbigniew tracked done the necessary macros to check for to distuingish
the various ARM ABIs. This means things are looking pretty good on this
front. The only problem: systemd is apparently used on more archs that
Debian has been ported to, and given that we kinda hook into Debian here
for norming the tuples, we probably have to make up temporary tuples for
the remaining archs, until Debian picks up those archs too...
dpkg has arch tuples for more architectures than people use Debian on
too, so they'll likely be happy to incorporate the names of whatever
architectures you find.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
]] Lennart Poettering
On Tue, 08.07.14 02:55, Kay Sievers (k...@vrfy.org) wrote:
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
Shouldn't we possibly we find a word for environment which explains
itself a bit better? Environment we usually call the numerous
variables of a process or service.
Yeah, I don't really like environment as name for this either. This is
already used quite commonly in the environment variable sense, we
shouldn't redefine this in this comment.
It's the term which is generally used when talking about, well,
environments, though.
See http://docs.puppetlabs.com/puppet/latest/reference/environments.html
for puppet's use of the term, or
http://docs.opscode.com/essentials_environments.html for Chef's to pick
two popular automation tools.
Make it be «Machine environment», maybe?
I'd go for something generic like description or comment or so. Or
maybe purpose. I think simply description appears to be the best
option for me.
Those are all useful (we have both description and purpose in the Debian
LDAP[1] for instance).
BTW, something I also wanted to see for a long time, was a location
field, that can be freely configured by the admin, but is initially
filled in from geoip or so. In many setups it's quite relevant to know
where a server is located. Depending on the usecase ot could be as
generic as Berlin, Germany or maybe as specific as 3rd shelf, left
cabinet or so, whatever people need. (Of course, on laptops it makes
little sense...)
Lennart
[1] for instance, https://db.debian.org/machines.cgi?host=abel
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/08/2014 07:31 PM, Tollef Fog Heen wrote: ]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) These days people usually use only 3 tier level ( used to be four back in the day ) as in Development and Integration is done the same tier while Staging and Production are separated tiers altogether. We could extend that and include the fourth tier missing tier ( as in Integration ) as optional for those that prefer 4 tier layer over 3 tier but people moved away form that model to the 3 tier one. Development tier Is the working environment for individual developers or small teams. More often than not this work is done in isolation with the rest of the tiers, the developer(s) can try radical changes to the code without adversely affecting the rest of the development team. Integration tier A common environment where all developers commit code changes. This environment combines and validates the work of the entire project team so it can be tested before being promoted to the Staging Environment. More common these days is for Development and Integration to be the same environment as well as run automate tests etc. Staging tier The staging tier is a environment that is as identical to the production environment as possible. The purpose of the Staging environment is to simulate as much of the Production environment as possible for the final test phase ( test using deployment process and test using an real data source, final test of the application itself etc ) as well as more often than not acts as an demonstration/training environment. Production The production tier consist the final products and might include a single machine or or cluster of machines or containers, cloud whatever. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Tue, Jul 08, 2014 at 08:23:15PM +, Jóhann B. Guðmundsson wrote: On 07/08/2014 07:31 PM, Tollef Fog Heen wrote: ]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) These days people usually use only 3 tier level ( used to be four back in the day ) as in Development and Integration is done the same tier while Staging and Production are separated tiers altogether. We could extend that and include the fourth tier missing tier ( as in Integration ) as optional for those that prefer 4 tier layer over 3 tier but people moved away form that model to the 3 tier one. Development tier Integration tier Staging tier Production We also have Disaster Recovery (DR) tier. It's basically copy of production, started when disaster strucks. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
]] Jóhann B. Guðmundsson On 07/08/2014 07:31 PM, Tollef Fog Heen wrote: ]] Tom Gundersen Patches look good. Only found one tiny nit. We should come up with a better name though, feels wrong that the name is very generic (and clashes with other uses), whilst the usage is quite specific (limited to testing, staging, production). Surely at least qa and dev should go onto that list. (You generally want more than one dev environment too, often one or more per developer.) These days people usually use only 3 tier level ( used to be four back in the day ) as in Development and Integration is done the same tier while Staging and Production are separated tiers altogether. We could extend that and include the fourth tier missing tier ( as in Integration ) as optional for those that prefer 4 tier layer over 3 tier but people moved away form that model to the 3 tier one. That's not my experience. Some do what you say, some elide one of them, some do multiple levels of production, some add one or more tiers, in particular when you need to do things like «this test needs to run in this part of production so we can collect data». I don't believe there's a one-size-fits-all here. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On 07/08/2014 08:31 PM, Tomasz Torcz wrote: We also have Disaster Recovery (DR) tier. It's basically copy of production, started when disaster strucks. I dont think we should add Recovery as an layer since it's just a replica of production in one form or another and as an administrator or developer you treat that as an production as well as DR being a layered process of their own. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] A bug in systemctl ( systemd-125)
Hi to all, I thought to inform you that I came across a bug within systemctl. Some options produce no output, although according to manuals and examples it should. Like for example: systemctl -t mount But if I send systemctl's output through pipe, I get output. So: systemctl -t mount | cat actually produces output. Interesting thing is that same example without -t mount filter works, like simple systemctl without arguments. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
Am 08.07.2014 14:14 schrieb Lennart Poettering lenn...@poettering.net: On Tue, 08.07.14 00:22, Michael Biebl (mbi...@gmail.com) wrote: 2014-07-07 23:50 GMT+02:00 Michael Biebl mbi...@gmail.com: 2014-07-07 22:54 GMT+02:00 Lennart Poettering lenn...@poettering.net : I have now committed your original patch and beefed it up considerably. Added Zbigniew's --template= switch, and a couple of other things. Also added docs, with a few examples. http://www.freedesktop.org/software/systemd/man/systemd-escape.html Very nice, thanks a lot! Would you object moving that helper to rootbindir so it can be used from within udev rules without having to worry if /usr is a separate partition. Not thrilled about moving more stuff to the root dir, but well... IIRC you have commit access: fix it! Done. Thanks again! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A bug in systemctl ( systemd-125)
Dne 08. 07. 2014 22:15, piše brane2: Hi to all, I thought to inform you that I came across a bug within systemctl. Some options produce no output, although according to manuals and examples it should. first to cerrect a typo - I meant latest version 215,not 125 as in subject line. Second, when I add --no-pager option, it starts behaving as expected. It seems that only if output is short enough to fit on screen, it gets eaten... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A bug in systemctl ( systemd-125)
Dne 08. 07. 2014 22:34, piše brane2: Dne 08. 07. 2014 22:15, piše brane2: Hi to all, I thought to inform you that I came across a bug within systemctl. Some options produce no output, although according to manuals and examples it should. first to cerrect a typo - I meant latest version 215,not 125 as in subject line. Second, when I add --no-pager option, it starts behaving as expected. It seems that only if output is short enough to fit on screen, it gets eaten... And I've just noted that journalctl behaves similarly. If there is no output, but there should be, trivial piping helps. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl
---
man/hostnamectl.xml| 14 +
man/machine-info.xml | 17 +++-
src/hostname/hostnamectl.c | 20 ---
src/hostname/hostnamed.c | 50 +++---
4 files changed, 94 insertions(+), 7 deletions(-)
diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
index 7729ef6..42d3863 100644
--- a/man/hostnamectl.xml
+++ b/man/hostnamectl.xml
@@ -223,6 +223,20 @@
parameters./para/listitem
/varlistentry
+varlistentry
+termcommandset-deployment
[ENVIRONMENT]/command/term
+
+listitemparaSet the deployment
+environment. Currently, the following
+environments are defined:
+literaldevelopment/literal,
+ literalintegration/literal,
+literalstaging/literal,
+literalproduction/literal,
+/para/listitem
+/varlistentry
+
+
/variablelist
/refsect1
diff --git a/man/machine-info.xml b/man/machine-info.xml
index 7448e68..b380975 100644
--- a/man/machine-info.xml
+++ b/man/machine-info.xml
@@ -156,6 +156,20 @@
available./para/listitem
/varlistentry
+varlistentry
+termvarnameDEPLOYMENT=/varname/term
+
+listitemparaSet the system deployment
+environment. Currently, the following
+environments are defined:
+literaldevelopment/literal,
+ literalintegration/literal,
+literalstaging/literal,
+literalproduction/literal,
+/para/listitem
+/varlistentry
+
+
/variablelist
/refsect1
@@ -165,7 +179,8 @@
programlistingPRETTY_HOSTNAME=Lennart's Tablet
ICON_NAME=computer-tablet
-CHASSIS=tablet/programlisting
+CHASSIS=tablet
+DEPLOYMENT=production/programlisting
/refsect1
refsect1
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..7e6922b 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *deployment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Deployment: %s\n,
strna(i-icon_name),
- strna(i-chassis));
+ strna(i-chassis),
+ strna(i-deployment));
r = sd_id128_get_machine(mid);
if (r = 0)
@@ -157,6 +160,7 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo, icon_name)
},
{ Chassis,s, NULL, offsetof(StatusInfo, chassis) },
+{ Deployment,s, NULL, offsetof(StatusInfo,
deployment) },
{ KernelName, s, NULL, offsetof(StatusInfo,
kernel_name) },
{ KernelRelease, s, NULL, offsetof(StatusInfo,
kernel_release) },
{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
@@ -194,6 +198,7 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.deployment);
free(info.kernel_name);
free(info.kernel_release);
free(info.os_pretty_name);
@@ -309,6 +314,13 @@ static int set_chassis(sd_bus *bus, char **args, unsigned
n) {
return set_simple_string(bus, SetChassis, args[1]);
}
+static int set_deployment(sd_bus *bus, char **args, unsigned n) {
+assert(args);
+assert(n == 2);
+
+return set_simple_string(bus, SetDeployment, args[1]);
+}
+
static int help(void) {
printf(%s [OPTIONS...] COMMAND ...\n\n
@@ -325,7 +337,8 @@ static int help(void) {
status Show current hostname settings\n
set-hostname NAME Set system hostname\n
set-icon-name NAME Set icon name for host\n
- set-chassis NAME Set chassis type for host\n,
+
[systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet. The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]
On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
Can we please *not* attempt to limit or standardize this particular
set of machine roles? As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies. Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.
Debian has a file /etc/debian_chroot, used to describe the nature of a
chroot environment, such as i386 cross for a 32-bit build chroot, or
similar. The default prompt then incorporates that string. This seems
quite similar, and I'd love to see a standardized mechanism for that
kind of string.
Rather than limiting this list to a few specific tokens, could we just
provide a MachineRole or similar, which accepts a short freeform text
string? Then, a staged deployment system could use this for
development/staging/production/validation/replication/blue/whatever,
while another type of system can use its own tokens here.
As general guidance, we could say something like MachineRole should
consist of a space-separated series of printable tokens, such as
'production' or 'staging'.. This also allows MachineRole to contain
something like staging foobranch, for instance, which indicates a
staging server that's part of the experimental parallel foobranch
infrastructure.
This would still allow the role string to serve its primary functions:
querying it to check for particular values used within an organization,
or inserting it into prompts, window titles, and similar.
- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On 07/08/2014 10:45 PM, Josh Triplett wrote:
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet. The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]
On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
Can we please *not* attempt to limit or standardize this particular
set of machine roles? As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies. Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.
Roles != the environment they run in.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: add option to create pack in directory other than root
On Tue, Jul 8, 2014, at 05:12 AM, Lennart Poettering wrote: b) readahead-collect would check if /var/lib/systemd is on the same mount point as /. If so, it would store the file in /var/lib/systemd/readahead. Otherwise it would store the file in /.readahead, as before. If this logic was extended so that systemd also checked whether / was writable, and fell back to writing to /var regardless, it would work for OSTree at least. (/ is immutable on ostree since https://bugzilla.gnome.org/show_bug.cgi?id=728006 ) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Extending machine-info to include machine roles
Now let's start the dialog with machine roles and start by agreeing what roles are From my point of view roles are human representation of the primary duty the machine performs it's not the environment they are run in. ( like development,staging,production ) nor is it the components themselves that full fill the role ( like postgresql would full fill an role of an database server ) For example Monitoring Server Name server Mail server Database server Print server File server Directory Server Application Server Jump Server Terminal Server Remote Access Server Media Server Network Server Proxy server Network Server Web Server CMS Workstation Load Balancer Firewall etc... These are all roles who can exist in different environments like the role of an web server can exist in development, staging and production environments hence the clear distinction thus the clear need for the ability to define both as in... DEPLOYMENT=production ROLE=application server etc. Thoughts comments flames JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A bug in systemctl ( systemd-125)
On Tue, 08.07.14 22:41, brane2 (bran...@s5tehnika.net) wrote: I thought to inform you that I came across a bug within systemctl. Some options produce no output, although according to manuals and examples it should. first to cerrect a typo - I meant latest version 215,not 125 as in subject line. Second, when I add --no-pager option, it starts behaving as expected. It seems that only if output is short enough to fit on screen, it gets eaten... And I've just noted that journalctl behaves similarly. If there is no output, but there should be, trivial piping helps. Which pager do you have installed? less? which version? 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] A bug in systemctl ( systemd-125)
On Tue, 08.07.14 22:15, brane2 (bran...@s5tehnika.net) wrote: Hi to all, I thought to inform you that I came across a bug within systemctl. Some options produce no output, although according to manuals and examples it should. Like for example: systemctl -t mount But if I send systemctl's output through pipe, I get output. So: systemctl -t mount | cat actually produces output. Interesting thing is that same example without -t mount filter works, like simple systemctl without arguments. Most likely your $PAGER is set to something weird? systemd (like git, ...) does autopaging, where it will automatically pass long outputs to less or some other pager. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl
As someone who deploys developer VMs and production ones, this is useful. Will it be possible to make units have ConditionDeployment=? That would allow disabling, say, pushes of log messages to our log aggregation servers from development and testing deployments. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
I don't see much value in choosing a role from a predefined list. Rarely do machines fit into one single, straightforward role. It would be more useful to support machine tags/labels/roles that map to units, especially if that's dynamically configurable using, say, DHCP(v6). Then, something may be WantedBy=nameserver.role. That would support both livestock deployments with a standardized /usr and pet deployments where admins sign on and may enable roles shipped with the distribution. Then again, I don't see how those would be different from shipping more unit.target files and adding some method to dynamically enable them. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Improve xz compression performance.
+1 on anything that makes the journal faster on heavy workloads. It remains a major bottleneck on our systems. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl
On 07/08/2014 11:52 PM, David Timothy Strauss wrote: As someone who deploys developer VMs and production ones, this is useful. Will it be possible to make units have ConditionDeployment=? That would allow disabling, say, pushes of log messages to our log aggregation servers from development and testing deployments. If we can settle on the environment implementation I cannot see why not. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Seeking advice for configuring SystemCallFilter=
Is there a good way to empirically determine the additional calls required for an application, sort of like selinux permissive mode? We're often running user code on our servers, and we'd like to perform analysis and gradually roll out filtering. We'd like to be as non-disruptive as possible. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
On 07/09/2014 12:14 AM, David Timothy Strauss wrote: I don't see much value in choosing a role from a predefined list. Rarely do machines fit into one single, straightforward role. I would disagree here like for one example security wise you want to implement only one primary role per server to prevent roles that require different security levels from co-existing on the same server. (For example the roles of web servers, database servers should be implemented on separate servers.) as well as for other practical deployment practices. It would be more useful to support machine tags/labels/roles that map to units, especially if that's dynamically configurable using, say, DHCP(v6). Then, something may be WantedBy=nameserver.role. That would support both livestock deployments with a standardized /usr and pet deployments where admins sign on and may enable roles shipped with the distribution. I think this would overlap with targets and we really should be very restrict on introducing new type units and basically what I was thinking was the other way around. Then again, I don't see how those would be different from shipping more unit.target files and adding some method to dynamically enable them. The general idea I had in my mind was to define primary role or machinerole then trying to get us to agree on standardize predefined set of roles. If we manage to do that, introduce rolefulfilment= in units which we would define those standardized predefined set of roles as in for httpd.service we might have rolefulfilment=web server, for postgresql, rolefulfilment=database server etc. so you could list/query etc the machine primary role and at the same time list the daemon/service who fulfills that role As well as all the other running service role fulfilment on the host and maybe introduce ConditionRoleFulfilment= or ConditionRole= if valid use cases existed for that etc. That's basically how I pictured the role implementation and from my point of view if we cant standardized on predefined set of roles there is no point in implementing it since we cant properly integrate roles with units JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +, Jóhann B. Guðmundsson wrote:
On 07/08/2014 10:45 PM, Josh Triplett wrote:
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet. The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]
On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
Can we please*not* attempt to limit or standardize this particular
set of machine roles? As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies. Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.
Roles != the environment they run in.
I'm not trying to bikeshed over the naming of the variable itself. I'm
arguing that standardizing this particular bit of metadata won't work
well when so many different deployment strategies exist. Thus, rather
than having a fixed set of keywords, I'd propose simply saying this
contains keywords, and leaving the specific keywords up to the admin.
If you attempt to standardize production/development/staging, you'll
either end up with a model that only works for a small subset of
deployments, or you'll end up adding twelve more keywords, at which
point you might as well have just said use whatever keyword you like.
The 4 tier covers the majority of the models since more or less the
entire internet recommend three tier model including M$ [1]
Anyone wanting to extend that further can do so using the
PRETTY_HOSTNAME=
This patch is very specific to deployment environment and to solve a
very specific long standing problem and to achieve that we need to a
standardize, if we dont we can just as well drop this patch since in the
long run we cannot introduce something like ConditionDeployment= like
David mentioned and it kinda defeat's my purpose working in this in the
firsplace...
1. http://msdn.microsoft.com/en-US/library/cc982570%28v=bts.10%29.aspx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]
On Wed, Jul 09, 2014 at 01:16:04AM +, Jóhann B. Guðmundsson wrote:
On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
On Tue, Jul 08, 2014 at 10:45:11PM +, Jóhann B. Guðmundsson wrote:
On 07/08/2014 10:45 PM, Josh Triplett wrote:
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet. The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]
On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
+static bool valid_environment(const char *environment) {
+
+assert(environment);
+
+return nulstr_contains(
+development\0
+staging\0
+production\0,
+environment);
+}
Can we please*not* attempt to limit or standardize this particular
set of machine roles? As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies. Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.
Roles != the environment they run in.
I'm not trying to bikeshed over the naming of the variable itself. I'm
arguing that standardizing this particular bit of metadata won't work
well when so many different deployment strategies exist. Thus, rather
than having a fixed set of keywords, I'd propose simply saying this
contains keywords, and leaving the specific keywords up to the admin.
If you attempt to standardize production/development/staging, you'll
either end up with a model that only works for a small subset of
deployments, or you'll end up adding twelve more keywords, at which
point you might as well have just said use whatever keyword you like.
The 4 tier covers the majority of the models since more or less the entire
internet recommend three tier model including M$ [1]
Anyone wanting to extend that further can do so using the PRETTY_HOSTNAME=
PRETTY_HOSTNAME does not equate to description, and in any case is
not the same thing as a deployment environment.
This patch is very specific to deployment environment and to solve a very
specific long standing problem and to achieve that we need to a standardize,
if we dont we can just as well drop this patch since in the long run we
cannot introduce something like ConditionDeployment= like David mentioned
and it kinda defeat's my purpose working in this in the firsplace...
Distribution unit files will never use ConditionDeployment; only
admin-created or admin-modified unit files will. Given that, it will
work perfectly without a standardized set of names. Just specify that
DEPLOYMENT contains a keyword *such as* (but not limited to)
production or development, and then state that ConditionDeployment
can specify a keyword. That will work perfectly without limiting the
set of possible keywords.
- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix #ifdef
On Tue, Jul 08, 2014 at 09:22:25AM +0200, Ronny Chevalier wrote: --- Zbigniew seems to have fix the LZ4 decompression, so here is the remaining part of the previous patch src/journal/journal-def.h | 2 +- src/journal/journal-file.c | 2 +- src/journal/test-compress.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Thanks! Both applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Improve xz compression performance.
On Tue, Jul 08, 2014 at 06:29:46PM +0200, Jon Severinsson wrote: The new lzma2 compression options at the top of compress_blob_xz are equivalent to using preset 0, exept for using a 1 MiB dictionary (the same as preset 1). This makes the memory usage at most 7.5 MiB in the compressor, and 1 MiB in the decompressor, instead of the previous 92 MiB in the compressor and 8 MiB in the decompressor. According to test-compress-benchmark this commit makes XZ compression 20 times faster, with no increase in compressed data size. Using more realistic test data (an ELF binary rather than repeating ASCII letters 'a' through 'z' in order) it only provides a factor 10 speedup, and at a cost if a 10% increase in compressed data size. But that is still a worthwhile trade-off. According to test-compress-benchmark XZ compression is still 25 times slower than LZ4, but the compressed data is one eighth the size. Using more realistic test data XZ compression is only 18 times slower than LZ4, and the compressed data is only one quarter the size. Nice improvement. I made some whitespace modifications and added static to the options and pushed it. If you modified test-compress-benchmark to use more realistic data, please send a patch. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
