[systemd-devel] Start and stop actions of device units
Hi. Would it be possible to bind something to the start and stop actions of a device unit ? I've got a device (a hard drive) that I can programmatically plug/unplug using commands such as echo '0 0 0' /sys/class/scsi_host/host1/ scan and echo 1 /sys/devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete. The goal is reducing noise. It would be nice to bind these commands in the device unit itself so that other units needing it can start it by themselves, etc. Thanks, Léo Gillot-Lamure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-readahead and often used applications
Hi as far as i understand systemd-readahead is catching what is loaded directly due boot and 10 seconds after, well that's fine but is there a possibility to feed it with additional applications? example of the real life here: * the machine get powered on in the morning * due this sitting in the kitchen with a coffee * after that login in KDE, plasma and kopete are started * finally Thunderbird and Firefox are started * mostly Eclipse is the next * the machine has 16 GB RAM it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start and stop actions of device units
'Twas brillig, and Léo Gillot-Lamure at 13/04/13 11:11 did gyre and gimble: Hi. Would it be possible to bind something to the start and stop actions of a device unit ? I've got a device (a hard drive) that I can programmatically plug/unplug using commands such as echo '0 0 0' /sys/class/scsi_host/host1/ scan and echo 1 /sys/devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete. The goal is reducing noise. It would be nice to bind these commands in the device unit itself so that other units needing it can start it by themselves, etc. So I think this should just be a matter of creating a .service unit with appropriate ExecStart/Stop directives and then add a BindTo= directive to bind it to the device. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start and stop actions of device units
On Sat, Apr 13, 2013 at 12:11 PM, Léo Gillot-Lamure leo.gil...@navaati.net wrote: Hi. Would it be possible to bind something to the start and stop actions of a device unit ? I've got a device (a hard drive) that I can programmatically plug/unplug using commands such as echo '0 0 0' /sys/class/scsi_host/host1/ scan and echo 1 /sys/devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete. The goal is reducing noise. It would be nice to bind these commands in the device unit itself so that other units needing it can start it by themselves, etc. Sounds like a job for udev rules, not systemd? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start and stop actions of device units
On Sat, Apr 13, 2013 at 12:30:33PM +0100, Colin Guthrie wrote: 'Twas brillig, and Léo Gillot-Lamure at 13/04/13 11:11 did gyre and gimble: Hi. Would it be possible to bind something to the start and stop actions of a device unit ? I've got a device (a hard drive) that I can programmatically plug/unplug using commands such as echo '0 0 0' /sys/class/scsi_host/host1/ scan and echo 1 /sys/devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete. The goal is reducing noise. It would be nice to bind these commands in the device unit itself so that other units needing it can start it by themselves, etc. So I think this should just be a matter of creating a .service unit with appropriate ExecStart/Stop directives and then add a BindTo= directive to bind it to the device. BindTo= would give the opposite ordering than the one required. I think that RequiredBy=...device, Before=device, StopWhenUnneeded=true (in the plug-unplug.unit) should give you what you need. It might make sense to make the plug-unplug.unit a template, so that you can enable it for a device by saying 'systemctl enable plug-unplug@...device.service'. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for initial state of NumLock
On Fri, 12.04.13 18:53, Stanislav Brabec (sbra...@suse.cz) wrote: Add support for setting of initial state of NumLock. Supported values are yes, no and bios (on x86 platforms). It sets NumLock in virtual consoles. If NumLock should be turned on, it also creates empty /run/numlock-on, which can be used e. g. for setting of X session default. This ports a feature that exists for a long time in SUSE to systemd. Humm, so this without doubt sounds like a useful feature, but I am pretty sure systemd is the wrong place to do this. To inherit the num lock state from the BIOS to kernel please fix this problem at the source, and fix the kernel to simply inherit the state. I am not sure we should add BIOS parsing code to systemd, this really sounds like a job for the kernel. And to inherit the num lock state from the kernel to X11, then please fix this problem at the source, too, and fix X11 to to simply inherit the state. I am pretty sure we shouldn't shadow flags which are maintained anyway in another file, if X11 could get the same data directly from the kernel. What I am open to do is adding a setting to override whatever is set in the BIOS from vconsole based on a configuration file. But the inheriting stuff between BIOS/vconsole/X11 that's what I am not OK with. 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] [RFCv5] Optionally save core dumps as plain files
Introduce configuration file: /etc/systemd/coredump.conf with configurable uid/gid parameters, optional backends to journal and files, per storage size limits Default filestorage choosed as /run/log/coredump or /var/log/coredump with next reason: 1. These files produced with systemd component 2. These files registered with journal --- Makefile-man.am | 1 + Makefile.am | 13 +- man/coredump.conf.xml| 142 ++ src/core/manager.c | 1 + src/journal/coredump-gperf.gperf | 22 ++ src/journal/coredump.c | 558 --- src/journal/coredump.conf| 15 ++ src/journal/coredump.h | 51 src/journal/journald-server.h| 2 +- 9 files changed, 706 insertions(+), 99 deletions(-) create mode 100644 man/coredump.conf.xml create mode 100644 src/journal/coredump-gperf.gperf create mode 100644 src/journal/coredump.conf create mode 100644 src/journal/coredump.h diff --git a/Makefile-man.am b/Makefile-man.am index 0e08eb5..d39a0e7 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -8,6 +8,7 @@ MANPAGES += \ man/hostname.5 \ man/journalctl.1 \ man/journald.conf.5 \ + man/coredump.conf.5 \ man/kernel-command-line.7 \ man/kernel-install.8 \ man/locale.conf.5 \ diff --git a/Makefile.am b/Makefile.am index ec81f53..771eb49 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2851,7 +2851,8 @@ nodist_systemunit_DATA += \ units/systemd-journal-flush.service dist_pkgsysconf_DATA += \ - src/journal/journald.conf + src/journal/journald.conf \ + src/journal/coredump.conf pkgconfiglib_DATA += \ src/journal/libsystemd-journal.pc @@ -2870,10 +2871,12 @@ EXTRA_DIST += \ src/journal/libsystemd-journal.sym \ units/systemd-journald.service.in \ units/systemd-journal-flush.service.in \ - src/journal/journald-gperf.gperf + src/journal/journald-gperf.gperf \ + src/journal/coredump-gperf.gperf CLEANFILES += \ - src/journal/journald-gperf.c + src/journal/journald-gperf.c \ + src/journal/coredump-gperf.c # -- if HAVE_MICROHTTPD @@ -2918,10 +2921,12 @@ EXTRA_DIST += \ # -- if ENABLE_COREDUMP systemd_coredump_SOURCES = \ - src/journal/coredump.c + src/journal/coredump.c \ + src/journal/coredump-gperf.c systemd_coredump_LDADD = \ libsystemd-journal-internal.la \ + libsystemd-id128-internal.la \ libsystemd-label.la \ libsystemd-shared.la diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml new file mode 100644 index 000..8ab92c1 --- /dev/null +++ b/man/coredump.conf.xml @@ -0,0 +1,142 @@ +?xml version='1.0'? !--*-nxml-*-- +?xml-stylesheet type=text/xsl href=http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl;? +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; + +!-- + This file is part of systemd. + + Copyright 2013 Lennart Poettering + Oleksii Shevchuk + + systemd is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or + (at your option) any later version. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with systemd; If not, see http://www.gnu.org/licenses/. +-- + +refentry id=coredump.conf +refentryinfo +titlecoredump.conf/title +productnamesystemd/productname + +authorgroup +author +contribDeveloper/contrib +firstnameLennart/firstname +surnamePoettering/surname +emaillenn...@poettering.net/email +/author +author +contribDeveloper/contrib +firstnameOleksii/firstname +surnameShevchuk/surname +emailalx...@gmail.com/email +/author +/authorgroup +/refentryinfo + +refmeta +refentrytitlecoredump.conf/refentrytitle +manvolnum5/manvolnum +/refmeta + +refnamediv +refnamecoredump.conf/refname +
Re: [systemd-devel] systemd-readahead and often used applications
On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote: Hi as far as i understand systemd-readahead is catching what is loaded directly due boot and 10 seconds after, well that's fine but is there a possibility to feed it with additional applications? example of the real life here: * the machine get powered on in the morning * due this sitting in the kitchen with a coffee * after that login in KDE, plasma and kopete are started * finally Thunderbird and Firefox are started * mostly Eclipse is the next * the machine has 16 GB RAM it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login A lot of things are possible and would help this: - change your system to auto-logon your account and start the applications for you. This is possible without any coding. - do per-user readahead, so that when a user logs in readahead-collect runs again but with a different pack, stored in the users home folder. Most of this should be possible with little work, but you'd have to write some xdg autostart files and possibly patch the readahead - extend the collector to run much longer - manually create a pack and disable the collector one of the problems is that it's hard to create something that generally works well for all situations, and autologon+lock desktop benefits from simplicity since readahead catches almost all of it. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
Am 13.04.2013 23:08, schrieb Kok: On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote: it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login A lot of things are possible and would help this: - change your system to auto-logon your account and start the applications for you. This is possible without any coding. well, that's a no-go - do per-user readahead, so that when a user logs in readahead-collect runs again but with a different pack, stored in the users home folder. Most of this should be possible with little work, but you'd have to write some xdg autostart files and possibly patch the readahead - extend the collector to run much longer which scre to change in teh config? - manually create a pack and disable the collector one of the problems is that it's hard to create something that generally works well for all situations, and autologon+lock desktop benefits from simplicity since readahead catches almost all of it my idea is not any generic and collecting thing it is more that have a config file where the professional user can manually add application paths which are caught by systemd-readahead P.S.: yes i know about preload but since systemd assimilates mayn things in the past few years including readahead i feel this would be the right direction to make systemd-readahead complete and sadly i am a webdeveloper and can not provide code/patches :-( signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python journal reader
On 13/04/13 23:00, David Strauss wrote:
If seems like we should put the conditional special handling for
__REALTIME_TIMESTAMP and __MONOTONIC_TIMESTAMP in either _reader.c or
right in get().
Here's why:
* With the code above, calling Reader.get('__REALTIME_TIMESTAMP')
results in the wrong type (if anything, I'd need to check), but
Reader.get_realtime() gives the right thing.
* The type of Reader.get('__REALTIME_TIMESTAMP') is different from
Reader.get_next()['__REALTIME_TIMESTAMP'], and it should be
equivalent.
Good point. Currently, `get` for realtime, monotonic or cursor do not
return anything, but raise an exception (invalid field). Given the plan
to keep things in `_Reader` close to the C API, I'd suggest adding the
handling within the `Reader.get`. Suggestion merged below:
```
diff --git a/src/python-systemd/journal.py b/src/python-systemd/journal.py
index 48f57ac..d0ca32b 100644
--- a/src/python-systemd/journal.py
+++ b/src/python-systemd/journal.py
@@ -189,6 +189,28 @@ class Reader(_Reader):
for arg in args:
super(Reader, self).add_match(arg)
+def get(self, key):
+if key == __REALTIME_TIMESTAMP:
+return self.get_realtime()
+elif key == __MONOTONIC_TIMESTAMP:
+return self.get_monotonic()
+elif key == __CURSOR:
+return self.get_cursor()
+else:
+return self._convert_field(key, super(Reader, self).get(key))
+
+def get_realtime(self):
+return self._convert_field(
+'__REALTIME_TIMESTAMP', super(Reader, self).get_realtime())
+
+def get_monotonic(self):
+return self._convert_field(
+'__MONOTONIC_TIMESTAMP', super(Reader, self).get_monotonic())
+
+def get_cursor(self):
+return self._convert_field(
+'__CURSOR', super(Reader, self).get_cursor())
+
def get_next(self, skip=1):
Return the next log entry as a dictionary of fields.
@@ -197,8 +219,13 @@ class Reader(_Reader):
Entries will be processed with converters specified during
Reader creation.
-return self._convert_entry(
+entry = self._convert_entry(
super(Reader, self).get_next(skip))
+entry['__REALTIME_TIMESTAMP'] = self.get_realtime()
+entry['__MONOTONIC_TIMESTAMP'] = self.get_monotonic()
+entry['__CURSOR'] = self.get_cursor()
+
+return entry
def query_unique(self, field):
Return unique values appearing in the journal for given
`field`.
```
On Fri, Apr 12, 2013 at 10:13 AM, Steven Hiscocks
steven-syst...@hiscocks.me.uk wrote:
Hi,
In the python journal Reader, the splitting out of monotonic and realtime
stamps, has affected `get_next` function as timestamp values are no longer
present in the dictionary returned. Also the new `get_monotonic` and
`get_realtime` functions are not run through the converters. Equally, the
'get' method added is not run through the converters. I also noted the
additional `next` method doesn't work on python2, as it clashes with the
iter `next` method (python3 not affected as it changes iter method to
`__next__`)
My suggestion with the python Reader `get_next` method is that the realtime
and monotonic timestamps remain part of it, as these are key parts of a log
entry, and two more lines in everyone's code to get them seems cumbersome.
Equally also the cursor value. This also makes the output fields the same as
the journalctl json format. (I agree it makes sense the _Reader object
element to remain separate so close to actual C API).
I'm not sure what the best approach to the `next` method issue is…
Proposed changes below. I've add `get_cursor` to go through converters for
consistency, even if not required currently.
```
```
Thanks
--
Steven Hiscocks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Steven Hiscocks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python journal reader
On 13/04/13 23:47, Steven Hiscocks wrote:
On 13/04/13 23:00, David Strauss wrote:
If seems like we should put the conditional special handling for
__REALTIME_TIMESTAMP and __MONOTONIC_TIMESTAMP in either _reader.c or
right in get().
Here's why:
* With the code above, calling Reader.get('__REALTIME_TIMESTAMP')
results in the wrong type (if anything, I'd need to check), but
Reader.get_realtime() gives the right thing.
* The type of Reader.get('__REALTIME_TIMESTAMP') is different from
Reader.get_next()['__REALTIME_TIMESTAMP'], and it should be
equivalent.
Good point. Currently, `get` for realtime, monotonic or cursor do not
return anything, but raise an exception (invalid field). Given the plan
to keep things in `_Reader` close to the C API, I'd suggest adding the
handling within the `Reader.get`. Suggestion merged below:
```
```
On Fri, Apr 12, 2013 at 10:13 AM, Steven Hiscocks
steven-syst...@hiscocks.me.uk wrote:
Hi,
In the python journal Reader, the splitting out of monotonic and
realtime
stamps, has affected `get_next` function as timestamp values are no
longer
present in the dictionary returned. Also the new `get_monotonic` and
`get_realtime` functions are not run through the converters. Equally,
the
'get' method added is not run through the converters. I also noted the
additional `next` method doesn't work on python2, as it clashes with the
iter `next` method (python3 not affected as it changes iter method to
`__next__`)
My suggestion with the python Reader `get_next` method is that the
realtime
and monotonic timestamps remain part of it, as these are key parts of
a log
entry, and two more lines in everyone's code to get them seems
cumbersome.
Equally also the cursor value. This also makes the output fields the
same as
the journalctl json format. (I agree it makes sense the _Reader object
element to remain separate so close to actual C API).
I'm not sure what the best approach to the `next` method issue is…
Proposed changes below. I've add `get_cursor` to go through
converters for
consistency, even if not required currently.
```
```
Thanks
--
Steven Hiscocks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Just noticed an unintended effect if _Reader.get_next returns empty
dictionary. Fixed:
```
diff --git a/src/python-systemd/journal.py b/src/python-systemd/journal.py
index 48f57ac..281d7c3 100644
--- a/src/python-systemd/journal.py
+++ b/src/python-systemd/journal.py
@@ -189,6 +189,28 @@ class Reader(_Reader):
for arg in args:
super(Reader, self).add_match(arg)
+def get(self, key):
+if key == __REALTIME_TIMESTAMP:
+return self.get_realtime()
+elif key == __MONOTONIC_TIMESTAMP:
+return self.get_monotonic()
+elif key == __CURSOR:
+return self.get_cursor()
+else:
+return self._convert_field(key, super(Reader, self).get(key))
+
+def get_realtime(self):
+return self._convert_field(
+'__REALTIME_TIMESTAMP', super(Reader, self).get_realtime())
+
+def get_monotonic(self):
+return self._convert_field(
+'__MONOTONIC_TIMESTAMP', super(Reader, self).get_monotonic())
+
+def get_cursor(self):
+return self._convert_field(
+'__CURSOR', super(Reader, self).get_cursor())
+
def get_next(self, skip=1):
Return the next log entry as a dictionary of fields.
@@ -197,8 +219,14 @@ class Reader(_Reader):
Entries will be processed with converters specified during
Reader creation.
-return self._convert_entry(
+entry = self._convert_entry(
super(Reader, self).get_next(skip))
+if entry:
+entry['__REALTIME_TIMESTAMP'] = self.get_realtime()
+entry['__MONOTONIC_TIMESTAMP'] = self.get_monotonic()
+entry['__CURSOR'] = self.get_cursor()
+
+return entry
def query_unique(self, field):
Return unique values appearing in the journal for given
`field`.
```
--
Steven Hiscocks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python journal reader
I keep writing lengthy emails about how we can use this as an
opportunity to reduce redundancy and improve consistency, but I should
probably ping you on #systemd IRC to hash it out. I can't think of
anything elegant that doesn't involve altering the existing journal.py
or _reader.c code.
What's your handle? Mine's davidstrauss.
As a starter, I want to enumerate the places where
__REALTIME_TIMESTAMP has special handling:
(1) Existing code: A C-based member function in _reader.c.
(2) Existing code: A native Python conversion function in journal.py.
(3) Existing code: An entry in DEFAULT_CONVERTERS.
(4) Added in your patch: A key setting in get_next().
(5) Added in your patch: A Python-based member function in journal.py
that overrides (1).
(6) Added in your patch: A condition in get() that invokes (1) when
the specific field is requested.
While I want to fix this bug, I also don't want six scattered special
cases for __REALTIME_TIMESTAMP and similar fields.
On Sat, Apr 13, 2013 at 4:18 PM, Steven Hiscocks
steven-syst...@hiscocks.me.uk wrote:
On 13/04/13 23:47, Steven Hiscocks wrote:
On 13/04/13 23:00, David Strauss wrote:
If seems like we should put the conditional special handling for
__REALTIME_TIMESTAMP and __MONOTONIC_TIMESTAMP in either _reader.c or
right in get().
Here's why:
* With the code above, calling Reader.get('__REALTIME_TIMESTAMP')
results in the wrong type (if anything, I'd need to check), but
Reader.get_realtime() gives the right thing.
* The type of Reader.get('__REALTIME_TIMESTAMP') is different from
Reader.get_next()['__REALTIME_TIMESTAMP'], and it should be
equivalent.
Good point. Currently, `get` for realtime, monotonic or cursor do not
return anything, but raise an exception (invalid field). Given the plan
to keep things in `_Reader` close to the C API, I'd suggest adding the
handling within the `Reader.get`. Suggestion merged below:
```
```
On Fri, Apr 12, 2013 at 10:13 AM, Steven Hiscocks
steven-syst...@hiscocks.me.uk wrote:
Hi,
In the python journal Reader, the splitting out of monotonic and
realtime
stamps, has affected `get_next` function as timestamp values are no
longer
present in the dictionary returned. Also the new `get_monotonic` and
`get_realtime` functions are not run through the converters. Equally,
the
'get' method added is not run through the converters. I also noted the
additional `next` method doesn't work on python2, as it clashes with the
iter `next` method (python3 not affected as it changes iter method to
`__next__`)
My suggestion with the python Reader `get_next` method is that the
realtime
and monotonic timestamps remain part of it, as these are key parts of
a log
entry, and two more lines in everyone's code to get them seems
cumbersome.
Equally also the cursor value. This also makes the output fields the
same as
the journalctl json format. (I agree it makes sense the _Reader object
element to remain separate so close to actual C API).
I'm not sure what the best approach to the `next` method issue is…
Proposed changes below. I've add `get_cursor` to go through
converters for
consistency, even if not required currently.
```
```
Thanks
--
Steven Hiscocks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Just noticed an unintended effect if _Reader.get_next returns empty
dictionary. Fixed:
```
diff --git a/src/python-systemd/journal.py b/src/python-systemd/journal.py
index 48f57ac..281d7c3 100644
--- a/src/python-systemd/journal.py
+++ b/src/python-systemd/journal.py
@@ -189,6 +189,28 @@ class Reader(_Reader):
for arg in args:
super(Reader, self).add_match(arg)
+def get(self, key):
+if key == __REALTIME_TIMESTAMP:
+return self.get_realtime()
+elif key == __MONOTONIC_TIMESTAMP:
+return self.get_monotonic()
+elif key == __CURSOR:
+return self.get_cursor()
+else:
+return self._convert_field(key, super(Reader, self).get(key))
+
+def get_realtime(self):
+return self._convert_field(
+'__REALTIME_TIMESTAMP', super(Reader, self).get_realtime())
+
+def get_monotonic(self):
+return self._convert_field(
+'__MONOTONIC_TIMESTAMP', super(Reader, self).get_monotonic())
+
+def get_cursor(self):
+return self._convert_field(
+'__CURSOR', super(Reader, self).get_cursor())
+
def get_next(self, skip=1):
Return the next log entry as a dictionary of fields.
@@ -197,8 +219,14 @@ class Reader(_Reader):
Entries will be processed with converters specified during
Reader creation.
-return self._convert_entry(
+entry = self._convert_entry(
super(Reader, self).get_next(skip))
+if entry:
Re: [systemd-devel] systemd-readahead and often used applications
On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.04.2013 23:08, schrieb Kok: On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote: it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login A lot of things are possible and would help this: - change your system to auto-logon your account and start the applications for you. This is possible without any coding. well, that's a no-go - do per-user readahead, so that when a user logs in readahead-collect runs again but with a different pack, stored in the users home folder. Most of this should be possible with little work, but you'd have to write some xdg autostart files and possibly patch the readahead - extend the collector to run much longer which scre to change in teh config? You can modify systemd-readahead-done.timer, basically change: OnActiveSec=10s to whatever value you like. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
