[systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
Hi, For some reason after I've built the Xorg xserver from git, and then login through gdm (on an otherwise unmodified F-20 install), the acls on /dev/snd/pcm* (and likely others too) no longer get setup to give the user I've just logged in with access to them. Reverting to Xorg from the F-20 packages fixes this. I was wonder if someone could give a short step by step of all components involved in doing the acl management for devices which should be usable by console users now a days. As well as some hints for debugging this. Thanks & Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-dhcp-client: refactor state machine check
---
src/libsystemd/sd-dhcp-client.c | 147 ++-
1 files changed, 36 insertions(+), 111 deletions(-)
diff --git a/src/libsystemd/sd-dhcp-client.c b/src/libsystemd/sd-dhcp-client.c
index a057852..3b7b9f4 100644
--- a/src/libsystemd/sd-dhcp-client.c
+++ b/src/libsystemd/sd-dhcp-client.c
@@ -33,6 +33,15 @@
#define DHCP_CLIENT_MIN_OPTIONS_SIZE312
+#define client_state_machine_check(s, r)\
+do {\
+if (s != DHCP_STATE_BOUND &&\
+s != DHCP_STATE_RENEWING && \
+s != DHCP_STATE_REBINDING) {\
+return (r); \
+} \
+} while (false)
+
struct DHCPLease {
uint32_t t1;
uint32_t t2;
@@ -166,21 +175,9 @@ int sd_dhcp_client_get_address(sd_dhcp_client *client,
struct in_addr *addr) {
assert_return(client, -EINVAL);
assert_return(addr, -EINVAL);
-switch (client->state) {
-case DHCP_STATE_INIT:
-case DHCP_STATE_SELECTING:
-case DHCP_STATE_INIT_REBOOT:
-case DHCP_STATE_REBOOTING:
-case DHCP_STATE_REQUESTING:
-return -EADDRNOTAVAIL;
-
-case DHCP_STATE_BOUND:
-case DHCP_STATE_RENEWING:
-case DHCP_STATE_REBINDING:
-addr->s_addr = client->lease->address;
+client_state_machine_check (client->state, -EADDRNOTAVAIL);
-break;
-}
+addr->s_addr = client->lease->address;
return 0;
}
@@ -189,24 +186,12 @@ int sd_dhcp_client_get_mtu(sd_dhcp_client *client,
uint16_t *mtu) {
assert_return(client, -EINVAL);
assert_return(mtu, -EINVAL);
-switch (client->state) {
-case DHCP_STATE_INIT:
-case DHCP_STATE_SELECTING:
-case DHCP_STATE_INIT_REBOOT:
-case DHCP_STATE_REBOOTING:
-case DHCP_STATE_REQUESTING:
-return -EADDRNOTAVAIL;
-
-case DHCP_STATE_BOUND:
-case DHCP_STATE_RENEWING:
-case DHCP_STATE_REBINDING:
-if (client->lease->mtu)
-*mtu = client->lease->mtu;
-else
-return -ENOENT;
+client_state_machine_check (client->state, -EADDRNOTAVAIL);
-break;
-}
+if (client->lease->mtu)
+*mtu = client->lease->mtu;
+else
+return -ENOENT;
return 0;
}
@@ -216,25 +201,13 @@ int sd_dhcp_client_get_dns(sd_dhcp_client *client, struct
in_addr **addr, size_t
assert_return(addr, -EINVAL);
assert_return(addr_size, -EINVAL);
-switch (client->state) {
-case DHCP_STATE_INIT:
-case DHCP_STATE_SELECTING:
-case DHCP_STATE_INIT_REBOOT:
-case DHCP_STATE_REBOOTING:
-case DHCP_STATE_REQUESTING:
-return -EADDRNOTAVAIL;
-
-case DHCP_STATE_BOUND:
-case DHCP_STATE_RENEWING:
-case DHCP_STATE_REBINDING:
-if (client->lease->dns_size) {
-*addr_size = client->lease->dns_size;
-*addr = client->lease->dns;
-} else
-return -ENOENT;
+client_state_machine_check (client->state, -EADDRNOTAVAIL);
-break;
-}
+if (client->lease->dns_size) {
+*addr_size = client->lease->dns_size;
+*addr = client->lease->dns;
+} else
+return -ENOENT;
return 0;
}
@@ -243,24 +216,12 @@ int sd_dhcp_client_get_domainname(sd_dhcp_client *client,
const char **domainnam
assert_return(client, -EINVAL);
assert_return(domainname, -EINVAL);
-switch (client->state) {
-case DHCP_STATE_INIT:
-case DHCP_STATE_SELECTING:
-case DHCP_STATE_INIT_REBOOT:
-case DHCP_STATE_REBOOTING:
-case DHCP_STATE_REQUESTING:
-return -EADDRNOTAVAIL;
-
-case DHCP_STATE_BOUND:
-case DHCP_STATE_RENEWING:
-case DHCP_STATE_REBINDING:
-if (client->lease->domainname)
-*domainname = client->lease->domainname;
-else
-return -ENOENT;
+client_state_machine_check (client->state, -EADDRNOTAVAIL);
-break;
-}
+if (client->lease->domainname)
+*domainname = client->lease->domainname;
+else
+return -ENOENT;
return 0;
}
@@ -269,24 +230,12 @@ int sd_dhcp_client_get_hostname(sd_dhcp_client *client,
const char **hostname) {
assert_return(client, -EINVAL);
assert_return(hostname
Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
'Twas brillig, and Hans de Goede at 20/01/14 08:42 did gyre and gimble: > Hi, > > For some reason after I've built the Xorg xserver from git, and then login > through gdm (on an otherwise unmodified F-20 install), the acls on > /dev/snd/pcm* (and likely others too) no longer get setup to give the user > I've just logged in with access to them. > > Reverting to Xorg from the F-20 packages fixes this. I was wonder if > someone > could give a short step by step of all components involved in doing the acl > management for devices which should be usable by console users now a days. > > As well as some hints for debugging this. Ultimately, the ACLs are applied to the active session to all device nodes which have the uaccess tag. e.g. on my machine: [colin@jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p P: /devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p N: snd/pcmC0D0p E: DEVNAME=/dev/snd/pcmC0D0p E: DEVPATH=/devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p E: MAJOR=116 E: MINOR=3 E: SUBSYSTEM=sound E: TAGS=:uaccess: E: USEC_INITIALIZED=62743 Notice the uaccess tag. Ultimately this is applied to the "active" session, so you have to look to loginctl: [colin@jimmy code (master)]$ loginctl SESSIONUID USER SEAT 1603 colinseat0 20603 colinseat0 I seem to have two sessions here. I'll look a the first one: [colin@jimmy code (master)]$ loginctl show-session 1 Id=1 Timestamp=Thu 2014-01-16 12:34:44 GMT TimestampMonotonic=41640698 VTNr=1 Display=:0 Remote=no Service=gdm-password Scope=session-1.scope Leader=3563 Audit=1 Type=x11 Class=user Active=no State=closing IdleHint=no IdleSinceHint=1389896019397017 IdleSinceHintMonotonic=20376502012 Name=colin OK, this one is NOT active and is closing. This is likely an older session that has since been replaced after logging out and back in again but it keeps some binaries running (likely gpg-agent stuff at a first guess). Lets look: [colin@jimmy code (master)]$ loginctl session-status 1 1 - colin (603) Since: Thu 2014-01-16 12:34:44 GMT; 3 days ago Leader: 3563 Seat: seat0; vc1 Display: :0 Service: gdm-password; type x11; class user State: closing Unit: session-1.scope ├─3647 ssh-agent ├─3672 gpg-agent --daemon ├─3889 /usr/bin/pulseaudio --start --log-target=syslog ├─3898 /usr/libexec/pulse/gconf-helper └─6871 gpg-agent --keep-display --daemon --write-env-file /root/.gnupg/gpg-agent-info Yup, in this case, I have my ssh-agent, gpg-agent and PulseAudio services all loaded under the previous session. They didn't timeout and stop after my logout and as things are not setup to kill all processes, the session stays around in it's closing state. This is, so far, not overly surprising even if the whole situation there is a little messy (having the "closing" session live on as a kind of expected thing). Anyway, looking at session 20: [colin@jimmy code (master)]$ loginctl show-session 20 Id=20 Timestamp=Thu 2014-01-16 18:15:14 GMT TimestampMonotonic=20471336546 VTNr=1 Display=:0 Remote=no Service=gdm-password Scope=session-20.scope Leader=17287 Audit=20 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=1390208956248075 IdleSinceHintMonotonic=138343463253 Name=colin It IS active, and thus my ACLs should be in place. To actually debug the process of the uaccess tag and the device chowining etc. you'd have to look more into logind itself and perhaps turn on systemd debugging to see what it says about it (that said, I'm not sure what debug it actually shows about this operation). Certainly if the above bits are all working OK, then you can start to probe further. If you don't have an active session then this is likely what's wrong. Note that logging in via a tty and using e.g. startx *can* lead to this situation unless the VT is reused for X11 which is not the default upstream behaviour AFAIK. Most downstreams patch this behaviour in in some way however, but worth pointing out just in case that's what's tripping you up. HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
On Mon, Jan 20, 2014 at 9:42 AM, Hans de Goede wrote:
> Hi,
>
> For some reason after I've built the Xorg xserver from git, and then login
> through gdm (on an otherwise unmodified F-20 install), the acls on
> /dev/snd/pcm* (and likely others too) no longer get setup to give the user
> I've just logged in with access to them.
>
> Reverting to Xorg from the F-20 packages fixes this. I was wonder if someone
> could give a short step by step of all components involved in doing the acl
> management for devices which should be usable by console users now a days.
>
> As well as some hints for debugging this.
There are udev rules adding a tag to the devices which should get ACLs attached:
/usr/lib/udev/rules.d/70-uaccess.rules
TAG+="uaccess"
After device processing, the tags end up in the udev database:
$ udevadm info /sys/class/sound/controlC0 | grep TAGS
E: TAGS=:uaccess:
Private implementation details, never read directly, but useful for debugging:
$ grep G: /run/udev/data/c116\:10
G:uaccess
$ ls -1 /run/udev/tags/uaccess/
c10:232
c10:58
c116:10
...
During rules processing udev calls internally:
/usr/lib/udev/rules.d/73-seat-late.rules
RUN{builtin}+="uaccess"
which actually adds the ACLs directly in the hotplug path.
At login/logout time, pam_systemd calls out to systemd-logind, logind
reads the above tags directory (with libudev) and applies/removes ACLs
to all devices with the uaccess tag.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Fri 17 Jan 2014 21:17:04 Lennart Poettering wrote: > On Tue, 14.01.14 13:31, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > systemd-208-9.fc20.x86_64 > > > > We have been porting a working configuration from fedora 19 to fedora 20. > > After systemd prints the Welcome message it then hangs. > > What do you mean by "hangs"? Is it just the output that doesn't continue > anymore or does the entire system lock up? After a few minutes nothing is output after the Welcome message. No evidence that any unit start. > > Note that during really early boot the journal is not available yet, > which means we can only log to kmsg then (and thus the > console). However, as soon as the journal is available we then start > logging directly to the journal. This might appear from the outside as > if only during the first part of the boot output is generated if you > only look at the console. Understood and recall that I'm porting from F19 to F20 and this works in F19. With my engineer hat on I wonder why info messages can be output but not one debug message? > You can use LogTarget=kmsg to redirect output to kmsg unconditionally, > so that you get everything in kmsg and thus the console. And by using the kernel option log_buf_len=128M we can make sure all the messages are kept. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .socket in a network namespace
On Fri, 17.01.14 17:11, Alex Polvi (a...@polvi.net) wrote: > Hello, > > Is there a way to have a .socket bind in a particular network > namespace? The use case is to have a container with isolated > networking be able to start a service, or tunnel to a remote service, > that exists outside the containers namespace. > > Thank you for any leads. I could not find anything related to this in > the documentation. This is currently not available, and not easy to do, since for creating and binding the sockets in the right namespace we'd have to change the namespace first. Doing this for the whole of PID 1 is however something I really would hate. So the other option is to fork a tiny process off, that joins the namespace, creates/binds the sockets and passes the fd back to PID 1 via SCM_RIGHTS. Not pretty, but certainly doable, and we in fact do something similar in libsystem-bus in order to be able to connect to container busses from outside of them, which also requires doing a namespace transition. There has been a long standing TODO list item, that could also benefit from a scheme like this: it has been requested that AF_UNIX sockets created via .socket units could get a specific UID/GID assigned (i.e. chown() and chgrp() run on them). This, however, is hard to do from PID 1, since we cannot allow doing NSS calls from PID 1, for resolving those names. Such a forked off mini process that does NSS and joins a specific namespace could work for this however. So, when we fix one, we can certainly fix the other at the same time. However, both of these issues are not trivial to do, so don't hold your breath... ;-) For now I have added this to the TODO list. 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 1/2] build-sys: merge libsystemd-login into libsystemd
On Sun, 19.01.14 14:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > So, I prepared a test patch. This all doesn't seem to be too ugly generally, > although the warning generation in patch 2 is a bit. > > Comments? > > A compatibility libsystemd-login library is created which uses > .symver and ifunc magic proposed by Lennart to make programs linked > to the old library name continue to work seamlessly. > > Unfortunately the bfd linker crashes: > https://sourceware.org/bugzilla/show_bug.cgi?id=16467 > As a work-around, gold can be used: > LDFLAGS=-Wl,-fuse-ld=gold > > This also doesn't work with LLVM: > http://llvm.org/bugs/show_bug.cgi?id=11897 Looks good to me. That bfd chokes on this is a bummer though... But as long as the bfd fix is backportable it sounds totally OK to me to still do this. 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] logind and sessions tracking questions - (was: Debugging acl settings)
Hi Coling, Coling please I've some questions regarding what you have posted, see below. I'm trying to debug another bug in logind logic: http://lists.freedesktop.org/archives/systemd-devel/2014-January/015968.html I've located some bugs, I've a PoC version working, will post it but first need to clear some points here to avoid breaking things. On Mon, Jan 20, 2014 at 09:54:48AM +, Colin Guthrie wrote: > 'Twas brillig, and Hans de Goede at 20/01/14 08:42 did gyre and gimble: > > Hi, > > > > For some reason after I've built the Xorg xserver from git, and then login > > through gdm (on an otherwise unmodified F-20 install), the acls on > > /dev/snd/pcm* (and likely others too) no longer get setup to give the user > > I've just logged in with access to them. > > > > Reverting to Xorg from the F-20 packages fixes this. I was wonder if > > someone > > could give a short step by step of all components involved in doing the acl > > management for devices which should be usable by console users now a days. > > > > As well as some hints for debugging this. > > Ultimately, the ACLs are applied to the active session to all device > nodes which have the uaccess tag. > > e.g. on my machine: > > [colin@jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p > P: /devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p > N: snd/pcmC0D0p > E: DEVNAME=/dev/snd/pcmC0D0p > E: DEVPATH=/devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p > E: MAJOR=116 > E: MINOR=3 > E: SUBSYSTEM=sound > E: TAGS=:uaccess: > E: USEC_INITIALIZED=62743 > > > Notice the uaccess tag. > > Ultimately this is applied to the "active" session, so you have to look > to loginctl: > > > [colin@jimmy code (master)]$ loginctl >SESSIONUID USER SEAT > 1603 colinseat0 > 20603 colinseat0 > > > > I seem to have two sessions here. I'll look a the first one: > > [colin@jimmy code (master)]$ loginctl show-session 1 > Id=1 > Timestamp=Thu 2014-01-16 12:34:44 GMT > TimestampMonotonic=41640698 > VTNr=1 > Display=:0 > Remote=no > Service=gdm-password > Scope=session-1.scope > Leader=3563 > Audit=1 > Type=x11 > Class=user > Active=no > State=closing > IdleHint=no > IdleSinceHint=1389896019397017 > IdleSinceHintMonotonic=20376502012 > Name=colin > > > OK, this one is NOT active and is closing. This is likely an older > session that has since been replaced after logging out and back in again > but it keeps some binaries running (likely gpg-agent stuff at a first > guess). Lets look: Here I assume you are using a new systemd version (Fedora 20)? or systemd from git? I noticed in old systemd v204, the "Active" flag would be set to "yes" when we logout and the session keeps some programs running like 'screen'! I guess this also applies to gpg-agent... > [colin@jimmy code (master)]$ loginctl session-status 1 > 1 - colin (603) >Since: Thu 2014-01-16 12:34:44 GMT; 3 days ago > Leader: 3563 > Seat: seat0; vc1 > Display: :0 > Service: gdm-password; type x11; class user >State: closing > Unit: session-1.scope > ├─3647 ssh-agent > ├─3672 gpg-agent --daemon > ├─3889 /usr/bin/pulseaudio --start --log-target=syslog > ├─3898 /usr/libexec/pulse/gconf-helper > └─6871 gpg-agent --keep-display --daemon > --write-env-file /root/.gnupg/gpg-agent-info > > > Yup, in this case, I have my ssh-agent, gpg-agent and PulseAudio > services all loaded under the previous session. They didn't timeout and > stop after my logout and as things are not setup to kill all processes, Please can you tell me about this last one "kill all processes" ? How we set this flag? from my source code analysis I didn't found it and the new man page of pam_systemd does not show it: http://www.freedesktop.org/software/systemd/man/pam_systemd.html And I'm sure it was there at least for systemd 204! > the session stays around in it's closing state. This is, so far, not > overly surprising even if the whole situation there is a little messy > (having the "closing" session live on as a kind of expected thing). Hmm, ok this should be the default behaviour, I mean if processes are not killed after logout then the session and user state files should not be removed and the state would be "closing"! I've some notes about logind logic, I'll post them with the patches and Cc'you Thank you in advance Colin, I will Cc'you for pathes! -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Fri, 17.01.14 16:52, David Timothy Strauss (da...@davidstrauss.net) wrote: > It would be nice if bootup could realize the journal queue is full and > wait for journal startup before proceeding further. It might cause > some annoying non-determinism, though. Not following here. Logging in syslog and the journal is synhchronous: as soon as the socket fills up the clients start to block until the other side made space again. THis means that no messages should be lost and boot-up should be neatly synchronized to the logging sserver speed. Note that by default the socket buffer is really small. The kernel puts a limit to 15 messages by default, (/proc/sys/net/unix/max_dgram_qlen can be used to change this, unfortunately only globally), and the socket buffer limit in bytes is pretty short too... -- the latter is now bumped if possible with systemd git, but that only works with priviliged clients... 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] systemd hangs after Welcome message when LogLevel=debug
On Mon, 20.01.14 11:22, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > On Fri 17 Jan 2014 21:17:04 Lennart Poettering wrote: > > On Tue, 14.01.14 13:31, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > > systemd-208-9.fc20.x86_64 > > > > > > We have been porting a working configuration from fedora 19 to fedora 20. > > > After systemd prints the Welcome message it then hangs. > > > > What do you mean by "hangs"? Is it just the output that doesn't continue > > anymore or does the entire system lock up? > > After a few minutes nothing is output after the Welcome message. > No evidence that any unit start. It would be good to if I could have a look at the output of "journalctl -o short-monotonic -b" of the log messages around the time where this happens... > With my engineer hat on I wonder why info messages can be output but not one > debug message? Not following? 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] daemon-reload seems racy
On Thu, 16.01.14 12:28, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Colin Guthrie at 14/01/14 13:28 did gyre and gimble: > > 3. Some sort of kernel trigger for me today led it to run two reexecs > > quite quickly and triggered this problem randomly during runtime. This > > *might* have come in via "telinit u" instead. It doesn't appear that the > > kernel actually execs telinit directly but perhaps userspace can react > > on it in some way? > > OK, this, it turns out is a result of running prelink via cron. > > The prelink package we (Mageia) have is basically the same as the Fedora > one. It has a cronjob which calls "telinit u" but the prelink binary > itself calls "/sbin/init U" which does the same thing, thus two > daemon-reexecs in rapid succession which triggers this bug. > > For now I've disabled the "telinit u" call in prelink, but the real > trick would be fixing the bug/race in serialisation :) Hmm, so, normally PID 1 should not accept new requests after the deserialization of the first reexec is complete. Let me sumarize this a bit: Is this about reexec or reload? Or both? This is supposed to trigger the issue? "systemctl daemon-reexec ; systemctl daemon-reexec"? What precisely goes bad afterwards? Does this always trigger the issue or only sometimes? WHat version are you using? Can you reproduce the issue on git? 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] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
On Mon, 13.01.14 11:16, Colin Guthrie (gm...@colin.guthr.ie) wrote: > Hi, > > I've just been debugging a weird problem in my 208 build (which is quite > similar to Fedora's - a lot of the same patches). > > So far I've noticed two problems: > > > 1. If I do "systemctl enable sysvinitscript" it will print me a warning > about how the units do not carry [Install] sections. This is > unsurprising as there are no units (the systemctl.c mangled_names - or > just names in git master) left after the enable_sysv_units() method is > called and the first item is a pointer to a null string. I suspect > various bus calls could just be harmlessly skipped if this is the case > (i.e. just don't do the various unit related method calls) as we know > they are handled locally. > > I've attached two patches which should solve this (one for 208+patches > and one for git master aka 209) although I've not tested either > directly. Some other eyes on it as to whether it's the correct approach > or not would be appreciated. The only difference between the two > versions is a variable name change. For this issue I applied a different patch to git now. Can you check pls? (The patch simply skips all of the native enabling if the list is empty, including the reload, under the assumption that chkconfig will care for that on its own...) 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] sd-dhcp-client: refactor state machine check
On Mon, Jan 20, 2014 at 9:58 AM, Umut Tezduyar Lindskog
wrote:
> ---
> src/libsystemd/sd-dhcp-client.c | 147
> ++-
> 1 files changed, 36 insertions(+), 111 deletions(-)
>
> diff --git a/src/libsystemd/sd-dhcp-client.c b/src/libsystemd/sd-dhcp-client.c
> index a057852..3b7b9f4 100644
> --- a/src/libsystemd/sd-dhcp-client.c
> +++ b/src/libsystemd/sd-dhcp-client.c
> @@ -33,6 +33,15 @@
>
> #define DHCP_CLIENT_MIN_OPTIONS_SIZE312
>
> +#define client_state_machine_check(s, r)\
> +do {\
> +if (s != DHCP_STATE_BOUND &&\
> +s != DHCP_STATE_RENEWING && \
> +s != DHCP_STATE_REBINDING) {\
> +return (r); \
> +} \
> +} while (false)
> +
> struct DHCPLease {
> uint32_t t1;
> uint32_t t2;
> @@ -166,21 +175,9 @@ int sd_dhcp_client_get_address(sd_dhcp_client *client,
> struct in_addr *addr) {
> assert_return(client, -EINVAL);
> assert_return(addr, -EINVAL);
>
> -switch (client->state) {
> -case DHCP_STATE_INIT:
> -case DHCP_STATE_SELECTING:
> -case DHCP_STATE_INIT_REBOOT:
> -case DHCP_STATE_REBOOTING:
> -case DHCP_STATE_REQUESTING:
> -return -EADDRNOTAVAIL;
> -
> -case DHCP_STATE_BOUND:
> -case DHCP_STATE_RENEWING:
> -case DHCP_STATE_REBINDING:
> -addr->s_addr = client->lease->address;
> +client_state_machine_check (client->state, -EADDRNOTAVAIL);
>
> -break;
> -}
> +addr->s_addr = client->lease->address;
>
> return 0;
> }
> @@ -189,24 +186,12 @@ int sd_dhcp_client_get_mtu(sd_dhcp_client *client,
> uint16_t *mtu) {
> assert_return(client, -EINVAL);
> assert_return(mtu, -EINVAL);
>
> -switch (client->state) {
> -case DHCP_STATE_INIT:
> -case DHCP_STATE_SELECTING:
> -case DHCP_STATE_INIT_REBOOT:
> -case DHCP_STATE_REBOOTING:
> -case DHCP_STATE_REQUESTING:
> -return -EADDRNOTAVAIL;
> -
> -case DHCP_STATE_BOUND:
> -case DHCP_STATE_RENEWING:
> -case DHCP_STATE_REBINDING:
> -if (client->lease->mtu)
> -*mtu = client->lease->mtu;
> -else
> -return -ENOENT;
> +client_state_machine_check (client->state, -EADDRNOTAVAIL);
>
> -break;
> -}
> +if (client->lease->mtu)
> +*mtu = client->lease->mtu;
> +else
> +return -ENOENT;
>
> return 0;
> }
> @@ -216,25 +201,13 @@ int sd_dhcp_client_get_dns(sd_dhcp_client *client,
> struct in_addr **addr, size_t
> assert_return(addr, -EINVAL);
> assert_return(addr_size, -EINVAL);
>
> -switch (client->state) {
> -case DHCP_STATE_INIT:
> -case DHCP_STATE_SELECTING:
> -case DHCP_STATE_INIT_REBOOT:
> -case DHCP_STATE_REBOOTING:
> -case DHCP_STATE_REQUESTING:
> -return -EADDRNOTAVAIL;
> -
> -case DHCP_STATE_BOUND:
> -case DHCP_STATE_RENEWING:
> -case DHCP_STATE_REBINDING:
> -if (client->lease->dns_size) {
> -*addr_size = client->lease->dns_size;
> -*addr = client->lease->dns;
> -} else
> -return -ENOENT;
> +client_state_machine_check (client->state, -EADDRNOTAVAIL);
>
> -break;
> -}
> +if (client->lease->dns_size) {
> +*addr_size = client->lease->dns_size;
> +*addr = client->lease->dns;
> +} else
> +return -ENOENT;
>
> return 0;
> }
> @@ -243,24 +216,12 @@ int sd_dhcp_client_get_domainname(sd_dhcp_client
> *client, const char **domainnam
> assert_return(client, -EINVAL);
> assert_return(domainname, -EINVAL);
>
> -switch (client->state) {
> -case DHCP_STATE_INIT:
> -case DHCP_STATE_SELECTING:
> -case DHCP_STATE_INIT_REBOOT:
> -case DHCP_STATE_REBOOTING:
> -case DHCP_STATE_REQUESTING:
> -return -EADDRNOTAVAIL;
> -
> -case DHCP_STATE_BOUND:
> -case DHCP_STATE_RENEWING:
> -case DHCP_STATE_REBINDING:
> -if (client->lease->domainname)
> -*domainname = client->lease->domainname;
> -else
> -return -ENOENT;
> +client_state_machine_check (client->state, -EADDRNOTAVAIL);
>
> -break;
> -}
> +if (client->lease->d
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Mon 20 Jan 2014 13:21:14 Lennart Poettering wrote: > On Mon, 20.01.14 11:22, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > On Fri 17 Jan 2014 21:17:04 Lennart Poettering wrote: > > > On Tue, 14.01.14 13:31, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > > > systemd-208-9.fc20.x86_64 > > > > > > > > We have been porting a working configuration from fedora 19 to fedora > > > > 20. > > > > After systemd prints the Welcome message it then hangs. > > > > > > What do you mean by "hangs"? Is it just the output that doesn't continue > > > anymore or does the entire system lock up? > > > > After a few minutes nothing is output after the Welcome message. > > No evidence that any unit start. > > It would be good to if I could have a look at the output of "journalctl > -o short-monotonic -b" of the log messages around the time where this > happens... > > > With my engineer hat on I wonder why info messages can be output but not > > one debug message? > > Not following? Given this problem has not trigger an insight from your selves I clearly need to dig deeper to get more information. I'm very busy at work at the moment but hope to come back to this to help bottom out what is happening. Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
I drafted this last week, sorry for the delay. On Wed 15 Jan 2014 16:44:21 Holger Schurig wrote: > Educated guess (!) > > With LogLevel=debug, you generate huge amounts of output. With LogTarget=syslog-or-kmsg and kernel not quiet I would expect to see the first few debug messages before it hung up. But nothing appears. > With DefaultStandardOutput=syslog, you're asking systemd to send it's > output to syslog. > > But while systemd is starting your system the syslog might not be > ready. Probably systemd has some buffer, where it buffers the output. > Once syslog becomes available, it will be fed with the buffer's > contents first. If the output is small enought, as with LogLevel=info, > this actually works. But when you generate gobs of output, the buffer > will overflow and the output routine will wait until the buffer get's > emptied, which it never will ... > > So, you might try to use DefaultStandardOutput=syslog-or-kmsg or > DefaultStandardOutput=journal instead. The latter will eventually also > send the output to syslog, which is why it's a default. I guess you are saying that because all output must go to syslog and syslog is not running that systemd will hang. But why does the configuration work if LogLevel=info in that case? Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] daemon-reload seems racy
CC'ing Zbigniew as he's working on the Fedora bug AFAIK. 'Twas brillig, and Lennart Poettering at 20/01/14 12:37 did gyre and gimble: > On Thu, 16.01.14 12:28, Colin Guthrie (gm...@colin.guthr.ie) wrote: > >> >> 'Twas brillig, and Colin Guthrie at 14/01/14 13:28 did gyre and gimble: >>> 3. Some sort of kernel trigger for me today led it to run two reexecs >>> quite quickly and triggered this problem randomly during runtime. This >>> *might* have come in via "telinit u" instead. It doesn't appear that the >>> kernel actually execs telinit directly but perhaps userspace can react >>> on it in some way? >> >> OK, this, it turns out is a result of running prelink via cron. >> >> The prelink package we (Mageia) have is basically the same as the Fedora >> one. It has a cronjob which calls "telinit u" but the prelink binary >> itself calls "/sbin/init U" which does the same thing, thus two >> daemon-reexecs in rapid succession which triggers this bug. >> >> For now I've disabled the "telinit u" call in prelink, but the real >> trick would be fixing the bug/race in serialisation :) > > Hmm, so, normally PID 1 should not accept new requests after the > deserialization of the first reexec is complete. > > Let me sumarize this a bit: > > Is this about reexec or reload? Or both? I was confused at first, but it seems "both" in the end. See here for a reproduction case involving either (tho' reload requires a --no-block param to trigger): https://bugzilla.redhat.com/show_bug.cgi?id=1043212#c20 > This is supposed to trigger the issue? "systemctl daemon-reexec ; > systemctl daemon-reexec"? What precisely goes bad afterwards? Does this > always trigger the issue or only sometimes? On my system it's pretty reliable and will trigger it every time. It might need a setup where loading the serialised state triggers a few jobs to make it take longer. e.g. on my setup the Type=oneshot units were all rerun when reloading the state (which actually seems wrong to me - e.g. my alsa-restore.service job kicked in again which made an in-progress VoIP call weird by suddenly changing my Headphones port back to Speakers!! - I've since started using the alsa-state daemon instead which mitigates things, but re-running oneshot's seems wrong no?) > What version are you using? Can you reproduce the issue on git? It's almost identical to the fedora 20 version - 208 + lots of patches. Not tried latest git yet I'm afraid, but as it also apparently affects fedora 20 (see above bug) I'm guessing you'll need something backported anyway and I'm not sure if there is any specific fix (although the sdbus port might have fixed it indirectly if it doesn't occur any more) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] daemon-reload seems racy
2014/1/20 Colin Guthrie : > CC'ing Zbigniew as he's working on the Fedora bug AFAIK. > > 'Twas brillig, and Lennart Poettering at 20/01/14 12:37 did gyre and gimble: >> On Thu, 16.01.14 12:28, Colin Guthrie (gm...@colin.guthr.ie) wrote: >> >>> >>> 'Twas brillig, and Colin Guthrie at 14/01/14 13:28 did gyre and gimble: 3. Some sort of kernel trigger for me today led it to run two reexecs quite quickly and triggered this problem randomly during runtime. This *might* have come in via "telinit u" instead. It doesn't appear that the kernel actually execs telinit directly but perhaps userspace can react on it in some way? >>> >>> OK, this, it turns out is a result of running prelink via cron. >>> >>> The prelink package we (Mageia) have is basically the same as the Fedora >>> one. It has a cronjob which calls "telinit u" but the prelink binary >>> itself calls "/sbin/init U" which does the same thing, thus two >>> daemon-reexecs in rapid succession which triggers this bug. >>> >>> For now I've disabled the "telinit u" call in prelink, but the real >>> trick would be fixing the bug/race in serialisation :) >> >> Hmm, so, normally PID 1 should not accept new requests after the >> deserialization of the first reexec is complete. >> >> Let me sumarize this a bit: >> >> Is this about reexec or reload? Or both? > > I was confused at first, but it seems "both" in the end. See here for a > reproduction case involving either (tho' reload requires a --no-block > param to trigger): > > https://bugzilla.redhat.com/show_bug.cgi?id=1043212#c20 > >> This is supposed to trigger the issue? "systemctl daemon-reexec ; >> systemctl daemon-reexec"? What precisely goes bad afterwards? Does this >> always trigger the issue or only sometimes? > > On my system it's pretty reliable and will trigger it every time. It > might need a setup where loading the serialised state triggers a few > jobs to make it take longer. e.g. on my setup the Type=oneshot units > were all rerun when reloading the state (which actually seems wrong to > me - e.g. my alsa-restore.service job kicked in again which made an > in-progress VoIP call weird by suddenly changing my Headphones port back > to Speakers!! - I've since started using the alsa-state daemon instead > which mitigates things, but re-running oneshot's seems wrong no?) > >> What version are you using? Can you reproduce the issue on git? > > It's almost identical to the fedora 20 version - 208 + lots of patches. > > Not tried latest git yet I'm afraid, but as it also apparently affects > fedora 20 (see above bug) I'm guessing you'll need something backported > anyway and I'm not sure if there is any specific fix (although the sdbus > port might have fixed it indirectly if it doesn't occur any more) fwiw: I just tested with a (quiet recent) git version and I can't reproduce it. note that this is on archlinux, without any sysv compat stuff. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
'Twas brillig, and Lennart Poettering at 20/01/14 12:45 did gyre and gimble: > On Mon, 13.01.14 11:16, Colin Guthrie (gm...@colin.guthr.ie) wrote: > >> Hi, >> >> I've just been debugging a weird problem in my 208 build (which is quite >> similar to Fedora's - a lot of the same patches). >> >> So far I've noticed two problems: >> >> >> 1. If I do "systemctl enable sysvinitscript" it will print me a warning >> about how the units do not carry [Install] sections. This is >> unsurprising as there are no units (the systemctl.c mangled_names - or >> just names in git master) left after the enable_sysv_units() method is >> called and the first item is a pointer to a null string. I suspect >> various bus calls could just be harmlessly skipped if this is the case >> (i.e. just don't do the various unit related method calls) as we know >> they are handled locally. >> >> I've attached two patches which should solve this (one for 208+patches >> and one for git master aka 209) although I've not tested either >> directly. Some other eyes on it as to whether it's the correct approach >> or not would be appreciated. The only difference between the two >> versions is a variable name change. > > For this issue I applied a different patch to git now. Can you check > pls? > > (The patch simply skips all of the native enabling if the list is empty, > including the reload, under the assumption that chkconfig will care for > that on its own...) Yeah that fix seems to be fine generally. Technically, until I/we can get to the bottom of the underlying race problem, this approach doesn't help all cases - e.g. if someone does a "systemctl enable sysvinitservice nativeservice", then we will still get two reloads in quick succession (or interleaved or whatever) and go boom. So this is still a corner case just now, but it should be considered separately to this fix so I'd give it my ACK on that principle. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Mon, 20.01.14 13:42, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > But while systemd is starting your system the syslog might not be > > ready. Probably systemd has some buffer, where it buffers the output. > > Once syslog becomes available, it will be fed with the buffer's > > contents first. If the output is small enought, as with LogLevel=info, > > this actually works. But when you generate gobs of output, the buffer > > will overflow and the output routine will wait until the buffer get's > > emptied, which it never will ... > > > > So, you might try to use DefaultStandardOutput=syslog-or-kmsg or > > DefaultStandardOutput=journal instead. The latter will eventually also > > send the output to syslog, which is why it's a default. > > I guess you are saying that because all output must go to syslog and syslog > is > not running that systemd will hang. But why does the configuration work if > LogLevel=info in that case? systemd will never hang on this. syslog-or-kmsg means that syslog is used when it is up, and kmsg otherwise. We will not block on anything, it's just a really simple condition check each time we write a msg. 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 1/2] build-sys: merge libsystemd-login into libsystemd
On Mon, Jan 20, 2014 at 01:14:02PM +0100, Lennart Poettering wrote: > On Sun, 19.01.14 14:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > So, I prepared a test patch. This all doesn't seem to be too ugly generally, > > although the warning generation in patch 2 is a bit. > > > > Comments? > > > > A compatibility libsystemd-login library is created which uses > > .symver and ifunc magic proposed by Lennart to make programs linked > > to the old library name continue to work seamlessly. > > > > Unfortunately the bfd linker crashes: > > https://sourceware.org/bugzilla/show_bug.cgi?id=16467 > > As a work-around, gold can be used: > > LDFLAGS=-Wl,-fuse-ld=gold > > > > This also doesn't work with LLVM: > > http://llvm.org/bugs/show_bug.cgi?id=11897 > > Looks good to me. That bfd chokes on this is a bummer though... But as > long as the bfd fix is backportable it sounds totally OK to me to still > do this. The bfs fix is backportable, and was proposed for the stable branch too. Anyway, I don't see why using gold would be bad. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] TTY ownership and systemd user session
On Fri, 10.01.14 14:11, Yin Kangkai (kangkai@linux.intel.com) wrote: > > On 2014-01-10, 06:27 +0100, Lennart Poettering wrote: > > On Thu, 09.01.14 09:56, Yin Kangkai (kangkai@linux.intel.com) wrote: > > > > > Hi, > > > > > > I am bringing up systemd user session in Tizen, I am using v208. > > > > > > We run into a small issue that if a user session service file claims > > > TTY, systemd user session will fail to chown_terminal() for it: > > > > > > "Failed at step STDIN spawning /usr/bin/xorg-launch-helper: Permission > > > denied" > > > > > > My testing service file has something like this: > > > > > > [Service] > > > StandardInput=tty > > > TTYPath=/dev/tty1 > > > ExecStart=/usr/bin/xxx > > > > > > > > > I tried to look into the code... The failure seems happen after > > > "systemd --user" forked and about the exec into the new process, in > > > execute.c:exec_spawn(), when calling chown_terminal(). > > > > > > So my question is: > > > > > > * does systemd depend on other (e.g. udev) to set the /dev/tty1 > > >permission beforehand? Or > > > > > > * should we do the chown_terminal() stuff in PAM/pam_systemd after we > > >got the PAM_TTY? since otherwise it's too late to do it in > > >exec_spawn(), it's already running as normal "user", you can't > > >chown /dev/tty1 etc. > > > > > > Please help me to understand this, and anything I am missing. Thanks. > > > > The chown_terminal() call is invoked at point in time where privileges > > have not been dropped yet for the process that is being forked off. This > > means that there isn't actually relly any excuse for ths to fail with > > EPERM, since we are still root. > > No? It is already in user session, systemd is not root here any more > right? Do I miss anything? Oh sorry, I missed that this was about the user session. When systemd runs with "--user" it is an unprivileged process like any other. This means that access to /dev/tty1 is granted by the OS based on the file access mode and ACL of the /dev/tty1 device node. If you want to run a user service likes this you hence need to somehow make sure the device node is chowned properly or got the right ACLs assigned... 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 1/2] build-sys: merge libsystemd-login into libsystemd
On Mon, 20.01.14 17:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > On Mon, Jan 20, 2014 at 01:14:02PM +0100, Lennart Poettering wrote: > > On Sun, 19.01.14 14:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > So, I prepared a test patch. This all doesn't seem to be too ugly > > > generally, > > > although the warning generation in patch 2 is a bit. > > > > > > Comments? > > > > > > A compatibility libsystemd-login library is created which uses > > > .symver and ifunc magic proposed by Lennart to make programs linked > > > to the old library name continue to work seamlessly. > > > > > > Unfortunately the bfd linker crashes: > > > https://sourceware.org/bugzilla/show_bug.cgi?id=16467 > > > As a work-around, gold can be used: > > > LDFLAGS=-Wl,-fuse-ld=gold > > > > > > This also doesn't work with LLVM: > > > http://llvm.org/bugs/show_bug.cgi?id=11897 > > > > Looks good to me. That bfd chokes on this is a bummer though... But as > > long as the bfd fix is backportable it sounds totally OK to me to still > > do this. > The bfs fix is backportable, and was proposed for the stable branch too. > > Anyway, I don't see why using gold would be bad. Good question. I have no experience with gold, but it's commonly available these days, right? maybe we should just default to gold anyway after detection in configur.ac? 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] Starting in a network name?
On Mon, 06.01.14 11:04, Holger Schurig (holgerschu...@gmail.com) wrote: > Hi, I used "ip netns" commands to setup several network namespaces. > Now I want to run a user-space (non-root) in one of those netspaces. > "ip netns exec NAME COMMAND" seems to only work for root, not normal > users. > > Is there a way to configure a systemd unit to run in a *specific* > network namespace? I mean similar to, but more general than, > PrivateNetwork=true and JoinsNamespaceOf= ... No, this is currently not available. But certainly doable. I added it to the TODO list 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] [PATCH 1/2] build-sys: merge libsystemd-login into libsystemd
On 20/01/14 17:08, Lennart Poettering wrote:
> On Mon, 20.01.14 17:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>> Anyway, I don't see why using gold would be bad.
>
> Good question. I have no experience with gold, but it's commonly
> available these days, right?
"Sort of; hardware-dependent". It's better than it used to be (initially
x86-only); among the Debian architectures, it exists on the x86, ARM,
PowerPC and Sparc families, but not mips*, s390x, ia64 or various
unofficial ports. I don't know which one new architecture families tend
to bootstrap with.
> maybe we should just default to gold anyway
> after detection in configur.ac?
Choosing a default linker seems like a system-integration issue rather
than something individual upstreams should be doing. For a while, D-Bus
forced particular "hardening" compiler options if they existed (-fPIC,
etc.), but they were often broken on particular
architectures/toolchains, and we eventually came to the conclusion that
it's far easier for a distribution to do that sort of thing correctly
than it is for an upstream to do it.
If it was my library, I'd be inclined to provide a .pc file for the old
name, that directs API users to link to the library under the new name
(source/API compatibility, but not binary/ABI compatibility); then it's
just like any other SONAME transition, in which you have to keep the old
binary package around until everything depending on it has been rebuilt.
Distributions have to be pretty good at "recompile everything that
depends on libfoo" anyway ("binary non-maintainer uploads" or "binNMUs"
in Debian jargon). If it's a simple recompile, it's easy to automate,
but if source-code changes are needed (even just configure.ac), then
someone needs to edit the source packages and it becomes considerably
more work.
S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
