[systemd-devel] Periodic tasks on battery-powered devices
I could be missing something, but I think there's a gap in the functionality for timers for periodic tasks on battery-powered devices. Basically, I want to generate a security report (SCAP style) approximately weekly but avoid doing so on battery. Here's what I've tried or looked at: - If I use ConditionACPower=true on the Type=OneShot service performing the task, then systemd will not run the task while on battery, but it still resets the timer. With a longer OnCalendar= interval, there's a significant chance that the infrequent check will overlap with battery-mode operation, causing the task to never run. - If I use ConditionACPower=true on the timer, then the timer just won't start if the machine boots on battery. This is also undesirable, as a machine may only boot every few weeks. - OnActiveSec= doesn't support persistence, so intervals of approximately a week may never fire on some laptops that shutdown or reboot frequently. - OnBootSec= would be too frequent for laptops that shutdown or reboot frequently. It seems the best I can do right now is use a shorter timer interval with no AC power condition but have the Type=OneShot service exit early if it last ran too recently, especially if currently on battery power. I'm also looking at just using anacron. What I would prefer is a [Timer] option like AvoidOnBatterySec= that causes the timer to avoid firing on battery yet fire on restoration of AC power if overdue. If the AvoidOnBatterySec= duration has elapsed since the last firing, the timer fires regardless of whether the device is on battery. This would allow easy configuration of periodic tasks that are power-hungry but need to run eventually. Some of our laptops rarely run on AC aside from when they're closed at night. I would even consider a directive like WakeSystemSec= that specifies a maximum interval that must elapse since the timer last fired before waking up the system to fire the timer. Similarly to AvoidOnBatterySec=, it would serve as a way to get more aggressive if a periodic task is too far overdue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd reboot problem
> But I don't want to wait for those services to shutdown. Then there's no reason to interact with systemd if you want to force an immediate, unclean reboot. You just want something like the reboot syscall with LINUX_REBOOT_CMD_RESTART. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 3CX PhoneSystem 01 Management Console won't start
This failure is not from systemd; systemd is only the messenger: > Mar 07 11:08:09 3CX systemd[1]: 3CXPhoneSystemMC01.service start operation timed out. Terminating. Someone needs to troubleshoot why 3CXPhoneSystemMC01.service is hanging when it tries to start, and this list can't answer that. You should contact the vendor behind 3CX or check any log files the service might be creating on its own. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] Cache aggregated cgroup mask data at the slice level.
This is not the solution we need. :-( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] guidance on how to start systemctrl with service files in specified locations
Admin-created service files should go in /etc/systemd/system/. You manage them using systemctl and the name of the service file *with no path*. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Cache aggregated cgroup mask data at the slice level.
I'm specifically wondering if it's safe to use cgroup_mask in slices to aggregate the masks of their children. If not, it's trivial to add another item to the struct (like cgroup_mask_children) to use for aggregation. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Cache aggregated cgroup mask data at the slice level.
This may need a few tweaks, most notably the extraneous log items. Is this a decent approach, though, to caching cgroup mask data? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Another critical feature for server configs is bonding. It's possible right from Kickstart and with the normal configurations in Fedora. We use it on every bare-metal server we manage to get HA networking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need advice on daemon's architecture
On Sat, Nov 2, 2013 at 11:40 PM, Peter Lemenkov lemen...@gmail.com wrote: Does it add anything if I change type of a main service to dbus thus allowing systemd to know for sure if my service is fully initialized? Yes. Changing to Type=dbus will cause systemd to only consider the service fully started after there's a listener for whatever's specified with BusName= [1]. [1] http://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix compiler warnings
Thank. I'll commit this once I'm at my desk.
On Oct 31, 2013 11:26 AM, Ronny Chevalier chevalier.ro...@gmail.com
wrote:
multiple warnings like
src/socket-proxy/socket-proxyd.c: In function ‘transfer_data_cb’:
src/socket-proxy/socket-proxyd.c:237:25: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 6 has type ‘size_t’ [-Wformat=]
log_debug(Buffer now has %ld bytes full.,
c-buffer_filled_len);
---
src/socket-proxy/socket-proxyd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/socket-proxy/socket-proxyd.c
b/src/socket-proxy/socket-proxyd.c
index 054a27a..34b1c15 100644
--- a/src/socket-proxy/socket-proxyd.c
+++ b/src/socket-proxy/socket-proxyd.c
@@ -129,7 +129,7 @@ static int send_buffer(struct connection *sender) {
* it does. */
while (sender-buffer_filled_len sender-buffer_sent_len) {
len = send(receiver-fd, sender-buffer +
sender-buffer_sent_len, sender-buffer_filled_len -
sender-buffer_sent_len, 0);
-log_debug(send(%d, ...)=%ld, receiver-fd, len);
+log_debug(send(%d, ...)=%zd, receiver-fd, len);
if (len 0) {
if (errno != EWOULDBLOCK errno != EAGAIN) {
log_error(Error %d in send to fd=%d:
%m, errno, receiver-fd);
@@ -147,7 +147,7 @@ static int send_buffer(struct connection *sender) {
sender-buffer_sent_len += len;
}
-log_debug(send(%d, ...) completed with %lu bytes still
buffered., receiver-fd, sender-buffer_filled_len -
sender-buffer_sent_len);
+log_debug(send(%d, ...) completed with %zd bytes still
buffered., receiver-fd, sender-buffer_filled_len -
sender-buffer_sent_len);
/* Detect a would-block state or partial send. */
if (sender-buffer_filled_len sender-buffer_sent_len) {
@@ -206,13 +206,13 @@ static int transfer_data_cb(sd_event_source *s, int
fd, uint32_t revents, void *
log_debug(Got event revents=%d from fd=%d (conn %p)., revents,
fd, c);
if (revents EPOLLIN) {
-log_debug(About to recv up to %lu bytes from fd=%d
(%lu/BUFFER_SIZE)., BUFFER_SIZE - c-buffer_filled_len, fd,
c-buffer_filled_len);
+log_debug(About to recv up to %zd bytes from fd=%d
(%zd/BUFFER_SIZE)., BUFFER_SIZE - c-buffer_filled_len, fd,
c-buffer_filled_len);
/* Receive until the buffer's full, there's no more data,
* or the client/server disconnects. */
while (c-buffer_filled_len BUFFER_SIZE) {
len = recv(fd, c-buffer + c-buffer_filled_len,
BUFFER_SIZE - c-buffer_filled_len, 0);
-log_debug(recv(%d, ...)=%ld, fd, len);
+log_debug(recv(%d, ...)=%zd, fd, len);
if (len 0) {
if (errno != EWOULDBLOCK errno !=
EAGAIN) {
log_error(Error %d in recv from
fd=%d: %m, errno, fd);
@@ -232,9 +232,9 @@ static int transfer_data_cb(sd_event_source *s, int
fd, uint32_t revents, void *
}
assert(len 0);
-log_debug(Recording that the buffer got %ld more
bytes full., len);
+log_debug(Recording that the buffer got %zd more
bytes full., len);
c-buffer_filled_len += len;
-log_debug(Buffer now has %ld bytes full.,
c-buffer_filled_len);
+log_debug(Buffer now has %zd bytes full.,
c-buffer_filled_len);
}
/* Try sending the data immediately. */
--
1.8.4.2
___
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] [PATCH] fix compiler warnings
Committed. Did you happen to be on 32-bit? I didn't see any warnings on my own builds (64-bit Fedora 19). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix compiler warnings
I did a quick follow-up to make some of them %zu where they're actually unsigned. Can you let me know if that still works for you? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Experimental socket process pool.
On Mon, Oct 28, 2013 at 11:30 AM, Lennart Poettering lenn...@poettering.net wrote: So yeah, cool feature, and I'd be very happy to see this in PID 1, but I am very sure we shouldn't merge this tool like this! Can I get some pointers on how to do it in PID 1? If I start them the same way as the semicolon delimiter for ExecStart= does, then they'll all have different namespaces if any are in use. I'd like to avoid that. I'd also like to spawn replacements for ones that exit, and that's an equally hard problem if there's no supervisor process in the namespace. Would it be better to build this around a child instance of systemd, container-style, that manages the pool? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Experimental socket process pool.
This daemon is a proof-of-concept that manages a process pool of (usually) socket-activated child processes. It exploits the ability to have multiple processes accept() on the same socket, allowing the kernel to distribute requests among the children. We've talked about adding this to systemd core, but that will probably take a great deal more work than running it as PID 1. This code is definitely not ready to commit for multiple reasons (man pages, argument parsing being confused by children getting --args, and more), but I'd like feedback on the general idea. I've already noticed that it doesn't work so well with multiple processes and EPOLLIN to do accept() callbacks (like in systemd-socket-proxyd), but I'm looking for options there [1]. I would like this to work well with (1) systemd-socket-proxyd, (2) Twisted socket activation, and (3) node.js socket activation. If it can handle all of those well, I'll be confident in the design. Currently, the options for running pools of Twisted or node.js processes are clunky, like fronting a set of instance services with haproxy. [1] http://stackoverflow.com/q/19493498/450218 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Experimental socket process pool.
On Mon, Oct 21, 2013 at 7:08 AM, Tom Gundersen t...@jklm.no wrote: This is a cool feature. However, it seems to me that adding it to the core makes much more sense, that way the children can be managed properly by systemd as real services. What problems do you see with adding this to pid1? There's no inherent technical barrier, but there are some improvements to make and hurdles to jump. systemd unshares namespaces for every direct child spawned. Processes in a pool should usually share the same network namespace, though, among other resources. systemd core would need to accommodate arrays of other currently singular, per-service data, like PID files and status for each child. Given that each child would run as a main process from the daemon's perspective, we'd need to treat it to the same oversight. PID 1 also comes with its advantages. It's an easier place to prove this idea out in isolation. We can studying accept() as a way to load-balance a set of modern (often event-oriented) daemons, a problem that will be equally interesting in or out of core. Because the socket still gets handed through with a PID 1 pool manager, there's no substantial overhead to the running daemons, making it a reasonable choice for sustained production use. I'd certainly still to see this in core, eventually. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Experimental socket process pool.
On Mon, Oct 21, 2013 at 4:59 AM, David Strauss da...@davidstrauss.net wrote: I've already noticed that it doesn't work so well with multiple processes and EPOLLIN to do accept() callbacks (like in systemd-socket-proxyd), but I'm looking for options there. Thanks to some helpful advice [1] on Stack Overflow and some man page reading about EPOLLONESHOT + EPOLL_CTL_MOD [2], I've fixed up EPOLLONESHOT support in the event library (including tests) and updated socket-proxyd to use it. There's now a much lower rate of process activation and competition to accept(). [1] http://stackoverflow.com/a/19497265/450218 [2] http://linux.die.net/man/2/epoll_ctl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
For anyone watching here at home, the utility is now named systemd-socket-proxyd in git. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] issues with large number of units, systemd 204 and 208 [d10k]
Initial perf results confirm cgroups rework as the culprit. We're seeing huge time spent in unit_get_members_mask, cgroup_context_get_mask, and unit_get_cgroup_context. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in source_io_register?
On Wed, Oct 16, 2013 at 4:34 AM, Lennart Poettering lenn...@poettering.net wrote: This is explicitly not supported by epoll, as discussed earlier. You should get an EEXIST if you try to do this, and rightfully so. Yes, but I only truly understood what you meant after having failure as the teacher (and then fixing it). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
On Wed, Oct 16, 2013 at 6:59 AM, Kay Sievers k...@vrfy.org wrote: Also this thing does not actually *activate* anything it just proxies. I was going more for socket *activated* proxy, in the sense that the proxy uses socket activation to get its listen() fd. And long-running processes should get a d(aemon) at the end. Agreed here. Not sure why I forgot about that. I'll add that in. So why not just call it systemd-socket-proxyd. It doesn't emphasize the main reason someone would use this over existing tools. (Admittedly, sa doesn't do so too directly, either.) Say the word proxy to someone who's a developer or in IT, and they'll already assume it's a proxy based on *sockets*, even if they don't know what sockets are, exactly. We can compare to these established ones: * haproxy can do pure TCP (protocol neutrality) at scale (event-driven), but it can't start with socket activation or use Unix sockets. * socat is also protocol-neutral, but it assumes any inherited socket is post-accept(). It can only do listen() if it doesn't inherit the socket. There are also questions about its performance and reliability at scale (it's thread-based). It's not really designed to be a long-running daemon. * nginx can inherit sockets and run at scale (event-driven), but it's protocol-constrained to HTTP and SMTP, maybe one more. The proxy here (1) accepts an inherited socket for activation, (2) works with Unix domain sockets, (3) is protocol-neutral, and (4) should work at scale. Of those four characteristics, I consider the first (socket activation) the most novel and the main reason someone would opt for this proxy over other, established ones. This systemd-bundled proxy should work for creating socket-activate-able MySQL, Redis, Tomcat, Cassandra, some of which may never get native socket activation support. Would systemd-activated-proxyd work? I'd also consider systemd-socket-activated-proxyd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
Current feature limitations I'd like to overcome *after this gets in master*: * getaddrinfo() is still blocking, though this shouldn't be an issue for things like localhost. * Running sabridge in the same namespace as the daemon requires an ugly shell script. * The nginx shell script may be racy. * Only one inherited socket can be proxied, and sabridge can only use fd=3. Other notes regarding review comments: * I'm keeping the CDATA for now, for two reasons: (a) XML formatting tools know to respect the whitespace (b) Docbook's own docs [1] show using it with CDATA, albeit for better reasons than my own usage. * The name stays for now. It's not that hard to say ess eh bridge. [1] http://www.docbook.org/tdg/en/html/programlisting.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
On Tue, Oct 15, 2013 at 8:55 AM, Colin Guthrie gm...@colin.guthr.ie wrote: I don't have much in the way of comments (although I followed the threads closely), but can you please version your patch emails. I see three threads all with the same title... a [PATCH v3] is the traditional way (also some comments below the --- about what changed in v2 and v3 etc. would be nice). Ah, I see now. git send-email does that if you use --thread and --no-chain-reply-to. I'll use those in the future. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
On less-exhausted self-review, the partial send code is broken here. Please await a follow-up. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
One question, though: Is it safe to assume send will block if it returns having sent fewer bytes than requested? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
On Tue, Oct 15, 2013 at 1:59 PM, David Strauss da...@davidstrauss.net wrote: One question, though: Is it safe to assume send will block if it returns having sent fewer bytes than requested? Much searching is not giving me an answer, so I've also posted [1] to Stack Overflow. [1] http://stackoverflow.com/questions/19391208/when-a-non-blocking-send-only-transfers-partial-data-can-we-assume-it-is-read ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] Add sabridge for socket activation of traditional daemons
The partial-send and recv is still buggy. :-( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5] Add sabridge for socket activation of traditional daemons
Connection structs were using dirty memory for the buffer offsets, which were the only struct members not initialized. This had worked fine in all of my small tests, but under load it was failing terribly. Using malloc0() causes it to now work with any level of concurrency. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5] Add sabridge for socket activation of traditional daemons
I've merged this. I'll update the main task list with follow-up work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
On Tue, Oct 15, 2013 at 4:32 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I'm not sure if I understand the question correctly. First of all, the socket is in non-blocking mode, no? And anyway, even if it was in blocking mode, in the time between an incomplete send was done, the buffer could have been emptied by the kernel, so you cannot assume that the next send will block. That's correct, and that's the response I got on Stack Exchange. I figured it was the safe approach, anyway. The code now does that. Specifically, it loops until it hits EAGAIN or EWOULDBLOCK, even if it got a partial send(). This also works well under load tests. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
Oh, and Zbigniew, if you have any follow-ups on the code I pushed to master, I'm happy to handle them right now. 100% of your feedback should either be implemented or in the TODOs. If you think any of the TODOs are release blockers, I can handle those now, too. My backup plan if we think the shell script is too ugly is to just remove that example. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in source_io_register?
On Mon, Oct 14, 2013 at 1:25 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Oct 14, 2013 at 12:33 PM, Lennart Poettering lenn...@poettering.net wrote: COuld you rebase please and try to reproduce the issue? I'm not seeing the issue anymore after doing that, but I may have fixed something on my side, too. Actually, I am still seeing this if I force send() to go EAGAIN/EWOULDBLOCK: Oct 15 17:41:30 olympian sabridge.sh[30744]: Recording that the buffer got 16384 more bytes full. Oct 15 17:41:30 olympian sabridge.sh[30744]: Buffer now has 16384 bytes full. Oct 15 17:41:30 olympian sabridge.sh[30744]: send(5, ...)=15488 Oct 15 17:41:30 olympian sabridge.sh[30744]: send(5, ...)=-1 Oct 15 17:41:30 olympian sabridge.sh[30744]: send(5, ...) completed with 896 bytes still buffered. Oct 15 17:41:30 olympian sabridge.sh[30744]: Is send watching enabled on fd=5? 0 Oct 15 17:41:30 olympian sabridge.sh[30744]: Error -17 enabling send for fd=5: File exists The Is send watching enabled check is in my local code, but it just runs sd_event_source_get_enabled() to check the watcher. I'll do some research into it. I'm 90% sure the library side has something wrong. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5] Add sabridge for socket activation of traditional daemons
On Tue, Oct 15, 2013 at 5:33 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: So, is the bump to 16kB based on benchmarking? If you could post any results that would be great. Also, how does the original threaded aproach compare to the sd_event based one? The 16kB bump is based on using the same buffer size as libcurl. Any network library that established can't be using a choice that's *too* wrong. The 4kB size was only based on someone else's suggestion to go larger than the default MTU. My original 1kB size was based on no real-world data at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5] Add sabridge for socket activation of traditional daemons
On Tue, Oct 15, 2013 at 5:33 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Also, how does the original threaded aproach compare to the sd_event based one? I haven't tried this. I went event-oriented because I know some daemons this will be used with expect to juggle many connections. We're also looking at supporting process-pools at the system service/socket level. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in source_io_register?
This appears to be a case of having more than one source enabled for the same fd, even if they're for different conditions (EPOLLIN vs. EPOLLOUT). I'm looking now at changing the code to use only one source but in a disabled, EPOLLIN only, EPOLLIN only, or EPOLLIN | EPOLLOUT state. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in source_io_register?
It turned out to be an error on my part in assuming systemd's event library abstracts sources from watched fds added to epoll. saproxy now manages its own bitwise operations and only uses a single source/watcher per socket fd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
Here's a revised version that should be pretty close to done, except
for needing libasyncns and less logging. Blocking on getaddrinfo
doesn't concern me too much for the initial release, given that
primary use of this should be with localhost IPs.
If this gets a thumbs-up, I'll send in a proper patch set. The full
sabridge branch is here [1], including the sd-event.c fix for EEXIST.
[1] https://github.com/davidstrauss/systemd/tree/sabridge
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd.
Copyright 2013 David Strauss
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/.
***/
#include errno.h
#include stdio.h
#include stdlib.h
#include string.h
#include netdb.h
#include sys/fcntl.h
#include sys/socket.h
#include sys/un.h
#include unistd.h
#include log.h
#include util.h
#include sd-daemon.h
#include sd-event.h
#define BUFFER_SIZE 1024
#define _cleanup_freeaddrinfo_ _cleanup_(freeaddrinfop)
unsigned int total_clients = 0;
struct proxy {
int listen_fd;
bool remote_is_inet;
const char *remote_host;
const char *remote_service;
};
struct connection {
int fd;
char buffer[BUFFER_SIZE];
ssize_t buffer_len;
sd_event_source *w_recv;
sd_event_source *w_send;
struct connection *c_destination;
};
static inline void freeaddrinfop(struct addrinfo **ai) {
if (*ai)
freeaddrinfo(*ai);
}
static void free_connection(struct connection *c) {
sd_event_source_unref(c-w_recv);
sd_event_source_unref(c-w_send);
close(c-fd);
free(c);
}
static int transfer_data_cb(sd_event_source *s, int fd, uint32_t revents, void *userdata) {
struct connection *c = (struct connection *) userdata;
int r = 0;
assert(revents (EPOLLIN | EPOLLOUT));
if (revents EPOLLIN) {
log_info(About to recv up to %u bytes from fd=%d., BUFFER_SIZE, fd);
assert(s == c-w_recv);
c-buffer_len = recv(fd, c-buffer, BUFFER_SIZE, 0);
if (c-buffer_len == 0) {
log_info(Clean disconnection.);
free_connection(c-c_destination);
free_connection(c);
goto finish;
}
else if (c-buffer_len == -1) {
log_error(Error %d in recv from fd=%d: %s, errno, fd, strerror(errno));
r = -1;
goto finish;
}
/* Try sending the data immediately. */
r = send(c-c_destination-fd, c-buffer, c-buffer_len, 0);
if (r 0 errno != EWOULDBLOCK errno != EAGAIN) {
log_error(Error %d in send to fd=%d: %s, errno, fd, strerror(errno));
goto finish;
}
else if (errno == EWOULDBLOCK || errno == EAGAIN) {
/* Switch to listening for a sendable state in destination. */
r = sd_event_source_set_mute(c-w_recv, SD_EVENT_MUTED);
if (r 0) {
log_error(Error %d muting recv for fd=%d: %s, r, fd, strerror(r));
goto finish;
}
r = sd_event_source_set_mute(c-c_destination-w_send, SD_EVENT_UNMUTED);
if (r 0) {
log_error(Error %d unmuting send for fd=%d: %s, r, c-c_destination-fd, strerror(-r));
goto finish;
}
log_info(Done with recv for fd=%d. Waiting on send for fd=%d., fd, c-c_destination-fd);
goto finish;
}
log_info(Done with recv for fd=%d and send for fd=%d., fd, c-c_destination-fd);
}
else {
log_info(About to send up to %u bytes to fd=%d., BUFFER_SIZE, fd);
assert(s == c-w_send);
assert(c-buffer != NULL);
r = send(fd, c-buffer, c-buffer_len, 0);
if (r 0) {
log_error(Error %d in send to fd=%d: %s, errno, fd, strerror(errno));
goto finish;
}
/* Switch to listening
Re: [systemd-devel] Early review request: socket activation bridge
On Mon, Oct 14, 2013 at 3:53 AM, David Strauss da...@davidstrauss.net wrote: Here's a revised version that should be pretty close to done And also aside from my Unix socket and IPv6 TODOs, which are tiny. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in source_io_register?
I'm not using multiple threads. This is occurring when I create, then mute, and then unmute an IO source. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] accept() and socket activation
One of the biggest pains with accept() for socket activation is supporting IPv4, IPv6, and Unix domain socket simultaneously while being able to log useful information about the client. Is there a straightforward way, using either existing libraries or functions withing systemd, to do this without *any* conditionals for the different types? Basically, I'd like to get just a string describing the client origin. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
Slightly better performance now with per-connection buffers. [root@olympian systemd]# ab -n1000 -c10 http://localhost:8080/ This is ApacheBench, Version 2.3 $Revision: 1430300 $ Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software:nginx/1.4.2 Server Hostname:localhost Server Port:8080 Document Path: / Document Length:3700 bytes Concurrency Level: 10 Time taken for tests: 0.164 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 3933000 bytes HTML transferred: 370 bytes Requests per second:6093.21 [#/sec] (mean) Time per request: 1.641 [ms] (mean) Time per request: 0.164 [ms] (mean, across all concurrent requests) Transfer rate: 23402.94 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.3 0 2 Processing: 01 0.3 1 4 Waiting:01 0.2 1 2 Total: 12 0.3 1 4 ERROR: The median and mean for the total time are more than twice the standard deviation apart. These results are NOT reliable. Percentage of the requests served within a certain time (ms) 50% 1 66% 2 75% 2 80% 2 90% 2 95% 2 98% 3 99% 3 100% 4 (longest request) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug in source_io_register?
On Mon, Oct 14, 2013 at 12:33 PM, Lennart Poettering lenn...@poettering.net wrote: COuld you rebase please and try to reproduce the issue? I'm not seeing the issue anymore after doing that, but I may have fixed something on my side, too. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons.
Please ignore. This patch is incomplete. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add sabridge for socket activation of traditional daemons
Of course, I can commit this myself if there are no objections. The risk to non-users of the tool is pretty much zero. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Bug in source_io_register?
source_io_register errors out with EEXIST, but that's supposed to be harmless for epoll [1]: Q1: What happens if you add the same fd to an epoll_set twice? A1: You will probably get EEXIST. However, it is possible that two threads may add the same fd twice. This is a harmless condition. I assume we should ignore it in the event library? [1] http://linux.die.net/man/4/epoll -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
On Thu, Oct 10, 2013 at 10:12 PM, Tollef Fog Heen tfh...@err.no wrote: I'd go with something how it's done in Varnish: Have an (or n) acceptor threads that schedule work to a pool of worker threads. That scheduler should be careful about such things as treating the worker threads as LIFO (to preserve CPU cache). If we have systemd manage the processes as a pool, each process will run persistently and directly accept() from the inherited listener socket. This means the kernel will choose which process to wake up when a new connection comes in. This is stampede-free in modern Linux, but I'm not sure about the ordering of connections versus processes accept()ing them or whether busy workers can hold off on both notifications and accept()ing for a while. The advice about only 2-3 threads per CPU core looks excessively conservative. We're usually, and quite happily running with a few thousand threads, no matter the number of cores. The number of processes or threads per core shouldn't substantially affect any architecture work we're doing. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
On Thu, Oct 10, 2013 at 8:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: One thing which we can't make work currently, is having the target service managed by systemd, but running with PrivateNetwork=yes. In this case, the bridge process must be inside of the target service and start the target binary itself. But maybe that's not so bad, since the proxy can be introduced by adding one word to ExecStart=. This is why I opted for the tiny script to start nginx and then the bridge in my proof-of-concept implementation. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
I was actually planning to rewrite on top of libuv today, but I'm happy to port to the new, native event library. Is there any best-practice for using it with multiple threads? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
On Thu, Oct 10, 2013 at 1:20 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Best-practice is using just one thread :) That depends on whether you need to scale up to multiple cores. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] cgroups: support for MemorySoftLimit= setting
Didn't we recently drop this option? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
On Thu, Oct 10, 2013 at 7:07 PM, Lennart Poettering lenn...@poettering.net wrote: All load balancing would be done by the kernel, and that's kinda cool, because they actually are good at these things... This is essentially what I was advocating a while back for other event-oriented frameworks like Node and Twisted. Both support socket activation these days, but they have no reliable mechanism for distributing the load across multiple processes. So, a big +1 to generic support for pools of socket-activated processes that still run accept() on their own. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
Here's a first take on having sabridge use the systemd-native event
library. The current, full diff is also visible on GitHub [1].
Obviously, this work still needs considerable cleanup and tightening.
I like how we're currently hammering out the basics, like the event
library to use and where the multiprocess/multithreaded logic should
go in the longer-run.
I'm open to better ideas for the data structures. Right now, the
priority is to hammer everything into symmetric structures so the
bi-directionality of the proxy gets abstracted away from the transfer
function. This is useful for ensuring we have consistent support for
server-first (MySQL) and client-first (HTTP) protocols.
[1] https://github.com/systemd/systemd/pull/5/files
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd.
Copyright 2013 David Strauss
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/.
***/
#define __STDC_FORMAT_MACROS
#include errno.h
#include stdio.h
#include stdlib.h
#include string.h
#include netdb.h
#include sys/fcntl.h
#include sys/socket.h
#include sys/un.h
#include unistd.h
#include log.h
#include sd-daemon.h
#include sd-event.h
#define BUFFER_SIZE 1024
unsigned int total_clients = 0;
struct proxy {
int listen_fd;
bool remote_is_inet;
const char *remote_host;
const char *remote_service;
};
struct connection {
int origin_fd;
int destination_fd;
sd_event_source *w_destination;
struct connection *c_destination;
};
static int transfer_data_cb(sd_event_source *s, int fd, uint32_t revents, void *userdata) {
struct connection *connection = (struct connection *) userdata;
char *buffer = malloc(BUFFER_SIZE);
ssize_t buffer_len;
assert(revents EPOLLIN);
assert(fd == connection-origin_fd);
log_info(About to transfer up to %u bytes from %d to %d., BUFFER_SIZE, connection-origin_fd, connection-destination_fd);
buffer_len = recv(connection-origin_fd, buffer, BUFFER_SIZE, 0);
if (buffer_len == 0) {
log_info(Clean disconnection.);
sd_event_source_unref(connection-w_destination);
sd_event_source_unref(s);
close(connection-origin_fd);
close(connection-destination_fd);
free(connection-c_destination);
free(connection);
goto finish;
}
else if (buffer_len == -1) {
log_error(Error %d in recv from fd=%d: %s, errno, connection-origin_fd, strerror(errno));
exit(EXIT_FAILURE);
}
if (send(connection-destination_fd, buffer, buffer_len, 0) 0) {
log_error(Error %d in send to fd=%d: %s, errno, connection-destination_fd, strerror(errno));
exit(EXIT_FAILURE);
}
finish:
free(buffer);
return 0;
}
static int connected_to_server_cb(sd_event_source *s, int fd, uint32_t revents, void *userdata) {
struct connection *c_server_to_client = (struct connection *) userdata;
struct sd_event *e = sd_event_get(s);
log_info(Connected to server. Initializing watchers for sending data.);
// Start listening for data sent by the client.
sd_event_add_io(e, c_server_to_client-destination_fd, EPOLLIN, transfer_data_cb, c_server_to_client-c_destination, c_server_to_client-w_destination);
// Cancel the write watcher for the server.
sd_event_source_unref(s);
// Start listening for data sent by the server.
sd_event_add_io(e, c_server_to_client-origin_fd, EPOLLIN, transfer_data_cb, c_server_to_client, c_server_to_client-c_destination-w_destination);
return 0;
}
static int set_nonblock(int fd) {
int flags;
flags = fcntl(fd, F_GETFL);
flags |= O_NONBLOCK;
return fcntl(fd, F_SETFL, flags);
}
static int get_server_connection_fd(const struct proxy *proxy) {
int server_fd;
int len;
if (proxy-remote_is_inet) {
struct addrinfo hints;
struct addrinfo *result;
int s;
memset(hints, 0, sizeof(struct addrinfo));
hints.ai_family = AF_UNSPEC; /* IPv4 or IPv6 */
hints.ai_socktype = SOCK_STREAM; /* TCP */
hints.ai_flags = AI_PASSIVE; /* Any IP address */
//log_error(Looking up address info for %s:%s, proxy-remote_host, proxy-remote_service);
s = getaddrinfo(proxy-remote_host, proxy-remote_service, hints, result);
if (s != 0) {
log_error(getaddrinfo error (%d): %s, s, gai_strerror(s));
exit
[systemd-devel] Early review request: socket activation bridge
I've attached the initial implementation -- not yet ready to merge --
for an event-oriented socket activation bridge. It performs well under
load. I haven't tied up all potential leaks yet, but the normal
execution paths seem to be clean. I also need to use proper shell
option management.
The bridge adds about 0.569ms to an average request, which is the same
overhead I see from a normal, local-network Ethernet hop.
This is with it wrapping nginx using Fedora's default nginx
configuration and default homepage:
[straussd@olympian straussd]# ab -n1000 -c10 http://localhost:8080/
This is ApacheBench, Version 2.3 $Revision: 1430300 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software:nginx/1.4.2
Server Hostname:localhost
Server Port:8080
Document Path: /
Document Length:3700 bytes
Concurrency Level: 10
Time taken for tests: 0.192 seconds
Complete requests: 1000
Failed requests:0
Write errors: 0
Total transferred: 3933000 bytes
HTML transferred: 370 bytes
Requests per second:5214.39 [#/sec] (mean)
Time per request: 1.918 [ms] (mean)
Time per request: 0.192 [ms] (mean, across all concurrent requests)
Transfer rate: 20027.53 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect:00 0.1 0 2
Processing: 02 0.4 2 4
Waiting:01 0.3 1 3
Total: 12 0.4 2 4
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 2
90% 2
95% 2
98% 3
99% 3
100% 4 (longest request)
For comparison, here is direct nginx over TCP:
[straussd@olympian straussd]# ab -n1000 -c10 http://localhost:80/
This is ApacheBench, Version 2.3 $Revision: 1430300 $
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software:nginx/1.4.2
Server Hostname:localhost
Server Port:80
Document Path: /
Document Length:3700 bytes
Concurrency Level: 10
Time taken for tests: 0.135 seconds
Complete requests: 1000
Failed requests:0
Write errors: 0
Total transferred: 3933000 bytes
HTML transferred: 370 bytes
Requests per second:7411.52 [#/sec] (mean)
Time per request: 1.349 [ms] (mean)
Time per request: 0.135 [ms] (mean, across all concurrent requests)
Transfer rate: 28466.34 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect:01 0.1 1 1
Processing: 01 0.2 1 2
Waiting:01 0.2 1 2
Total: 11 0.2 1 3
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 2
95% 2
98% 2
99% 2
100% 3 (longest request)
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
/***
This file is part of systemd.
Copyright 2013 David Strauss da...@davidstrauss.net
systemd is free software; you can redistribute it and/or modify it
under the terms of the GNU 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 General Public License
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
#define __STDC_FORMAT_MACROS
#include errno.h
#include ev.h
#include stdio.h
#include stdlib.h
#include string.h
#include netdb.h
#include sys/fcntl.h
#include sys/socket.h
#include sys/un.h
#include unistd.h
#include log.h
#include sd-daemon.h
#define BUFFER_SIZE 1024
unsigned int total_clients = 0;
struct proxy_t {
int listen_fd;
bool remote_is_inet;
const char *remote_host;
const char *remote_service;
};
struct connection_t
Re: [systemd-devel] Early review request: socket activation bridge
On Tue, Oct 8, 2013 at 4:12 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: how do you intend target service to be started? I understand that the intended use case case is for non-socket-activatable services, so they should be started synchronously in the background. In case of local services normal systemd management (over dbus) would work. In case of remote systems, maybe too, if dbus over the network was properly authorized. Do you havy any plans here? I attached the service unit, socket unit, and the shell script I'm using to integrate nginx with the sabridge utility. That's part of why I didn't just send a git patch from the systemd tree alone. I forgot to note that PrivateNetwork does work in the service unit; I only disabled it to benchmark the control of Apache Bench directly against nginx. Here's what the script does: (1) Starts nginx (2) Waits for nginx's PID file (3) Starts the bridge A future version might integrate the first two into the bridge to streamline usage. Why not implement this using startand epoll loop? libev uses epoll on any kernel systemd supports. The abstractions don't cost must in overhead (compared to libevent) and are useful. For example, libev bundles convenient signal trapping and can also cleanly exit on ev_unloop(). It also has thread/loop-integration facilities if we ever want to support multiple threads. Since you're proxying all data transfered in both directions, why disallow multiple sockets? There's no reason it couldn't scale to any number in future versions. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
I should also mention that the way I've integrated libev in the autotools chain makes it optional. If you don't have it, you just won't get the bridge utility. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
On Tue, Oct 8, 2013 at 4:56 AM, David Strauss da...@davidstrauss.net wrote: There's no reason it couldn't scale to any number in future versions. Sorry for the copious replies, but I have another thing to add here. The current design doesn't rely on globals; it passes all state up the stack in the watcher data. This makes adding additional socket-to-backend mappings trivial. We'd just need to call the ev_io_init() + ev_io_start() pair in run_main_loop() for each mapping. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early review request: socket activation bridge
The bridge won't relay traffic until it gets a connection. This is also no worse than the situation with other systemd services. On Oct 8, 2013 3:28 PM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 08/10/13 08:56, David Strauss escribió: (2) Waits for nginx's PID file hold on there, are you aware that almost no software available creates this pid files in a race-free fashion ? -- If debugging is the process of removing bugs, then programming must be the process of putting them in. - Edsger Dijkstra ___ 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
[systemd-devel] Haskell support for socket activation
David Fisher has kindly informed me that high-level socket activation support is now available for Haskell developers! http://hackage.haskell.org/package/socket-activation -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to completely clear journal?
On Tue, Oct 1, 2013 at 11:48 PM, Manuel Reimer manuel.s...@nurfuerspam.de wrote: So long story short: How to tell journald to just forget all previously logged stuff? Can I safely delete anything below /run/log/journal? Will this really clear the log (journalctl no longer returns anything after that)? Do you really need to clear it? Presumably, the system has to meet its memory constraints just before you dump the logs. What is the advantage of freeing memory that the system has to account for, anyway? If it's just to know when the last dump was, you can use the journal's cursor data or record a special log entry just before you dump. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to completely clear journal?
Instead of doing your own compressed dump to flash, how about this: (1) Enable persistence. (2) When you want a backup, force rotation by sending the journal SIGUSR2 [1]. (3) Copy away the rotated journal file and delete it. This would allow getting entries in a way that's compressed and never duplicated between files. [1] http://www.freedesktop.org/software/systemd/man/systemd-journald.service ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to completely clear journal?
On Wed, Oct 2, 2013 at 2:04 AM, Manuel Reimer manuel.s...@nurfuerspam.de wrote: Another option seems to be to store a timestamp in memory and use --since. Maybe this is even more error proof as a cursor could maybe get invalid if the log really exceeds my 1M limit. If your cursor's invalid, that probably means you've missed some items. That might be worth knowing rather than silently handling. You can always fall back to fetching all if the cursor has rolled out of memory. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Journalctl performance
On Tue, Oct 1, 2013 at 6:13 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Ouch 5s for a status is nasty. We regularly see this on our production systems. Yes, it's unfortunate. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 208
And, of particular importance to some high-density users: unit ordering reworked around a hashmap that scales much better with large numbers of Unix socket and mount units. Initial testing shows daemon-reload times dropping from 8+ seconds to under 2 with thousands of mount+automount unit pairs. Further work on this is still ongoing. Thanks Lennart! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd hackfest at FOSDEM 2014/Brussels or devconf.cz 2014/Brno?
I would strongly prefer Brussels for travel reasons. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a dependency to a systemd.mount that is activated by /bin/mount?
It's also possible to create your own file system type. mount (including via systemd mount units) simply invokes /usr/sbin/mount.YOURTYPEHERE as root. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Actually fix capability logging when effective caps are 0
The larger backtracking (t -= 2;) makes assumptions about the source data and pattern that make Zbigniew and me uneasy. Zbigniew apparently has a bunch of tests in this area that should land soon. We can take a fresh look then. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util, fileio: do not use get_status_field() for get_process_capeff()
Does this supersede your earlier patch for get_status_field()? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Actually fix capability logging when effective caps are 0
Committed, including the spelling fix. signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Environment or an environment file with empty variable value
On Wed, Sep 18, 2013 at 7:25 AM, Belal, Awais awais_be...@mentor.com wrote: Is this the intended behavior? Yes: If the empty string is assigned to this option, the list of environment variables is reset, all prior assignments have no effect. [1] [1] http://www.freedesktop.org/software/systemd/man/systemd.exec.html -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest at Linux Plumbers Conference?
On Wed, Aug 14, 2013 at 11:11 PM, Harald Hoyer harald.ho...@gmail.com wrote: Linux Foundation is looking into it. Right now they don't have space, but they are trying to find something for us. We should know early/mid next week. Any word on this? -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest at Linux Plumbers Conference?
On Tue, Aug 13, 2013 at 7:36 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Is this definite? With 10 RSVPs, we'll make it happen. I added the G+ event after Kay said, The current idea is to do [a hackfest] during the two LinuxCon days before Plumbers starts. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest at Linux Plumbers Conference?
However, I should ask if we have space formally reserved yet. I'm willing to go in on costs here if we need that. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] travis: Add a travis.yml for doing CI after commits
On Wed, Aug 14, 2013 at 2:15 PM, Kay Sievers k...@vrfy.org wrote: Maybe someone has an idea, or an alternative. The CI I maintain [1] for systemd is certainly one alternative that continues to be in production. I'd like to get more test automation going, but it's not like TravisCI was running any tests beyond a successful build. I plan to continue maintaining the Jenkins CI, if only to ensure the systemd GitHub mirror is always buildable on the master branch. [1] http://systemd.getpantheon.com/ -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest at Linux Plumbers Conference?
On Tue, Aug 13, 2013 at 1:16 PM, Kay Sievers k...@vrfy.org wrote: The current idea is to do that during the two LinuxCon days before Plumbers starts. Thanks. That's all I need to know for booking. I'll edit the systemd wiki if it's not already there. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest at Linux Plumbers Conference?
On Tue, Aug 13, 2013 at 1:23 PM, David Strauss da...@davidstrauss.net wrote: Thanks. That's all I need to know for booking. I'll edit the systemd wiki if it's not already there. I noticed there wasn't a G+ event for it, either. So, I made one [1] and posted it to the Hackfest section of the systemd wiki. [1] https://plus.google.com/events/ce60f0rq4lldbti9qgg0u4j8rbc -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Hackfest at Linux Plumbers Conference?
Are there any plans? -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Lightweight OS for containers based on systemd
On Mon, Aug 5, 2013 at 12:59 AM, David Strauss da...@davidstrauss.net wrote: I'll be following up with them to see if there are good coordination opportunities, especially around socket activation, security isolation, and resource management. We're meeting Monday afternoon at my office downtown. I'll post a summary back here afterward. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Lightweight OS for containers based on systemd
CoreOS [1] is a systemd-centric mini-OS based on distributing applications as containers. I'll be following up with them to see if there are good coordination opportunities, especially around socket activation, security isolation, and resource management. Containers are a major professional focus [2] for me. [1] http://coreos.com/ [2] http://www.linuxjournal.com/content/containers%E2%80%94not-virtual-machines%E2%80%94are-future-cloud -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .automount from user?
On Mon, Jul 29, 2013 at 10:02 PM, rekt...@voodoowarez.com wrote: Hello. I'm curious, and perhaps maybe lazy: is there any way to do automount units from a user systemd instance? I don't think this is possible given the security model around automount. Specifically, the automount needs to associate with a mount unit to invoke the mount command as root. It would seem possible to use it with a new UID namespace, but such capability is very new and disabled in kernels like Fedora's. You could also just treat FUSE mounts as normal services in the user account. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does systemd have points to spend many times to complete its process?
Please don't send HTML mail to this list. On Thu, Jul 25, 2013 at 4:58 AM, Tony Seo tonys...@gmail.com wrote: 1. what is -.mount ? when I first saw -.mout, I was confused how to configure it. You configure it from the /etc/fstab entry for the root file system, which then generates that unit during boot-up. The unit is only present for the sake of consistency and dependency management. 2. I doubt that there are critical points which make systemd more delayed for several reasons. I have tried to test my systemd for optimization in perspective of time consume. So, I changed the order of unit dependency and sequence among units. But I found that I may not reduce the time to activate getty.target, multi-user.target and graphical.target. And I doubt that there are critical points or span of stage to make the systemd more delayed. I want to know whether I'm wrong or not. what do you think about it? systemd eagerly starts any unit wanted or required, and it does so with maximum parallelism. In other words, it keeps the boot hierarchy as flat as possible to minimize startup time overhead caused by waiting on dependencies. systemd introduces a couple mechanisms to increase parallelism: (1) the ability to want or require other units without waiting for them to finish starting (no assumed After=) and (2) socket activation. If you know some tip to improve a systemd in optimize perspective, could you give some tips to make my systemd more fast? You should use systemd's boot chart [1] and analysis [2] tools. 3. I need a clear knowledge about transaction stage. I read a manpage which introduces a few contents of transaction, but I would like to get more information about it. A systemd transaction is simply the idea that the operation is only successful if the main operation and its dependencies succeed. If service A requires service B, you start service A, and the not-yet-running service B fails to start, the transaction fails. [1] http://www.freedesktop.org/software/systemd/man/systemd-bootchart.html [2] http://www.freedesktop.org/software/systemd/man/systemd-analyze.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does systemd have points to spend many times to complete its process?
Oh, just noticed your attached boot chart. That definitely doesn't look right, but I'm not really sure what the problem is. It looks like no single service is blocking the other services, just that a ton of things already running in parallel are taking excessive time. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Profiling systemctl daemon-reload
With thousands of units, doing a daemon-reload puts a surprisingly huge CPU and memory burden on the system. Has anyone profiled why? I'd like to get started on optimizing this, but I'll obviously need to understand where the problem is first. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] cgroup changes
On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering lenn...@poettering.net wrote: As long as you only used the high-level options such as CPUShares, MemoryLimit and so on you should be on the safe side. This is already representative of how we're doing thing in large-scale production and how we recommend other users use cgroups on systemd-based distributions. So, +1. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Go socket activated http server example
Exciting! You should post this to the systemd group on Google+. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] We are working on trying to scale up to 1000 containers.
In our case, the issue wasn't kernel process creation; it was the CPU and I/O overhead of service start-up. At some point, the system gets dominated by context-switching, and throughput suffers. For example, you certainly wouldn't want the box to go into swap because of start-up allocation spikes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] We are working on trying to scale up to 1000 containers.
On Mon, Jun 24, 2013 at 9:55 AM, David Strauss da...@davidstrauss.net wrote: For example, you certainly wouldn't want the box to go into swap because of start-up allocation spikes. I should clarify: that's not a context-switching example. It's just another case where throttling might help. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] We are working on trying to scale up to 1000 containers.
We have machines with thousands of containers on them. The key for us was understanding that we didn't need thousands of containers to run after start-up; we needed thousands of containers to be *accessible* after start-up. The vast majority of our containers use socket activation or resurrection (a sort of try-to-do-something-and-start-the-corresponding-service-on-failure path we use). That said, I'd be interested in allowing caps on parallelism in systemd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
On Tue, Jun 18, 2013 at 10:23 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: Therefore, the .service daemon should NOT unlink the socket. And you can generally prevent the service from having the service unit drop permissions to something that can't delete the socket. The service get get the fd from socket activation and accept connections on it even if it doesn't have permission to unlink the socket. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature wish - auto-complete
It definitely works for me on Fedora, but it's terribly slow with 1000+ units. I've been meaning to look into that. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start/stop messages when activating a target?
On Tue, Jun 11, 2013 at 10:59 PM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
Not for me. systemctl {start,stop} anything never prints anything.
I think it prints status in the Unix way: stderr explanation on
failure and nothing on success.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Sprint/Hackfest at Linux Plumbers Conference?
On Thu, Jun 6, 2013 at 2:01 AM, Lennart Poettering lenn...@poettering.net wrote: We'll also have a hackfest at GUADEC in Brno, btw. I'm looking into my travel options right now. I'll be especially interested if we can work for three or four of the hacking days. As I know the LPC folks it should be fairly easy getting a room assigned a day before or after the conference for this kind of stuff. I'll ask them as soon as we have the boot MC settled. Great. I'm already booked to be at LPC again this year. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Sprint/Hackfest at Linux Plumbers Conference?
On Thu, Jun 6, 2013 at 10:15 PM, David Strauss da...@davidstrauss.net wrote: I'll be especially interested if we can work for three or four of the hacking days. To clarify, I mean if systemd developers are hacking together for at least three of the days. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
I'm skipping to the questions I can answer. On Sat, May 18, 2013 at 2:44 PM, Michael Scherer m...@zarb.org wrote: - we should avoid as much as possible to use Type=forking when we can avoid it. This one is likely the one that will be met with resistance from packagers, so before adding it as warning, I would like to be sure that I am not totally wrong. A standard daemon will fork ( likely twice ) in the background, do various stuff and then write the pidfile on /run. By not going in the background, we can : - avoid forking 1 or 2 times for nothing, - avoid taking memory for /run, and avoid taking a inode So that's should be a little bit better in most case, or do I miss anything ? ( ie, something like this is so negligible that we shouldn't care ) That's not correct. Doing Type=simple services is generally undesirable because they lack proper support for dependent units only starting after startup completes (versus when startup begins, which is all systemd knows about a Type=simple unit). Type=notify is the most desirable because it gives the benefits you list for Type=simple but still allows proper dependency effects. However, Type=notify requires use of systemd APIs from the daemon's own code. If a service is socket-activiated, though, dependencies on the service itself are generally unnecessary, as units can depend on the socket instead. In such situations, Type=simple is quite good, with Type=notify offering almost only academic advantages over Type=simple. - if using Type=forking, it is better to use PIDFile, While systemd seems to support fine to guess the main pid, I think this should be avoided when possible , according to http://lists.freedesktop.org/archives/systemd-devel/2011-June/002690.html . So does it make sense to send a warning if there is a service that do not use PIDFile and of type Forking ? Absolutely. While the guessing behavior is solid, any packager should be able to set this explicitly. - some package install directly file in /usr/lib/systemd/system/*.wants There is some special case ( like plymouth ), but usually, that shouldn't be done directly in the package, but better done in %post, and in /etc ? No, the systemd ideal is that packages should not ever install systemd units or settings into /etc. Lennart's long-term goal is for daemons to not install anything by default to /etc, but I think our scope of authority in this discussion ends with systemd-related matters. IE, is this right to make a warning or a error when that occurs ? It should be an error. I was also interested into checking the syntax of systemd file, but since systemd is moving quite fast, I doubt to be able to keep a up to date parser of unit/service/timer/snapshot files. And duplicating code of systemd in python do not seems like a smart move. It should be possible to invoke something in systemd to sanity-check the included unit files. Is it okay if the Python invokes a subprocess? If not, I work to add unit file sanity checking to the C APIs and extend our Python bindings. I didn't found any way to reuse systemd code, but I think that a tool like desktop-file-validate would be quite useful for all distributions. Agreed. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
On Sun, May 19, 2013 at 12:10 AM, Andrey Borzenkov arvidj...@gmail.com wrote: Do you mean, installing directly under /usr/lib/systemd/system/*.wants should be an error? It was the actual question. I do not think there is single answer in all cases. IMHO it is perfectly valid to use /usr/lib/systemd/system/*.wants to express inter-services dependencies. If service A needs services B and C to work, they should be installed as /usr/lib/systemd/A.wants, so starting A also transparently starts them. An RPM installing systemd-related files to /etc should produce an error. RPMs should install their systemd files to /usr/lib/systemd (or equivalent if that's not the unified systemd installed file location). -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
On Sun, May 19, 2013 at 12:10 AM, Andrey Borzenkov arvidj...@gmail.com wrote: Do you mean, installing directly under /usr/lib/systemd/system/*.wants should be an error? It was the actual question. Wait, do you mean versus putting WantedBy= into the unit? That depends on packaging policy. RPM packaging policy is to not have services start by default, so I'd recommend using WantedBy= so systemd computes the dependencies at the time the administrator enables the service -- if she enables it at all. If service A needs services B and C to work, they should be installed as /usr/lib/systemd/A.wants, so starting A also transparently starts them. If service A *needs* B and C, then service A should use Requires= and possibly After= for B and C, not wants. A want in system still allows the transaction to complete even with dependency failure. We generally use wants for startup and shutdown targets so the system can still boot to those stages even with a service failing. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
I hopped in IRC just now if you'd like to chat. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trusting systemd vs. trusting daemons
On Thu, May 16, 2013 at 11:39 PM, Aaron Faanes dafr...@gmail.com wrote: So my question, simply, is this: Should I prefer running a process as root knowing that it chroots itself, or should I run it as non-root and chroot it via systemd? I support the trust systemd; don't trust the daemon model going forward. It's not because systemd has impeccable security, it's because of the following: * systemd contains one heavily reviewed implementation of privilege management, while daemons get varying levels of scrutiny. rsync has probably received decent scrutiny here. * Many daemons drop privileges using set seteuid(), which leaves open a root escalation path if someone finds any arbitrary execution exploit in the daemon. * If you're an administrator, you're more likely to get things right if you learn a common way to configure things with systemd rather than learning each daemon's own model. * systemd supports restrictions that are generally more powerful than simply dropping root privileges and chroot. You can also integrate with MAC frameworks and syscall filtering. * Most restrictions systemd puts in place actually just configure restrictions managed in the kernel (whether UID-based, selinux-based, or syscall filtering-based), so you're not changing the attack surface for systemd-managed security versus daemon-managed security. systemd has a suite of tools to enable services to have fewer permissions than every before, even in terms of the directories they'd need access to: * The systemd simple service model doesn't require PID files. * The journal allows advanced logging without access to files. Access is only necessary to stdout/stderr, the syslog socket, or the journal socket. Logs get automatically bound to the applicable service. * Socket activation, as you noticed, allows a service to listen on any port without starting as root. * Resource limits can get set by systemd without the daemon needing to make such syscalls. While I'm at it, one thing I'd like to do is construct a whitelist like this: InaccessibleDirectories=/ ReadOnlyDirectories=stuff I'm serving This is a great question, and something I've wondered myself. It shouldn't be hard to try empirically. Don't forget SecureTmp= and PrivateNetwork= as well. The former is just good sense, and the latter should work well if the only network communication rsync needs to do is over the socket systemd passes in. I would run this service using systemd-nspawn if I wanted to maximize security at the cost of simplicity. systemd-nspawn isn't designed for secure containerization, but I'd have to search a bit to enumerate why. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] build problems without largefile support
On Wed, May 15, 2013 at 11:49 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: The constants for T/P/E don't fit in a 23bit off_t. That's why largefile was introduced in the first place. I'm not sure how to fix this. Maybe just use 'ifdef' and not support those formats? That sounds reasonable to me. The lack of support for the T/P/E units on non-largefile builds should be then documented in the man pages. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Sprint/Hackfest at Linux Plumbers Conference?
I'd definitely like to do one, and I assume we'll have the systemd leads on site. Should I contact the LPC folks directly? -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora 16 and upstart
On Sat, May 4, 2013 at 3:14 AM, Mirco Tischler mt...@gmx.de wrote: No this won't work. Systemd is not a shell. Simply write a bash script where you do all your stuff and then put that as the ExecStart line. Many shell built-ins have real execuables, too. Just run which on them. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
I don't recommend spawning user instances of systemd just for their timer units to run. Each instance comes with a few MB of overhead, and you'll have no fun trying to spawn sessions in a way isolated from (but somehow integrated with) the PAM session initialization process. On Mon, May 6, 2013 at 3:14 PM, Kai Krakow hurikha...@gmail.com wrote: Jóhann B. Guðmundsson johan...@gmail.com schrieb: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... That's the obvious solution but a little bit counter-productive with respect to my question... Anyway, one has to take that route if everything else fails. Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
