[systemd-devel] libsystemd-daemon wrapper
Hi.
I've got question partially inspired by recent posts to this ML from some troll
without shift on his keyboard :)
It's been mentioned that calls like sd_listen_fds(0) and others become NOOP when
socket activation is not available due to lack of systemd. Which is fine but
leads to
rather inflated code as in here:
http://0pointer.de/blog/projects/socket-activation.html
Is there some wrapper library which hides this boilerplate from developers?
I mean instead of writing every time code like
if (sd_listen_fds(0) 1) {
... // error
} else if (n == 1)
... // systemd OK
else {
... // fallback to legacy
}
I'd really prefer to use something like:
int fd = listen_on_fd_with_or_without_systemd(...);
which effectively incorporates all the fallback-to-legacy logic.
The same question, naturally, applies to non-scocket-activation daemons.
I've tried to search for it but unfortunately came up with nothing so I'd
appreciate
links to such projects or to documentation which would explain why this kind of
wrapper is really stupid idea :)
cheers,
Max.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
Hello Luke, On Mon, Feb 23, 2015 at 12:58 AM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: I understood most of these dependencies to be indirect: Packages that depend on other packages that in turn depend on libsystemd. Is that correct? that's right. so, what that means is that the actual number of packages which would need to be converted to dynamic loading is actually very small (about 100), and the remaining 4,483 would be fine (not need any work done on them at all). Good. At least all sides agree on the facts:-) they made it possible to remove systemd entirely. they had to recompile cups, stunnel, udisks2, upower, util-linux and many more... here's the list: http://angband.pl/debian/dists/nosystemd/main/binary-amd64/Packages but here's the problem: because there is no dynamic run-time decisions possible here, people are forced to adding that (unofficial) repo and to risk their systems in the process. reverting is also just as risky. Libsystemd provides the code that does the runtime detection. The alternative is to copy and paste the code contained in that library into those 100 binaries directly, with all the negative consequences. Libsystemd's job is basically to provide exactly what you ask for: A wrapper around systemd functionality, that fails gracefully in case systemd is not used. honestly, i find it hard to argue with that. i think i know what the problem is. the problem is, i believe, that the detection is not user-controllable. question: does libsystemd have a config-file option that it reads, where if systemd = disabled is present, for example, it is effectively equivalent to not having systemd installed? Libsystemd is fully user control-able: Run systemd as PID1 and libsystemd does something for you, run anything else as PID1 and it turns into a noop. Not running systemd as PID1 does state I do not want to use systemd pretty clearly, doesn't it? I see no need to repeat that statement of intent in some config file. Again: That seems to be exactly the behavior you are asking for. in many ways it doesn't matter that i (or anyone else) finds the solution objectionable. what should matter - to you - is that i (or anyone else) wishes to make that choice [we might have a solution above btw as you can see]. I am afraid you lost me. You want to not use systemd: Fine. You want to not have any code from the systemd repository on your system? Fine, too. You want to use a distribution that does not include systemd code? Fine, I can get that, I am lazy, too. But where is the relation between your distribution does not provide you with packages without any systemd code that you want and systemd-the-project? Distributions do include a lot of packages with dependencies that make sense for part of the user base only, provided it does not hurt the other users too much. This is exactly such a case: Users of systemd get to use socket activation and whatnot, users that do not use systemd get a library onto their system that eats a bit of disk space and RAM and does nothing otherwise. How does this particular decision of your distribution cause you so much anguish, while you are ok with packages dragging in other dependencies you do not strictly need? Why is this a matter of choice here and not elsewhere? i think... really, although technically what i am asking *appears* to be achieved in an equivalent fashion, they're not entirely the same. bear with me whist i think this through, ok? my thoughts go like this: virtually every GNU/Linux distro has gone for a mutually-exclusive all-or-nothing choice: systemd or out. even Debian has had to provide systemd-shim to quotes stop the whiners quotes. it has Breaks: systemd 209 in the package file. they *did not* notice that systemd may be easily disabled by not running as PID 1. So far we talked about libsystemd as a dependency to core packages in Debian. You are now widening the scope of this discussion. Is that your intention? You are heading of into systemd-logind land at this point. This is a very different discussion, as it does effect users and not-users in a very different way than libsystemd does. I would be looking forward to having that with you, but we should keep that in a separate thread and do not mix the topics. I would personally like to see a libinitd which brings the socket activation features that is provided to daemons as part of libsystemd to other init systems (that can support those). That would make it so much easier for upstreams to support more than one init system. But I would expect that to be implemented by the teams working on alternatives to systemd or by distributions centered around other init systems. i would _love_ to see a situation where there is more dialog and collaboration between the developers of systemd and the maintainers of the alternatives. So would I, but I actually think the people that are willing to discuss to
Re: [systemd-devel] feature request: dlopen
Hi Luke, On Mon, Feb 23, 2015 at 3:08 AM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: the problem, zbigniew, is that the intended use of this silent noop feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. You are starting to mix things: Libsystemd does work the way it was intended: They make it possible to add socket activation to daemons and make those report back to systemd. That part is nicely encapsulated. There are unrelated things like systemd-logind, which are higher up in the stack. Those are indeed harder to replace. Part of the problem is that there are no fully functionally equivalent pieces of software to replace the systemd stuff with. ConsoleKit and Co. do have severe limitations, that (apparently) can not be fixed without resorting to cgroups. aside from getting the message across to upstream developers about doing runtime detection, i feel that what you guys really need to do is to set up conferences with everyone, to talk - urgently - about ways to ensure that the alternative systems which the wholesale adoption of systemd has excluded may be reinstated as *runtime* choices (not compile-time). that may mean discussing a set of APIs that end up being DL'd (like PAM is, right now), it may mean doing something similar to apache loadable modules, or something like the infrastructure behind python objects, i don't know, but you *need to talk*. I do expect developers to search for information and not wait for the systemd project (whoever that is) to feed it to them. E.g. I would expect people that want to do a distribution without systemd will actually find out what systemd does first, so that they can do informed decisions on how to replace the individual parts. The documentation of systemd is -- at least in my experience -- pretty good in most areas. And where it is lacking people tend to act when somebody pokes them about it and actually improve on it. What do you want to be able to reinstate as runtime choices? There is a lot of stuff in the systemd repository. Those parts are at different levels of the stack and with varying levels of dependency on other parts. Your request is so generic that it is impossible to answer. the situation now is one where people believe that systemd is being heavily promoted to the exclusion of all other PID1 alternatives, developed with a focus on fedora / redhat to the exclusion of all other distros, developed for desktop systems *only* to the exclusion of servers and embedded systems... it's no wonder that there's a lot of upset people in the software libre community! That is a complete mis-representation of the project. Unfortunately I doubt there is anything the systemd project can do to rectify that impression at this point: Many people are past rational arguments at this point. i know it sounds weird to go backwards, but the situation is - amongst other not very nice things - that the GNU/Linux world now has a new monoculture attack vector at the PID1 level in code that's being *actively developed and extended, dramatically*. I do not understand this point. Systemd PID1 is pretty small, the rest of systemd runs with severely limited privileges. In fact most services are more tied down than their traditional counterparts ever were. it was bad enough that shellshock meant that sysvinit was vulnerable right across the board of every GNU/Linux distribution. but at least sysvinit is old enough to have had significant security audit and review over the decades, such that when shellshock was fixed, that was it, problem solved [until the next vulnerability...] Shellshock was lurking in the code for decades, evading all the security audits and reviews done on bash in all that time. Xorg has had similar long-lived bugs. Sysv-rc also depends on a lot of external code. The shell, core utilities, awk and whatnot. I doubt all the whole mess ever was audited for security in its total. contrast that to the situation now: with systemd being so actively developed and then deployed across literally every major GNU/Linux distro without exception, the possibility for serious vulnerabilities having a disproportionately large adverse effect is much higher than i feel it should be. The same is true for the Linux kernel, and I am more than happy about that. Bugs do get found in actively developed code, simply because people actually look at that code! Maybe we should all run more BSDs? That would also reduce the reliance on systemd:-) Two birds with one stone. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [PATCH] fstab-generator: mask systemd-fsck-root for /sysroot unit
On 21.02.2015 12:44, Andrei Borzenkov wrote: В Fri, 20 Feb 2015 12:24:33 +0100 har...@redhat.com пишет: From: Harald Hoyer har...@redhat.com If the fstab-generator generates a mount unit for /sysroot, we shall not run systemd-fsck-root in the real root. --- Makefile.am | 1 + src/fstab-generator/fstab-generator.c | 11 +++ But this does not solve problem if dracut runs without systemd module. Why not revert 956eaf2b8d6c024705ddadc7393bc707de02 and make dracut create /run/initramfs/root-fsck instead in both cases? Although, I can change dracut to add the mask instead of /run/initramfs/root-fsck, I think you are right and we are probably over engineering this small problem. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] shutdown from within a service
Hello, I've run into another side-effect of systemd's supervisory power over processes. The application is a simple ruby webrick daemon. It get's started just fine. It provides web service configuration to an appliance. One of the service calls gives clients the ability to power down the system. Previously this was an external system call to shutdown -h now. Doing the same thing or even a systemctl isolate poweroff.target yields the same results: namely, a timeout is logged while trying to shutdown the ruby daemon that has made the system call. Shutting down any other way goes just fine. How can I get systemd to shut the system down without thinking it has to sit around waiting for itself to shutdown as part of completing the ruby call to systemctl or the shutdown command so that it will shutdown quickly regardless of how the shutdown is initiated? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2][RFC] bus-proxy: add support for GetConnectionCredentials method
GetConnectionCredentials method was added to dbus-1 specification
more than one year ago. This method should return [...] as many
credentials as possible for the process connected to the server,
but at this moment only UnixUserID, LinuxSecurityLabel and
ProcessID are defined by the specification. We should add support
for next credentials after extending dbus-1 spec.
diff --git a/src/bus-proxyd/driver.c b/src/bus-proxyd/driver.c
index bc2c0c8..dc864f0 100644
--- a/src/bus-proxyd/driver.c
+++ b/src/bus-proxyd/driver.c
@@ -56,9 +56,6 @@ static int get_creds_by_name(sd_bus *bus, const char *name,
uint64_t mask, sd_bu
if (r 0)
return r;
-if ((c-mask mask) != mask)
-return -ENOTSUP;
-
*_creds = c;
c = NULL;
@@ -116,6 +113,10 @@ int bus_proxy_process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m, SharedPoli
method name=\RemoveMatch\\n
arg type=\s\ direction=\in\/\n
/method\n
+ method name=\GetConnectionCredentials\\n
+ arg type=\s\ direction=\in\/\n
+ arg type=\a{sv}\ direction=\out\/\n
+ /method\n
method
name=\GetConnectionSELinuxSecurityContext\\n
arg type=\s\ direction=\in\/\n
arg type=\ay\ direction=\out\/\n
@@ -219,6 +220,72 @@ int bus_proxy_process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m, SharedPoli
return synthetic_reply_method_return(m, NULL);
+} else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus,
GetConnectionCredentials)) {
+_cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
+_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
+_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
+
+if (!sd_bus_message_has_signature(m, s))
+return synthetic_reply_method_error(m,
SD_BUS_ERROR_MAKE_CONST(SD_BUS_ERROR_INVALID_ARGS, Invalid parameters));
+
+r = get_creds_by_message(a, m,
SD_BUS_CREDS_PID|SD_BUS_CREDS_EUID|SD_BUS_CREDS_SELINUX_CONTEXT, creds,
error);
+if (r 0)
+return synthetic_reply_method_errno(m, r, error);
+
+r = sd_bus_message_new_method_return(m, reply);
+if (r 0)
+return synthetic_reply_method_errno(m, r, NULL);
+
+r = sd_bus_message_open_container(reply, 'a', {sv});
+if (r 0)
+return synthetic_reply_method_errno(m, r, NULL);
+
+/* Due to i.e. namespace translations some data might be
missing */
+
+if (creds-mask SD_BUS_CREDS_PID) {
+r = sd_bus_message_append(reply, {sv}, ProcessID,
u, (uint32_t) creds-pid);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+}
+
+if (creds-mask SD_BUS_CREDS_EUID) {
+r = sd_bus_message_append(reply, {sv}, UnixUserID,
u, (uint32_t) creds-euid);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+}
+
+if (creds-mask SD_BUS_CREDS_SELINUX_CONTEXT) {
+r = sd_bus_message_open_container(reply, 'e', sv);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+
+r = sd_bus_message_append(reply, s,
LinuxSecurityLabel);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+
+r = sd_bus_message_open_container(reply, 'v', ay);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+
+r = sd_bus_message_append_array(reply, 'y',
creds-label, strlen(creds-label));
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+
+r = sd_bus_message_close_container(reply);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+
+r = sd_bus_message_close_container(reply);
+if (r 0)
+return synthetic_reply_method_errno(m, r,
NULL);
+}
+
+r = sd_bus_message_close_container(reply);
+if (r 0)
+return synthetic_reply_method_errno(m, r, NULL);
+
+return synthetic_driver_send(m-bus, reply);
+
} else if (sd_bus_message_is_method_call(m,
Re: [systemd-devel] shutdown from within a service
On Mon, Feb 23, 2015 at 1:33 PM, JB gene...@itpsg.com wrote: Hello, I've run into another side-effect of systemd's supervisory power over processes. The application is a simple ruby webrick daemon. It get's started just fine. It provides web service configuration to an appliance. One of the service calls gives clients the ability to power down the system. Previously this was an external system call to shutdown -h now. Doing the same thing or even a systemctl isolate poweroff.target yields the same results: namely, a timeout is logged while trying to shutdown the ruby daemon that has made the system call. Shutting down any other way goes just fine. systemctl --no-block poweroff -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, Feb 12, 2015 at 05:33:26PM +0100, Martin Pitt wrote: \o/ looking forward to let /etc/mtab die a bit more :-) util-linux v2.26 (released last week) provides --enable-libmount-force-mountinfo configure option to make mtab's grave more robust. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: fix whitespace and typo in partition table blurb
Hey Jan, Jan Synacek [2015-02-23 15:22 +0100]: - fix additional typo on the same line, doh Applied, thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Mon, 23.02.15 01:37, Luke Kenneth Casson Leighton (l...@lkcl.net) wrote: Convince the upstream developers in question not to link against systemd's libraries, or convince the distros not to package it like that. well, you could provide hints in the documentation (and force them to be read by deliberately changing the API) To make this clear: I think dlopen() is a really bad idea. It complicates code, hides dependencies, fucks up API versioning and I am very sure I will not push people to use it. and you could provide an example by leading the conversion. for example, i understand that you're the developer behind portaudio? This is non-sense. I have nothing to do with portaudio. that would be a good place to start, showing people how to begin the process of dlopen()ing libsystemd0, documenting it well so that it was easy to follow. We just offer a library, which apparently is interesting to people to use, but whether they use it is really not up to us. well... they've used it, alright. so much so that there isn't a single major GNU/Linux distro left, nor a major GNU/Linux desktop environment, that may be used *without* systemd or a systemd-compatible component. xfce4, lxde, kde, gnome - they're all now critically and exclusively dependent on systemd. This is non-sense. * distros are forced to follow suit on upstream decisions, without consulting what any other distros do Well, distros don't write software. Upstream projects do. The ones who write the software make the decisions which APIs the software use. It's that simple. If you want to make decisions on how software is written, then write software. Or pay people to write software. But that's really it. * distros are (with the exception of gentoo, freebsd and macports as they are all source-based) forced to hard-code the best possible compile-time options that are *available* to them This is non-sense. Nobody is forced by anyone here. * the upstream decisions on a per-app basis have been made in isolation without a proper across-the-board cross-project analysis. Yeah, it's how open source works. The developers can do what they want. And you have the liberity to fork their stuff if you are unhappy. I encourage you to do so, and stop annoying people who actually do the work. * the development of systemd has been done in the perfectly reasonable way of using fedora as the proving-ground... in isolation from other distros. This is non-sense. When we started Kay was working for Suse not RH, and we probably adopted more Debianisms in systemd, than -isms from any other distro. end result: systemd is now *the* de-facto PID 1 across all major GNU/Linux distros in the space of something like under a year, with This is non-sense. Nah, systemd is 5 years old now. It took five years to get most distros onboard. unfortunately, on all the major GNU/Linux distros, the correlation between libsystemd0 being present and every other PID1 management system being excluded from consideration is near 100%. This is non-sense. the detection tobias mentioned that it may have been *intended* that libsystemd0 provide, of remaining dormant if systemd is not detected as PID1 should signal to the upstream developers that they should *permit* alternative PID1s to run, but in reality the upstream developers have simply ripped out all alternative code - not even provided a compile-time switch to support the previous code. the KDE5 developer recently removed the code that used console-kit (etc. etc. whatever it was) and replaced it with a d-bus call to logind, for example. This is non-sense. When I added logind support to gdm for example I carefully made sure to keep the ConsoleKit codepaths in place, so that gdm could work against either, and the choice could be made at runtime. I did that precisely to allow people like you to stick to CK. and *importantly*, provide a backup choice in case something goes wrong with systemd. hit-by-bus scenarios, monoculture development leading to ecosystem-wide malware exploits across multiple GNU/Linux distros, that sort of thing... This is non-sense. You have no idea how Open Source works. Since the source is open somebody else can and will take over if I disappear. ... except the rapid and wholesale exclusive adoption of systemd across the horizontal (isolated) layer of upstream and the vertical (isolated) layer of the distros *isn't allowing for any competition to grow*. Well, our project apparently was a lot more convincing than all other options, hence distros adopted it. If you think you can put together something better, please do, make it convincing, and people will adopt it instead. regarding the evil shit innuendo, amusing as it is, that i feel is It's not an innuendo. It's pretty explicit. a red herring. i'm aware for example of several independent technical analysis of the code quality of systemd have encouraged others
[systemd-devel] [PATCH] nspawn: fix whitespace in partition table blurb
---
src/nspawn/nspawn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 0d8d199..9c5b8cd 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2754,7 +2754,7 @@ static int setup_image(char **device_path, int *loop_nr) {
#define PARTITION_TABLE_BLURB \
Note that the disk image needs to either contain only a single MBR
partition of\n \
-type 0x83 that is marked bootable, or a sinlge GPT partition of type
\
+type 0x83 that is marked bootable, or a sinlge GPT partition of type
\
0FC63DAF-8483-4772-8E79-3D69D8477DE4 or follow\n \
http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/\n; \
to be bootable with systemd-nspawn.
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A use case for staged startup
On Sun, 22.02.15 02:31, Jeff Waugh (j...@bethesignal.org) wrote: But it's time to get serious. And everyone knows that serious means having a writeable root filesystem. OpenWrt uses overlayfs with JFFS2 as the top layer. but I'm just using tmpfs for now. (For some values of serious.) Why would you want a writable root fs? I mean, a writable /var should suffice? I wanted to make best use of systemd's built-in primitives, so here's what I've done: - default.target is symlinked to initrd.target in the read-only filesystem image Why bother with an initrd in an embedded device? Can't you just boot directly into the main image with an initrd-less kernel? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd: add getrandom syscall numbers for MIPS
Add getrandom syscall numbers for MIPS. Based on Linux 3.17 kernel
(commit 42944521af97a3b25516f15f3149aec3779656dc, MIPS: Wire up new
syscalls getrandom and memfd_create).
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
src/shared/missing.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index b33a70c..e72631e 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -179,6 +179,16 @@ static inline int memfd_create(const char *name, unsigned
int flags) {
#define __NR_getrandom 349
# elif defined(__powerpc__)
#define __NR_getrandom 359
+# elif defined _MIPS_SIM
+#if _MIPS_SIM == _MIPS_SIM_ABI32
+# define __NR_getrandom 4353
+#endif
+#if _MIPS_SIM == _MIPS_SIM_NABI32
+# define __NR_getrandom 6317
+#endif
+#if _MIPS_SIM == _MIPS_SIM_ABI64
+# define __NR_getrandom 5313
+#endif
# else
#warning __NR_getrandom unknown for your architecture
#define __NR_getrandom 0x
--
2.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: fix whitespace and typo in partition table blurb
---
Changes in v2:
- fix additional typo on the same line, doh
src/nspawn/nspawn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 0d8d199..a9b9a3e 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2754,7 +2754,7 @@ static int setup_image(char **device_path, int *loop_nr) {
#define PARTITION_TABLE_BLURB \
Note that the disk image needs to either contain only a single MBR
partition of\n \
-type 0x83 that is marked bootable, or a sinlge GPT partition of type
\
+type 0x83 that is marked bootable, or a single GPT partition of type
\
0FC63DAF-8483-4772-8E79-3D69D8477DE4 or follow\n \
http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/\n; \
to be bootable with systemd-nspawn.
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Mon, Feb 23, 2015 at 6:17 AM, Martin Pitt martin.p...@ubuntu.com wrote: Luke Kenneth Casson Leighton [2015-02-23 2:08 +]: the problem, zbigniew, is that the intended use of this silent noop feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. It sure has. Debian supports systemd, SysV init, and to a lesser degree OpenRC and upstart. see below, last paragraph. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. libsystemd does that very run-time detection, and upstream software usually falls back to the normal way of opening sockets if socket activation via libsystemd fails (either because you aren't running systemd or the service isn't socket activated). see below, last paragraph. aside from getting the message across to upstream developers about doing runtime detection, i feel that what you guys really need to do is to set up conferences with everyone, to talk - urgently - about ways to ensure that the alternative systems which the wholesale adoption of systemd has excluded may be reinstated as *runtime* choices (not compile-time). You didn't follow, or see the results of the big Debian systemd debate at all, did you? :-) the one where people were violently rude to each other? of course not. Pretty please do some actual research about the situtation first, and keep apart libsystemd (harmless, works with any init system) from systemd (the init system, pid 1, services around it, etc). martin, this is very condescending. please don't do that again. it also misses the larger picture. what the distros do is fait-accomplit driven by the decisions of the upstream developers. what the upstream developers do is fait-accomplit driven by the decisions of their dependencies. everyone has been working in near-isolation (which is normally fine and absolutely nothing wrong with that), except that in this one very specific unique instance it's resulted - *entirely by accident* the abandonment of the alternatives to systemd. if what you said was genuinely true - that there is choice *within* the distros, http://angband.pl/debian/, TriOS, and devuan would not exist. l. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
Am 23.02.2015 um 13:41 schrieb Luke Kenneth Casson Leighton: also misses the larger picture. what the distros do is fait-accomplit driven by the decisions of the upstream developers. what the upstream developers do is fait-accomplit driven by the decisions of their dependencies. everyone has been working in near-isolation (which is normally fine and absolutely nothing wrong with that), except that in this one very specific unique instance it's resulted - *entirely by accident* the abandonment of the alternatives to systemd. if what you said was genuinely true - that there is choice *within* the distros, http://angband.pl/debian/, TriOS, and devuan would not exist. the larger picture is that every project writes it's code and choses to rely on code of other projects as dependency - that's it - not more and not less if there would be a big need and a large base of people to keep and maintain systemd free distributions it just would happen and if we here *anything* about devuan in two years is more than questionable what you are missing at your big picture is based on mis-information or how did you come to the conclusion in this thread that systemd is not for servers (frankly tell that my servers) while a ton of options making sense more on servers than on workstations or that it is not for embedded devices while http://0pointer.net/blog/projects/stateless.html is especially useful for exactly that type of setups signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] libsystemd-daemon wrapper
On Mon, 23.02.15 11:30, Max (maxim.sur...@campus.tu-berlin.de) wrote:
Hi.
I've got question partially inspired by recent posts to this ML from some
troll
without shift on his keyboard :)
It's been mentioned that calls like sd_listen_fds(0) and others become NOOP
when
socket activation is not available due to lack of systemd. Which is fine but
leads to
rather inflated code as in here:
http://0pointer.de/blog/projects/socket-activation.html
Is there some wrapper library which hides this boilerplate from developers?
I mean instead of writing every time code like
if (sd_listen_fds(0) 1) {
... // error
} else if (n == 1)
... // systemd OK
else {
... // fallback to legacy
}
I'd really prefer to use something like:
int fd = listen_on_fd_with_or_without_systemd(...);
which effectively incorporates all the fallback-to-legacy logic.
The same question, naturally, applies to non-scocket-activation daemons.
I've tried to search for it but unfortunately came up with nothing so I'd
appreciate
links to such projects or to documentation which would explain why this kind
of
wrapper is really stupid idea :)
For testing purposes we do provide the systemd-activate tool to run
socket activated daemons without socket activation.
I am not really sure thought whether we should provide more than
that. The thing is simply that I cannot see how an API we would
provide could be any simpler than the BSD socket API is on its own. If
you want to listen on something, you need socket(), maybe a couple of
setsockopt()s, a bind() and a listen(). Any API that would wrap that
would kinda need the same amount of function calls, hence wouldn't be
any shorter or easier with it...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Mon, 23.02.15 12:41, Luke Kenneth Casson Leighton (l...@lkcl.net) wrote: Luke, you are now on moderation. I am sorry, but I don't find what you are writing particularly useful or new. You keep repeating the same untruths, and I'd prefer if we could again focus on technical discussions on the mailing list instead. Please move this discussion elsewhere. Thanks, 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] Removing unnecessary includes
On Sun, 22.02.15 14:56, Thomas H.P. Andersen (pho...@gmail.com) wrote: For info I am attaching a diff with the changes so far: 1309 includes removed out of the current 7707. It is only compile and make check-tested. I am only looking for comments (and perhaps compile testing on an AppArmor system as I do not have a system with that). The patch bitrots quickly. I have updated it and also dropped a few removals of architecture.h and endian.h. It passes make check and I have not seen any issues with using it on my own system. Still not tested with AppArmor though. If you are reasonably sure that the patch is OK, go ahead and push. We are still at the beginning of the cycle, and can fix any fallout in time. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: fix whitespace in partition table blurb
While you're at it,
-sinlge
+single
On Mon, Feb 23, 2015 at 2:32 PM, Jan Synacek jsyna...@redhat.com wrote:
---
src/nspawn/nspawn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 0d8d199..9c5b8cd 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2754,7 +2754,7 @@ static int setup_image(char **device_path, int
*loop_nr) {
#define PARTITION_TABLE_BLURB \
Note that the disk image needs to either contain only a single
MBR partition of\n \
-type 0x83 that is marked bootable, or a sinlge GPT partition of
type \
+type 0x83 that is marked bootable, or a sinlge GPT partition of
type \
0FC63DAF-8483-4772-8E79-3D69D8477DE4 or follow\n \
http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/\n;
\
to be bootable with systemd-nspawn.
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Logroate + Pass signal to executable in container (nspawn)
Hi,
I run nginx in a container which itself is under systemd-control. All
error messages are put to stderr and the incomming requests are logged in
access.log. To reduce the filesize I want to rotate the access.log.
I see two possibilities to make nginx release the file handle:
* Restart service
* Send signal USR1 or whatever it needs to the service
Does it make sense to send SIGUSR1 (or whatever signal it needs) to
nginx to rotate the logs afterwards or is it ok to restart the whole
service because systemd will buffer all incoming request - though socket
activation is not in use? I'm not sure, what's best for this use case.
Any ideas? Thanks a lot.
/pp
This is the service.unit
[Unit]
Description=Webservice for %I
[Service]
EnvironmentFile=/etc/default/machines/%I.conf
Environment=WWW_DIR=/srv/machines/%I
Environment=LOG_DIR=/var/log/machines/%I
Environment=SITES_DIR=/etc/machines/%I/sites-enabled
Environment=CONFIG_DIR=/etc/machines/%I/other-config
Environment=SSL_DIR=/etc/ssl/machines/%I
ExecStart=/usr/bin/systemd-nspawn --register=no --ephemeral
--bind-ro ${SSL_DIR}:/etc/ssl/nginx --bind-ro ${WWW_DIR}:/srv/www
--bind ${LOG_DIR}:/var/log/nginx/ --bind-ro
${SITES_DIR}:/etc/nginx/sites-enabled/ --bind-ro
${CONFIG_DIR}:/etc/nginx/other-config/ -M docker-centos-nginx
/usr/sbin/nginx
KillMode=process
[Install]
WantedBy=network.target
And to make things easier for you to read, here's the expanded exec
start commandline
/usr/bin/systemd-nspawn \
--register=no \
--ephemeral \
--bind-ro /etc/ssl/machines/www_example_org:/etc/ssl/nginx \
--bind-ro /srv/machines/www_example_org:/srv/www \
--bind /var/log/machines/www_example_org:/var/log/nginx/ \
--bind-ro
/etc/machines/www_example_org/sites-enabled:/etc/nginx/sites-enabled/ \
--bind-ro
/etc/machines/www_example_org/other-config:/etc/nginx/other-config/ \
-M docker-centos-nginx \
/usr/sbin/nginx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: fix whitespace in partition table blurb
Mantas Mikulėnas graw...@gmail.com writes: While you're at it, -sinlge +single I have no idea how this one escaped me... Will fix, thanks! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Mon, 23.02.15 14:36, Karel Zak (k...@redhat.com) wrote: On Thu, Feb 12, 2015 at 05:33:26PM +0100, Martin Pitt wrote: \o/ looking forward to let /etc/mtab die a bit more :-) util-linux v2.26 (released last week) provides --enable-libmount-force-mountinfo configure option to make mtab's grave more robust. Will this be turned on in Fedora? 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] Removing unnecessary includes
On Mon, Feb 23, 2015 at 2:02 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Sun, 22.02.15 14:56, Thomas H.P. Andersen (pho...@gmail.com) wrote: For info I am attaching a diff with the changes so far: 1309 includes removed out of the current 7707. It is only compile and make check-tested. I am only looking for comments (and perhaps compile testing on an AppArmor system as I do not have a system with that). The patch bitrots quickly. I have updated it and also dropped a few removals of architecture.h and endian.h. It passes make check and I have not seen any issues with using it on my own system. Still not tested with AppArmor though. If you are reasonably sure that the patch is OK, go ahead and push. We are still at the beginning of the cycle, and can fix any fallout in time. Ok. I pushed the patch now. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Mon, Feb 23, 2015 at 02:08:26AM +, Luke Kenneth Casson Leighton wrote: the problem, zbigniew, is that the intended use of this silent noop feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. Luke, please be careful with quantificators like ”any upstream developer”. I invite you to check sd_notify() and/or socket activation that I did* in various projects: rrd_cached, iscsid, transmissionbt, owfs, uptimed, tor. In each case there is no degradation when systemd is not used, previous way of doing things is preserved. Enhancement patches (Type=notify, watchdog) are NOOP when systemd is not used. Some of the above project don't even lin with libsystemd. * in case of Tor and transsmission I've either inspired the change or expanded it over original patches; for others I prepared a patch which was merged by upstream -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] machinectl: Support for cache cleaning
Hi Lennart, after getting the Permission Denied-error mentioned in one of my previous mails, which went away when running importd under root: Got 1% of https://registry-1.docker.io/v1/images/e03153f199183f91a9ee47334e65c7155d8619ef35c8158da80d0790af05ad98/layer. 2min 50s left at 187.0K/s. tar: usr/sbin/nginx: Cannot open: Permission denied tar: usr/bin/gmake: Cannot create symlink to ‘make’: Permission denied tar: usr/bin/make: Cannot open: Permission denied tar: usr/bin/openssl: Cannot open: Permission denied tar: usr/bin/gtar: Cannot create symlink to ‘tar’: Permission denied tar: usr/bin/tar: Cannot open: Permission denied I asked myself how I can get rid of those broken temporary subvolumes, to re-pull the image: drwxr-xr-x 1 root root 158 Feb 20 18:46 .dkr-00b2b6c6a2f93b2dde1d46b06cff32de82dabfd3b5ac6a8f27c5064f429e3e7a drwxr-xr-x 1 root root 158 Feb 20 18:46 .dkr-052665c23d7f38d475095f383196c5bf0b13dafe8b7fd02e3a4926767f839e95 drwxr-xr-x 1 root root 158 Feb 20 18:46 .dkr-0a6d917a8308476a069be3411d5aefddd34a9d4b3342e5deee5922b9a3abfa14 drwxr-xr-x 1 root root 158 Feb 20 18:46 .dkr-0a9465a17f988e749d3c217ecfd935a093789e7489a3516a7eedd17492b556d9 Do you plan to add a cache cleansing command to machinectl? I think now only btrfs subvolume delete will do the trick, correct? Can I delete those subvolumes safely without losing any data? Now I've got only only one container running, so I can be pretty sure to delete the correct volumes, but the situation will get a little more complex when I add more and more images/containers. And I'm a little bit concerned about running out of storage, when not cleaning up the temporary subvolumes regularly. Thanks a lot. /pp ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
