Re: [systemd-devel] A way to better integrate rsyslog into systemd?
On 10/04/2014 05:55 AM, Aleksei Besogonov wrote:
With all the recent noise about systemd abusing its position with the
way it takes over logging I’ve been thinking about a way to solve it.
As far as I understand the following holds:
- Systemd takes over /dev/log socket which is normally served by
rsyslog (or other syslog daemon).
- That’s really required to make journald-based logging transparent
and coherent for most use-cases.
However, it creates a problem for log-heavy applications, because of
additional roundtrips between processes. So far I’ve heard people
actually using LD_PRELOAD tricks to hack around applications opening
the /dev/log file inside the syslog(2). As far as I understand, it’s
also not really configurable - the '/dev/log’ string is hardcoded into
various libcs (e.g.:
http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent
versions of rsyslog can directly read journald files. But that’s still
suboptimal solution, because it introduces an unnecessary layer.
Namespacing each daemon to provide its own /dev tree with custom
/dev/log sockets is possible, but impractical.
So I propose the following solution:
1) Add an option to systemd units to allow passing opened /dev/log
sockets to rsyslog (using the usual SOL_SOCKET mechanism).
2) Add the corresponding functionality to rsyslog. It should listen on
a special socket (perhaps /run/rsyslog/socket_server ?) and treat all
the incoming sockets as if they were accepted from /dev/log.
It would also solve the problems with rsyslog using its own
SCM_CREDENTIALS lookups.
Tying the solution to rsyslog or syslog-ng is not something that should
be done but rather fix the usability.
Based on what I have observed thus far people uses of sending journal
logs to centralized syslog server of any kind boils down to...
journalctl -o format -f | ncat protocolhostport
journalctl -o format -f | own written python tool/filter who then
sends the logs protocolhostport
As well as adding somekind of token in front of the log entries (
cloud/container specific ) as in
ncat --ssl --ssl-verify host port (awk -v token=token_here '{
print token, $0; fflush(); }' (journalctl -o short -f))
Embedded uses netconsole as in
systemd.log_target=kmsg
netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr]
So the solution which combines these common denominators thus should
eventually make everyone happy is integrate something like netconsole...
Then add following lines to journald.conf
ForwardToHost=yes
ForwardToHostIP=Destination IP
ForwardToHostPort=Destination Port
ForwardToHostFormat=short,json etc
ForwardToHostLogToken=insert token who get appended before each log
line here probably should default to machineid
If someone does provide patches that does just that or similar I think
this outspoken shortcoming of journal can be finally put to rest and
people be happy.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses
On Fri, 2014-10-03 at 10:04 -0500, Dan Williams wrote: sd_dhcp_client_set_mac() does have an 'arp_type' parameter that's cached in the client struct, so that could be changed to: if (client-arp_type == ARPHRD_ETHER) if you'd like. If it's there already, it is a good thing to use. It does look clearer in the code that way. Thanks, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add --utc option
On Thu, 02.10.14 12:51, Josh Triplett (j...@joshtriplett.org) wrote: On Thu, Oct 02, 2014 at 09:11:39PM +0200, Lennart Poettering wrote: On Thu, 02.10.14 11:56, Josh Triplett (j...@joshtriplett.org) wrote: On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote: Introduce option to display time in UTC. Does TZ=UTC journalctl not do the right thing? A quick test here suggests that it does. That seems preferable to teaching individual tools to special-case UTC. Not sure i agree. --utc really should only have an effect on our own output, and that's a good thing. If you set $TZ you end up changing much much more, for example the logic of glibc's own syslog() and what it passes on, and we shouldn't influence that. True, but in the case of journalctl, which just queries and outputs journal data, what would TZ=UTC affect that you *wouldn't* want? journalctl shouldn't be calling syslog(). Well, who knows what is ultimately called. I mean, we fork off a $PAGER, which can be almost anything. We call into libraries and whatnot. All I am saying is that I think there's great value to keeping this as local as possible, and have this only effect the log display we do and nothing else. And beyond that: an environment variable is in many ways awful API, and non-discoverable. A command line switch is a lot more discoverable, as everybody knows to look for them in --help and in man pages. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] dbus-manager: don't allow enabling if unit is masked
https://bugzilla.redhat.com/show_bug.cgi?id=1149069
---
src/core/dbus-manager.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 533ce43..c2d52b2 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1588,18 +1588,23 @@ static int method_enable_unit_files_generic(
if (r 0)
return r;
-#ifdef HAVE_SELINUX
STRV_FOREACH(i, l) {
Unit *u;
u = manager_get_unit(m, *i);
if (u) {
+#ifdef HAVE_SELINUX
r = selinux_unit_access_check(u, message, verb, error);
if (r 0)
return r;
+#endif
+if (u-load_state == UNIT_MASKED) {
+sd_bus_error_setf(error, BUS_ERROR_UNIT_MASKED,
+ Unit %s is masked., u-id);
+return -EADDRNOTAVAIL;
+}
}
}
-#endif
scope = m-running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM :
UNIT_FILE_USER;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats
On Fri, Oct 03, 2014 at 02:13:51AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Sep 22, 2014 at 04:33:28PM +0100, Daniel P. Berrange wrote:
The current '--output FORMAT' argument defines a number of
common output formats, but there are some useful cases it
does cover. In particular when reading application logs it
is often desirable to display the code file name, line number
and function name. Rather than defining yet more fixed output
formats, this patch introduces user defined output formats.
Hi,
I think this makes sense. But I think that the format strings you
propose are damn ugly :). Using %() for variables seems too heavy.
Also, journal fields are all text, so I don't think that specifying
the type is useful.
Well there are two virtual fields which are timestamps which the existing
hardcoded output modes convert into a date string in various ways. I want
the format strings we define here to be able to express the semantics of
the current hardcoded output modes, so this neccessitates a way to ask
for various date formats.
Also although the physically stored journal fields are strings per the
journal API storage backend, they can be simple string versions of
other data types. eg an application defined journal field could be used
to store an integer, floating point, boolean, etc. It would be natural
for the app to use many decimal places if storing a floating point value
in the journal, so being able to give data types in the output mode lets
us alter the precision displayed when extracting it again. Of course my
patch didn't try todo this, it only deal with dates.
Maybe we could adopt the {} format from Java and Python, as
implemented in Python [1]. It has a fairly rich and consistent field
formatting language. We would care only about the part relevant
to strings, at least in the beginning.
I'll see what I can cook up along these lines, but the existing python
language is focused on C data types and doesn't directly provide types
for the various date formats to support, so we can't use it 100% as-is.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Sun, 05.10.14 12:20, Martin Steigerwald (mar...@lichtvoll.de) wrote: However, I also believe that the change we are making is for the good, and even though it might not be obvious to many immediately, it brings major benefits when administering machines, and they massively outweigh the disadvantage of changing things. And apparently I am not entirely alone with this, as the folks who make technical decision for the various distributions ended up deciding in favour of systemd in most cases. Why do you believe so? What key points make you believe so? Believe what precisely? Why I believe systemd is better than sysvinit? Well, that's a big question, and I am pretty sure already well enough discussed elsewhere, that we really do't have to repeat this here. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. Well, we provide good APIs. We provide them for a reason, because applications benefit from them. App developers see that, so they adopt them. That's pretty natural and obvious, no? If you want to know more, about why they do that, then ask them. What I find so puzzling about certain aspects of the criticism is that some people apparently assume that logind and similar things were entirely redundant, and that the APIs that it provides were so redundant, that one could trivially write the same app, but not make use of them... This idea that logind had exactly no merits, and was little more than just an evil tool to drive systemd adoption... Dependencies like this actually create some force to adopt systemd. Well, I certainly don't force anybody. We provide APIs for technical reasons, and because we believe that people might benefit from them, even need them. And apparently I am not too wrong with that, after all they tend to adopt them... Now I know ConsoleKit isn´t developed anymore, but also I never got why a logind implementation needs to depend on systemd base package in such a way that at least in Debian systemd package has to be installed if someone wants to use GNOME. Well, logind talks to systemd to manage user sessions and user processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted. Our intention with systemd is to provide a strong platform. One platform. If people want to use our code in other contexts, then that's totally fine, but please understand that I am not going to do any work for that, I am not going to maintain it, and I don't want to see that in my code. Much of the feedback is related to that. Many would appreciate something like systemd if it just did *services* stuff. That is also what seemed to have motivated the dev behind the use less d fork. Well, I am sorry, but systemd is more than that. If systemd is no what people want, they can roll their own thing, can continue to use sysvinit, or even fork systemd, That's completely OK. But for what we have in mind for systemd it's definitely a goal to make Linux more attractive for developers, by providing a good set of core OS APIs that people can just make use of, instead of a zoo of things that are combined in wild combinations. The current increase noised level around systemd adoption I attribute to three things: the fact that RHEL7 is out now, the fact that due to the adoption of systemd as default by Debian and Ubuntu the folks who ignored the discussion so far now are faced with this change, and also to a big part to certain columnists who in the interest of generating traffic to their sites try to create a hubbub out of very little. Anyway, long story short: we knew what we did, and yeah, I read feedback, even if it is written in a hateful style, and we learn from it. Well, I for myself have been concerned and surprised by *such an mount* of uproar. Not even GNOME 3 triggered anywhere near that amount of threads and mails. Well, I am not sure this is really that way. GNOME 3 noise was pretty bad too, maybe you just weren't involved so closely... But even if it wasn't, our stuff touches most of the Linux community, which is larger than the GNOME community. And I worry regarding various attempts to replace systemd functionality (by systembsd services) and by use less d or using different inits. I think quite some of them are based on solid technical arguments. I wonder whether systemd might be missing out on something here. Well, some competition would be great. I am pretty sure that uselessd is not based on solid technical arguments though, and pretty sure it's maintainer will figure that out pretty soon too... Anyway, more power to him, at least he
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote: systemd does a lot. And an 1,3 MiB binary is a hug binary size for something that started out as managing services and sessions via control cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) This is an interesting question, where this 1.3 MB comes from. objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail 0a13 service_deserialize_item -- .text 0a6e cgroup_context_apply -- .text 0ae2 socket_apply_socket_options -- .text 0b00 rtnl_types -- .data.rel.ro.local 0b32 exec_context_dump -- .text 0d50 bus_exec_vtable -- .data.rel.ro 0d62 transaction_add_job_and_dependencies -- .text 0e40 bus_unit_vtable -- .data.rel.ro 11d7 bus_cgroup_set_property -- .text 1410 bus_manager_vtable -- .data.rel.ro 1453 exec_child -- .text 1470 wordlist.7848 -- .data.rel.ro.local 2b90 main -- .text e1c0 wordlist.14097 -- .data.rel.ro wordlist.14097 is a generated table for all configuration options in load-fragment-gperf.c. wordlist.7848 is for errno_from_name (5k for this is a bit of a stretch though). There's pretty complex code (main is 11k), combined with a large number of configuration and reporting code (the wordlists, vtables, exec_context_dump). This shows that splitting the binary into two would not be really effective: this code would essentially have to be duplicated, once for communication between PID 1 and the helper, and second time for communication between the helpers and the rest, i.e. the existing code. -- I think this hasn't been mentioned in this thread, but PID1 is shrinking at least a bit, because a bunch of things which used to be implemented in PID1 have been outsourced to generators. ./systemd-sysv-generator, ./systemd-fstab-generator are relatively recent and significant. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote: systemd does a lot. And an 1,3 MiB binary is a hug binary size for something that started out as managing services and sessions via control cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) This is an interesting question, where this 1.3 MB comes from. objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail 0a13 service_deserialize_item -- .text 0a6e cgroup_context_apply -- .text 0ae2 socket_apply_socket_options -- .text 0b00 rtnl_types -- .data.rel.ro.local 0b32 exec_context_dump -- .text 0d50 bus_exec_vtable -- .data.rel.ro 0d62 transaction_add_job_and_dependencies -- .text 0e40 bus_unit_vtable -- .data.rel.ro 11d7 bus_cgroup_set_property -- .text 1410 bus_manager_vtable -- .data.rel.ro 1453 exec_child -- .text 1470 wordlist.7848 -- .data.rel.ro.local 2b90 main -- .text e1c0 wordlist.14097 -- .data.rel.ro wordlist.14097 is a generated table for all configuration options in load-fragment-gperf.c. wordlist.7848 is for errno_from_name (5k for this is a bit of a stretch though). I wonder if any of these tables might have holes in them? i.e. some enums skip a few numbers in the middle, and are thus not really appropriate for the usual DEFINE_STRING_TABLE() stuff we do? I think this hasn't been mentioned in this thread, but PID1 is shrinking at least a bit, because a bunch of things which used to be implemented in PID1 have been outsourced to generators. ./systemd-sysv-generator, ./systemd-fstab-generator are relatively recent and significant. And I'd be willing to split out more, but I am not sure currently what could be a good candidate. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 06, 2014 at 05:14:17PM +0200, Lennart Poettering wrote: On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote: systemd does a lot. And an 1,3 MiB binary is a hug binary size for something that started out as managing services and sessions via control cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) This is an interesting question, where this 1.3 MB comes from. objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail 0a13 service_deserialize_item -- .text 0a6e cgroup_context_apply -- .text 0ae2 socket_apply_socket_options -- .text 0b00 rtnl_types -- .data.rel.ro.local 0b32 exec_context_dump -- .text 0d50 bus_exec_vtable -- .data.rel.ro 0d62 transaction_add_job_and_dependencies -- .text 0e40 bus_unit_vtable -- .data.rel.ro 11d7 bus_cgroup_set_property -- .text 1410 bus_manager_vtable -- .data.rel.ro 1453 exec_child -- .text 1470 wordlist.7848 -- .data.rel.ro.local 2b90 main -- .text e1c0 wordlist.14097 -- .data.rel.ro wordlist.14097 is a generated table for all configuration options in load-fragment-gperf.c. wordlist.7848 is for errno_from_name (5k for this is a bit of a stretch though). I wonder if any of these tables might have holes in them? i.e. some enums skip a few numbers in the middle, and are thus not really appropriate for the usual DEFINE_STRING_TABLE() stuff we do? I think it's like a hash table, i.e. approx %50 empty on purpose. At least in case load load-fragment-gperf, we are trading a bit of space for speed in an important code path, so I'm sure it is worth it. The errno stuff isn't probably that important, because iiuc we won't even load this page until it is used, so again, this seems fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dbus-manager: don't allow enabling if unit is masked
On Mon, 06.10.14 13:21, Jan Synacek (jsyna...@redhat.com) wrote:
Hmm with this change in place we'd have different behaviour for the
cases where systemctl executes the operation client-side, and when it
goes via the bus. We really should keep those differences in behaviour
to a minimum.
I figure the verification for this really needs to be moved a few
levels down, somewhere into unit_file_enable() and friends, so that
all code paths behave the same.
https://bugzilla.redhat.com/show_bug.cgi?id=1149069
---
src/core/dbus-manager.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 533ce43..c2d52b2 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1588,18 +1588,23 @@ static int method_enable_unit_files_generic(
if (r 0)
return r;
-#ifdef HAVE_SELINUX
STRV_FOREACH(i, l) {
Unit *u;
u = manager_get_unit(m, *i);
if (u) {
+#ifdef HAVE_SELINUX
r = selinux_unit_access_check(u, message, verb,
error);
if (r 0)
return r;
+#endif
+if (u-load_state == UNIT_MASKED) {
+sd_bus_error_setf(error,
BUS_ERROR_UNIT_MASKED,
+ Unit %s is masked.,
u-id);
+return -EADDRNOTAVAIL;
+}
}
}
-#endif
scope = m-running_as == SYSTEMD_SYSTEM ? UNIT_FILE_SYSTEM :
UNIT_FILE_USER;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] variable expansion in ExecStart
On Sat, 04.10.14 21:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
Hi,
Environment=X='Y' Z
ExecStart=/bin/echo $X ${X}
results in echo[31266]: Y Z 'Y' Z
i.e., $X not only splits at whitespace, as documented, but also strips quotes.
Is this by design, or is it an implementation accident? Should this behaviour
be changed?
Well, I wouldn't claim it was by design, but I think it actually
*does* make some sense the way it is. Might need documentation though...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A way to better integrate rsyslog into systemd?
On Sun, 05.10.14 14:54, Aleksei Besogonov (alex.besogo...@gmail.com) wrote: On 05 Oct 2014, at 11:02, Andrei Borzenkov arvidj...@gmail.com wrote: В Fri, 3 Oct 2014 22:55:13 -0700 Aleksei Besogonov alex.besogo...@gmail.com пишет: With all the recent noise about systemd abusing its position with the way it takes over logging I’ve been thinking about a way to solve it. As far as I understand the following holds: - Systemd takes over /dev/log socket which is normally served by rsyslog (or other syslog daemon). - That’s really required to make journald-based logging transparent and coherent for most use-cases. However, it creates a problem for log-heavy applications, because of additional roundtrips between processes. So far I’ve heard people actually using LD_PRELOAD tricks to hack around applications opening the /dev/log file inside the syslog(2). As far as I understand, it’s also not really configurable - the '/dev/log’ string is hardcoded into various libcs (e.g.: http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent versions of rsyslog can directly read journald files. But that’s still suboptimal solution, because it introduces an unnecessary layer. Namespacing each daemon to provide its own /dev tree with custom /dev/log sockets is possible, but impractical. So I propose the following solution: 1) Add an option to systemd units to allow passing opened /dev/log sockets to rsyslog (using the usual SOL_SOCKET mechanism). This will make syslog compete with journald for /dev/log, no? So either one will miss some messages? No, it won’t. Systemd owns the /dev/log socket and accepts connections to it as usual. However, if a ForwardLogSocket=/path option is set for a certain service then systemd connects to this socket and sends the client connection over it. There aer no client connections for syslog really. It's an AF_UNIX/SOCK_DGRAM socket, i.e. connection-less. While in theory there's a connection-ful mode, it's not really that great a choice (and we don't support it in systemd) since it loses global ordering of log messages, for zero benefit. There can only be one process reading off the socket. It's either journald or rsyslog. It cannot be both. If both listen and read of it, it's essential random which process gets a message, and the other one will not see it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values
*bump*
On 2014-09-06 10:36, Jan Janssen wrote:
sd_journal_enumerate_unique will lock its mmap window to prevent it
from being released by calling mmap_cache_get with keep_always=true.
This call may return windows that are wider, but compatible with the
parameters provided to it.
This can result in a mismatch where the window to be released cannot
properly be selected, because we have more than one window matching the
parameters of mmap_cache_release. Therefore, introduce a release_cookie
to be used when releasing the window.
https://bugs.freedesktop.org/show_bug.cgi?id=79380
---
src/journal/journal-file.c| 2 +-
src/journal/journal-file.h| 11 ---
src/journal/journal-verify.c | 2 +-
src/journal/mmap-cache.c | 32 +++-
src/journal/mmap-cache.h | 8 +++-
src/journal/sd-journal.c | 11 ++-
src/journal/test-mmap-cache.c | 10 +-
7 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 7286e14..0ed51ed 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -391,7 +391,7 @@ static int journal_file_move_to(JournalFile *f, int
context, bool keep_always, u
return -EADDRNOTAVAIL;
}
-return mmap_cache_get(f-mmap, f-fd, f-prot, context, keep_always, offset,
size, f-last_stat, ret);
+return mmap_cache_get(f-mmap, f-fd, f-prot, context, keep_always, offset,
size, f-last_stat, ret, NULL);
}
static uint64_t minimum_header_size(Object *o) {
diff --git a/src/journal/journal-file.h b/src/journal/journal-file.h
index da2ef3b..da1b793 100644
--- a/src/journal/journal-file.h
+++ b/src/journal/journal-file.h
@@ -212,17 +212,14 @@ static unsigned type_to_context(int type) {
return type 0 type _OBJECT_TYPE_MAX ? type : 0;
}
-static inline int journal_file_object_keep(JournalFile *f, Object *o, uint64_t
offset) {
+static inline int journal_file_object_keep(JournalFile *f, Object *o, uint64_t
offset, void **release_cookie) {
unsigned context = type_to_context(o-object.type);
uint64_t s = le64toh(o-object.size);
return mmap_cache_get(f-mmap, f-fd, f-prot, context, true,
- offset, s, f-last_stat, NULL);
+ offset, s, f-last_stat, NULL, release_cookie);
}
-static inline int journal_file_object_release(JournalFile *f, Object *o,
uint64_t offset) {
-unsigned context = type_to_context(o-object.type);
-uint64_t s = le64toh(o-object.size);
-
-return mmap_cache_release(f-mmap, f-fd, f-prot, context, offset, s);
+static inline int journal_file_object_release(JournalFile *f, void
*release_cookie) {
+return mmap_cache_release(f-mmap, f-fd, release_cookie);
}
diff --git a/src/journal/journal-verify.c b/src/journal/journal-verify.c
index 6c8ca8c..a1c34ac 100644
--- a/src/journal/journal-verify.c
+++ b/src/journal/journal-verify.c
@@ -368,7 +368,7 @@ static int contains_uint64(MMapCache *m, int fd, uint64_t
n, uint64_t p) {
c = (a + b) / 2;
-r = mmap_cache_get(m, fd, PROT_READ|PROT_WRITE, 0, false, c *
sizeof(uint64_t), sizeof(uint64_t), NULL, (void **) z);
+r = mmap_cache_get(m, fd, PROT_READ|PROT_WRITE, 0, false, c *
sizeof(uint64_t), sizeof(uint64_t), NULL, (void **) z, NULL);
if (r 0)
return r;
diff --git a/src/journal/mmap-cache.c b/src/journal/mmap-cache.c
index 7dbbb5e..64bc8da 100644
--- a/src/journal/mmap-cache.c
+++ b/src/journal/mmap-cache.c
@@ -352,7 +352,8 @@ static int try_context(
bool keep_always,
uint64_t offset,
size_t size,
-void **ret) {
+void **ret,
+void **release_cookie) {
Context *c;
@@ -381,6 +382,8 @@ static int try_context(
if (ret)
*ret = (uint8_t*) c-window-ptr + (offset -
c-window-offset);
+if (keep_always release_cookie)
+*release_cookie = c-window;
return 1;
}
@@ -392,7 +395,8 @@ static int find_mmap(
bool keep_always,
uint64_t offset,
size_t size,
-void **ret) {
+void **ret,
+void **release_cookie) {
FileDescriptor *f;
Window *w;
@@ -425,6 +429,8 @@ static int find_mmap(
if (ret)
*ret = (uint8_t*) w-ptr + (offset - w-offset);
+if (keep_always release_cookie)
+*release_cookie = c-window;
return 1;
}
@@ -437,7 +443,8 @@ static int add_mmap(
uint64_t offset,
size_t size,
struct stat *st,
-void **ret) {
+void **ret,
+void **release_cookie) {
uint64_t
Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values
On Mon, Oct 06, 2014 at 06:36:34PM +0200, Jan Janssen wrote:
*bump*
Sorry, I'll look into this.
Zbyszek
On 2014-09-06 10:36, Jan Janssen wrote:
sd_journal_enumerate_unique will lock its mmap window to prevent it
from being released by calling mmap_cache_get with keep_always=true.
This call may return windows that are wider, but compatible with the
parameters provided to it.
This can result in a mismatch where the window to be released cannot
properly be selected, because we have more than one window matching the
parameters of mmap_cache_release. Therefore, introduce a release_cookie
to be used when releasing the window.
https://bugs.freedesktop.org/show_bug.cgi?id=79380
---
src/journal/journal-file.c| 2 +-
src/journal/journal-file.h| 11 ---
src/journal/journal-verify.c | 2 +-
src/journal/mmap-cache.c | 32 +++-
src/journal/mmap-cache.h | 8 +++-
src/journal/sd-journal.c | 11 ++-
src/journal/test-mmap-cache.c | 10 +-
7 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 7286e14..0ed51ed 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -391,7 +391,7 @@ static int journal_file_move_to(JournalFile *f, int
context, bool keep_always, u
return -EADDRNOTAVAIL;
}
-return mmap_cache_get(f-mmap, f-fd, f-prot, context,
keep_always, offset, size, f-last_stat, ret);
+return mmap_cache_get(f-mmap, f-fd, f-prot, context,
keep_always, offset, size, f-last_stat, ret, NULL);
}
static uint64_t minimum_header_size(Object *o) {
diff --git a/src/journal/journal-file.h b/src/journal/journal-file.h
index da2ef3b..da1b793 100644
--- a/src/journal/journal-file.h
+++ b/src/journal/journal-file.h
@@ -212,17 +212,14 @@ static unsigned type_to_context(int type) {
return type 0 type _OBJECT_TYPE_MAX ? type : 0;
}
-static inline int journal_file_object_keep(JournalFile *f, Object *o,
uint64_t offset) {
+static inline int journal_file_object_keep(JournalFile *f, Object *o,
uint64_t offset, void **release_cookie) {
unsigned context = type_to_context(o-object.type);
uint64_t s = le64toh(o-object.size);
return mmap_cache_get(f-mmap, f-fd, f-prot, context, true,
- offset, s, f-last_stat, NULL);
+ offset, s, f-last_stat, NULL,
release_cookie);
}
-static inline int journal_file_object_release(JournalFile *f, Object *o,
uint64_t offset) {
-unsigned context = type_to_context(o-object.type);
-uint64_t s = le64toh(o-object.size);
-
-return mmap_cache_release(f-mmap, f-fd, f-prot, context, offset,
s);
+static inline int journal_file_object_release(JournalFile *f, void
*release_cookie) {
+return mmap_cache_release(f-mmap, f-fd, release_cookie);
}
diff --git a/src/journal/journal-verify.c b/src/journal/journal-verify.c
index 6c8ca8c..a1c34ac 100644
--- a/src/journal/journal-verify.c
+++ b/src/journal/journal-verify.c
@@ -368,7 +368,7 @@ static int contains_uint64(MMapCache *m, int fd,
uint64_t n, uint64_t p) {
c = (a + b) / 2;
-r = mmap_cache_get(m, fd, PROT_READ|PROT_WRITE, 0, false, c
* sizeof(uint64_t), sizeof(uint64_t), NULL, (void **) z);
+r = mmap_cache_get(m, fd, PROT_READ|PROT_WRITE, 0, false, c
* sizeof(uint64_t), sizeof(uint64_t), NULL, (void **) z, NULL);
if (r 0)
return r;
diff --git a/src/journal/mmap-cache.c b/src/journal/mmap-cache.c
index 7dbbb5e..64bc8da 100644
--- a/src/journal/mmap-cache.c
+++ b/src/journal/mmap-cache.c
@@ -352,7 +352,8 @@ static int try_context(
bool keep_always,
uint64_t offset,
size_t size,
-void **ret) {
+void **ret,
+void **release_cookie) {
Context *c;
@@ -381,6 +382,8 @@ static int try_context(
if (ret)
*ret = (uint8_t*) c-window-ptr + (offset -
c-window-offset);
+if (keep_always release_cookie)
+*release_cookie = c-window;
return 1;
}
@@ -392,7 +395,8 @@ static int find_mmap(
bool keep_always,
uint64_t offset,
size_t size,
-void **ret) {
+void **ret,
+void **release_cookie) {
FileDescriptor *f;
Window *w;
@@ -425,6 +429,8 @@ static int find_mmap(
if (ret)
*ret = (uint8_t*) w-ptr + (offset - w-offset);
+if (keep_always release_cookie)
+*release_cookie = c-window;
return 1;
}
@@ -437,7 +443,8 @@ static int
Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
On my system it is consistently. okt 06 20:09:09 dbuch-laptop systemd[1]: systemd-timedated.service stopping timed out. Terminating. okt 06 20:09:09 dbuch-laptop systemd[1]: Unit systemd-timedated.service entered failed state. okt 06 20:09:09 dbuch-laptop systemd[1]: systemd-timedated.service failed. okt 06 20:09:09 dbuch-laptop systemd[1]: systemd-hostnamed.service stopping timed out. Terminating. okt 06 20:09:09 dbuch-laptop systemd[1]: Unit systemd-hostnamed.service entered failed state. okt 06 20:09:09 dbuch-laptop systemd[1]: systemd-hostnamed.service failed. okt 06 20:09:09 dbuch-laptop systemd[1]: systemd-localed.service stopping timed out. Terminating. okt 06 20:09:09 dbuch-laptop systemd[1]: Unit systemd-localed.service entered failed state. okt 06 20:09:09 dbuch-laptop systemd[1]: systemd-localed.service failed. This happens every boot after the given timeout. 2014-10-04 18:26 GMT+02:00 David Herrmann dh.herrm...@gmail.com: Hi On Fri, Oct 3, 2014 at 10:00 PM, Daniel Buch boogiewasth...@gmail.com wrote: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units I also occasionally get timeouts on bus-activated systemd services with -git. I haven't been able to reproduce it consistently. Maybe Lennart has an idea what's going wrong, otherwise I will spend some time pinning this down. Thanks David dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. Best regards, Daniel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Martin Steigerwald mar...@lichtvoll.de Heck, I started a thread here and then didn´t manage to take time to carefully read it and reply here and there as I see fit. But I challenged people on debian-user mailing list to constructively voice their concerns upstream, and even pointed them to this mailing list. As far as I saw *no one* of the posters in debian-user took up on that challenge. Which I view as a pity. Cause now actually you invited constructive feedback. I wonder whether I may forward your answer to debian-user so they see your statement of inviting constructive feedback. I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :) For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. On of the most talked on things on debian-user is the logind thing. GNOME actually depends on it, as far as I know. While KDE in Debian still uses ConsoleKit, as it seems to me when looking at the process list and finding: On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now. But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality. The issue, I think, is that some of these packages provide very broad functionality. As I put it in a Debian bug report: Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it. I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd. Dependencies like this actually create some force to adopt systemd. Based on Lennart's and others' comments in this thread, forced adoption does not seem to be a goal. But forced adoption is a reality due to dependencies like the one above. I think there would be a lot less skepticism about systemd if the perception of forced adoption weren't so strong, and I'd love to see something done about this situation. Now I know ConsoleKit isn´t developed anymore, but also I never got why a logind implementation needs to depend on systemd base package in such a way that at least in Debian systemd package has to be installed if someone wants to use GNOME. Is this what Debian's systemd-shim is for? If not, well I'm going to talk about that anyway... Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality from the init system in the first place. Systemd-shim is a duplication of effort. Not only that, but it must time its releases with the releases of systemd-sysv. That's no big deal for Debian's stable release, but it can be problematic in Debian's unstable and testing branches. Wouldn't the systemd developers prefer to have their implementation of this functionality be used, regardless of the chosen init system? Let me stress this: constructive feedback is *always* welcome! The following may not concern you personally, but Debian is attempting to support multiple kernels (Linux, BSD and Hurd I think). As I understand it, systemd is Linux-only. Defaulting to a Linux-only init system makes supporting non-Linux kernels more work, because an alternate init system must be maintained, as well as init scripts for that init system. If functionality was separated as I described above, and the systemd project provided a very basic init-only package, would that be portable to non-Linux kernels? Users can also decide to help test the alternatives. Unlike other distros Debian still supports them. But systemd's approach of incorporating additional non-init
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hello Rob, this is higly Debian specific (doesn't even apply to Ubuntu) and thus a bit off-topic, but as the question already is on the upstream ML.. sorry! Rob Owens [2014-10-06 14:56 -0400]: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv You can break it up after libpam-systemd, as this has dependency alternatives to systemd-shim. With that you can use sysvinit or upstart. But currently systemd-sysv is the preferred alternative, so if you don't specify anything else it will pick systemd-sysv. You can do e. g. apt-get install brasero systemd-shim to select another (or install -shim first). I gather that this has something to do with logind and/or cgroups. That's correct; in fact most desktop-y software talks to logind only, but logind is a crucial component on a modern desktop. Systemd-shim is a duplication of effort. It's a looong story/history, but systemd-shim itself is actually fairly small. It's mostly glue to provide systemd's D-BUS API and implement it in terms of other components like cgmanager and pm-utils. And its development was quite inevitable at least from Debian's/Ubuntu's perspective as it is just practically impossible to do a SysV/upstart → systemd migration on a flag day. Not only that, but it must time its releases with the releases of systemd-sysv. Mostly not. That needs to happen for D-BUS API changes like they happened around version 209, but that happens fairly seldomly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote: - Original Message - From: Martin Steigerwald mar...@lichtvoll.de Heck, I started a thread here and then didn´t manage to take time to carefully read it and reply here and there as I see fit. But I challenged people on debian-user mailing list to constructively voice their concerns upstream, and even pointed them to this mailing list. As far as I saw *no one* of the posters in debian-user took up on that challenge. Which I view as a pity. Cause now actually you invited constructive feedback. I wonder whether I may forward your answer to debian-user so they see your statement of inviting constructive feedback. I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :) For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that. Here the feedback I read over and over again is that you and RedHat basically forced the systemd decision onto other distributions. While I do not see how you actually can be powerful enough to do that, as we live in a free will zone. I do see tendencies that more and more stuff *depends* on systemd cause it needs features only available there. On of the most talked on things on debian-user is the logind thing. GNOME actually depends on it, as far as I know. While KDE in Debian still uses ConsoleKit, as it seems to me when looking at the process list and finding: On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this: brasero - gvfs - gvfs-daemons - udisks2 - libpam-systemd - systemd-sysv I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now. But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality. The issue, I think, is that some of these packages provide very broad functionality. As I put it in a Debian bug report: Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it. I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd. I'll assume that this is a serious question, despite being rather elementary... You describe a dependency chain. First of all, it is important to note that it does not matter if brasero actually uses the part of gvfs that uses the part of udisk2 that uses the part of libpam-systemd that requires systemd to be running. Possibly not, and maybe brasero would still function correctly w/o systemd. But dependencies are expressed on package level, so if systemd is required for some functionality of libpam-systemd, which is used by any package depending on libpam-systemd, then libpam-systemd must depend on systemd-sysv, and transitively so must brasero. To break this chain at some point, it is necessary replace the strict dependency with recommends/suggests or provide a different different package which satisfies the dependency. The first option is only possible if the functionality provided by the dependent package is not essential. In some cases it is really clear, e.g. a binary requires a library to be installed to be able to run, but in other cases it's a judgment call by the maintainers, whether some part of functionality is important enough to add a dependency. In this case brasero, gvfs, udisks2, and systemd maintainers decided that yes, it is. The second option requires someone to step up and provide an alternative implementation. So far, systemd-shim is one candidate, but it took months to appear and still has occasional problems. (I don't follow the situation quite closely, but Michael seems to find serious bugs with very light testing). At some point, systemd-shim might become a viable replacement. This work should be done by people who want the alternatives, not the maintainers of systemd, who happily use the existing stack. So if the alternatives are not in the shape you would like them to be, inquire with the maintainers of the said alternatives. But even assuming that an alternative is functional, using it is not without costs for the maintainers of dependent packages. Let's say that we have some systems with systemd, some with systemd-shim. It is likely that a bug
Re: [systemd-devel] [PATCH 2/2] sysusers.d: split files to cope with split packages.
-Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, October 02, 2014 4:19 AM To: Barbieri, Gustavo Cc: Zbigniew Jędrzejewski-Szmek; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH 2/2] sysusers.d: split files to cope with split packages. On Tue, 30.09.14 14:44, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: systemd-timesyncd is ~400kb. Other binaries aren't too big either. Splitting everything up complicated things, and I'm not convinced that this is a useful change. indeed they are not big per se, but see my other email about tmpfiles, they contribute to a misinterpretation of systemd. since they are optional I want to make that clear and help the user to choose. I do have a complete set of packages for yocto that generates that nicely and the final system size difference is huge: 7.5 to 30Mb (whole system, not just systemd, but the dependencies, etc -- in contrast sysvinit + busybox is 6.5Mb). as I wrote in the other email, I'll make sure that some packages are highly recommended (ie: journal, udev, sysctl...), but forcing We don't support builds without journal or udev. We simply don't. I'm not trying to build without, just running without. Actually I'm not using any of --disable-SERVICE_OR_DAEMON, I build with all of them and let the user install or not the package -- thus the need for different *files* :-) everyone to ship a ntp client (timesyncd) is asking for trouble when people analyze systemd x options. Yes, timesyncd should definitely be optional, and so should resolved, that's true. I'd be OK with splitting those out on tmpfiles/sysusers, but would really prefer this to be done via m4, rather than in seperate files. As per above, I don't want to build without, rather build with all and just package them in separate. In the recommended setup users will get all they need. Just in cases where they remove (blacklist) the systemd-services-essential they can run without those (tmpfiles, sysusers...), I guess the name makes it clear they are not something to mess with if you are unsure. Please help, this will be for good. The m4 macros just makes the build system and packaging more difficult. It would only be useful for systems like Gentoo. BR, -- Gustavo (sorry the formatting, stupid outlook in this laptop) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.
-Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, October 02, 2014 4:16 AM To: Barbieri, Gustavo Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages. On Thu, 25.09.14 18:12, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: etc.conf was selectively (using m4) using resolved link, now this is moved to systemd-resolved.conf file. The etc.conf can be static and does not need to be generated anymore. systemd.conf was doing all the journal setup, now this is moved to systemd-journald.conf file. journald is not optional. And it won't be. Sorry. Got it, but clarity sake having it in a different file wouldn't hurt. But is not a big deal if you are completely against it. +z /var/log/journal/remote 2755 root systemd-journal-remote - - +z /run/log/journal/remote 2755 root systemd-journal-remote - - I am not convinced this is really worth it. This line has no effect anyway if the dir is missing... You mean the dir in systemd.conf? diff --git a/tmpfiles.d/systemd-networkd.conf b/tmpfiles.d/systemd-networkd.conf new file mode 100644 index 000..2419755 --- /dev/null +++ b/tmpfiles.d/systemd-networkd.conf @@ -0,0 +1,12 @@ +# This file is part of systemd. +# +# 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. + +# See tmpfiles.d(5) for details + +d /run/systemd/netif 0755 systemd-network systemd-network - +d /run/systemd/netif/links 0755 systemd-network systemd-network - +d /run/systemd/netif/leases 0755 systemd-network systemd-network - I am very much against this. Even if networkd is not used the dirs should really exist so that libsystemd-network can create an inotify watch on it without problem. It won't ever see any interfaces in it, but it will at least not fail. It's really just three dirs in /run, this costs barely anything. I am totally not convinced splitting this up is really a good idea... Well, I have to agree with you. It's just weird to have unused stuff in there. OTOH right now base-files will also add some of those, like spool/mail in an embedded device... so indeed no big deal. BR, -- Gustavo (again sorry about the formatting, outlook again -- I'm on vacations and just have this laptop with the company mail) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.
-Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, October 02, 2014 4:22 AM To: Barbieri, Gustavo Cc: Zbigniew Jędrzejewski-Szmek; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages. On Tue, 30.09.14 14:36, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: On Tue, Sep 30, 2014 at 04:26:38AM +0200, Zbigniew Jędrzejewski- Szmek wrote: On Thu, Sep 25, 2014 at 06:12:50PM -0300, Gustavo Sverzut Barbieri wrote: etc.conf was selectively (using m4) using resolved link, now this is moved to systemd-resolved.conf file. The etc.conf can be static and does not need to be generated anymore. systemd.conf was doing all the journal setup, now this is moved to systemd-journald.conf file. Is this useful? We don't support journald-less setups. I did forget about this part but it is important, so here it is: I just tested, although journald-less systems are not supported, they work beautifully (as beautify as it can). and we run great without a dbus-daemon, even if not running kdbus as systemctl bus is private and we can do with that (I didn't even think about that, someone at #systemd alerted me and it will help to stop those people that complain about dbus usage and that we could just do socket, the private socket is basically the same, but the protocol is a standard and not just some random handcrafted one). It's great if this works, and people can do whatever they want with the code. But this is nothing we want to support upstream. In upstream neither udev, nor dbus, nor the journal are optional. If people want to make that work, they can do this downstream. resolved, networkd, timesyncd are optional, for these it's OK to make the necessary changes upstream. It's just cumbersome to have to patch the installed files to split it. Doable, but not good to do. BR, -- Gustavo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] dbus: introduce new method call NewTransientUnit
It similar with StartTransientUnit but the NewTransientUnit does not
start the unit immediately. Newly generated transient unit can be
activated by systemctl start.
---
src/core/dbus-manager.c| 99 +-
src/core/org.freedesktop.systemd1.conf | 4 ++
src/core/service.c | 12 +
3 files changed, 103 insertions(+), 12 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 533ce43..84c913b 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -615,10 +615,15 @@ static int method_set_unit_properties(sd_bus *bus,
sd_bus_message *message, void
return bus_unit_method_set_properties(bus, message, u, error);
}
-static int method_start_transient_unit(sd_bus *bus, sd_bus_message *message,
void *userdata, sd_bus_error *error) {
+static int new_transient_unit_from_message(sd_bus *bus,
+ sd_bus_message *message,
+ void *userdata,
+ sd_bus_error *error,
+ Unit **unit,
+ JobMode *mode,
+ bool keep) {
const char *name, *smode;
Manager *m = userdata;
-JobMode mode;
UnitType t;
Unit *u;
int r;
@@ -631,7 +636,9 @@ static int method_start_transient_unit(sd_bus *bus,
sd_bus_message *message, voi
if (r 0)
return r;
if (r == 0)
-return 1; /* No authorization for now, but the async polkit
stuff will call us again when it has it */
+/* No authorization for now, but the async polkit
+ * stuff will call us again when it has it */
+return 1;
r = sd_bus_message_read(message, ss, name, smode);
if (r 0)
@@ -639,14 +646,22 @@ static int method_start_transient_unit(sd_bus *bus,
sd_bus_message *message, voi
t = unit_name_to_type(name);
if (t 0)
-return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS,
Invalid unit type.);
+return sd_bus_error_setf(error,
+ SD_BUS_ERROR_INVALID_ARGS,
+ Invalid unit type.);
if (!unit_vtable[t]-can_transient)
-return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS,
Unit type %s does not support transient units., unit_type_to_string(t));
-
-mode = job_mode_from_string(smode);
-if (mode 0)
-return sd_bus_error_setf(error, SD_BUS_ERROR_INVALID_ARGS,
Job mode %s is invalid., smode);
+return sd_bus_error_setf(error,
+ SD_BUS_ERROR_INVALID_ARGS,
+ Unit type %s does not support
transient units.,
+ unit_type_to_string(t));
+
+*mode = job_mode_from_string(smode);
+if (*mode 0)
+return sd_bus_error_setf(error,
+ SD_BUS_ERROR_INVALID_ARGS,
+ Job mode %s is invalid.,
+ smode);
r = selinux_access_check(message, start, error);
if (r 0)
@@ -656,8 +671,12 @@ static int method_start_transient_unit(sd_bus *bus,
sd_bus_message *message, voi
if (r 0)
return r;
-if (u-load_state != UNIT_NOT_FOUND ||
set_size(u-dependencies[UNIT_REFERENCED_BY]) 0)
-return sd_bus_error_setf(error, BUS_ERROR_UNIT_EXISTS, Unit
%s already exists., name);
+if (u-load_state != UNIT_NOT_FOUND ||
+set_size(u-dependencies[UNIT_REFERENCED_BY]) 0)
+return sd_bus_error_setf(error,
+ BUS_ERROR_UNIT_EXISTS,
+ Unit %s already exists.,
+ name);
/* OK, the unit failed to load and is unreferenced, now let's
* fill in the transient data instead */
@@ -675,10 +694,65 @@ static int method_start_transient_unit(sd_bus *bus,
sd_bus_message *message, voi
if (r 0)
return r;
+*unit = u;
manager_dispatch_load_queue(m);
+return 0;
+}
+
+static int method_new_transient_unit(sd_bus *bus,
+ sd_bus_message *message,
+ void *userdata,
+ sd_bus_error *error) {
+_cleanup_free_ char *path = NULL;
+JobMode mode;
+Unit *u = NULL;
+int r;
+
+r = new_transient_unit_from_message(bus,
+message,
+userdata,
+
[systemd-devel] [PATCH 3/3] run: introduce timer support option
If systemd-run is called with timer option, then systemd-run call NewTransientUnit with service unit. And also call StartTransientUnit with timer unit which has same name with the service. So actually, two method call is coming and two transient unit is generated. One is service and the other is timer. Supported timer options are --after=, --after-boot=, --after-startup=, --after-active=, --after-inactive=, --calendar=, --accuracy= and --wake-system. Each option corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=, AccuracySec= and AccuracySec= of timer respectively. --- man/systemd-run.xml | 70 + src/run/run.c | 294 ++-- 2 files changed, 331 insertions(+), 33 deletions(-) diff --git a/man/systemd-run.xml b/man/systemd-run.xml index 0c9d13d..452721c 100644 --- a/man/systemd-run.xml +++ b/man/systemd-run.xml @@ -210,6 +210,64 @@ along with systemd; If not, see http://www.gnu.org/licenses/. xi:include href=user-system-options.xml xpointer=host / xi:include href=user-system-options.xml xpointer=machine / + varlistentry +termoption--after=/option/term +termoption--after-boot=/option/term +termoption--after-startup=/option/term +termoption--after-active=/option/term +termoption--after-inactive=/option/term + +listitemparaDefines monotonic timers relative to different +starting points. Also see varnameOnActiveSec=/varname, +varnameOnBootSec=/varname, +varnameOnStartupSec=/varname, +varnameOnUnitActiveSec=/varname and +varnameOnUnitInactiveSec=/varname in + citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry. This +option has no effect in conjunction with +option--scope/option./para +/listitem + /varlistentry + + varlistentry +termoption--calendar=/option/term + +listitemparaDefines realtime (i.e. wallclock) timers with +calendar event expressions. Also see +varnameOnCalendar=/varname in + citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry. This +option has no effect in conjunction with +option--scope/option./para +/listitem + /varlistentry + + varlistentry +termoption--accuracy=/option/term + +listitemparaSpecify the accuracy the timer shall elapse +with. Also see varnameAccuracySec=/varname in + citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry. This +option only has effect with option--after=/option, +option--after-boot=/option, option--after-startup=/option, +option--after-active=/option, option--after-inactive=/option +or option--calendar=/option./para +/listitem + /varlistentry + + varlistentry +termoption--wake-system/option/term + +listitemparaElapsing timer will cause the system to resume +from suspend, should it be suspended and if the system supports +this. Also see varnameWakeSystem=/varname in + citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry. This +option only has effect with option--after=/option, +option--after-boot=/option, option--after-startup=/option, +option--after-active=/option, option--after-inactive=/option +or option--calendar=/option./para +/listitem + /varlistentry + xi:include href=standard-options.xml xpointer=help / xi:include href=standard-options.xml xpointer=version / /variablelist @@ -250,6 +308,17 @@ Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20. property./para programlisting# systemd-run -p BlockIOWeight=10 updatedb/programlisting + +paraThe following command will touch a file after 10 seconds./para + +programlisting# date; systemd-run --after=10 --accuracy=100ms touch /tmp/hello +Tue Oct 7 14:00:37 KST 2014 +Will running as unit run-115.service. +Running as unit run-115.timer. +# journalctl -u run-115.service +-- Logs begin at Sat 2014-10-04 13:54:49 KST, end at Tue 2014-10-07 14:00:47 KST. -- +Oct 07 14:00:47 container systemd[1]: Starting /bin/touch /tmp/hello... +Oct 07 14:00:47 container systemd[1]: Started /bin/touch /tmp/hello./programlisting /refsect1 refsect1 @@ -263,6 +332,7 @@ Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20. citerefentryrefentrytitlesystemd.slice/refentrytitlemanvolnum5/manvolnum/citerefentry, citerefentryrefentrytitlesystemd.exec/refentrytitlemanvolnum5/manvolnum/citerefentry, citerefentryrefentrytitlesystemd.resource-control/refentrytitlemanvolnum5/manvolnum/citerefentry, +
[systemd-devel] [PATCH 2/3] timer: timer can be a transient unit
---
src/core/dbus-timer.c | 140 ++
src/core/dbus-timer.h | 3 ++
src/core/timer.c | 10
3 files changed, 153 insertions(+)
diff --git a/src/core/dbus-timer.c b/src/core/dbus-timer.c
index f1f8c54..5f0b80e 100644
--- a/src/core/dbus-timer.c
+++ b/src/core/dbus-timer.c
@@ -24,6 +24,7 @@
#include dbus-unit.h
#include dbus-timer.h
#include bus-util.h
+#include errno-list.h
static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_result, timer_result,
TimerResult);
@@ -183,3 +184,142 @@ const sd_bus_vtable bus_timer_vtable[] = {
SD_BUS_PROPERTY(WakeSystem, b, bus_property_get_bool,
offsetof(Timer, wake_system), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_VTABLE_END
};
+
+static int bus_timer_set_transient_property(
+Timer *t,
+const char *name,
+sd_bus_message *message,
+UnitSetPropertiesMode mode,
+sd_bus_error *error) {
+
+const char *str;
+int r;
+
+assert(t);
+assert(name);
+assert(message);
+
+if (streq(name, OnActiveSec) ||
+streq(name, OnBootSec) ||
+streq(name, OnStartupSec) ||
+streq(name, OnUnitActiveSec) ||
+streq(name, OnUnitInactiveSec)) {
+
+TimerValue *v;
+TimerBase b = _TIMER_BASE_INVALID;
+usec_t u = 0;
+CalendarSpec *c = NULL;
+
+b = timer_base_from_string(name);
+if (b 0)
+return 0;
+
+r = sd_bus_message_read(message, s, str);
+if (r 0)
+return r;
+
+if (mode != UNIT_CHECK) {
+if (b == TIMER_CALENDAR) {
+r = calendar_spec_from_string(str, c);
+if (r 0)
+return r;
+} else {
+r = parse_sec(str, u);
+if (r 0)
+return r;
+}
+
+unit_write_drop_in_private_format(UNIT(t),
+ mode,
+ name,
+ %s=%s\n,
+ name,
+ str);
+
+v = new0(TimerValue, 1);
+if (!v) {
+if (c)
+calendar_spec_free(c);
+return -ENOMEM;
+}
+
+v-base = b;
+v-value = u;
+v-calendar_spec = c;
+
+LIST_PREPEND(value, t-values, v);
+}
+
+return 1;
+
+} else if (streq(name, AccuracySec)) {
+
+usec_t u = 0;
+
+r = sd_bus_message_read(message, s, str);
+if (r 0)
+return r;
+
+r = parse_sec(str, u);
+if (r 0)
+return r;
+
+if (mode != UNIT_CHECK) {
+t-accuracy_usec = u;
+unit_write_drop_in_private_format(UNIT(t),
+ mode,
+ name,
+ %s=%s\n,
+ name,
+ str);
+}
+
+return 1;
+
+} else if (streq(name, WakeSystem)) {
+
+int b;
+
+r = sd_bus_message_read(message, b, b);
+if (r 0)
+return r;
+
+if (mode != UNIT_CHECK) {
+t-wake_system = b;
+unit_write_drop_in_private_format(UNIT(t),
+ mode,
+ name,
+ %s=%s\n,
+ name,
+
yes_no(t-wake_system));
+}
+
+return 1;
+
+}
+
+return 0;
+}
+
+int bus_timer_set_property(
+Unit *u,
+const char *name,
+sd_bus_message *message,
+UnitSetPropertiesMode mode,
+sd_bus_error *error) {
+
+Timer *t = TIMER(u);
+int r;
+
+
