Re: [systemd-devel] timed events
2012/6/29 Kok, Auke-jan H auke-jan.h@intel.com: On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). cheap trick: make a script and run it from a timer, have the script run `systemctl ...` better trick: fix the daemon to do all of this properly. Hello. The company I work for has a similar need. The director has permitted me to disclose the details in full, in hope that this will permit you to understand the use case better and understand why fix the daemon is not a possible solution in our case. We are not using systemd yet on our servers, but this doesn't make the problem statement invalid. We have several servers hosted at different ISPs, and our own autonomous system. The service is provided to our clients via IPv4 anycast. So, at each of the servers, we run bgpd (from quagga) and announce a route to our own IPv4 block. This means that each client will be routed to the nearest (in the BGP sense) server. It also protects our service against outages that affect the entire ISP, and allows us to perform maintenance and software upgrades safely (i.e. with near zero visible downtime for clients) by stopping bgpd first. The issue is that twice in the company's lifetime there was a payment problem with one of the servers. When this happened, the ISP did not shut down the affected server. Instead, they somehow firewalled the packets destined to it, but the BGP session was left intact. End result: the route is still announced into the global routing table, but doesn't work, and some clients see service interruption. So, as a protection against such mistakes, we need some form of a custom dead man's switch that would stop bgpd if none of the test IPv4 addresses is pingable. Of course, such monitoring need is specific to our use case, and other companies will either not need it at all or write a dead man's switch with a different logic. So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. The run systemctl from timer is close, but not close enough: extra care is needed during maintenance periods to disable the dead man's switch script (so it doesn't restart bgpd contrary to the administrator's decision) and not to forget to reenable it later. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
On Thu, Jun 28, 2012 at 11:01 PM, Alexander E. Patrakov patra...@gmail.com wrote: 2012/6/29 Kok, Auke-jan H auke-jan.h@intel.com: On Fri, Jun 29, 2012 at 12:49 AM, Nathan qwerty@gmail.com wrote: Another issue (though slightly related) is we have an external binary that when run will return 0 or 1 depending if we should run a service is there a way to run this command in the service_name.service and start the service if it returns 0 and stop the service if the script returns 1 (retrying the script every 5 minutes or so). cheap trick: make a script and run it from a timer, have the script run `systemctl ...` better trick: fix the daemon to do all of this properly. Hello. The company I work for has a similar need. The director has permitted me to disclose the details in full, in hope that this will permit you to understand the use case better and understand why fix the daemon is not a possible solution in our case. We are not using systemd yet on our servers, but this doesn't make the problem statement invalid. We have several servers hosted at different ISPs, and our own autonomous system. The service is provided to our clients via IPv4 anycast. So, at each of the servers, we run bgpd (from quagga) and announce a route to our own IPv4 block. This means that each client will be routed to the nearest (in the BGP sense) server. It also protects our service against outages that affect the entire ISP, and allows us to perform maintenance and software upgrades safely (i.e. with near zero visible downtime for clients) by stopping bgpd first. The issue is that twice in the company's lifetime there was a payment problem with one of the servers. When this happened, the ISP did not shut down the affected server. Instead, they somehow firewalled the packets destined to it, but the BGP session was left intact. End result: the route is still announced into the global routing table, but doesn't work, and some clients see service interruption. So, as a protection against such mistakes, we need some form of a custom dead man's switch that would stop bgpd if none of the test IPv4 addresses is pingable. Of course, such monitoring need is specific to our use case, and other companies will either not need it at all or write a dead man's switch with a different logic. So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. The run systemctl from timer is close, but not close enough: extra care is needed during maintenance periods to disable the dead man's switch script (so it doesn't restart bgpd contrary to the administrator's decision) and not to forget to reenable it later. nothing a sticky note on a monitor couldn't fix. A real solution would be to use some sort of heartbeat feature, or just wrap the bgpd in a wrapper program that takes care of starting/stopping it. That allows you to keep the wrapper running from systemd at all times. No timers needed. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hosting a sprint in SF?
On Fri, 29.06.12 00:27, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 06/28/2012 11:06 PM, David Strauss wrote: * Other suggestions? Last time I checked and unless I have missed something since, journal and systemd still lack the ability to be connected and managed remotely so you might want to focus on that. Oh, there is network support built in, but have to set it up. One way for example is to NFS mount /var/log/journal/machine id locally. Then you will have beneat /var/log/journal/ one dir each for each machine on your network and journalctl will automatically interleave them. Yes, we will beef this up sooner or later, but the basics are there. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cryptsetup: add keyfile-offset= support
This is useful if your keyfile is a block device, and you want to
use a specific part of it, such as an area between the MBR and the
first partition.
This feature is documented in the Arch wiki[0], and has been supported
by the Arch initscripts, so would be nice to get this into systemd.
[0]:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition
---
configure.ac| 2 +-
man/crypttab.xml| 13 +
src/cryptsetup/cryptsetup.c | 11 ++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e0a2526..e1876cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -333,7 +333,7 @@ AC_SUBST(AUDIT_LIBS)
have_libcryptsetup=no
AC_ARG_ENABLE(libcryptsetup, AS_HELP_STRING([--disable-libcryptsetup],
[disable libcryptsetup tools]))
if test x$enable_libcryptsetup != xno; then
-PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup ],
+PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup = 1.4.2 ],
[AC_DEFINE(HAVE_LIBCRYPTSETUP, 1, [Define if libcryptsetup is
available]) have_libcryptsetup=yes], have_libcryptsetup=no)
if test x$have_libcryptsetup = xno -a x$enable_libcryptsetup =
xyes; then
AC_MSG_ERROR([*** libcryptsetup support requested but
libraries not found])
diff --git a/man/crypttab.xml b/man/crypttab.xml
index f3bde71..e54f78c 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -131,6 +131,19 @@
varlistentry
+termvarnamekeyfile-offset=/varname/term
+
+ listitemparaSpecifies the number
+of bytes to skip at the start of
+the keyfile; see
+
citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
+for possible values and the default
+value of this
+option. /para/listitem
+/varlistentry
+
+
+varlistentry
termvarnamehash=/varname/term
listitemparaSpecifies the hash to
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index b26fcca..f570724 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -37,6 +37,7 @@
static const char *opt_type = NULL; /* LUKS1 or PLAIN */
static char *opt_cipher = NULL;
static unsigned opt_key_size = 0;
+static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
static unsigned opt_tries = 0;
static bool opt_readonly = false;
@@ -79,6 +80,13 @@ static int parse_one_option(const char *option) {
return 0;
}
+} else if (startswith(option, keyfile-offset=)) {
+
+if (safe_atou(option+15, opt_keyfile_offset) 0) {
+log_error(keyfile-offset= parse failure, ignoring.);
+return 0;
+}
+
} else if (startswith(option, hash=)) {
char *t;
@@ -462,7 +470,8 @@ int main(int argc, char *argv[]) {
argv[3]);
if (key_file)
-k = crypt_activate_by_keyfile(cd, argv[2],
CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
+k = crypt_activate_by_keyfile_offset(cd,
argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size,
+opt_keyfile_offset, flags);
else {
char **p;
--
1.7.11.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: add keyfile-offset= support
Dear Tom,
Am Freitag, den 29.06.2012, 13:40 +0200 schrieb Tom Gundersen:
This is useful if your keyfile is a block device, and you want to
use a specific part of it, such as an area between the MBR and the
first partition.
This feature is documented in the Arch wiki[0], and has been supported
by the Arch initscripts, so would be nice to get this into systemd.
please document that libcryptsetup ≥ 1.4.2 is needed in the commit
message.
[0]:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition
Please no line break here.
---
configure.ac| 2 +-
man/crypttab.xml| 13 +
src/cryptsetup/cryptsetup.c | 11 ++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e0a2526..e1876cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -333,7 +333,7 @@ AC_SUBST(AUDIT_LIBS)
have_libcryptsetup=no
AC_ARG_ENABLE(libcryptsetup, AS_HELP_STRING([--disable-libcryptsetup],
[disable libcryptsetup tools]))
if test x$enable_libcryptsetup != xno; then
-PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup ],
+PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup = 1.4.2 ],
[AC_DEFINE(HAVE_LIBCRYPTSETUP, 1, [Define if libcryptsetup
is available]) have_libcryptsetup=yes], have_libcryptsetup=no)
if test x$have_libcryptsetup = xno -a x$enable_libcryptsetup =
xyes; then
AC_MSG_ERROR([*** libcryptsetup support requested but
libraries not found])
diff --git a/man/crypttab.xml b/man/crypttab.xml
index f3bde71..e54f78c 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -131,6 +131,19 @@
varlistentry
+
termvarnamekeyfile-offset=/varname/term
Wrong indentation?
+
+ listitemparaSpecifies the number
+of bytes to skip at the start of
+the keyfile; see
+
citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
+for possible values and the default
+value of this
+option. /para/listitem
No space after full stop and merge with line before?
+/varlistentry
+
+
+varlistentry
termvarnamehash=/varname/term
listitemparaSpecifies the hash to
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index b26fcca..f570724 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -37,6 +37,7 @@
static const char *opt_type = NULL; /* LUKS1 or PLAIN */
static char *opt_cipher = NULL;
static unsigned opt_key_size = 0;
+static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
static unsigned opt_tries = 0;
static bool opt_readonly = false;
@@ -79,6 +80,13 @@ static int parse_one_option(const char *option) {
return 0;
}
+} else if (startswith(option, keyfile-offset=)) {
+
+if (safe_atou(option+15, opt_keyfile_offset) 0) {
+log_error(keyfile-offset= parse failure,
ignoring.);
+return 0;
+}
+
} else if (startswith(option, hash=)) {
char *t;
@@ -462,7 +470,8 @@ int main(int argc, char *argv[]) {
argv[3]);
if (key_file)
-k = crypt_activate_by_keyfile(cd, argv[2],
CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
+k = crypt_activate_by_keyfile_offset(cd,
argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size,
+opt_keyfile_offset, flags);
else {
char **p;
Otherwise this looks good.
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] cryptsetup: add keyfile-offset= support
This is useful if your keyfile is a block device, and you want to
use a specific part of it, such as an area between the MBR and the
first partition.
This feature is documented in the Arch wiki[0], and has been supported
by the Arch initscripts, so would be nice to get this into systemd.
This requires libcryptsetup = 1.4.2 (released 12.4.2012).
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
[0]:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#
Storing_the_key_between_MBR_and_1st_partition
---
configure.ac| 2 +-
man/crypttab.xml| 12
src/cryptsetup/cryptsetup.c | 11 ++-
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e0a2526..e1876cc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -333,7 +333,7 @@ AC_SUBST(AUDIT_LIBS)
have_libcryptsetup=no
AC_ARG_ENABLE(libcryptsetup, AS_HELP_STRING([--disable-libcryptsetup],
[disable libcryptsetup tools]))
if test x$enable_libcryptsetup != xno; then
-PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup ],
+PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup = 1.4.2 ],
[AC_DEFINE(HAVE_LIBCRYPTSETUP, 1, [Define if libcryptsetup is
available]) have_libcryptsetup=yes], have_libcryptsetup=no)
if test x$have_libcryptsetup = xno -a x$enable_libcryptsetup =
xyes; then
AC_MSG_ERROR([*** libcryptsetup support requested but
libraries not found])
diff --git a/man/crypttab.xml b/man/crypttab.xml
index f3bde71..2fa8e89 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -131,6 +131,18 @@
varlistentry
+termvarnamekeyfile-offset=/varname/term
+
+listitemparaSpecifies the number
+of bytes to skip at the start of
+the keyfile; see
+
citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
+for possible values and the default
+value of this option./para/listitem
+/varlistentry
+
+
+varlistentry
termvarnamehash=/varname/term
listitemparaSpecifies the hash to
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index b26fcca..f570724 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -37,6 +37,7 @@
static const char *opt_type = NULL; /* LUKS1 or PLAIN */
static char *opt_cipher = NULL;
static unsigned opt_key_size = 0;
+static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
static unsigned opt_tries = 0;
static bool opt_readonly = false;
@@ -79,6 +80,13 @@ static int parse_one_option(const char *option) {
return 0;
}
+} else if (startswith(option, keyfile-offset=)) {
+
+if (safe_atou(option+15, opt_keyfile_offset) 0) {
+log_error(keyfile-offset= parse failure, ignoring.);
+return 0;
+}
+
} else if (startswith(option, hash=)) {
char *t;
@@ -462,7 +470,8 @@ int main(int argc, char *argv[]) {
argv[3]);
if (key_file)
-k = crypt_activate_by_keyfile(cd, argv[2],
CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
+k = crypt_activate_by_keyfile_offset(cd,
argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size,
+opt_keyfile_offset, flags);
else {
char **p;
--
1.7.11.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: add keyfile-offset= support
On Fri, Jun 29, 2012 at 2:22 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Otherwise this looks good. Acked-by: Paul Menzel paulepan...@users.sourceforge.net Thanks for the corrections! Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hosting a sprint in SF?
On Thu, 28.06.12 16:06, David Strauss (da...@davidstrauss.net) wrote: Heya, My company just moved into a new office at California and Grant (Chinatown, near the Financial District) in San Francisco -- finally with enough space to host a sprint. We use systemd extensively (100+ production Fedora instances) and would like to host a sprint at our office. My personal goal is journald everywhere, but I would be happy to see better systemd support in other areas. Oh, this is awesome! Much appreciated! I can almost certainly sponsor travel for some people with a history of contributing to systemd/low-level Linux or projects/languages we'd like to support. Neat! Namely, it would be great to work on the following: * journald logging libraries for every major language. Python and PHP are deep into being kicked off. Java, Ruby, and node.js are next on my list. * Once a language has journald support, build application-level integration. For example, Drupal's watchdog could go field-for-field into journald. Jenkins could have a plugin for build and administration logs. Twisted's log facility could send to journald. * Tools to automatically ship journald logs off to systems like Graylog2 and Flume. This is possible now in the lowest-common-denominator of syslog, but we could be preserving fields. * Documentation and examples for the native journald APIs I am currently working myself through the documentation backlog. I already documented logind now in its entirety and the documentation of PID 1's bus APIs are already showing up in the Wiki. The journal docs are going to be next ones, unless somebody beats me to them ;-) * Documented deployment strategies for recording append-only logs of the hash chains * Other suggestions? I also have some general systemd goals: * Better support and documentation for services running with systemd doing the daemonization and privilege dropping * Adding application support for socket inheritance (as we sponsored for Twisted) This all looks really cool! I'd like to feel out people's interest and travel schedules in this thread. With a week of time from the right people, we could kick off a major improvement in logging and journald uptake. Hmm, I'll be in the bay area the week after LPC most likely (Sep 3...). If the hackfest could take place in that time frame I'd be happy to join! Thanks a lot for this suggestion! BTW, there's going to be another hackfest related to systemd at LPC itself. It's going to be an LXC/libvirt/systemd/SELinux hackfest, in order to make systemd integrated formidably with containers and security subsystems, so that we end up with secure containers for Linux that match more closely what Solaris Zones can offer. One of the topics we're likely to discuss is journal integration for this, so that the journals of the containers seemlessly browsable on the host system. It's going to be the day before LPC, in San Diego, 28th Aug. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald API documentation
On 06/29/2012 02:49 PM, Lennart Poettering wrote: On Fri, 29.06.12 14:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Hi, I've been playing around with the python journald client, and I'm not entirely clear on a few API details. I think it would be nice if the new documentation cleared them up: 1. If the iovect passed to sd_journal_sendv() doesn't contain MESSAGE= field, the whole request seems to be ignored. And no error is thrown. Is this expected? It shouldn't be ignored, but journalctl currently just skips over it in the normal output, since there is nothing to show. The data should actually be stored on disk just fine, and the verbose mode of journalctl should show it. Oh, that explains it. journalctl -o verbose and -o export indeed show that it is logged. Invalid messages like =goo error out. That's good. MESSAGE= is logged, and even displayed as an empty line with '-o short'. That might be good, I'm not sure. But message= is neither logged, nor causes an error. What's going on here? In the long run we actually want to make this a bit smarter, and if no MESSAGE= field is set, try to look up MESSAGE_ID= in an explanation database we want to integrated. If MESSAGE_ID= doesn't exist either it might be a good idea to show some place holder text rather than not showing anything... 2. The documentation mentions ASCII as the coding, but shouldn't the messages rather be standardized on UTF-8? And also, is there a way for the reader to know, which attributes are binary? Is there some convention? The fields are typeless and can carry anything you like. We suggest people format things as ASCII strings wherever possible, UTF-8 where necessary, and binary where nothing else makes sense. This is what we call primarily ASCII. But yeah the bit that UTF-8 is the second best thing if pure ASCII is not applicable is currently not mentioned anyway and deserves. OK, that's fine, as long as 'ASCII' here means a script subset of UTF-8. Then applications can just show UTF-8. The idea is that log viewers try to detect if something is valid UTF8 and show it as such if it is. If it isn't they should show something like a hexdump or so instead. Currently journalctl isn't really doing this yet, it just has a very simple logic that checks for a subset of ASCII. This needs to be beefed up... Let's just hope that this doesn't deteriorate into web-style 90%-successful encoding-guessing-game. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug? Ordering services on device aliases
On Mon, Jun 25, 2012 at 09:18:23PM -0400, Dave Reisner wrote: On Tue, Jun 26, 2012 at 03:11:19AM +0200, Malte Starostik wrote: Hi Dave, Am Montag, 25. Juni 2012, 16:23:13 schrieb Dave Reisner: The premise is fairly simple, given the below unit: [Unit] Description=dhcpcd on %I Wants=network.target Before=network.target After=sys-subsystem-net-devices-%i.device BindTo=sys-subsystem-net-devices-%i.device [Service] Type=forking PIDFile=/run/dhcpcd-%I.pid ExecStart=/sbin/dhcpcd -A -q -w %I ExecStop=/sbin/dhcpcd -k %I [Install] Alias=multi-user.target.wants/dhcpcd@eth0.service All I'm interested in is making sure that the device is available before starting dhcpcd for an interface. However, when I enable this unit, the device alias is inactive after booting: not exactly answering your question, but dhcpcd 5.5.6 comes with this lean and clean unit: [Unit] Description=Lightweight DHCP client daemon Wants=network.target Before=network.target [Service] ExecStart=/sbin/dhcpcd --nobackground [Install] WantedBy=multi-user.target apart from the preferable --nobackground, this starts dhcpcd on all available interfaces, including those that only gonna appear later on. To fine-tune which devices to actually manage or ignore, you can then use /etc/dhcpcd.conf instead. And you only need one dhcpcd process, not one per interface. I even use that to assign static addresses and routes via dhcpcd, as I haven't found anything remotely as straighforward to setup the simplest of configs. Just some food for considerations, Malte Interesting! Thanks for pointing this out. Anyone? Still curious if my original query is working as intended, a bug, user fail, aliens... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed events
On Thu, Jun 28, 2012 at 11:01 PM, Alexander E. Patrakov patra...@gmail.com wrote: So the logic, as I understand it, should be as follows: run bgpd if the administrator has not prohibited this due to maintenance or similar reasons, and the periodically-executed (?) dead-man's-switch script doesn't say that bgpd should not run. You could also have a dead-mans-switch.service that declares bgpd.service's dependency on it. If dead-mans-switch.service fails, bgpd.service will get shut down. As long as dead-mans-switch.service exits with a non-zero code, it will even get marked as failed, which is probably a boon in your use case. Restarting bgpd.service would be manual after dead-mans-switch.service failure. If you *did* want bgpd.service to restart when the connection gets re-enabled, dead-mans-switch.service can depend on bgpd.service with bgpd.service configured to run only when required by dependencies. dead-mans-switch.service can exit with code 1 on failure, and systemd can attempt to revive dead-mans-switch.service on a configurable schedule (say, every 10 minutes) in the unit. Having a timer-based service start/stop bgpd.service works fine. I just wanted to offer a dependency-based take. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald API documentation
On Fri, Jun 29, 2012 at 6:09 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Let's just hope that this doesn't deteriorate into web-style 90%-successful encoding-guessing-game. Indeed. It would be great to just go UTF-8 clean for text and treat failures as binary data. UTF-8 is identical to ASCII in the vast majority of real log message cases. When it's not identical, saying it could be either is ambiguous. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hosting a sprint in SF?
On Fri, Jun 29, 2012 at 5:58 AM, Lennart Poettering lenn...@poettering.net wrote: Hmm, I'll be in the bay area the week after LPC most likely (Sep 3...). If the hackfest could take place in that time frame I'd be happy to join! I would be happy to set hackfest dates based on when you can join in. How do other people feel about September 3-7 in San Francisco? I can start booking out travel/lodging for some participants as soon as I get some +1s on the dates. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hosting a sprint in SF?
On Fri, Jun 29, 2012 at 5:58 AM, Lennart Poettering lenn...@poettering.net wrote: It's going to be an LXC/libvirt/systemd/SELinux hackfest, in order to make systemd integrated formidably with containers and security subsystems, so that we end up with secure containers for Linux that match more closely what Solaris Zones can offer. One of the topics we're likely to discuss is journal integration for this, so that the journals of the containers seemlessly browsable on the host system. It's going to be the day before LPC, in San Diego, 28th Aug. The LXC/libvirt part is pretty interesting, and I'd like to learn more about selinux. Is there any interest from OpenShift in participating? They have a similar container to Pantheon and have their stuff in the Fedora 18 roadmap. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Documentation about upstreaming unit files
On Fri, Jun 29, 2012 at 05:52:45PM +0200, Paul Menzel wrote: 1. What license should the unit files have? The one of the upstream project? Probably yes. Unit files are trivial in most cases. 2. Should the unit files be put in a directory `systemd/`? 3. Do the distributions install the file to the correct directory `/lib/systemd/system/` or is the upstream build system supposed to do that? man 7 daemon contains example autotools snippets, which install unit files to directory pointed by pkg-config. Those snippets detects non-systemd distributions and do not install units then. Some changes may be needed to parse unit definitions and substitute for example paths in accordance with --prefix= and --*dir= parameters during build. 4. What should upstream do if the service files differ for distributions? Try very hard to minimize delta and optimally have only one unit for all distributions. This may require implementing configuration file support and build-time declaration of its default location. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hosting a sprint in SF?
On Thu, Jun 28, 2012 at 4:06 PM, David Strauss da...@davidstrauss.net wrote: My company just moved into a new office at California and Grant (Chinatown, near the Financial District) in San Francisco -- finally with enough space to host a sprint. We use systemd extensively (100+ production Fedora instances) and would like to host a sprint at our office. My personal goal is journald everywhere, but I would be happy to see better systemd support in other areas. I can almost certainly sponsor travel for some people with a history of contributing to systemd/low-level Linux or projects/languages we'd like to support. Namely, it would be great to work on the following: * journald logging libraries for every major language. Python and PHP are deep into being kicked off. Java, Ruby, and node.js are next on my list. * Once a language has journald support, build application-level integration. For example, Drupal's watchdog could go field-for-field into journald. Jenkins could have a plugin for build and administration logs. Twisted's log facility could send to journald. * Tools to automatically ship journald logs off to systems like Graylog2 and Flume. This is possible now in the lowest-common-denominator of syslog, but we could be preserving fields. * Documentation and examples for the native journald APIs * Documented deployment strategies for recording append-only logs of the hash chains * Other suggestions? I'm somewhat concerned about the large amount of CPU utilization that I've seen with the journal, so, I'd consider putting some time into optimizing the journal internal code. The concern was that on one of our systems we had a large amount of output being piped through journald. And with a ~12 second boot, the total CPU consumption of the journal alone was 2+ seconds. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix incorrectly named manpage for udev service
On Fri, Jun 29, 2012 at 3:15 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Lennart Poettering at 27/06/12 21:38 did gyre and gimble: On Wed, 27.06.12 14:56, Dave Reisner (dreis...@archlinux.org) wrote: The service is systemd-udev.service, not systemd-udevd.service. Applied, thanks! Why isn't it called systemd-udevd.service? It would be more consistent with the others (systemd-logind.service, systemd-journald.service, systemd-localed.service etc.) Sound good to me to rename it to *d. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Upstream service file for NTP daemon chrony
Dear systemd folks, I got some private (I do not know why) replies regarding this service files giving me some hints. Am Freitag, den 22.06.2012, 11:57 +0200 schrieb Paul Menzel: Fedora ships systemd service files for chrony [1][2]. • chrony-wait.service: 1 [Unit] 2 Description=Wait for chrony to synchronize system clock 3 After=chronyd.service 4 Requires=chronyd.service 5 Before=time-sync.target 6 Wants=time-sync.target 7 8 [Service] 9 Type=oneshot 10 # Wait up to ~10 minutes for chronyd to synchronize and the remaining 11 # clock correction to be less than 0.1 seconds 12 ExecStart=/usr/bin/chronyc waitsync 60 0.1 13 RemainAfterExit=yes 14 15 [Install] 16 WantedBy=multi-user.target • chronyd.service: 1 [Unit] 2 Description=NTP client/server 3 After=syslog.target ntpdate.service 4 Conflicts=ntpd.service 5 BindTo=systemd-timedated-ntp.target 6 7 [Service] 8 Type=forking 9 EnvironmentFile=-/etc/sysconfig/chronyd 10 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey 11 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS 12 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers 13 14 [Install] 15 WantedBy=multi-user.target Do these look good enough to get upstream? `systemd-arch-units` refused a pull request [3]. It was pointed out that the service files above are very Fedora specific. Mantas pointed out that Arch Linux now ships unit files directly [4] [Unit] Description=Chrony Network Time Daemon [Service] Type=forking ExecStart=/usr/sbin/chronyd PIDFile=/var/run/chronyd.pid [Install] WantedBy=multi-user.target and therefore the pull request above was rejected. Furthermore David had some great ideas whose result is quite similar to the service file in Arch Linux. [Unit] Description=Chrony Network Time Daemon After=nss-lockup.target syslog.target [Service] ExecStart=/usr/sbin/chronyd -n [Install] WantedBy=multi-user.target David suggested that a separate system user could be used for this daemon too and systemd should do this. But it looks like that Arch Linux or Debian assume `chronyd` is run as `root` and do not set up devices or certain files for time setting to be used by a different user than root. Additionally `After=nss-lockup.target` should be set, so that the NTP daemon actually finds a NTP server. And lastly, in the directory `units/` of the systemd source tree contains `time-sync.target` and the Fedora services use that too. But reading the manual of systemd.special, my take on this is this is just a compatibility file and should not be used in a systemd service file. So does the last service file look reasonable and should be used for upstream inclusion? Thanks, Paul [1] http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chrony-wait.service;h=3958160098eae926aaf7136d7b5b8bab42a6aa35;hb=HEAD [2] http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chronyd.service;h=167332e37511f19019aabc32f82a47ef80656cd5;hb=HEAD [3] https://github.com/falconindy/systemd-arch-units/issues/98 [4] https://projects.archlinux.org/svntogit/community.git/tree/trunk/service?h=packages/chrony signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
