Re: [systemd-devel] [RFC] socket-proxyd: resolve addrinfo using sd-resolve
It's not ridiculous, but it's also no better. This patch still blocks the main event loop during each lookup. Proper integration of non-blocking lookup would involve using sd_resolve_get_fd() to integrate with the main event loop. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker, Supervisor and systemd
On Thu, Feb 20, 2014 at 2:25 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Or is there a reason why systemd should not be used for that? Distro portability, but that's rapidly dying as a reason. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statically linking systemd-socket-proxyd
On Thu, Feb 27, 2014 at 12:35 PM, Vincent Batts vba...@redhat.com wrote: Can we get a Makefile target for compiling the systemd-socket-proxyd as statically linked? For it to be portable for any guest container. I think that would be neat. While I wrote much of that proxy, I'm not versed well enough on linking and our toolchain to do static linking work myself. I'd happily review a patch, though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support
This is a lot of code, and this approach is largely obsoleted by link-local IPv6 addressing, which also has the benefits of being simpler, deterministic (at least with RFC 4862), and collision-proof. Both Apple [1] and Microsoft [2] prefer IPv6 link-local as the best practice. Is it really that important to support self-assigned IPv4? [1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/NetServices/Articles/about.html [2] https://blogs.technet.com/b/jlosey/archive/2011/02/02/why-you-should-leave-ipv6-alone.aspx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
I'll be attending the Linux Storage, Filesystem MM Summit in March. Are there any topics germane to systemd I should put on the agenda or discuss with other folks there? Things I have in mind so far: * Next steps for mount and automount units * That's it so far. I'm mostly attending for my company's FuseDAV/Valhalla work, but I'd like to effectively represent systemd as well. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to build systemd with statically linking
On Sat, Mar 1, 2014 at 12:46 AM, 황재영 j-zero.hw...@samsung.com wrote: I've tried to build systemd(v43) with statically linking. That version is ancient. I'm afraid you won't find much help with it here. Have you tried a newer release? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: add startup resource control option
When is startup considered over? I'd like if it meant before the WantedBy unit was started so this value still has use for arbitrary startup. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd-bootchart - fix spacing in command
Applied. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Talks comparing systemd and launchd.
On Mon, Mar 3, 2014 at 5:47 PM, David Farning dfarn...@gmail.com wrote: Several of the ground breaking ideas in systemd seem to come directly from launchd. systemd makes no claim to be original or ground-breaking with many of its ideas. As you mention, some come from launchd. Others come from Solaris service management. I don't know any presentations off the top of my head drawing direct comparisons, though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Talks comparing systemd and launchd.
On Thu, Mar 6, 2014 at 2:57 PM, David Farning dfarn...@gmail.com wrote: Now my philosophical sticking point is how big pid1 should be to do what it needs to do. Practically, I am trying to understand where those boundaries should be and how to communicate that information. A large amount of systemd's code does not run in PID 1. Are you referring to systemd's code or PID 1 in particular? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Forwarding logs to another systems journal
On Thu, Mar 13, 2014 at 12:54 PM, Anand Neeli anand.ne...@gmail.com wrote: I have multiple systems, How do i forward logs from one system running systemd-journald to another remote systems journal service, so that all the logs are stored on a centralized machine. Have went through systemd-journal-gatewayd, but this forwards logs on http/https, doesnt send it to another remote systems journal. can this be done only using systemd services? without using syslog-ng or any other tools? can anyone please give more details. If this is already answered then pls point me to the mail thread. You'll really want to use a more sophisticated aggregator than the journal. We use Kibana [1] with journal2gelf [2]. [1] http://www.elasticsearch.org/overview/kibana/ [2] https://github.com/systemd/journal2gelf ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journal-remote
On Sun, Mar 16, 2014 at 11:29 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Curl requires the whole file to be exported first, which isn't great, because it wants to give the content size in the header. I'm note sure if it is possible to tell it to not do that. I'm think you just need to implement your own function to use with CURLOPT_READFUNCTION and set a chunked encoding header [1] instead of giving libcurl an actual file to upload. You can return zero when you're done sending everything you want to send. [1] http://curl.haxx.se/libcurl/c/post-callback.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restarting a socket starts the associated service
It's already reported (by me): https://bugs.freedesktop.org/show_bug.cgi?id=75185 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default
On Mon, Mar 24, 2014 at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: So on Fedora tcpwrap is unlikely to go away soon. Not necessarily. We just decided this morning in the server working group that we would only include it if base OS insists: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-25/fedora-meeting-1.2014-03-25-15.00.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
Other than for zswap discussions, I spent the whole time on the storage and file system side. I've filled in the topics that came up (or I could topically ask about), and I have some good contacts now if answering any others proves essential. Outside the file system/MM space, at least one Ganesha developer is working on a comprehensive credential-setting/caching syscall that might be useful for systemd's privilege dropping for starting services. It would set credentials and return an fd that is usable to rapidly set the same credentials again. He's planning on stuffing the file descriptors into an LRU cache to both reduce syscalls and accelerate the application of credentials in the kernel. His work is focused on FS permissions, but it would make sense for it to be available for general ones, too. It may be useful to see if we can use Trinity for kdbus and systemd testing. On Thu, Feb 27, 2014 at 3:09 PM, Lennart Poettering lenn...@poettering.net wrote: - quota for tmpfs - saner autofs elapse logic (no blocking ioctls...) - uuids for btrfs subvols - a umount (or maybe last-change) timestamp in the btrfs superblock, which we can use to initialize the system clock from if a machine lacks RTC or has a dead battery. Even better: a unified ioctl() to query this from all file systems the same way. - fanotify: accessible to unprivileged users I asked about the state of this given Ganesha's userspace operation. I don't think there are any changes. Many services using fanotify seem to require root privileges for other reasons, too. - fanotify: events for renames - fanotify: pass info about open() flags to monitoring processes - fanotify: when getting getting a notification for close, actually get information whether the file was changed or not - an ioctl-based way to change FAT file system labels - cheaper xattrs. currently querying xattrs on most file systems is prohibitively slow, since it results in seeks and whatnot. Which has the result that pretty nobody uses them. One way to make things better would be to maybe expose in some fstat2() call a flag whether there even are xattrs, so that apps could check for that flag before actually trying to read them This is being suggested as a readdir+ enhancement for Ganesha's sake. It would only be a flag that xattrs exist. - An API to query the birthtime of files. ext234 actually stores that and keeps it up-to-date, but there's no API to get to this data - An fsetxattrat() call, so that race-free selinux relabelling can be done - a way to mark an entire tree of mounts read-only with one call. i.e. a working combination of MS_REC|MS_RDONLY - Allow creating read-only bind mounts in a single mount() invocation, instead of requiring two. Similar, a way to set the propagation settings for a mount when one creates it, rather than requiring two mount() invocations for that. - Swappiness control for individual pages via madvise() - volatile ranges There was a session on this, but I went to Direct I/O instead. - A better SIGBUS/SIGSEGV API (for accessing invalidated memory maps), that actually works for libraries. i.e. a sane way how libraries can register handlers for specific memory regions they maage. Currently there can only be one handler for the entire process which makes this totally unavailable for libraries, since they'd always step on each others toes. Probably hard one to get into the brains of kernel guys, since for them that is a userspace problem. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to start Sendmail Mail Transport Agent
On Fri, Mar 28, 2014 at 12:41 PM, Lee Atkinson linuxle...@gmail.com wrote: .reading the Fedora 18 Users Guide Fedora 18 is not a currently supported release, and its systemd is ancient by this mailing list's standards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql
Oh dear. Perhaps there's a way to use cgroups data to more selectively do cleanup when there's overlap between regular users and service users? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] use systemd.debug on the kernel command line, not debug
On Thu, Apr 3, 2014 at 12:03 PM, Florian Albrechtskirchinger falbrechtskirchin...@gmail.com wrote: Both you and Tom Gundersen raised the point of assisting end-users with boot issues. 'dbg' (as suggested, shorthand for 'dbg=kri') is as concise and simple as it gets. -1 on this because it moves in the opposite direction of namespace clarity. systemd should not use both more verbose, namespaced versions of kernel options and abbreviated, non-namespaced versions of the same. At least do sd.dbg or similar; we already use sd as a namespace prefix elsewhere. With respect to the main change suggested in this thread, I'm a +1 for systemd.debug, especially because it's consistent with log level options. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] run systemd-tmpfiles-clean only when we have AC power
-1 on adding ConditionACPower=true I frequently only plug in my laptop after putting it to sleep and then disconnect it before waking it up again. It'd be possible to run cleanup less frequently when on battery, but that would just delay the work and increase the impact (which is pretty negligible right now) when it happens. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug
On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu wrote: init.debug would be better than systemd.debug, in my opinion. It is shorter (less typing and no possible end-user confusion over systemd.debug vs. system.debug), and it is init-agnostic. Other init systems (OpenRC, Upstart, etc.) would be able to add their own support for this, if they want, without requiring an init-specific kernel parameter. It just seems a lot simpler this way. It would be a little odd given how systemd.name is how other probably portable options get namespaced. Arguably, systemd.log_level would become init.log_level. I'm not against it, but it couldn't be just init.debug. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two git trees
On Tue, Apr 8, 2014 at 5:30 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I think it is synchronized after successful jenkins runs, so it is always buildable and unit tests pass. That's my GitHub mirror, not anything on freedesktop.org. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two git trees
On Tue, Apr 8, 2014 at 11:31 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: https://github.com/systemd/systemd is not yours? Nope, that's mine. You were right. I misread the two trees as the authenticated and anonymous git on freedesktop.org for some reason. They were out of sync because CI broke. It should never be more than 30 minutes behind unless master is broken on freedesktop.org. Fixing it now. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two git trees
CI is back online, but test-dhcp-option is currently failing, so it won't update on GitHub until that's fixed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroup: After MemmoryAccounting=yes running scope has no memusage
+1 from me. Seems like a good bugfix. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Two git trees
Tests are back to passing, so GitHub is now in sync with the freedesktop.org git. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql
On Thu, Apr 10, 2014 at 9:01 PM, Lennart Poettering lenn...@poettering.net wrote: Yuck, I figure we need to ignore RemoveIPC for all system users, not just for root. This still seems dangerous to me. I'm sure I have services running under users where I've forgotten the system flag for the users. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql
Maybe if any service is running something as a user *or* it's a system user, that user is immune to RemoveIPC? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ systemd-devel ] [PATCH] Fix Bug 72611 (systemctl is-enabled scales poorly with many units
Posting here for discussion at the systemd hackfest today. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.
This is a completed version of the patch Lennart and I worked on at the hackfest. The version we worked on had separate string arguments for each type of state. This patch harmonizes it more with the way systemctl --state already works, which is an array of possible states to match across all state types. ListUnits is retained for API compatibility, but systemctl is updated to always use ListUnitsFiltered, even with an empty array. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disable timers
systemctl disable or systemctl mask. You also have to stop it first, as that only changes the default. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timer: allow user to control activation time of cron-like timers
On Sun, May 11, 2014 at 9:30 AM, Alex B pkunk...@gmail.com wrote: It's ok for one timer, but not for the set of them. In general I'm want to schedule all maintenance tasks to 5 a.m. or lunch break and forget about them. This applies both for distro provided timers an my own. I'd personally like sort of timer that activates at times of low system load but with quality-of-service guarantees, like never running less frequently than once a day. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.
Bumping this for review. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User and Group permissions for .socket files
An alternative workaround is to put the socket into a directory that has the permissions desired. If you can't read the directory, you can't use a socket in that directory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timesyncd, dnssec
On Wed, May 21, 2014 at 5:48 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: Temporary work around is to hard code IPs into NTP. It'd be neat to do the following: (1) Do a DNS lookup for NTP servers, fetching DNSSec information. (2) If a signature/clock sync issue is the only barrier to validating the response, still use the response for the next couple steps. (3) Fetch time from the NTP servers, but only use it to validate the DNS response signatures. (4) If the signature now checks out, sync the local clock to the data. Code could ship minimum timestamps to accept in step #3, thereby ensuring that malicious, replayed responses are never older than the release itself. This is superior to shipping fixed IPs because this algorithm ensures the IPs are *at least* as fresh as the release rather than *exactly* as fresh as the release. It's a shame that there's no provision in DNSSec for a server creating custom-signed responses based on a client nonce, just for this sort of case. That would only require the ability to generate one-time values, even if it's just a MAC address plus a counter. Might be an easy way to DoS attack DNS servers, though, by breaking through caches and forcing lots of signing work. Wouldn't work with servers supporting only offline signing, either. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to escape from systemd slice
One of the cleanest ways to do what you want is to create a D-Bus-activated systemd service (or socket-activated, if that's more appropriate). That allows activation completely outside the user's session without elevated privileges. Of course, it requires considerable work for each service to do it right. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: use KillMode=process for systemd-nspawn@.service
Is there a downside to using KillMode=mixed instead? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
The CoreOS crew has already done most of this work by writing a native Go implementation (rather than wrapping the C APIs). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
On Tue, Jun 10, 2014 at 6:07 AM, Dan Mace dm...@redhat.com wrote: Which only handles writes via the Unix socket. The implementation we're prototyping supports journal queries in ways that (to my knowledge) aren't possible without either forking to external tools (e.g. journalctl) or linking to sd-journal. If there's already code out there which satisfies the need, I'd be happy to use and contribute to it. I just pinged someone from CoreOS to hopefully shed more light on this. What you linked on GitHub is what I remember from LinuxCon in New Orleans. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd: Prepend static nameserver to DHCP-discovered nameservers
On Tue, Jun 17, 2014 at 4:33 AM, Mantas Mikulėnas graw...@gmail.com wrote: I mean, as long as the first-listed server responds – and localhost always responds – then the fallback servers won't be used at all. Localhost can be subject to two types of failure: * The local daemon being down. * The resources the local daemon uses being inaccessible. It is possible for root servers, for example, to be inaccessible while the DHCP-issued nameservers can still be. Not all local daemons will prefer to use the DHCP-issued nameservers as their upstream, particularly if DNSSec is preferred/required. Therefore, it can be useful to have a local daemon followed by fallback to using the DHCP-issued nameservers. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add DEPLOYMENT to hostnamectl
As someone who deploys developer VMs and production ones, this is useful. Will it be possible to make units have ConditionDeployment=? That would allow disabling, say, pushes of log messages to our log aggregation servers from development and testing deployments. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Extending machine-info to include machine roles
I don't see much value in choosing a role from a predefined list. Rarely do machines fit into one single, straightforward role. It would be more useful to support machine tags/labels/roles that map to units, especially if that's dynamically configurable using, say, DHCP(v6). Then, something may be WantedBy=nameserver.role. That would support both livestock deployments with a standardized /usr and pet deployments where admins sign on and may enable roles shipped with the distribution. Then again, I don't see how those would be different from shipping more unit.target files and adding some method to dynamically enable them. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Improve xz compression performance.
+1 on anything that makes the journal faster on heavy workloads. It remains a major bottleneck on our systems. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Seeking advice for configuring SystemCallFilter=
Is there a good way to empirically determine the additional calls required for an application, sort of like selinux permissive mode? We're often running user code on our servers, and we'd like to perform analysis and gradually roll out filtering. We'd like to be as non-disruptive as possible. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
On Sun, Jul 6, 2014 at 3:32 PM, Tom Gundersen t...@jklm.no wrote: yes is a synonym for both and no for none. These are odd semantics, given that IPv6 is completely configurable using router advertisements for even DNS information (that is, no DHCP whatsoever). Perhaps the option should be Autoconfig= with options for DHCPv4, DHCPv6, and RA and yes meaning all? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-socket-proxyd slapd
On Wed, Jul 16, 2014 at 7:29 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: This won't work, since proxyd now cannot connect to port 400. There is now a way to make that work with JoinsNamespaceOf= ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-socket-proxyd slapd
Would you be willing to post the entire unit files for everything here, just so future users can see them? Presumably, you're using JoinsNamespaceOf=proxy-to-directory-400.service in vgp.master-ldap-400.service? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use bit as unit for network card speeds
Is the code already assuming megabits in the speed variable? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use bit as unit for network card speeds
On Tue, Nov 12, 2013 at 3:27 PM, Jan Engelhardt jeng...@inai.de wrote: As far as I can see, ethtool-util.c in systemd merely passes that on to ethtool, and /usr/include/linux/ethtool.h says MBps in its comments. The capitalized B is generally bytes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use bit as unit for network card speeds
On Tue, Nov 12, 2013 at 4:06 PM, Jan Engelhardt jeng...@inai.de wrote: In any case, even if the ethtool structures awkwardly specified the use of bytes, the user-visible part should be in bits, and this patch was to give an impetus. I won't commit the patch unless there's clarity that setting the value in megabits works properly. I don't believe in breaking things to motivate progress. :-) I'm fine with us providing the setting as Mbps, but it's unclear whether that will get passed to the kernel as MBps. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: use bit as unit for network card speeds
+1 on the unit in the value. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: Allow disabling maintainer mode
Based on the autotools docs, it looks like this would change the default to enabled maintainer mode, meaning developers would need to run --disable-maintainer-mode to maintain the current behavior. Is this correct? If that's so, then maybe the suggested ./configure command from ./autogen.sh should include --disable-maintainer-mode? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: Allow disabling maintainer mode
Thanks. Applied. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: honor --no-legend in 'list-jobs'
Thanks. Applied. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] activate: mention -E in the help text
Thanks. Applied. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] activate: fix crash when -s is passed
Thanks. Applied. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: Cache controller masks and optimize queues.
I'm pretty confident in the accuracy of the controller mask aggregation, especially given the new unit test. Here are the main review questions. Is it okay to couple realizing the cgroups and applying the attributes the way the patch does? Before, we were often applying the attributes for all of a unit's siblings (read: other units in the same slice). I believe these should never change as long as the controller mask is the same as what's been realized already. Perhaps the old implementation was done to avoid re-computation of the target masks (which is no longer required). Is it okay to skip realization and attribute setting for inactive/failed units? If they do start, we will set the attributes at that time with this patch. If they're not running, giving them CPU and Block IO weights doesn't seem to have any worthwhile effect. Am I ignoring something about, say, CPU accounting (which I don't use myself)? Also, hat tip to my coworker Kyle Ibrahim for the original idea of not queuing inactive and failed units. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart instantiated services after suspend
On Wed, Nov 20, 2013 at 2:18 AM, Marcos Felipe Rasia de Mello marcos...@gmail.com wrote: ConditionFileIsExecutable=/usr/sbin/hdparm It seems sketchy to me to put the executable in ExecStart into ConditionFileIsExecutable. Is it supposed to fail silently when hdparm is missing? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart instantiated services after suspend
On Wed, Nov 20, 2013 at 3:00 AM, Marcos Felipe Rasia de Mello marcos...@gmail.com wrote: In my first attempts, I forgot to install hdparm. ;) Shouldn't you only drop the rules and service with installation of hdparm, then? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd / PID 1 leak
On Wed, Nov 20, 2013 at 5:33 AM, Oleksii Shevchuk alx...@gmail.com wrote: Any suggestions how to find the problem? Valgrind ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Just to suggest the wildly different approach I mentioned on IRC, we could treat addresses (including DHCP) as the main units and then specify the backing hardware as part of the address's configuration. This would be particularly useful for bridges. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Thu, Nov 21, 2013 at 11:48 AM, David Timothy Strauss da...@davidstrauss.net wrote: This would be particularly useful for bridges. Actually, I meant bonded interfaces, not bridges. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build fix: add RT_LIBS to link against for test-bus-marshal
I often get this when I have a dirty build. Have you tried a fully clean build? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Newbie question - Requires doesn't work properly
The service configuration is strange. Normally, this is how they work with dependencies: * Type=simple considers the service started immediately on exec() with no respect for PIDFiles or sd_notify. This can cause dependent services to come up too early. * Type=forking considers the service started when either the file specified in PIDFile= appears or when the service completes a double fork. * Type=notify is like Type=simple, except that it relies on sd_notify to indicate final startup. * Type=bus is like Type=simple, except that it waits for the dbus listener to indicate final startup. You have PIDFile= specified, which is for Type=forking. I think PIDFile= just gets ignored for Type=simple (the default). So, for one, I'd pick a more coherent startup-detection configuration. More interesting is how Myservice gets marked failed but isn't forcibly stopped. That may be why systemd isn't bringing down dependent services. Most services only get marked failed after stopping (because of a non-zero exit code, for example). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Newbie question - Requires doesn't work properly
On Thu, Nov 21, 2013 at 4:33 PM, salil GK gksa...@gmail.com wrote: 3. One more use case I can think of is - if the process fail to send heartbeat message ( WATCHDOG ) for some time and later it starts sending - because of some time. So during the time WATCHDOG notification is missing process can be marked as failed and the moment notification start coming, can it be marked as active-running ? I'm not sure, but this would be easy to test. You could also restart on failed watchdog if you want systemd to react. 4. Is there way systemd can notify me in case a watchdog timeout happens for a service - like systemd calls some program or write to some socket etc. So basically in case any service fails because of watchdog timeout, I would like to know asynchronously. Is there any way I can configure this. We typically poll systemctl --failed periodically as part of our monitoring. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Newbie question - Requires doesn't work properly
It is the responsibility of whatever sends the watchdog to ensure everything's healthy, however necessary. It would be silly to spawn a thread and have it blindly report health to watchdog. The point is for that thread to do proper checks but ensure reports go in at the right intervals. On Nov 22, 2013 7:50 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.11.2013 03:04, schrieb salil GK: Thanks a lot David On 22 November 2013 06:44, David Timothy Strauss da...@davidstrauss.netmailto: da...@davidstrauss.net wrote: On Thu, Nov 21, 2013 at 4:57 PM, salil GK gksa...@gmail.commailto: gksa...@gmail.com wrote: What happens is - my process may be busy with some other activity during which time it will fail to send periodic message to systemd. After a while it will come out of it's loop and ready to serve. But during this time system would have already marked the process as failed. Then you need to either use another thread, refactor to make a tighter event loop, or increase the watchdog time. Drifting in and out of tolerance with watchdog is not a safe strategy. the problem i see with use another thread is that this thread can happily work and send it's keep alive, but that does not mean at the end that the service itself is working OK and responsible because both are running isolated in case of network services it would be pretty cool if systemd watchdog could be configured to connect to the service avery n seconds and if there is no response restart it because this would monitor the real service without need external tools ___ 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] Newbie question - Requires doesn't work properly
On Fri, Nov 22, 2013 at 10:24 PM, Reindl Harald h.rei...@thelounge.net wrote: your internal checks are mostly theory because in case of a bug you have undefined behavior and what you want to achieve with the watchdog is catch this undefined behavior and restart the service - in doubt this will not work in the rare cases the watchdog should restart until you went the complete code-path of a client, in case of a IMAP server you can enter the spin-loop everywhere from accept the connection to folder listing or receive a message and it may depend on a buffer overflow while high concurrency and different threads are touching each other in a unexpected way You're not hearing what I'm saying. Check what's relevant; it's not systemd's concern what you check. I you need to do a transactional check of an IMAP server from a separate process or thread, then do that. Only report back to watchdog if you've verified what you consider to be a healthy state. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: Cache controller masks and optimize queues.
I'm disappointed in your response here. It's not up to your normally high standards of technical discourse and tact on this mailing list. I realize I've stepped on some feet, but there's quite a bit more to this than me getting trigger-happy with a core commit. On Fri, Nov 22, 2013 at 11:43 PM, Lennart Poettering lenn...@poettering.net wrote: make distcheck is broken now. This is clearly not the key issue here, given the following: (a) make distcheck was already failing in the test-unit-file suite before my commit (and continues to be failing in master). So, it was already broken. (b) My oversight of excluding the Makefile.am lines to bundle the test units the proper way for make distcheck was pretty minor in its effect. The test still passed make check, and I didn't block general development or use of the project. (c) In the last couple weeks, you've broken builds yourself -- not just tests -- for 12 hours [1][2]. We all make mistakes like that, but I feel like you're using mine as a way to pile on criticism here. There's a reason I emailed you privately when you broke the build that day. In any case, I fixed make distcheck [3] shortly after hearing about the issue. I'll be sure to verify lack of any regression in make distcheck before pushing in the future. I'll also add it to CI once test-unit-file is working; I don't want to break CI builds in a misleading way. I am fine if commiters commit without review if it's in their own submodule, or if it's man pages, or really obvious things. But this commit does not qualify. It touches the core, and it is far from obvious to me. First, I'm not intentionally trying to skip process. At the same time, please understand my frustration with a performance issue introduced in v205 that added hours or days to the boot times of our previously working servers. My attempts to discuss options and approaches with you at LinuxCon, on the mailing list, and IRC have only been marginally productive. Before my commit, we only had a TODO logged. Requesting reviews (by you and others) of proposed changes didn't get much response. Zbigniew was the only person I was able to flag down in any way, but he also said he has minimal familiarity with the current cgroups implementations. In an effort to improve the transparency of my changes and reduce the chance of introducing instability, I coupled my changes with improved functional testing in the key area I optimized. I then posted that patch to the mailing list including some specific (but fairly edge-case) follow-up questions, let it sit several days, and heard back nothing. I hadn't even gotten a reply suggesting that a review would be forthcoming. It includes lines like TODO which are a good indication that this isn't even thought out to the end... I also think it's unfair to characterize my work here as not thought out. (a) My changes went through testing by my ops crew to verify that scalability issues were fixed for both stopped and starting units and that cgroups still received proper configuration values and controllers, including for slices. (b) I bundled a test suite covering functionality that lacked coverage before. (c) The TODO relates to a tiny optimization. The potential improvement is so minor that the optimization is more an issue of removing redundancy for tidiness. I used a similar approach in gutting (but leaving in place for now) functions that probably aren't necessary anymore given how they just return struct values. (d) The nature of the TODO isn't massively different from other items in the TODO file. It just happens to be proximal to the related code. (e) My implementation replaced one running O(n^3) on startup for enabled units, slightly better for disabled ones. There's no way the previous implementation qualified as long-term and thought-out in the first place. We're still waiting for some of those machines we started nearly a week ago to finish applying initial cgroups configuration and allow login. :-/ Please, for stuff like this get a review from Kay, Zbigniew, Michal Schmidt, or me, before you commit. Thanks! Indeed, I'd prefer for that to be the case. Let's talk about ways contributors can have more confidence going forward that fixes to regressions like this will get timely reviews. I know you're really busy with the D-Bus and network work, but maintaining a stable, usable master is increasingly important as this project matures. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=2b5c5383e48137d748681645ad7176f02b50ba30 [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=3db0e46b0de5e46922ebbbd77de4d3d1214bcc9a [3] http://cgit.freedesktop.org/systemd/systemd/commit/?id=21acf11d407ea93d1b0c99088f9f64adad6cff0e ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: Cache controller masks and optimize queues.
On Sat, Nov 23, 2013 at 7:53 AM, David Timothy Strauss da...@davidstrauss.net wrote: My attempts to discuss options and approaches with you at LinuxCon, on the mailing list, and IRC have only been marginally productive. Before my commit, we only had a TODO logged. Actually, I'm being a bit unfair here. Most of what we discussed at LinuxCon was the daemon-reload issue, which you addressed really nicely soon afterward. I think I only became aware of the cgroups issue after we started to test the path prefix fix at scale. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] syslog makes impossible to enter emergency mode
On Nov 25, 2013 4:36 AM, Andrey Borzenkov arvidj...@gmail.com wrote:
Interesting case (https://bugzilla.novell.com/show_bug.cgi?id=852021).
Systemd enters emergency due to failed mount. At the same time syslog
socket triggers syslog.service. Due to implicit Requires on
basic.target which Requires sysinit.target which conflicts with
emergency.{service,target} syslog.service tries to start basic.target
(it is not there yet ...) which apparently kills emergency shell.
I wonder if default service dependency should not be Requisite instead
of Requires. After all, if we are not past basic.target, there should
be really good reason for it and attempting to start it implicitly does
not look the right thing to do.
I haven't looked at all, but have you checked whether this is a systemd
core issue versus just a SUSE one?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd with 802.1x
On Mon, Nov 25, 2013 at 5:38 PM, Umut Tezduyar Lindskog umut.tezdu...@axis.com wrote: I would think port access protocols would be needed for servers even before sending a single IP package. I've never used a server that required 802.1x. I've only encountered it in places where physical network access is widespread among people who aren't trusted, like offices and universities. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thread level resource management
On Tue, Nov 26, 2013 at 2:28 AM, Umut Tezduyar Lindskog umut.tezdu...@axis.com wrote: Any plans to support existing applications that are making use of thread level resource management? If not, what are we left with then, posix thread priorities? Kay is right; there is no direct replacement. However, it's possible to fork processes on Linux with many of the same properties as threads (shared memory and file descriptors). Originally, all POSIX-like (loosely using like here) threads used this capability back with LinuxThreads. Using clone() that way would allow continued use of cgroups resources. Or, perhaps it's a good time to consider a more loosely coupled architecture with multiple processes or daemons. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/socket: we only want one event on standard sockets
On Tue, Nov 26, 2013 at 2:35 PM, Lennart Poettering lenn...@poettering.net wrote: Not following here. What precisely does this fix, can you elaborate? We currently turn off the poll for the socket fds as soon as we queued the service socket, so that we don't get woken up anymore. What would EPOLLET do good here? I think he's been working on having the distribute pool scale up on-demand, which would involve systemd getting events on new connections coming into the listener socket. More specifically, I think he intends to, as each new connection comes in, check if we've maxed out the number of processes. If not, spin another one up. Presumably, we'd drop the listener once the max-size pool is running. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tree-wide usage of %m specifier instead of strerror(errno)
Thanks. Applied. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/socket: we only want one event on standard sockets
On Wed, Nov 27, 2013 at 2:32 AM, Lennart Poettering lenn...@poettering.net wrote: Well, but EPOLLET only works correctly if each time an event is triggered we dispatch *all* possibly queued events on the fd, until EAGAIN is read again. But we don't do that, heck, if Listen=no is used we don''t even read a single incoming connection of the scket, we leave that to the daemon we spawn, but we cannot trust that. So, I don't get what EPOLLET is supposed to do good here? I should have more selectively quoted before answering. I was only trying to answer why we'd continue having poll for the socket fds after queuing the initial service. I was not trying to suggest EPOLLET is appropriate for the goal of lazy distribute process pool expansion. You've clearly correct about that. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/socket: we only want one event on standard sockets
On Wed, Nov 27, 2013 at 6:23 AM, Shawn Landden sh...@churchofgit.com wrote: I was worried that the fact that we never accept() the socket when using distribute (now I am convinced we shouldn't use it otherwise) I'm not sure what you mean here. Distribute-style functionality is absolutely useful with Accept=true (to cap the number of simultaneous connections) as well as Accept=false (to allow running of a process pool of self-accepting, long-running workers). would cause it to trigger multiple times for only one incoming connection, if the spawned thread never entered accept() (or we raced it), but reading this thread makes me think I don't fully understand the semantics of EPOLLET. There are some decent examples on the man page: http://linux.die.net/man/7/epoll ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/socket: we only want one event on standard sockets
On Wed, Nov 27, 2013 at 7:57 AM, Shawn Landden sh...@churchofgit.com wrote: Are you sure applications can handle the extra file descriptor of passing both the sockfd and the acceptfd in this case? I don't see why they wouldn't just do the accept() themselves? Can you explain what you mean here, and how it differs from the existing MaxConnections. Actually, MaxConnections was exactly what I was thinking of. I agree with you now on Distribute=true only being useful with Accept=false. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] man/systemd-socket-proxyd.xml src/socket-proxy TODO
On Wed, Nov 27, 2013 at 12:03 PM, Lennart Poettering lenn...@poettering.net wrote: Could you please explain what the usecase here is? Why is this better than having two socket units with two proxy services? Right now, it's because separate services cannot exist in the same network namespace with another service. The main motivation for this change was a desire within CoreOS to run etcd within a network-namespaced service. With the need to only map one port in, that would be equivalent to the network namespaced nginx example. But, they need to map *two* ports in and to distinct destination ports within the namespace. That was actually impossible before, where socket-proxyd would map all inherited sockets to the same destination. This change allows forcing a single socket-proxyd to inherit only one socket each. +/usr/bin/systemd-socket-proxyd --listener=3 localhost:8080 +/usr/bin/systemd-socket-proxyd --listener=4 localhost:8443 +wait]] If our examples suggest that people should write shell scripts that fork things, then this is usually an indication that we need to rethink what we are doing here. In fact, running multiple manually forked off processes inside the same service already sounds very wrong. We should try to keep a 1:1 mapping between processes we fork and services they run it. Agreed. I really don't want socket-proxyd directly involved in exec'ing of things, either. What's the usecase here? If this is about running multiple things in the same Network namespace, then there are certainly other, better ways to achieve the same. For example, we could introduce JoinPrivateNetwork=$SERVICE or so which would allow one service to join the network namespace of another. That makes this much smoother and more powerful, too. That would be wonderful. I'd love to shed the shell scripts. With that in place you could simply have three proxy instances, and make them join the private network of your nginx instance and you should be set? I think that would do exactly the trick. I didn't know it was possible to join into an existing namespace that way. It would be my pleasure to update the documentation to use something like that if it becomes available. I'd also enjoy dropping the --listener option. :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] man/systemd-socket-proxyd.xml src/socket-proxy TODO
Wow, that was fast. I was working on my own patch to submit to the list today, but I'll just consider it an education in config and exec configuration. I'll make sure everything looks good with the CoreOS folks, too. Thanks! On Nov 28, 2013 6:17 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 27.11.13 14:09, David Timothy Strauss (da...@davidstrauss.net) wrote: If this is about running multiple things in the same Network namespace, then there are certainly other, better ways to achieve the same. For example, we could introduce JoinPrivateNetwork=$SERVICE or so which would allow one service to join the network namespace of another. That makes this much smoother and more powerful, too. That would be wonderful. I'd love to shed the shell scripts. This is implemented now in JoinsNamespaceOf= and will affect both PrivateNetwork= and PrivateTmp=. I also took the liberty to revert the --listener patch, since it is unnecessary now, and I updated the examples in the man page to not use shell scripts anymore. I didn't test them though, please check if everything's OK now. 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] Thread level resource management
On Fri, Nov 29, 2013 at 1:58 AM, Umut Tezduyar Lindskog umut.tezdu...@axis.com wrote: Can someone explain the process level management? Right now, it's possible to do directly in the cgroups file system, but we're eventually moving away from anything manipulating that but systemd. I think that there will still be a way to move around processes via systemd, but it's speculation at this point. Your best best, overall, is to break up the program into separate *services*. This is hardly a neutral answer, given that you're asking on the systemd mailing list. Of course some of us here will advise you to break it up into services; systemd is a service-management tool. :-) Using services will allow you to easily configure resources in a way that will continue working through 2014 and beyond as systemd and the kernel update. Even with separate services, you can still use multithreaded-style (shared memory) techniques by mmapping the same paths with MAP_SHARED. There are a bunch of other, standard IPC mechanisms, too [1]. It's generally best to decouple the program into services that communicate at a high level. [1] http://www.tldp.org/LDP/lpg/node7.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is restart gracefull?
On Nov 29, 2013 9:52 PM, Cecil Westerhof cecil.wester...@snow.nl wrote: On 11/29/2013 08:59 AM, David Timothy Strauss wrote: On Fri, Nov 29, 2013 at 12:53 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 29.11.13 00:11, Cecil Westerhof (cecil.wester...@snow.nl) wrote: I have done a trial presentation about systemd. One of the questions there was: when a restart of for example apache is doen, is this restart done graceful? For systemd a restart is actually exactly what the name says: a stop plus a start. reload otoh is up to the implementer of the unit file, whatever he chooses. Just to clarify, stop (and, by extension restart) is also up to the implementer of the unit file. There just happens to be a default, unlike with reload. See the service and exec man pages for details. Regardless, restart and stop usually both involve a full shutdown of every process running the daemon. I think it's possible to override this behavior with certain options, but you shouldn't. There is of-course an important difference. As I understood it, Apache is notorious for processes that escape. (That is one of the reasons that cgroups usage of systemd is such an improvement.) In the old situation nothing happened to those processes. (With potential nasty results.) What happens to those processes under systemd? If you want to explore much deeper, you may also be interested in socket activation, which allows a server socket to remain open even while a daemon is fully shut down (whether because it hasn't started yet, is restarting, or has been stopped). It takes graceful restarts/reloads up to the systemd level. I certainly would. I thinks it is a very important part of systemd. And it is also clearly mentioned in my presentation. But I have a ‘few’ restrictions: - I have to give the presentation on December 5 - I am quite new to systemd and only scanned the surface I am afraid - There are a lot of other things I need to know more about - I am not an administrator, but a developer, so most is Terra Incognita to me How much time would I need to understand these levels? If you're willing to use nginx instead, it's fairly straightforward. I'd have to research the options for Apache. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Never use a systemd unit to call modprobe. And, even if you did, modprobe would be Type=oneshot (maybe also with RemainAfterExit=true), definitely not Type=simple. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 5, 2013 at 7:29 AM, Colin Guthrie gm...@colin.guthr.ie wrote: The above statement not withstanding, but the Type and RemainAfterExit applies only to ExecStart. This unit calls modprobe in ExecStartPre which is always expected to do something and return. So this branch of the thread really doesn't apply to this unit. Oh, indeed. I misread the unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Ensure unit is journaled for short-lived or oneshot processes
How reliable is the unit_id data this falls back to? If it's going into an underscore-prefixed field in the journal, we need confidence that it's not forgeable. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix memory leak in stdout journal streams
This fails to apply for me. Just to check yours methods and mine, I tried applying your Ensure unit is journaled for short-lived or oneshot processes patch and succeeded. Comparing the two, it looks like the text above the first triple-hyphen got dropped. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix memory leak in stdout journal streams
On Sun, Dec 8, 2013 at 12:23 PM, Dan McGee d...@archlinux.org wrote: It is the free(s-buffer); bit that snuck in there from the other patches I sent this morning. I can rebase this one before those so it applies to the current tree, my mistake. Aha! Applied. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] core: lazy distribute for Distribute pools
On Sun, Dec 8, 2013 at 8:25 PM, Shawn Landden shawnland...@gmail.com wrote: This one doesn't work. I have have a somewhat-working next patch, but the way epoll_wait works it actually isn't lazy at all, and would require EPOLLET to even do one-spawn-per-connection (global connection), but we can't do that with the current event loop. I ended up getting side-tracked into adding mount-namespace to lsof, cause i noticed that feature lacking while working on this Anyways, a new series will come, and I am working on it. Why don't we just start with an eagerly spawned pool? We can always add lazy support later. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logging in an enterprise environment
We currently use journal2gelf [1], which we also have a rewrite of that uses the native Python bindings to the journal. We're probably dumping our rewrite and adding journal integration to Beaver [2]. [1] https://github.com/systemd/journal2gelf [2] https://github.com/clifton/beaver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
After watching the results for an hour or so, this massively improves the performance of is-enabled and several other systems on our heavily loaded boxes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
On Thu, Dec 12, 2013 at 6:23 AM, Lennart Poettering lenn...@poettering.net wrote: This isn't right. Units might be symlinked under different names, we need to support that. For example, all template instances carry a different name for the symlink then for the source. Good point, though we could still support that with smarter matching that doesn't require dereferencing the symlink. Would that work in the mean time? We need to find a different solution here. Maybe introduce a cache object or so where we load everything we find in too and that can be indexed by the target rather then the name of a symlink. I'm up for anything that fixes the timeouts this is causing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
On Wed, Dec 11, 2013 at 8:36 PM, Andrey Borzenkov arvidj...@gmail.com wrote: This completely changes semantic of what it does. In this case no symlink is needed in the first place - just touch .../unit.wants/other.unit would be enough, as long as we assume units can only be located in standard config paths. That's interesting. I hadn't thought of that option. The only downside would be the loss of shell tooling related to finding stale symlinks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No security on systemd-journal-gatewayd
On Thu, Dec 12, 2013 at 8:15 AM, Kay Sievers k...@vrfy.org wrote: We must not give the impression that this is secure in any way, it is not, and cannot generally be used unless it is secured by other things. So, no this is not secure at all, just possibly encrypted, but I doubt that was the question. Supporting SSL means it's possible to set up an authority that only signs certificates you want to access the gateway. It's not sophisticated, but it's definitely a usable access-control mechanism. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.
This new patch version fixes instance support by replacing the instance with nothing, allowing a comparison equivalent to the one we make against the target of the symlink (which is something like abc@.service for instances). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.
Hold on. This breaks is-enabled if you've enabled an instance *and* that instance has its own override (using def@myinst.service versus using def@.service). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH 0/3] journal: Add deferred log processing to reduce synchonous IO overhead
On Sat, Dec 14, 2013 at 8:12 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Are you sure that the sysctl is set early enough, before the listening socket is created? Perhaps this is why your suggestion [1] for the journal bootup issue didn't help. [1] https://bugs.freedesktop.org/show_bug.cgi?id=71483#c10 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
If we supported PIDFile= for Type=simple, daemons could drop a PID file to indicate startup completion without having to be full-on Type=forking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] (no subject)
I replied in the thread with a subject line. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to control socket activation when it run respawn infinitely.
It seems odd to combine Type=oneshot with Accept=false (which is the default for socket activation). The latter setting causes systemd to expect a persistent daemon to accept() connections. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to control socket activation when it run respawn infinitely.
On Sun, Dec 22, 2013 at 11:43 AM, Tony Seo tonys...@gmail.com wrote: Frankly speaking, I don't understand why service daemon is infinitely spawned when I set the option Accept= false. And Why couldn't the client process connect to socket unit that I made by setting Accept= true. I think you need to learn more about Unix socket programming before it's possible to explain how those options work in systemd. The stage of accept() is pretty key, and it's not systemd-specific. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.
On Sun, Dec 29, 2013 at 11:57 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I have been looking at our bugs [1-10, there are others too] related to enabling/disabling of units and following of symlinks. Currently this is an unintuitive mess and some changes will have to be made. Another goal I have for any refinement in enable behavior is defining how instances should work with commands. For example, because we check is-enabled against the target of the symlinks, systemctl is-enabled nginx@123.service returns false unless there's a specific nginx@123.service unit (IIRC). So, status functions differently from is-enabled in terms of how it matches up data. This gets really weird when it comes to displaying the enabled state in the status output. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer m...@zarb.org wrote: So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 In the spirit of making isolation easy, it would be neat to have a built-in convention for selinux isolation in systemd where the full service/unit name has a default context name, constructed much like the quoted example, that the admin or packager can use simply by turning isolation on (SELinux=true). We would love to use SELinuxContext= or SELinux= for our needs at Pantheon. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
