Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames
Sam Tresler schreef op 13-04-16 18:51: >>Ifconfig does not show anything useful. lspci might provide something I > can use to construct it, but I'm >not sure. "dmesg | grep enp3s0" > confirms this, but I still need to manually construct the entire string. > > I didn't make it through the rest of your post, but thought I'd chime in > with `ifconfig` has been deprecated since 2009. > > 2009. I don't get deep into the distros, but I really wish they'd stop > shipping it. > > `man ip` should give you info on the right tool you need to retrieve > your network info. From there it is just some pipework to get a list you > can iterate over. > > $ ip -o a | awk '{print $2}' | uniq You are telling me that a tool that gives a lot of useful information in a command without parameters should be superseded by a tool meant for lowlevel work that needs a parameter to do anything, because why? Do you want to make life harder for everyone or something. This feels very much like the cannabilizing that the Gnome people are doing. You have something good that works amazingly as a user tool and you want to replace it by a tool and a command that gives much less (even though it can do more). It's the same with "route" and "ip route". I often (and only) use "ip route" because it does not resolve addresses and hence it is faster, but it clear route is more of a user oriented tool. Deprecated, give me a break please. You wish people would stop shipping a tool that everyone likes. Reminds me of something.. :-/. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] some services always being killed when stress tests running
> From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On > Behalf Of EXT Han Pingtian > Sent: Wednesday, April 06, 2016 4:33 AM > On Fri, Apr 01, 2016 at 09:13:54PM +0200, Lennart Poettering wrote: > > On Tue, 22.03.16 10:02, Han Pingtian (ha...@linux.vnet.ibm.com) wrote: > > > > > But only after about 30 minutes, a lot of systemd services failed > > > and restarted like this: > > > > > > ... ... > > > [26885.910036] systemd[1]: systemd-journald.service: Failed with result > 'signal'. > > > [26885.910218] systemd[1]: systemd-udevd.service: Main process > > > exited, code=killed, status=9/KILL > > > > This indicates that something killed the processes in question with > > SIGKILL. Quite possibly this was the OOM killer, which was triggered > > by your stress test? Check the kernel logs if you see anything about > > that... > > > I have seen this problem on another system a while ago. But on all the > systems which this problem can be reproduced, there isn't any OOM killer > message can be found in kernel logs. How could we debug this problem? You could use auditd to monitor the signals and then you will see which process have sent the SIGKILL. There is also another method mentioned here: https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/Finding_the_source_of_signals_on_Linux_with_strace_auditd_or_Systemtap?lang=en Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] on the default for, PredictableNetworkInterfaceNames
>Ifconfig does not show anything useful. lspci might provide something I can use to construct it, but I'm >not sure. "dmesg | grep enp3s0" confirms this, but I still need to manually construct the entire string. I didn't make it through the rest of your post, but thought I'd chime in with `ifconfig` has been deprecated since 2009. 2009. I don't get deep into the distros, but I really wish they'd stop shipping it. `man ip` should give you info on the right tool you need to retrieve your network info. From there it is just some pipework to get a list you can iterate over. $ ip -o a | awk '{print $2}' | uniq ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Call for a small extension - Passing the startup timeout to the processes as environment variable
Hi Hi, I'm interested in a small extension around systemd passing a set of environment variables to processes executed (mainly what is happening in: build_environment(); execute.c) What are we planning to do: - We are planning to have some functionality linked against applications started by systemd (in a shared library or so) - The purpose of the shared library is to debug out some information about the applications state and about the process in general in case o The watchdog is not served right in time o The READY=1 sd_notify signal is not sent right in time - The information must be dumped out before systemd kills the applications To the realization: - The involved sd_notify calls are not directly called by the application, the application uses an abstraction provided by the shared library. The library delegates further respective calls. o So we are able to detect when an application serves the watchdog or sends the READY=1 signal - We need now a way to detect at about 90% of the elapsed timeout that the application is not reacting - For this, we need to know the watchdog timeout and the startup timeout set in the service file o The first one is passed as ENVIRONMENT variable by systemd to the processes o The second one is not To the request: - Would it be possible to add some code lines to pass the startup timeout time as well as ENVIRONMENT variable? Would be cool. Thx in advance! Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to troubleshoot 'step CHDIR spawning' failure.
>>* I've verified that '/bin/mkdir' does exist and does run fine. So I assume *>>* the the 'No such file or directory' refers to the target of the chdir. *>> >>* My question is how do I troubleshoot from here? What can I do to determine *>>* exactly what file or directory is not being found. I'd like to understand *>>* what is wrong and fix it. *> > CHDIR failure points to something related with directory. Check > what directives you have in unit file - maybe WorkingDirectory= with > dir that do not exists? Or RootDirectory= ? > Speculating further - maybe you are trying to mkdir directory which > you also put in RootDirectory= ? This won't work, because /bin/mkdir is > run in the same environment that main process; but you can > – investigate if PermissionStartOnly= (man systemd.service) will help you > – use RuntimeDirectory= (man systemd.service) to automate directory >creation > - use tmpfiles to precreate all directories Sorry, I should have included the entire contents of the service file. Your speculation was right on... hidden among all the commands the the [Service] section was a WorkingDirectory= statement that I hadn't noticed. It was, indeed, pointing to a directory that doesn't exist. Easy fix. Thank you. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?
On Wed, Apr 13, 2016 at 04:43:27PM +0300, Ran Benita wrote: > On Wed, Apr 13, 2016 at 01:04:17PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Apr 13, 2016 at 02:26:49PM +0300, Ran Benita wrote: > > > coredumpctl doesn't show the crash so can't say what it's about. Maybe > > > it's a distro problem (archlinux) or it's fixed in git. > > > > It's probably the bug that was fixed in > > https://github.com/systemd/systemd/pull/2702. > > Thanks. > > BTW, this brings up this thought: say I'm a system administrator and I > set DNSSEC=yes, and rely on it to fail any unauthenticated lookups. If > resolved crashes for some reason, the nss module will just start using > the fallback, which probably doesn't fail unauthenticated lookups. So > it's fail-open, IIUC. Maybe the nss module should look at the DNSSEC= > setting? Good point. Definitely something to consider in the long run. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?
On Wed, Apr 13, 2016 at 01:04:17PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Apr 13, 2016 at 02:26:49PM +0300, Ran Benita wrote: > > coredumpctl doesn't show the crash so can't say what it's about. Maybe > > it's a distro problem (archlinux) or it's fixed in git. > > It's probably the bug that was fixed in > https://github.com/systemd/systemd/pull/2702. Thanks. BTW, this brings up this thought: say I'm a system administrator and I set DNSSEC=yes, and rely on it to fail any unauthenticated lookups. If resolved crashes for some reason, the nss module will just start using the fallback, which probably doesn't fail unauthenticated lookups. So it's fail-open, IIUC. Maybe the nss module should look at the DNSSEC= setting? Ran ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Best approach to run python service in virtualenv with systemd
Hi all, I'm trying to run kallithea using virtualenv, it kinda works (I can stop/start service) with this unit file [Unit] Description=Start Kallithea service After=network.target [Service] Type=forking User=kallithea WorkingDirectory=/srv/kallithea ExecStart=/srv/kallithea/venv/bin/python2 /srv/kallithea/venv/bin/paster serve --daemon --pid-file=/srv/kallithea/kallithea.pid --log-file=/srv/kallithea/kallithea.log my.ini PIDFile=/srv/kallithea/kallithea.pid [Install] WantedBy=multi-user.target # but I always see "Failed to read PID from file /srv/kallithea/kallithea.pid: Invalid argument" in "systemctl status", I know that "PIDFile" option isn't a best practice and should be avoided, but withou it service doesn't running. Is there any better methods to run it or at least remove this pid error message? Thanks, Stan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?
On Wed, Apr 13, 2016 at 02:26:49PM +0300, Ran Benita wrote: > OK, I just looked at the logs and figured out what happens: resolved > crashes whenever I perform a query with allow-downgrade, and after a few > times it doesn't restart and presumably the nss module falls back to > direct DNS queries. Here is the log: > > Apr 13 13:56:31 ran systemd[1]: Started Network Name Resolution. > Apr 13 13:56:31 ran systemd-resolved[4687]: Switching to DNS server 10.0.0.10 > for interface wlp3s0. > Apr 13 13:56:31 ran systemd-resolved[4687]: Using degraded feature set > (UDP+EDNS0) for DNS server 10.0.0.10. > Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for > question com. IN SOA: failed-auxiliary > Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for > question google.com. IN DS: failed-auxiliary > Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for > question google.com. IN SOA: failed-auxiliary > Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for > question google.com. IN A: failed-auxiliary > Apr 13 13:56:31 ran kernel: systemd-resolve[4687]: segfault at 5c ip > 55b0062a5c57 sp 7ffee0d320a0 error 4 in > systemd-resolved[55b006281000+9d000] > Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Main process > exited, code=killed, status=11/SEGV > Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Unit entered failed > state. > Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Failed with result > 'signal'. > Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Service has no > hold-off time, scheduling restart. > Apr 13 13:56:31 ran systemd[1]: Stopped Network Name Resolution. > Apr 13 13:56:31 ran systemd[1]: org.freedesktop.resolve1.busname: Start > request repeated too quickly. > Apr 13 13:56:31 ran systemd[1]: Failed to listen on Network Name Resolution > Service Bus Name. > Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Start request > repeated too quickly. > Apr 13 13:56:31 ran systemd[1]: Failed to start Network Name Resolution. > > coredumpctl doesn't show the crash so can't say what it's about. Maybe > it's a distro problem (archlinux) or it's fixed in git. It's probably the bug that was fixed in https://github.com/systemd/systemd/pull/2702. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to log to journald using fifo?
On Wed, Apr 13, 2016 at 2:43 PM, Samuel Williams < space.ship.travel...@gmail.com> wrote: > I guess what I'm proposing is not a specific workaround but a way for > legacy software which can only log to a file to get it's data into > journald. There is plenty of software like that, unfortunately. It's a > pragmatic option. > > In this specific case, I'm referring to Nginx in daemon mode, which closes > /dev/stderr as far as I can tell, and then spawns passenger, which can only > log to a file. There is no way to hook up passenger to /dev/stderr. > > The proposed service allows anyone to set up a fifo for logging in this > situation, it's very trivial and easy to set up, but I suspect there is > more than just one person with this issue. > If you're going to run a service anyway, could you use e.g. rsyslog's imfile → omjournal modules? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to troubleshoot 'step CHDIR spawning' failure.
On Wed, Apr 13, 2016 at 07:28:34AM -0400, MikeB wrote: > I'm running systemd 215 on a fairly up-to-date Debian Jessie system. > > I have a Type=forking service that fails on its first ExecStartPre command > which is using /bin/mkdir to create a directory. > > The service fails to start with the following. > > Apr 13 10:07:42 localhost systemd[1]: Starting OVSDB Server Daemon... > Apr 13 10:07:42 localhost systemd[4069]: Failed at step CHDIR spawning > /bin/mkdir: No such file or directory > Apr 13 10:07:42 localhost systemd[1]: ovsdb-server.service: control process > exited, code=exited status=200 > Job for ovsdb-server.service failed. See 'systemctl status > ovsdb-server.service' and 'journalctl -xn' for details. > Apr 13 10:07:42 localhost systemd[1]: Failed to start OVSDB Server Daemon. > Apr 13 10:07:42 localhost systemd[1]: Unit ovsdb-server.service entered > failed state. > a > > I've verified that '/bin/mkdir' does exist and does run fine. So I assume > the the 'No such file or directory' refers to the target of the chdir. > > My question is how do I troubleshoot from here? What can I do to determine > exactly what file or directory is not being found. I'd like to understand > what is wrong and fix it. CHDIR failure points to something related with directory. Check what directives you have in unit file - maybe WorkingDirectory= with dir that do not exists? Or RootDirectory= ? Speculating further - maybe you are trying to mkdir directory which you also put in RootDirectory= ? This won't work, because /bin/mkdir is run in the same environment that main process; but you can – investigate if PermissionStartOnly= (man systemd.service) will help you – use RuntimeDirectory= (man systemd.service) to automate directory creation - use tmpfiles to precreate all directories -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to log to journald using fifo?
I guess what I'm proposing is not a specific workaround but a way for legacy software which can only log to a file to get it's data into journald. There is plenty of software like that, unfortunately. It's a pragmatic option. In this specific case, I'm referring to Nginx in daemon mode, which closes /dev/stderr as far as I can tell, and then spawns passenger, which can only log to a file. There is no way to hook up passenger to /dev/stderr. The proposed service allows anyone to set up a fifo for logging in this situation, it's very trivial and easy to set up, but I suspect there is more than just one person with this issue. On 12 April 2016 at 02:21, Lennart Poettering wrote: > On Sun, 10.04.16 22:57, Samuel Williams (space.ship.travel...@gmail.com) > wrote: > > > Hello, > > > > > > I've been trying to figure out the best way to support legacy > applications > > that don't support syslog for logging. The best we can do, I think, is to > > use fifo and have another process read the fifo to journald. > > Note that on systemd everything logged out stdout or stderr ends up in > the journal anyway. And you can specify /dev/stderr or /proc/self/fd/2 > as path referring to stderr on Linux generally, if you need. > > > Finally, if this is a good approach, is this method worth putting into > > systemd/journald as a standard service? If so, how do I submit a PR or > > where to begin? > > Specific work-arounds around other, unrelated pieces of software are > not really what we we'd like to add to systemd directly. Sorry. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to troubleshoot 'step CHDIR spawning' failure.
I'm running systemd 215 on a fairly up-to-date Debian Jessie system. I have a Type=forking service that fails on its first ExecStartPre command which is using /bin/mkdir to create a directory. The service fails to start with the following. Apr 13 10:07:42 localhost systemd[1]: Starting OVSDB Server Daemon... Apr 13 10:07:42 localhost systemd[4069]: Failed at step CHDIR spawning /bin/mkdir: No such file or directory Apr 13 10:07:42 localhost systemd[1]: ovsdb-server.service: control process exited, code=exited status=200 Job for ovsdb-server.service failed. See 'systemctl status ovsdb-server.service' and 'journalctl -xn' for details. Apr 13 10:07:42 localhost systemd[1]: Failed to start OVSDB Server Daemon. Apr 13 10:07:42 localhost systemd[1]: Unit ovsdb-server.service entered failed state. a I've verified that '/bin/mkdir' does exist and does run fine. So I assume the the 'No such file or directory' refers to the target of the chdir. My question is how do I troubleshoot from here? What can I do to determine exactly what file or directory is not being found. I'd like to understand what is wrong and fix it. Thanks and Regards, Mike ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?
OK, I just looked at the logs and figured out what happens: resolved crashes whenever I perform a query with allow-downgrade, and after a few times it doesn't restart and presumably the nss module falls back to direct DNS queries. Here is the log: Apr 13 13:56:31 ran systemd[1]: Started Network Name Resolution. Apr 13 13:56:31 ran systemd-resolved[4687]: Switching to DNS server 10.0.0.10 for interface wlp3s0. Apr 13 13:56:31 ran systemd-resolved[4687]: Using degraded feature set (UDP+EDNS0) for DNS server 10.0.0.10. Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for question com. IN SOA: failed-auxiliary Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for question google.com. IN DS: failed-auxiliary Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for question google.com. IN SOA: failed-auxiliary Apr 13 13:56:31 ran systemd-resolved[4687]: DNSSEC validation failed for question google.com. IN A: failed-auxiliary Apr 13 13:56:31 ran kernel: systemd-resolve[4687]: segfault at 5c ip 55b0062a5c57 sp 7ffee0d320a0 error 4 in systemd-resolved[55b006281000+9d000] Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Main process exited, code=killed, status=11/SEGV Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Unit entered failed state. Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Failed with result 'signal'. Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Service has no hold-off time, scheduling restart. Apr 13 13:56:31 ran systemd[1]: Stopped Network Name Resolution. Apr 13 13:56:31 ran systemd[1]: org.freedesktop.resolve1.busname: Start request repeated too quickly. Apr 13 13:56:31 ran systemd[1]: Failed to listen on Network Name Resolution Service Bus Name. Apr 13 13:56:31 ran systemd[1]: systemd-resolved.service: Start request repeated too quickly. Apr 13 13:56:31 ran systemd[1]: Failed to start Network Name Resolution. coredumpctl doesn't show the crash so can't say what it's about. Maybe it's a distro problem (archlinux) or it's fixed in git. Ran ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] resolved: does DNSSEC=allow-downgrade affect caching?
Hey, I read in the v229 NEWS that it is now possible to specify DNSSEC=allow-downgrade and decided to try it. Note that I use my local home router's DNS server which certainly does not support DNSSEC. I configured the system to use resolved by changing "dns" to "resolve" in nsswitch.conf. I use systemd v229. I use the following simple python to test the DNS response time: import time, socket; before = time.time(); socket.gethostbyname('google.com'); after = time.time() print((after - before) * 1000) With resolved stopped entirely (systemctl stop), I get around ~22ms for all queries. With resolved started, and setting DNSSEC=no, I get ~22ms first time, and ~2m in subsequent queries. With resolved started, and setting DNSSEC=allow-downgrade, I get ~22ms consistently after a few times. So it seems like with allow-downgrade, local caching isn't performed? Is this expected behavior for this option? Or maybe I did something wrong? (I am lazy and didn't try to investigate with wireshark and/or the code). Ran ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 13.04.2016 um 02:15 schrieb pgndev: On Tue, Apr 12, 2016 at 5:06 PM, Reindl Harald wrote: Is there a ML anywhere on which you don't sputter, fume, rant and insult? interesting that you say that to me in this thread while the OP started very early to call people "Idiot", "why someone does not do a certain thing, you are an idiot" and "are you silly" given that and that he even admit repeatly that he have no really clue about many things which are relevant to the topic and then comes up with "well, do a sleep 3" the only correct answer is STOP IT, the whole thread signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 13.04.2016 um 03:08 schrieb Xen: Reindl Harald schreef op 13-04-16 02:06: Am 13.04.2016 um 01:20 schrieb Xen: Greg KH schreef op 13-04-16 01:16: On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: All you need to do is wait a few seconds before you start renaming Most machines boot to login faster than a "few seconds", so: Most machines boot to login faster than a few seconds? What machines are you talking about? Anyway the 3 seconds I mentioned is or would be a relative number STOP IT NOW What are you on about? Just because I don't have a superfast system, I cannot say anything? no beause of "hmm let wait 3 seconds for something we don't know if it ever appears and how long it would take to appear" is unacceptable in general as additional boot time and on many setups would double the whole boot time nobody right in his mind would implement a "sleep 3" for a general purpose setup in the boot process *kernel time* is below 1 second on most machines signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 13.04.2016 um 02:42 schrieb Xen: Greg KH schreef op 13-04-16 01:29: On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: All execpt for 4-socket and larger servers. They take tens of minutes in the BIOS and then less than a minute in the kernel/userspace, depending on the amount of memory. Doesn't your laptop/desktop boot that fast? If not, you are using the wrong distro :) I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively new processor (FX 6300) does definitely not boot within a few seconds 4xHDD raid-10, hardware from 2011 Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s (userspace) = 18.810s os on sd-card Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s (userspace) = 13.005s so 3 seconds is unacceptable and the idea ist a joke in general because you wait for something possibly happen while you don't know how long you have to wait and jsut hope for luck - that's not a good design and won't bew accepted anywhere signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel