[systemd-devel] [PATCH] test: Make testing work on systems without or old systemd
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
* Introduce a macro to conditionally execute tests. This avoids
skipping the entire test if some parts require systemd
* Skip the journal tests when no /etc/machine-id is present
* Change test-catalog to load the catalog from the source directory
of systemd.
* /proc/PID/comm got introduced in v2.6.33 but travis is still
using v2.6.32.
* Enable make check and make distcheck on the travis build
* Use -DCATALOG_DIR=STR($(abs_top_srcdir)/catalog) as a STRINGIY
would result in the path '/home/ich/source/linux' to be expanded
to '/home/ich/source/1' as linux is defined to 1.
---
.travis.yml | 5 +++--
Makefile.am | 13 +++--
src/journal/test-catalog.c | 20 +---
src/journal/test-journal-interleaving.c | 4
src/journal/test-journal-stream.c | 4
src/journal/test-journal-verify.c | 4
src/journal/test-journal.c | 4
src/test/test-cgroup-util.c | 5 +++--
src/test/test-helper.h | 31 +++
src/test/test-id128.c | 11 +++
src/test/test-unit-file.c | 3 ++-
src/test/test-unit-name.c | 5 -
src/test/test-util.c| 9 +++--
13 files changed, 101 insertions(+), 17 deletions(-)
create mode 100644 src/test/test-helper.h
diff --git a/.travis.yml b/.travis.yml
index 42433fd..7e5251c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,8 +3,9 @@ compiler:
- gcc
before_install:
- sudo apt-get update -qq
- - sudo apt-get install autotools-dev automake autoconf libtool libdbus-1-dev
libcap-dev libblkid-dev libpam-dev libcryptsetup-dev libaudit-dev libacl1-dev
libattr1-dev libselinux-dev liblzma-dev libgcrypt-dev libqrencode-dev
libmicrohttpd-dev gtk-doc-tools gperf
-script: ./autogen.sh ./configure --enable-gtk-doc --enable-gtk-doc-pdf
make V=1 make dist V=1
+ - sudo apt-get install autotools-dev automake autoconf libtool libdbus-1-dev
libcap-dev libblkid-dev libpam-dev libcryptsetup-dev libaudit-dev libacl1-dev
libattr1-dev libselinux-dev liblzma-dev libgcrypt-dev libqrencode-dev
libmicrohttpd-dev gtk-doc-tools gperf python2.7-dev
+script: ./autogen.sh ./configure --enable-gtk-doc --enable-gtk-doc-pdf
make V=1 sudo ./systemd-machine-id-setup make check make distcheck
+after_failure: cat test-suite.log
notifications:
irc:
channels:
diff --git a/Makefile.am b/Makefile.am
index c4b9b1a..e598585 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1130,6 +1130,9 @@ EXTRA_DIST += \
test/sched_rr_ok.service \
test/sched_rr_change.service
+EXTRA_DIST += \
+ src/test/test-helper.h
+
test_engine_SOURCES = \
src/test/test-engine.c
@@ -1328,7 +1331,8 @@ test_cgroup_util_SOURCES = \
test_cgroup_util_LDADD = \
libsystemd-label.la \
- libsystemd-shared.la
+ libsystemd-shared.la \
+ libsystemd-daemon.la
test_env_replace_SOURCES = \
src/test/test-env-replace.c
@@ -2647,7 +2651,8 @@ test_id128_SOURCES = \
test_id128_LDADD = \
libsystemd-shared.la \
- libsystemd-id128-internal.la
+ libsystemd-id128-internal.la \
+ libsystemd-daemon.la
tests += \
test-id128
@@ -2810,6 +2815,10 @@ test_mmap_cache_LDADD = \
test_catalog_SOURCES = \
src/journal/test-catalog.c
+test_catalog_CFLAGS = \
+ $(AM_CFLAGS) \
+ -DSTR(s)=\#s -DCATALOG_DIR=STR($(abs_top_srcdir)/catalog)
+
test_catalog_LDADD = \
libsystemd-shared.la \
libsystemd-label.la \
diff --git a/src/journal/test-catalog.c b/src/journal/test-catalog.c
index 987867f..5db5bed 100644
--- a/src/journal/test-catalog.c
+++ b/src/journal/test-catalog.c
@@ -31,6 +31,16 @@
#include sd-messages.h
#include catalog.h
+static const char *catalog_dirs[] = {
+CATALOG_DIR,
+NULL,
+};
+
+static const char *no_catalog_dirs[] = {
+/bin/hopefully/with/no/catalog,
+NULL
+};
+
static void test_import(Hashmap *h, struct strbuf *sb,
const char* contents, ssize_t size, int code) {
int r;
@@ -100,9 +110,13 @@ static void test_catalog_update(void) {
r = catalog_update(database, NULL, NULL);
assert(r = 0);
-/* Note: this might actually not find anything, if systemd was
- * not installed before. That should be fine too. */
-r = catalog_update(database, NULL, catalog_file_dirs);
+/* Test what happens if there are no files in the directory. */
+r = catalog_update(database, NULL, no_catalog_dirs);
+assert(r = 0);
+
+/* Make sure that we at least have some files loaded or the
+ catalog_list below will fail. */
+r = catalog_update(database, NULL, catalog_dirs);
assert(r = 0);
}
diff --git a/src/journal/test-journal-interleaving.c
[systemd-devel] [PATCH] make: Automake is complaining about .PRECIOUS being redefined
From: Holger Hans Peter Freyther hol...@moiji-mobile.com Yesterday I added test-suite.log as dependency to the .PRECIOUS target. Automake is warning about this target being redefined and from what I see there is no way I can stop the warning but I can add the %MAKEFILE% as dependency. automake warning: Makefile.am:35: warning: user target '.PRECIOUS' defined here ... /usr/share/automake-1.13/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index e598585..c9b0715 100644 --- a/Makefile.am +++ b/Makefile.am @@ -32,7 +32,7 @@ SUBDIRS = . po .SECONDARY: # Keep the test-suite.log -.PRECIOUS: $(TEST_SUITE_LOG) +.PRECIOUS: $(TEST_SUITE_LOG) %MAKEFILE% LIBUDEV_CURRENT=4 LIBUDEV_REVISION=6 -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place
- Original Message - From: Kay Sievers k...@redhat.com To: Václav Pavlín vpav...@redhat.com Cc: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl, Fedora systemd team systemd-ma...@redhat.com, systemd-devel@lists.freedesktop.org Sent: Friday, June 28, 2013 11:25:49 AM Subject: Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place - Original Message - Zbigniew Jędrzejewski-Szmek píše v Čt 27. 06. 2013 v 17:00 +0200: On Thu, Jun 27, 2013 at 04:30:12PM +0200, Vaclav Pavlin wrote: From: Fedora systemd team systemd-ma...@redhat.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3a196a6..c3988e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -65,7 +65,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig pkgconfiglibdir=$(libdir)/pkgconfig polkitpolicydir=$(datadir)/polkit-1/actions bashcompletiondir=@bashcompletiondir@ -rpmmacrosdir=$(sysconfdir)/rpm +rpmmacrosdir=$(prefix)/lib/rpm/macros.d Is this a recent change in rpmbuild? I don't see any macros in the new dir on FC19, and even don't have the dir on FC18... Zbyszek RPM guys removed systemd from default build-requires in buildroot by mistake. So we discussed how to do it so that systemd does not have to be default require for all packages that ship unit files. The result of this discussion was that we create a subpackage that will contain only rpm macro files. We used to have systemd-units for that, and it did not really work out to be useful and we merged it back. Why would it work today? It seems to be a pretty pattern to have a pkg-filesystem.rpm for larger projects. A package that contains the skeleton of empty directories. Should the empty directories also go into that package? Does the pkgconfig file needs to be packaged along with rpm macro file? Michal Schmidt then suggested we could follow this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=846679 and move macro file to the new location. And yes, this applies only for F19+. Nice. Maybe some day we will really have a clean /etc, with packages not messing around in it. :) Kay I am not sure about the directories, but I think it would do no harm if we move them to the subpackage. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Has systemd booted up command
Hi, This is in reference to https://bugs.freedesktop.org/show_bug.cgi?id=66926 request. I have been polling systemd with systemctl is-active default.target to detect if boot up has been completed or not. I have noticed that this is not enough though. It seems like starting a service that is not part of the initial job tree can keep in state activating after default.target is reached. I could use systemctl list-jobs to detect if there are still jobs available but systemctl list-jobs's output is not meant for programming. Same problem happens when I switch targets. Currently I rely on systemctl list-jobs output to detect if the target switch has been completed or not. What can we do about it? One way would be having a command systemctl job-count, other would be having a command systemctl has-booted or something similar? Any thoughts? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journalctl: add ”short-iso” output format with verbose ISO8601 timestamps
Example:
2013-07-18T10:10:01+0200 sandworm CROND[20957]: (root) CMD (/usr/lib64/sa/sa1 1
1)
---
man/journalctl.xml | 12
src/journal/journalctl.c | 2 +-
src/shared/logs-show.c | 10 +-
src/shared/output-mode.h | 1 +
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/man/journalctl.xml b/man/journalctl.xml
index 65a59ea..da43bf2 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -266,6 +266,18 @@
varlistentry
term
+
optionshort-iso/option
+/term
+listitem
+parais very similar
+but shows ISO 8601
+wallclock timestamps.
+/para
+/listitem
+/varlistentry
+
+varlistentry
+term
optionverbose/option
/term
listitem
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 9a40d69..9dbe15a 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -133,7 +133,7 @@ static int help(void) {
-n --lines[=INTEGER] Number of journal entries to show\n
--no-tail Show all lines, even in follow
mode\n
-r --reverse Show the newest entries first\n
- -o --output=STRING Change journal output mode (short,
short-monotonic,\n
+ -o --output=STRING Change journal output mode (short,
short-monotonic, short-iso\n
verbose, export, json, json-pretty,
json-sse, cat)\n
-x --catalog Add message explanations where
available\n
-l --fullDo not ellipsize fields\n
diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c
index ea47468..353fd2b 100644
--- a/src/shared/logs-show.c
+++ b/src/shared/logs-show.c
@@ -258,6 +258,7 @@ static int output_short(
uint64_t x;
time_t t;
struct tm tm;
+const char *timestamp_format;
r = -ENOENT;
@@ -272,8 +273,13 @@ static int output_short(
return r;
}
+ if (mode == OUTPUT_SHORT_ISO)
+ timestamp_format = %Y-%m-%dT%H:%M:%S%z;
+ else
+ timestamp_format = %b %d %H:%M:%S;
+
t = (time_t) (x / USEC_PER_SEC);
-if (strftime(buf, sizeof(buf), %b %d %H:%M:%S,
localtime_r(t, tm)) = 0) {
+if (strftime(buf, sizeof(buf), timestamp_format,
localtime_r(t, tm)) = 0) {
log_error(Failed to format time.);
return r;
}
@@ -798,6 +804,7 @@ static int (*output_funcs[_OUTPUT_MODE_MAX])(
[OUTPUT_SHORT] = output_short,
[OUTPUT_SHORT_MONOTONIC] = output_short,
+[OUTPUT_SHORT_ISO] = output_short,
[OUTPUT_VERBOSE] = output_verbose,
[OUTPUT_EXPORT] = output_export,
[OUTPUT_JSON] = output_json,
@@ -1076,6 +1083,7 @@ int show_journal_by_unit(
static const char *const output_mode_table[_OUTPUT_MODE_MAX] = {
[OUTPUT_SHORT] = short,
[OUTPUT_SHORT_MONOTONIC] = short-monotonic,
+[OUTPUT_SHORT_ISO] = short-iso,
[OUTPUT_VERBOSE] = verbose,
[OUTPUT_EXPORT] = export,
[OUTPUT_JSON] = json,
diff --git a/src/shared/output-mode.h b/src/shared/output-mode.h
index 0efd430..4012889 100644
--- a/src/shared/output-mode.h
+++ b/src/shared/output-mode.h
@@ -24,6 +24,7 @@
typedef enum OutputMode {
OUTPUT_SHORT,
OUTPUT_SHORT_MONOTONIC,
+OUTPUT_SHORT_ISO,
OUTPUT_VERBOSE,
OUTPUT_EXPORT,
OUTPUT_JSON,
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv4] systemctl, man: option to list units by state
This allows to show only units with specified LOAD or SUB or ACTIVE state.
Signed-off-by: Maciej Wereski m.were...@partner.samsung.com
---
man/systemctl.xml | 15 +--
src/systemctl/systemctl.c | 34 --
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index f550215..e8f043c 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -114,6 +114,16 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
/varlistentry
varlistentry
+termoption--state=/option/term
+
+listitem
+paraArgument should be a comma-separated list of unit LOAD
+or SUB or ACTIVE states. When listing units show only those
+with specified LOAD or SUB or ACTIVE state./para
+/listitem
+ /varlistentry
+
+ varlistentry
termoption-p/option/term
termoption--property=/option/term
@@ -169,8 +179,9 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
termoption--failed/option/term
listitem
- paraWhen listing units, show only failed units. Do not
- confuse with option--fail/option./para
+ paraWhen listing units, show only failed units.
+ This is the same as option--state=/optionfailed.
+ Do not confuse with option--fail/option./para
/listitem
/varlistentry
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index b3b679e..11239b9 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -93,13 +93,13 @@ static bool arg_quiet = false;
static bool arg_full = false;
static int arg_force = 0;
static bool arg_ask_password = true;
-static bool arg_failed = false;
static bool arg_runtime = false;
static char **arg_wall = NULL;
static const char *arg_kill_who = NULL;
static int arg_signal = SIGTERM;
static const char *arg_root = NULL;
static usec_t arg_when = 0;
+static char **arg_state = NULL;
static enum action {
ACTION_INVALID,
ACTION_SYSTEMCTL,
@@ -301,8 +301,8 @@ static int compare_unit_info(const void *a, const void *b) {
static bool output_show_unit(const struct unit_info *u) {
const char *dot;
-if (arg_failed)
-return streq(u-active_state, failed);
+if (!strv_isempty(arg_state))
+return strv_contains(arg_state, u-load_state) ||
strv_contains(arg_state, u-sub_state) || strv_contains(arg_state,
u-active_state);
return (!arg_types || ((dot = strrchr(u-id, '.'))
strv_find(arg_types, dot+1)))
@@ -4705,12 +4705,13 @@ static int systemctl_help(void) {
-h --help Show this help\n
--versionShow package version\n
-t --type=TYPE List only units of a particular type\n
+--state=STATEShow only units with particular LOAD or
SUB or ACTIVE state\n
-p --property=NAME Show only properties by this name\n
-a --allShow all loaded units/properties,
including dead/empty\n
ones. To list all units installed on the
system, use\n
the 'list-unit-files' command instead.\n
--reverseShow reverse dependencies with
'list-dependencies'\n
---failed Show only failed units\n
+--failed Show only failed units (the same as
--state=failed)\n
-l --full Don't ellipsize unit names on output\n
--fail When queueing a new job, fail if
conflicting jobs are\n
pending\n
@@ -4931,7 +4932,8 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
ARG_FAILED,
ARG_RUNTIME,
ARG_FORCE,
-ARG_PLAIN
+ARG_PLAIN,
+ARG_STATE
};
static const struct option options[] = {
@@ -4970,6 +4972,7 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
{ lines, required_argument, NULL, 'n' },
{ output,required_argument, NULL, 'o' },
{ plain, no_argument, NULL, ARG_PLAIN },
+{ state, required_argument, NULL, ARG_STATE },
{ NULL,0, NULL, 0 }
};
@@ -5131,7 +5134,12 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
break;
case ARG_FAILED:
-arg_failed = true;
+if (!strv_contains(arg_state, failed)) {
+int r;
+r = strv_extend(arg_state, failed);
+if (r 0)
+
[systemd-devel] /etc/systemd/system/darkice.service
Hi guys, http://sprunge.us/SLSF is the service file I have currently. I'm running http://archlinuxarm.org/ on a Rpi with systemd 204-3. I'm having issues creating a service file for darkice a audio streamer that depends on: * a network connection * a microphone sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device First scenario, microphone unplugged: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 2013-07-18 17:49:41 SGT; 5min ago Process: 279 ExecStart=/usr/bin/darkice (code=exited, status=255) Jul 18 17:49:41 pihsg systemd[1]: Started DarkIce audio forwarder. Jul 18 17:49:41 pihsg darkice[279]: DarkIce 1.1 live audio streamer, http://code.google.com/p/darkice/ Jul 18 17:49:41 pihsg systemd[1]: darkice.service: main process exited, code=exited, status=255/n/a Jul 18 17:49:41 pihsg systemd[1]: Unit darkice.service entered failed state. I expected systemd to deny the start with sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device loaded inactive dead sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device Second scenario, microphone plugged in: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago Process: 121 ExecStart=/usr/bin/darkice (code=exited, status=255) journalctl -b | grep -i dark reveals DarkIce: TcpSocket.cpp:226: gethostbyname error [0] So the network wasn't ready even when depending on nss-lookup.target. I did try tweaking restart interval settings to 20, but that didn't help either. Any tips? The network is brought up by netctl-ifplugd@eth0.service Many thanks, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] runtime directories for services vs. tmpfiles
On Thu, Jul 18, 2013 at 4:50 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jul 18, 2013 at 02:51:09AM +0200, Lennart Poettering wrote: [snip repoquery magic] This means: ~81% of the packages have been converted from sysv to systemd. And ~10% of the converted packages make use of tmpfiles. Now, my rpm/yum-fu is a bit too limited to easily figure out what precisely they use of the tmpfiles functionality. So, as the person who originally porposed adding tmpfiles to units, I'm now more or less convinced that it's too late and not worth it. Since the tmpfiles snippets have been written, and a big chunk is done, it would be too confusing to add duplicate functionality. People pointed out problems with the limited RuntimeDirectory=/RuntimeDirectoryMode= proposal, and Lennart and Kay are against the original idea to add tmpfiles snippets directly. The unproven benefits are not worth it, and we certainly have other things waiting on the table. So let's close this thread. Sounds good to me. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5] journalctl: Add support for showing messages from a previous boot
On 07/18/2013 06:10 AM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 16, 2013 at 05:46:04PM +0200, Lennart Poettering wrote: On Tue, 16.07.13 17:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Jul 16, 2013 at 05:39:54PM +0200, Lennart Poettering wrote: On Fri, 28.06.13 17:26, Jan Janssen (medhe...@web.de) wrote: Applied this one now. If people start complaining about its speed we can reinvestigate and do find some way for optimization... We need to think about negative matches. Looking for previous boots with negative matches should work nicely. The bisection tables make this less efficient but certainly possible. I'd like to complain about the : in the syntax though. Hmm, what would you propose? There's still time to fix it! I went ahead, and removed : from the syntax. It feels OK in my testing. And I also made one optimization, which is important imho: 'journactl -b' will still use the boot id from sd_id128_get_boot() to avoid searching through the tables, and 'journalctl -b BOOT_ID[+-0]' will just use BOOT_ID without searching through the tables. This should help a lot when running with cold cache. Zbyszek I really don't like arguments to options that can start with -, it can easily be confused with another option. Especially if one were ever to introduce options like -0 to -9. Also, not accepting long UUIDs is kind of restricting the user. But ultimately, this is bike-shedding... But more importantly, you've introduced a bug: $ ./journalctl -b a709bdcbaa1b422f8338a25fd2d4d61d Relative boot ID offset must start with a '+' or a '-', found '' Also, for the challenged people (me), does this really guard the array access (count = INT_MAX comes to my mind)? And if so, how? if (relative (int) count || relative = -(int)count) If you could silence this warning, it would be nice :P src/journal/journalctl.c: In function ‘get_relative_boot_id’: src/journal/journalctl.c:747:63: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] (id - all_ids) + relative = count) Anyway, gonna go sulk now for not having come up with such nice code in the first place :( Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv5] systemctl, man: option to list units by state
This allows to show only units with specified LOAD or SUB or ACTIVE state.
Signed-off-by: Maciej Wereski m.were...@partner.samsung.com
---
changes since v4:
* removed help information about deprecated behaviour
Sorry, that I've forgot about this in previous patch!
regards,
Maciej
---
man/systemctl.xml | 29 -
src/systemctl/systemctl.c | 40 +++-
2 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index f550215..9820517 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -94,19 +94,13 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
listitem
paraThe argument should be a comma-separated list of unit
types such as optionservice/option and
- optionsocket/option, or unit load states such as
- optionloaded/option and optionmasked/option
- (types and states can be mixed)./para
+ optionsocket/option.
+ /para
paraIf one of the arguments is a unit type, when listing
units, limit display to certain unit types. Otherwise, units
of all types will be shown./para
- paraIf one of the arguments is a unit load state, when
- listing units, limit display to certain unit
- types. Otherwise, units of in all load states will be
- shown./para
-
paraAs a special case, if one of the arguments is
optionhelp/option, a list of allowed values will be
printed and the program will exit./para
@@ -114,6 +108,16 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
/varlistentry
varlistentry
+termoption--state=/option/term
+
+listitem
+paraArgument should be a comma-separated list of unit LOAD
+or SUB or ACTIVE states. When listing units show only those
+with specified LOAD or SUB or ACTIVE state./para
+/listitem
+ /varlistentry
+
+ varlistentry
termoption-p/option/term
termoption--property=/option/term
@@ -166,15 +170,6 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
/varlistentry
varlistentry
-termoption--failed/option/term
-
-listitem
- paraWhen listing units, show only failed units. Do not
- confuse with option--fail/option./para
-/listitem
- /varlistentry
-
- varlistentry
termoption-l/option/term
termoption--full/option/term
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index b3b679e..c15d099 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -93,13 +93,13 @@ static bool arg_quiet = false;
static bool arg_full = false;
static int arg_force = 0;
static bool arg_ask_password = true;
-static bool arg_failed = false;
static bool arg_runtime = false;
static char **arg_wall = NULL;
static const char *arg_kill_who = NULL;
static int arg_signal = SIGTERM;
static const char *arg_root = NULL;
static usec_t arg_when = 0;
+static char **arg_state = NULL;
static enum action {
ACTION_INVALID,
ACTION_SYSTEMCTL,
@@ -301,8 +301,8 @@ static int compare_unit_info(const void *a, const void *b) {
static bool output_show_unit(const struct unit_info *u) {
const char *dot;
-if (arg_failed)
-return streq(u-active_state, failed);
+if (!strv_isempty(arg_state))
+return strv_contains(arg_state, u-load_state) ||
strv_contains(arg_state, u-sub_state) || strv_contains(arg_state,
u-active_state);
return (!arg_types || ((dot = strrchr(u-id, '.'))
strv_find(arg_types, dot+1)))
@@ -4705,12 +4705,12 @@ static int systemctl_help(void) {
-h --help Show this help\n
--versionShow package version\n
-t --type=TYPE List only units of a particular type\n
+--state=STATEShow only units with particular LOAD or
SUB or ACTIVE state\n
-p --property=NAME Show only properties by this name\n
-a --allShow all loaded units/properties,
including dead/empty\n
ones. To list all units installed on the
system, use\n
the 'list-unit-files' command instead.\n
--reverseShow reverse dependencies with
'list-dependencies'\n
---failed Show only failed units\n
-l --full Don't ellipsize unit names on output\n
--fail When queueing a new job, fail if
conflicting jobs are\n
pending\n
@@ -4896,13 +4896,6 @@ static int help_types(void) {
puts(t);
}
-puts(\nAvailable unit load
Re: [systemd-devel] [PATCH v5] journalctl: Add support for showing messages from a previous boot
On Thu, Jul 18, 2013 at 01:05:25PM +0200, Jan Janssen wrote: On 07/18/2013 06:10 AM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 16, 2013 at 05:46:04PM +0200, Lennart Poettering wrote: On Tue, 16.07.13 17:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Jul 16, 2013 at 05:39:54PM +0200, Lennart Poettering wrote: On Fri, 28.06.13 17:26, Jan Janssen (medhe...@web.de) wrote: Applied this one now. If people start complaining about its speed we can reinvestigate and do find some way for optimization... We need to think about negative matches. Looking for previous boots with negative matches should work nicely. The bisection tables make this less efficient but certainly possible. I'd like to complain about the : in the syntax though. Hmm, what would you propose? There's still time to fix it! I went ahead, and removed : from the syntax. It feels OK in my testing. And I also made one optimization, which is important imho: 'journactl -b' will still use the boot id from sd_id128_get_boot() to avoid searching through the tables, and 'journalctl -b BOOT_ID[+-0]' will just use BOOT_ID without searching through the tables. This should help a lot when running with cold cache. Zbyszek I really don't like arguments to options that can start with -, it can easily be confused with another option. Especially if one were ever to introduce options like -0 to -9. Also, not accepting long UUIDs is kind of restricting the user. But ultimately, this is bike-shedding... But more importantly, you've introduced a bug: $ ./journalctl -b a709bdcbaa1b422f8338a25fd2d4d61d Relative boot ID offset must start with a '+' or a '-', found '' Arrgh. Also, for the challenged people (me), does this really guard the array access (count = INT_MAX comes to my mind)? And if so, how? if (relative (int) count || relative = -(int)count) count comes from searching throught the database, so cannot really get too large without a really long wait. Nevertheless, if it was = INT_MAX, than after casting to (int) it would become negative, and the left side of the if should be satisfied. If you could silence this warning, it would be nice :P src/journal/journalctl.c: In function ‘get_relative_boot_id’: src/journal/journalctl.c:747:63: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] (id - all_ids) + relative = count) Interesting that my gcc (4.7.2) didn't show that. Anyway, gonna go sulk now for not having come up with such nice code in the first place :( The pull towards bikeshedding and µ-opts was too strong for me to resist :) But I seriously think that the arguments with a dash will turn out OK in practice. Zbyszek -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: Hi guys, http://sprunge.us/SLSF is the service file I have currently. I'm running http://archlinuxarm.org/ on a Rpi with systemd 204-3. I'm having issues creating a service file for darkice a audio streamer that depends on: * a network connection * a microphone sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device First scenario, microphone unplugged: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 2013-07-18 17:49:41 SGT; 5min ago Process: 279 ExecStart=/usr/bin/darkice (code=exited, status=255) Jul 18 17:49:41 pihsg systemd[1]: Started DarkIce audio forwarder. Jul 18 17:49:41 pihsg darkice[279]: DarkIce 1.1 live audio streamer, http://code.google.com/p/darkice/ Jul 18 17:49:41 pihsg systemd[1]: darkice.service: main process exited, code=exited, status=255/n/a Jul 18 17:49:41 pihsg systemd[1]: Unit darkice.service entered failed state. I expected systemd to deny the start with sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device loaded inactive dead sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device You need an After= here for the device, too. Second scenario, microphone plugged in: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago The timestamp looks weird. Does the device have no RTC or so? Process: 121 ExecStart=/usr/bin/darkice (code=exited, status=255) journalctl -b | grep -i dark reveals DarkIce: TcpSocket.cpp:226: gethostbyname error [0] So the network wasn't ready even when depending on nss-lookup.target. I did try tweaking restart interval settings to 20, but that didn't help either. Any tips? The network is brought up by netctl-ifplugd@eth0.service See: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ 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] runtime directories for services vs. tmpfiles
On 07/18/2013 12:51 AM, Lennart Poettering wrote:
Fedora is not completely converted, but here are some stats.
$ repoquery --whatprovides '/etc/rc.d/init.d/*' --qf %{name} | sort -u |
egrep -v '(-sysvinit|-initscript|-sysv)$' | wc -l
139
Well even that number is not accurate since we have several migrated
components being stuck in bugzilla and not being packaged and shipped
which is the biggest problem we are faced with in the migration process
( and have been faced with from the start ) as in not the actual
migration but to get maintainers of those components, package and ship
the units ( and quite few of those remaining ones seem to unmaintained ).
If everything goes as planned we should finish migrating those this
release cycle ( F20 ).
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, Jul 18, 2013 at 2:27 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago The timestamp looks weird. Does the device have no RTC or so? Yeah, the RPi does not have an RTC. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, Jul 18, 2013 at 02:27:09PM +0200, Lennart Poettering wrote: On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: Second scenario, microphone plugged in: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago The timestamp looks weird. Does the device have no RTC or so? RPis have no RTC. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: Leave server_dispatch_message early when Storage is none
From: Holger Hans Peter Freyther hol...@moiji-mobile.com When using Storage=none there is no point in collecting all the information just to throw them away. After this change journald consumes a lot less CPU time when only forwarding messages. --- src/journal/journald-server.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c index 369ebf4..f3599b7 100644 --- a/src/journal/journald-server.c +++ b/src/journal/journald-server.c @@ -862,6 +862,11 @@ void server_dispatch_message( if (LOG_PRI(priority) s-max_level_store) return; +/* Stop early in case the information will not be stored + * in a journal. */ +if (s-storage == STORAGE_NONE) +return; + if (!ucred) goto finish; -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Log failing start conditions
On Thu, 18.07.13 05:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I'd prefer if we'd solve this without the journal. Instead, I think
struct Condition should be extended to store the most recent test
result in a tri-state, i.e. negative for untested, zero for failed,
positive for succeeded. Then we should add bus property to the Unit
interface that is an array of structs with the conditions in them,
including their results.
I've now extended the dbus api, except that 0 means untested,
0 means OK, 0 means failed, in case we decide to extend failed
later on.
Hmm, so thinking about this, it probably is not a good idea to expose a
tristate as an int on the bus, but do that the same way as we expose
enums (i.e. as strings).
We already have some generic support for tri-states in place. For
example, there is config_parse_tristate() which parses a configuration
boolean into a tri-state int. And we have
bus_property_append_tristate_false() which serializes a tri-state int to
a dbus boolean mapping both 0 and 0 to false.
Now, in both cases the externally visible type is actually a bool, even
if we internally distuingish three different states. For the condition
stuff it is necessary to *actually* distuingish three states on the wire
too. D-Bus doesn't know this natively however.
Maybe use a string and map 0 to t, 0 to f and 0 to ?
static inline const char* tristate_to_string(int v) {
return v 0 ? t :
v == 0 ? f : ;
}
Or something like that?
Sounds a bit more future proof that way I think.
What I am afraid of here is that if we expose tristate-as-int on the bus
that people will actually assume -1 and 1 are the values to check for,
even though we actually mean 0 and 0...
With that in place systemctl should simple retrieve this property and
show the results of *all* individual condition checks if the overall
condition result was negatzive.
systemctl now will add a line (at most one), describing which condition
or condtions failed. Full output like in Harald's patch is not shown,
although we could still add it without any trouble, because full information
is exported over dbus. Nevertheless, I think current output is fine.
Great work! Thanks!
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] /etc/systemd/system/darkice.service
On 18 July 2013 20:27, Lennart Poettering lenn...@poettering.net wrote: You need an After= here for the device, too. Thanks this fixes the first scenario: http://sprunge.us/LiQF I must say needing After BindsTo is a bit confusing. I also don't see the need for different sections. Never quite know under which heading a stanza should go. The timestamp looks weird. Does the device have no RTC or so? no RTC, so does that mess up the retry interval code I wonder? Because I don't mind if systemd just retries it every so often. But that doesn't work. :/ Not sure I like the suggestions here: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ I despise NetworkManager. Hasn't someone written a simple service that say pings 8.8.8.8 and if that's OK, says the network is up? That's how even enterprise routers work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] core: notify triggered by socket of a service
On Thu, Jul 18, 2013 at 3:27 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 17.07.13 09:46, Umut Tezduyar (u...@tezduyar.com) wrote:
+static void socket_trigger_notify(Unit *u, Unit *other) {
+Socket *s = SOCKET(u);
+Service *se = SERVICE(other);
+
+assert(u);
+assert(other);
+
+if (other-load_state != UNIT_LOADED ||
+other-type != UNIT_SERVICE)
+return;
+
+if (se-state == SERVICE_FAILED se-socket_fd 0)
+socket_notify_service_dead(s, se-result ==
SERVICE_FAILURE_START_LIMIT);
+
+if ((se-state == SERVICE_DEAD ||
+se-state == SERVICE_STOP ||
+se-state == SERVICE_STOP_SIGTERM ||
+se-state == SERVICE_STOP_SIGKILL ||
+se-state == SERVICE_STOP_POST ||
+se-state == SERVICE_FINAL_SIGTERM ||
+se-state == SERVICE_FINAL_SIGKILL ||
+se-state == SERVICE_AUTO_RESTART)
+se-socket_fd 0)
+socket_notify_service_dead(s, false);
+
+if (!s-accept se-state == SERVICE_RUNNING)
+socket_set_state(s, SOCKET_RUNNING);
+}
Hmm, hmm, so, the se-socket_fd 0 check will be true for all services
where the socket has !s-accept set. (after all, s-accept=true indicates
that we should accept the sockets, and then pass the connection socket
to the service, and that is stored in se-socket_fd, since it becomes
private property of that service. That is different for s-accept=false
where the socket continues to be owned by the socket unit).
Hence, since all three if blocks effectivel just check for !s-accept,
could you split the check out and replace it with an early
if (s-accept)
return;
Immediately after the initial load/service type check?
Corrected in that way.
Otherwise the patch looks great! Have you tested that everything works
with it?
:) I tried different ways but I think it would be great if someone can
test it a bit more. Especially for the reason that I work on systemd
204 not 205. I have tried killing, stopping services that are socket
activated or not.
I have stumbled on assert error due to socket's coldplug function is
expecting socket to be in dead state. Next version of patch will
reflect this in a way that it will not change the socket state if
socket is in dead state.
Thanks for working on this!
Absolutely.
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] [PATCHv3] core: notify triggered by socket of a service
Refer to:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011532.html
---
TODO |3 ---
src/core/service.c | 31 ---
src/core/socket.c | 34 +-
src/core/socket.h |3 ---
4 files changed, 33 insertions(+), 38 deletions(-)
diff --git a/TODO b/TODO
index 753d1cc..b5ea4a7 100644
--- a/TODO
+++ b/TODO
@@ -120,9 +120,6 @@ Features:
maybe we should stop doing auto-activation of this after boot
entirely. https://bugzilla.gnome.org/show_bug.cgi?id=701676
-* when a service changes state make reflect that in the
- RUNNING/LISTENING states of its socket
-
* when recursively showing the cgroup hierarchy, optionally also show
the hierarchies of child processes
diff --git a/src/core/service.c b/src/core/service.c
index b98f11a..157d614 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1481,24 +1481,6 @@ static int service_search_main_pid(Service *s) {
return 0;
}
-static void service_notify_sockets_dead(Service *s, bool failed_permanent) {
-Iterator i;
-Unit *u;
-
-assert(s);
-
-/* Notifies all our sockets when we die */
-
-if (s-socket_fd = 0)
-return;
-
-SET_FOREACH(u, UNIT(s)-dependencies[UNIT_TRIGGERED_BY], i)
-if (u-type == UNIT_SOCKET)
-socket_notify_service_dead(SOCKET(u),
failed_permanent);
-
-return;
-}
-
static void service_set_state(Service *s, ServiceState state) {
ServiceState old_state;
const UnitActiveState *table;
@@ -1550,19 +1532,6 @@ static void service_set_state(Service *s, ServiceState
state) {
s-control_command_id = _SERVICE_EXEC_COMMAND_INVALID;
}
-if (state == SERVICE_FAILED)
-service_notify_sockets_dead(s, s-result ==
SERVICE_FAILURE_START_LIMIT);
-
-if (state == SERVICE_DEAD ||
-state == SERVICE_STOP ||
-state == SERVICE_STOP_SIGTERM ||
-state == SERVICE_STOP_SIGKILL ||
-state == SERVICE_STOP_POST ||
-state == SERVICE_FINAL_SIGTERM ||
-state == SERVICE_FINAL_SIGKILL ||
-state == SERVICE_AUTO_RESTART)
-service_notify_sockets_dead(s, false);
-
if (state != SERVICE_START_PRE
state != SERVICE_START
state != SERVICE_START_POST
diff --git a/src/core/socket.c b/src/core/socket.c
index cf88bae..49a58b5 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -2277,7 +2277,7 @@ int socket_collect_fds(Socket *s, int **fds, unsigned
*n_fds) {
return 0;
}
-void socket_notify_service_dead(Socket *s, bool failed_permanent) {
+static void socket_notify_service_dead(Socket *s, bool failed_permanent) {
assert(s);
/* The service is dead. Dang!
@@ -2322,6 +2322,36 @@ static void socket_reset_failed(Unit *u) {
s-result = SOCKET_SUCCESS;
}
+static void socket_trigger_notify(Unit *u, Unit *other) {
+Socket *s = SOCKET(u);
+Service *se = SERVICE(other);
+
+assert(u);
+assert(other);
+
+if (other-load_state != UNIT_LOADED ||
+other-type != UNIT_SERVICE ||
+s-accept)
+return;
+
+if (se-state == SERVICE_FAILED)
+socket_notify_service_dead(s, se-result ==
SERVICE_FAILURE_START_LIMIT);
+
+if (se-state == SERVICE_DEAD ||
+se-state == SERVICE_STOP ||
+se-state == SERVICE_STOP_SIGTERM ||
+se-state == SERVICE_STOP_SIGKILL ||
+se-state == SERVICE_STOP_POST ||
+se-state == SERVICE_FINAL_SIGTERM ||
+se-state == SERVICE_FINAL_SIGKILL ||
+se-state == SERVICE_AUTO_RESTART)
+socket_notify_service_dead(s, false);
+
+if (s-state != SOCKET_DEAD
+se-state == SERVICE_RUNNING)
+socket_set_state(s, SOCKET_RUNNING);
+}
+
static int socket_kill(Unit *u, KillWho who, int signo, DBusError *error) {
return unit_kill_common(u, who, signo, -1, SOCKET(u)-control_pid,
error);
}
@@ -2402,6 +2432,8 @@ const UnitVTable socket_vtable = {
.sigchld_event = socket_sigchld_event,
.timer_event = socket_timer_event,
+.trigger_notify = socket_trigger_notify,
+
.reset_failed = socket_reset_failed,
.bus_interface = org.freedesktop.systemd1.Socket,
diff --git a/src/core/socket.h b/src/core/socket.h
index 8f9dfdb..5733322 100644
--- a/src/core/socket.h
+++ b/src/core/socket.h
@@ -156,9 +156,6 @@ struct Socket {
/* Called from the service code when collecting fds */
int socket_collect_fds(Socket *s, int **fds, unsigned *n_fds);
-/* Called from the service when it shut down */
-void socket_notify_service_dead(Socket *s, bool failed_permanent);
-
/* Called from the mount code figure out if a mount is a dependency of
* any of the sockets of this
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, 18.07.13 14:34, Tom Gundersen (t...@jklm.no) wrote:
On Thu, Jul 18, 2013 at 2:27 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote:
[root@pihsg ~]# systemctl status darkice.service
darkice.service - DarkIce audio forwarder
Loaded: loaded (/etc/systemd/system/darkice.service; enabled)
Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08
SGT; 43 years 6 months ago
The timestamp looks weird. Does the device have no RTC or so?
Yeah, the RPi does not have an RTC.
Which reminds me that people suggested we should maybe add a simple
logic to systemd that during shutdown we should invoke
utimensat(clock_gettime(CLOCK_REALTIME)) on some file in /var/, and
during boot-up we should set the realtime clock from that if it is set
to a date earlier than that or so... That way time will monotonically
increase even across reboots, and even without network around, which is
useful in particular during boot up, and not constantly restart from
1970 again on each boot. For machines that are more often on than off
the accuracy might be good enough so that NTP never has to resort to
making the time jump abruptly.
If somebody wants to work on this: this should probably take inspiration
from the random seed service which is started after /var is up and
stopped before /var goes down. I figure embedded devices are the most
likely to use a split off /var (because of read-only /), so this
ordering is a must to ensure that we check for the file at the right
time.
In the cases where /var is not split off it might be a good idea to
apply the jump even earlier, from PID1 before the first unit is forked
off, so that userspace outside of PID 1 *never* has to see weird 1970
dates. Hence it would be a good choice to do the threshold-based RTC
jump logic twice: once in PID 1 in some code like
src/core/{hostname,loopback,machine-id,mount}-setup.c and once in that
random-seed-like unit that runs after /var is found. The threshold logic
should make sure we do not make the time jump twice. And of course if
the file is not found then this should not cause an error but should be
silently ignored.
A nice side effect of this is that even on systems which have an RTC
we'd always correct them at least to the date the OS image you run was
created at.
The stuff of course should be compile-time optional.
If somebody wants to work on this, I'd be happy to take the patch. If
figure this should be 50 lines or so.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Log failing start conditions
On Thu, Jul 18, 2013 at 02:47:56PM +0200, Lennart Poettering wrote:
On Thu, 18.07.13 05:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I'd prefer if we'd solve this without the journal. Instead, I think
struct Condition should be extended to store the most recent test
result in a tri-state, i.e. negative for untested, zero for failed,
positive for succeeded. Then we should add bus property to the Unit
interface that is an array of structs with the conditions in them,
including their results.
I've now extended the dbus api, except that 0 means untested,
0 means OK, 0 means failed, in case we decide to extend failed
later on.
Hmm, so thinking about this, it probably is not a good idea to expose a
tristate as an int on the bus, but do that the same way as we expose
enums (i.e. as strings).
We already have some generic support for tri-states in place. For
example, there is config_parse_tristate() which parses a configuration
boolean into a tri-state int. And we have
bus_property_append_tristate_false() which serializes a tri-state int to
a dbus boolean mapping both 0 and 0 to false.
Now, in both cases the externally visible type is actually a bool, even
if we internally distuingish three different states. For the condition
stuff it is necessary to *actually* distuingish three states on the wire
too. D-Bus doesn't know this natively however.
Maybe use a string and map 0 to t, 0 to f and 0 to ?
static inline const char* tristate_to_string(int v) {
return v 0 ? t :
v == 0 ? f : ;
}
Or something like that?
Sounds a bit more future proof that way I think.
What I am afraid of here is that if we expose tristate-as-int on the bus
that people will actually assume -1 and 1 are the values to check for,
even though we actually mean 0 and 0...
I don't see why anybody would assume that, if is is explicitly documented
(something like The value is 0, currently -1 is always used, but we
reserve the possibility of extending the range of values used to carry
additional information. So you should use 'state 0' as the condition
for a failed condition.)
I'm worried that numbers are easier to carry additional data
(e.g. errno), and if strings are used, the interface will be hard to
extend without breaking users who expect f for failure.
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add ”short-iso” output format with verbose ISO8601 timestamps
On Thu, 18.07.13 10:21, Tomasz Torcz (to...@pipebreaker.pl) wrote: Example: 2013-07-18T10:10:01+0200 sandworm CROND[20957]: (root) CMD (/usr/lib64/sa/sa1 1 1) Applied! Thanks! (Made some minor changes though: dropped tabs, and removed a gcc warning by changing the strftime() invocation to not take a variable as format string). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: get rid the start job when transitioning to deactivating
When dependency unit is configured with StopWhenUnneeded=yes and
activation of main unit fails, e.g. start timeout occurs, then
dependencies are never stopped. This happens because start job for
the main unit is still around.
---
src/core/unit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 0e9329f..d5c89a4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1461,7 +1461,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
else if (u-job-state == JOB_RUNNING ns !=
UNIT_ACTIVATING) {
unexpected = true;
-if (UNIT_IS_INACTIVE_OR_FAILED(ns))
+if (UNIT_IS_INACTIVE_OR_FAILED(ns) ||
UNIT_IS_INACTIVE_OR_DEACTIVATING(ns))
job_finish_and_invalidate(u-job, ns
== UNIT_FAILED ? JOB_FAILED : JOB_DONE, true);
}
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2, ping?] tmpfiles, man: Add xattr support to tmpfiles
Hello,
16.07.2013 at 00:31 Lennart Poettering lenn...@poettering.net wrote:
+STRV_FOREACH(x, i-xattrs) {
+value = *x;
+name = strsep(value, =);
I'd really prefer if we didn't corrupt the string here. Maybe use
strv_split_quoted() here? That handles all the values for you anyway...
You mean strv_split() (I'm splitting by =)? This has one issue: it
splits by all separator occurrences and I need to split after first one.
If corrupting string is the issue, I can make a copy of it. If you prefer
strv_split(), then I can just join if strv_length 2.
+for (n = 0; n strv_length(tmp); ++n) {
+len = strlen(tmp[n]);
+strncpy(xattr, tmp[n], len+1);
+p = strchr(xattr, '=');
+if (!p) {
+log_error(%s: Attribute has incorrect
format., i-path);
+return -EBADMSG;
+}
+if (p[1] == '\') {
+while (true) {
+if (!p)
+p = tmp[n];
+else
+p += 2;
+p = strchr(p, '\');
+if (p xattr[p-xattr-1] != '\\')
+break;
+p = NULL;
+++n;
+if (n == strv_length(tmp))
+break;
+len += strlen(tmp[n]) + 1;
+strncat(xattr, , 1);
+strncat(xattr, tmp[n], len);
+}
+}
+strstrip(xattr);
+f = i-xattrs;
+i-xattrs = strv_append(i-xattrs, xattr);
+if (!i-xattrs){
+strv_free(f);
+return log_oom();
+}
For this stuf I'd really prefer using one of our already existing
quoting APIs, like strv_spit_quoted() or FOREACH_WORD_QUOTED or so.
Well, I've tried it in the beginning, but in doesn't work properly in this
case. split_quoted() expects quote on the beginning of a string (ignoring
whitespace occurrences). If there's no such case string will be split using
whitespace. Example of extended attribute with quotes:
user.test=This will \ fail
So how would you like this case to be solved?
regards,
Maciej
--
Maciej Wereski
Samsung RD Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Thu, 18.07.13 10:45, Thomas Bächler (tho...@archlinux.org) wrote:
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
Note that most of the existing output modes can actually not be replaced
by such a format string. For example the json mode will serialize a
variable number of paramters into a single line, which is hard to
express in format strings. So, having the current output modes in place is
certainly going to be necessary always.
That said, I'd be open for a patch that adds support for printing logs
via such a format string, as an alternative to the defined output
modes. As syntax I'd prefer if we could requse the % specifier syntax
for the special fields (we already use % specifiers in the unit files,
so this would just reuse this language here), and @FOOBAR@ for the
journal fields (this syntax is already used by the message catalog
stuff, for the same purpose).
I hope that makes sense?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --iso-dates for long timestamps
On Thu, Jul 18, 2013 at 06:55:47PM +0200, Lennart Poettering wrote:
On Thu, 18.07.13 10:45, Thomas Bächler (tho...@archlinux.org) wrote:
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
Note that most of the existing output modes can actually not be replaced
by such a format string. For example the json mode will serialize a
variable number of paramters into a single line, which is hard to
express in format strings. So, having the current output modes in place is
certainly going to be necessary always.
That said, I'd be open for a patch that adds support for printing logs
via such a format string, as an alternative to the defined output
modes. As syntax I'd prefer if we could requse the % specifier syntax
for the special fields (we already use % specifiers in the unit files,
so this would just reuse this language here), and @FOOBAR@ for the
journal fields (this syntax is already used by the message catalog
stuff, for the same purpose).
Just a note: git log pretty format is used for something similar, and
it would be great to follow the lessons learned there. For example,
it is necessary to be able place some fields on a line of their own,
iff the field exists, and put nothing otherwise, and also that it's
nicer to have terminator not separator semantics.
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Has systemd booted up command
On Thu, 18.07.13 10:08, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, This is in reference to https://bugs.freedesktop.org/show_bug.cgi?id=66926 request. I have been polling systemd with systemctl is-active default.target to detect if boot up has been completed or not. I have noticed that this is not enough though. It seems like starting a service that is not part of the initial job tree can keep in state activating after default.target is reached. I could use systemctl list-jobs to detect if there are still jobs available but systemctl list-jobs's output is not meant for programming. Same problem happens when I switch targets. Currently I rely on systemctl list-jobs output to detect if the target switch has been completed or not. What can we do about it? One way would be having a command systemctl job-count, other would be having a command systemctl has-booted or something similar? Any thoughts? systemctl job-count is available in systemctl show -p NJobs. You can query this property easily via D-Bus too. It should be relatively easy to write a tool that waits for the boot to complete, as we send out a StartupFinished signal in that case, and systemctl show -p Progress will tell you as a fractional between 0 and 1 how far the boot completed so far. However, the problem I have with adding this is the weak definition of finished start-up. For example, StartupFinished is actually sent out as soon as the job queue ran empty for the first time (i.e. NJobs is 0). But you already want something slightly different there, and also wait for some later jobs? And of course, such a concept still wouldn't include desktop initialization times and suchlike, so I am not totally convinced we could find an approach that is sufficientlly well-defined that it works for most people, not just some. If you follow what I mean... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Log failing start conditions
On Thu, 18.07.13 15:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
Now, in both cases the externally visible type is actually a bool, even
if we internally distuingish three different states. For the condition
stuff it is necessary to *actually* distuingish three states on the wire
too. D-Bus doesn't know this natively however.
Maybe use a string and map 0 to t, 0 to f and 0 to ?
static inline const char* tristate_to_string(int v) {
return v 0 ? t :
v == 0 ? f : ;
}
Or something like that?
Sounds a bit more future proof that way I think.
What I am afraid of here is that if we expose tristate-as-int on the bus
that people will actually assume -1 and 1 are the values to check for,
even though we actually mean 0 and 0...
I don't see why anybody would assume that, if is is explicitly documented
(something like The value is 0, currently -1 is always used, but we
reserve the possibility of extending the range of values used to carry
additional information. So you should use 'state 0' as the condition
for a failed condition.)
I'm worried that numbers are easier to carry additional data
(e.g. errno), and if strings are used, the interface will be hard to
extend without breaking users who expect f for failure.
Well, regarding f and t, of course yes and no would work too,
the same way as yesno() already handles that...
But hmm, maybe the tristate-as-int thing is actually not that bad, so
let's leave this in.
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] /etc/systemd/system/darkice.service
On Thu, 18.07.13 21:11, Kai Hendry (hen...@iki.fi) wrote: On 18 July 2013 20:27, Lennart Poettering lenn...@poettering.net wrote: You need an After= here for the device, too. Thanks this fixes the first scenario: http://sprunge.us/LiQF I must say needing After BindsTo is a bit confusing. I also don't see the need for different sections. Never quite know under which heading a stanza should go. It is certainly surprising at first, but it makes a lot of sense. In systemd ordering deps and requirement deps are truly orthogonal. This is useful in many cases, because sometimes you just want to pull something else in, but not imply any ordering, sometimes you want to order without actually pulling it in, and often you want to do both. Of course, not all deps make sense in all combinations, but I think it's easy enough to grasp. The timestamp looks weird. Does the device have no RTC or so? no RTC, so does that mess up the retry interval code I wonder? Because I don't mind if systemd just retries it every so often. But that doesn't work. :/ All time-based logic in systemd uses CLOCK_MONOTONIC wherever that makes sense, so we should be fairly safe on that. Not sure I like the suggestions here: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ I despise NetworkManager. Hasn't someone written a simple service that say pings 8.8.8.8 and if that's OK, says the network is up? That's how even enterprise routers work. I figure you could try this with a service like the following (untested): [Unit] Before=network-online.target [Service] ExecStart=/usr/bin/ping -nq 8.8.8.8 -w 60 -c 1 Type=oneshot StandardOutput=null [Install] WantedBy=network-online.target Then, install and enable this service, and pull in network-online.target from the service that you want to wait for the network to be around. This will timeout after 60 seconds. It's hacky, generates awful traffic, and has quite some latency, but it should do what you asked for... 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] [PATCHv5] systemctl, man: option to list units by state
On Thu, 18.07.13 13:24, Maciej Wereski (m.were...@partner.samsung.com) wrote: This allows to show only units with specified LOAD or SUB or ACTIVE state. Thanks! Applied (with some changes, got rid of the arg_load_states strv which is kinda unnecessary if we have arg_states now). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: Leave server_dispatch_message early when Storage is none
On Thu, 18.07.13 14:45, Holger Hans Peter Freyther (hol...@freyther.de) wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com When using Storage=none there is no point in collecting all the information just to throw them away. After this change journald consumes a lot less CPU time when only forwarding messages. Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: get rid the start job when transitioning to deactivating
On Thu, 18.07.13 17:04, Michal Sekletar (msekl...@redhat.com) wrote:
When dependency unit is configured with StopWhenUnneeded=yes and
activation of main unit fails, e.g. start timeout occurs, then
dependencies are never stopped. This happens because start job for
the main unit is still around.
---
src/core/unit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 0e9329f..d5c89a4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1461,7 +1461,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
else if (u-job-state == JOB_RUNNING ns !=
UNIT_ACTIVATING) {
unexpected = true;
-if (UNIT_IS_INACTIVE_OR_FAILED(ns))
+if (UNIT_IS_INACTIVE_OR_FAILED(ns) ||
UNIT_IS_INACTIVE_OR_DEACTIVATING(ns))
job_finish_and_invalidate(u-job, ns
== UNIT_FAILED ? JOB_FAILED : JOB_DONE, true);
}
Hmm, so UNIT_IS_INACTIVE_OR_DEACTIVATING() actually tests for a superset
of UNIT_IS_INACTIVE_OR_FAILED(), so oring them is unnecessary.
I am not entirely grokking the patch though. So far the idea was that if
a unit is being deactviated while a start job is queued that we then
simply wait until the deactivation is complete and then execute the
start job. This would break with your patch though...
Hmm, can you eleraborate on the actual problem you are trying to solve=
I don't get it so far ;-)
Thanks,
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] [PATCHv3] core: notify triggered by socket of a service
On Thu, 18.07.13 15:27, Umut Tezduyar (u...@tezduyar.com) wrote:
+static void socket_trigger_notify(Unit *u, Unit *other) {
+Socket *s = SOCKET(u);
+Service *se = SERVICE(other);
+
+assert(u);
+assert(other);
+
+if (other-load_state != UNIT_LOADED ||
+other-type != UNIT_SERVICE ||
+s-accept)
+return;
+
+if (se-state == SERVICE_FAILED)
+socket_notify_service_dead(s, se-result ==
SERVICE_FAILURE_START_LIMIT);
+
+if (se-state == SERVICE_DEAD ||
+se-state == SERVICE_STOP ||
+se-state == SERVICE_STOP_SIGTERM ||
+se-state == SERVICE_STOP_SIGKILL ||
+se-state == SERVICE_STOP_POST ||
+se-state == SERVICE_FINAL_SIGTERM ||
+se-state == SERVICE_FINAL_SIGKILL ||
+se-state == SERVICE_AUTO_RESTART)
+socket_notify_service_dead(s, false);
+
+if (s-state != SOCKET_DEAD
+se-state == SERVICE_RUNNING)
+socket_set_state(s, SOCKET_RUNNING);
+}
Hmm, so I am pretty sure that the most recent change you did should
actually apply to all three if blocks... i.e. we shouldn't propagate the
state changes from the service to the socket if the socket is already
dead or failed. Or in fact, even stronger: we shouldn't propagate the
state unless the socket is actually fully up. Hence, it appears to me
that there should be an early return condition at the head
of the function that does:
/* Don't propagate state changes from the service if we are
already down. */
if (s-state != SOCKET_RUNNING s-state != SOCKET_LISTENING)
return;
Or something like that? Could you rework the patch and give it a bit of
testing? If things work for you I'll then merge it, and we can fix
everything that might still pop up in git.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2, ping?] tmpfiles, man: Add xattr support to tmpfiles
On Thu, 18.07.13 17:09, Maciej Wereski (m.were...@partner.samsung.com) wrote:
Hello,
16.07.2013 at 00:31 Lennart Poettering lenn...@poettering.net wrote:
+STRV_FOREACH(x, i-xattrs) {
+value = *x;
+name = strsep(value, =);
I'd really prefer if we didn't corrupt the string here. Maybe use
strv_split_quoted() here? That handles all the values for you anyway...
You mean strv_split() (I'm splitting by =)? This has one issue: it
splits by all separator occurrences and I need to split after first one.
If corrupting string is the issue, I can make a copy of it. If you prefer
strv_split(), then I can just join if strv_length 2.
Oh, true.
Given that this appears to be recurring theme I have now added a
split_pair() call for you. It will split a string up at a specified
separator into a pair. You could then pass the second argument into
unquote() and that's all you need?
Could you please rework your patch with that?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] RFC: journald: Allow to cache the cg_get_root_path
On 07/16/2013 03:26 AM, Lennart Poettering wrote: On Mon, 08.07.13 18:39, Karol Lewandowski (k.lewando...@samsung.com) wrote: According to my analysis /proc access is costly and it would be best to cache the result for later use. Difficulty comes from trying to keep cache up to date, though. We can't really cache this. This stuff is already racy, as by the time we read the attributes the process might already be gone. Agreed, this is why I have been naively thinking that caching wouldn't be that bad... However, sending all the required information in message itself is clearly the best solution to this problem. I think the best way to deal with the performance issue here is the stuff discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=963620 i.e. just have the kernel augment our messages with the data we need, unconditionally. That way we fix both the race issue, and the performance issue, since the data is just there and we can make use of it without any further work. Thanks a lot for this link! Having this issue sorted out will allow me to take closer look into eliminating 64-bit divisions in message receive path. ARM doesn't support divide operation so every div[1] is being done purely in software. [1] Every div/% by non-constant value and every div/% by 64-bit constant results in call to (slow) __aeabi_div*. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Has systemd booted up command
On Thu, Jul 18, 2013 at 7:06 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 18.07.13 10:08, Umut Tezduyar (u...@tezduyar.com) wrote:
Hi,
This is in reference to
https://bugs.freedesktop.org/show_bug.cgi?id=66926 request.
I have been polling systemd with systemctl is-active default.target
to detect if boot up has been completed or not. I have noticed that
this is not enough though.
It seems like starting a service that is not part of the initial job
tree can keep in state activating after default.target is reached. I
could use systemctl list-jobs to detect if there are still jobs
available but systemctl list-jobs's output is not meant for
programming.
Same problem happens when I switch targets. Currently I rely on
systemctl list-jobs output to detect if the target switch has been
completed or not.
What can we do about it?
One way would be having a command systemctl job-count, other would
be having a command systemctl has-booted or something similar?
Any thoughts?
systemctl job-count is available in systemctl show -p NJobs. You can
query this property easily via D-Bus too.
It should be relatively easy to write a tool that waits for the boot to
complete, as we send out a StartupFinished signal in that case, and
systemctl show -p Progress will tell you as a fractional between 0 and
1 how far the boot completed so far. However, the problem I have with
adding this is the weak definition of finished start-up. For example,
StartupFinished is actually sent out as soon as the job queue ran empty
for the first time (i.e. NJobs is 0). But you already want something
slightly different there, and also wait for some later jobs? And of
course, such a concept still wouldn't include desktop initialization times and
suchlike, so I am not totally convinced we could find an approach that
is sufficientlly well-defined that it works for most people, not just
some. If you follow what I mean...
Lennart
--
Lennart Poettering - Red Hat, Inc.
Hi,
Implementing a tool that catches the dbus signal, like you have said
must be relatively easy. In fact I believe it should be possible to do
it by dbus-monitor but the main problem is, tool itself must be
started by systemd as a service with a Before={target you are booting
to}. Otherwise you cannot be sure if the StartupFinished signal has
been sent before the tool starts.
To begin with, I see the need of having a command that outputs OK or
Not OK depending on StartupFinished sent or not. Like you said though,
there is a way to do it as systemctl is-active default.target
systemctl shop -pNJobs | grep -q Njobs=0. Why would I want to know
this? Because, I would like to start a test suite on my device as soon
as the device reaches to a complete state. Or, I would like to gather
statistics on the complete state. I do believe that this must be a
common use case.
The other need is coming due to an item in our TODO list which is,
when isolating, try to figure out a way how we implicitly can order
all units we stop before the isolating unit Since the stop jobs
are asynchronous, I would be using following command to make sure that
isolation is fully complete: systemctl is-active MyIsolated.target
systemctl show -pNJobs | grep -q Njobs=0. I do believe, this might
not be a common use case and I can live with parsing the output of
systemctl show -pNJobs.
Thanks,
Umut
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] RFC: journald: Allow to cache the cg_get_root_path
On Thu, Jul 18, 2013 at 08:32:18PM +0200, Karol Lewandowski wrote: Agreed, this is why I have been naively thinking that caching wouldn't be that bad... However, sending all the required information in message itself is clearly the best solution to this problem. It is nice to avoid the race for sure but unless I am not using perf record/top correctly or perf itself is broken on ARM, the bottleneck is really not the opening of files. For me glibc's _int_malloc remains at the top. So even if we skip a log of reading of files the journald will still create strings for KEY=VALUE. So maybe we could put key/val separtaely into the iovec array and avoid the extra strdup and then in the journal-file we can avoid the memchr for '='? Anyway I have not looked at journal-file.c much yet... holger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] What is a criterion to differentiate sysinit.target from basic.target?
On Thu, Jul 18, 2013 at 07:54:37PM +0900, Tony Seo wrote: Hello. I'm Tonyseo in south of Korea. As I'm a new stater, I try to study systemd. When I had studied bootup procedue in systemd, I found that there are two important targets which are sysinit.target and basic.target. I wonder why developer of bootup process made it divided into two stage. This way units which are starter for basic.target can depend on everything provided by sysinit.target. Zbyszek -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] What is a criterion to differentiate sysinit.target from basic.target?
On Thu, 18.07.13 21:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jul 18, 2013 at 07:54:37PM +0900, Tony Seo wrote: Hello. I'm Tonyseo in south of Korea. As I'm a new stater, I try to study systemd. When I had studied bootup procedue in systemd, I found that there are two important targets which are sysinit.target and basic.target. I wonder why developer of bootup process made it divided into two stage. This way units which are started for basic.target can depend on everything provided by sysinit.target. This is nicely explained by the charts in this man page: http://www.freedesktop.org/software/systemd/man/bootup.html 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] Has systemd booted up command
-Original Message- From: systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org [mailto:systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org] On Behalf Of Umut Tezduyar Sent: Thursday, July 18, 2013 8:38 PM To: Lennart Poettering Cc: Mailing-List systemd Subject: Re: [systemd-devel] Has systemd booted up command On Thu, Jul 18, 2013 at 7:06 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 18.07.13 10:08, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, This is in reference to https://bugs.freedesktop.org/show_bug.cgi?id=66926 request. I have been polling systemd with systemctl is-active default.target to detect if boot up has been completed or not. I have noticed that this is not enough though. It seems like starting a service that is not part of the initial job tree can keep in state activating after default.target is reached. I could use systemctl list-jobs to detect if there are still jobs available but systemctl list-jobs's output is not meant for programming. Same problem happens when I switch targets. Currently I rely on systemctl list-jobs output to detect if the target switch has been completed or not. What can we do about it? Why not simply writing a unit notify_default_target_done.service that - is linked into multi-user.target.wants - and defines: After=default.target Should work to my understanding ... Cheers, Marko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
