Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, Apr 21, 2015 at 12:40 AM, Lennart Poettering wrote: > On Wed, 15.04.15 01:08, Andrew Cooks (aco...@linux.com) wrote: > > > On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt wrote: > > > > > > > > On Monday 2015-01-12 18:29, Tom Gundersen wrote: > > > >> In systemd-218, I have configured the following testcase: > > > >> > > > >> /etc/systemd/network# ls -al > > > >> total 20 > > > >> drwxr-xr-x 2 root root 4096 Jan 11 18:14 . > > > >> drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. > > > >> -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link > > > > > > > >Hm, isn't this just a problem of 99a-ether.link being ordered after > > > >99-default.link? > > > > > > Well, the manpage states: "All link files are collectively > > > sorted and processed in lexical order", with that, I would assume > > > that 99a, being processed after 99, would override 99. > > > > > > >It works for me when naming it 98-ether.link instead. > > > > > > Not in my case. I have a feeling networkd won't touch > > > [08:00:27:0a:c5:b2]'s interface name because it has already > > > been named by udev to enp0s3 before networkd got a chance to run. > > > Could that be it? > > Note that networkd doesn't rename interfaces, only udev does. > > udev implements .link processing, nothing else. > > > I'm having a similar problem while running systemd version-219. Did you > > work out what was wrong? > > Maybe this is debian and the saving of interface names is still in > place? > Nope, sorry, this is based on yocto. The good news is that all legacy stuff can be safely ignored. > > > # cat /etc/systemd/network/01-mgmt.link > > [Match] > > Path=pci-:01:00.0 > > Type=ether > > > > [Link] > > Name=mgmt > > MACAddressPolicy=persistent > > Consider testing the .link file with "udevadm test-builtin > net_setup_link..." Thanks, this is exactly what I needed to find the problem. There were two issues with my .link file: I needed to call my local override 100-mgmt.link instead of 01-mgmt.link. IMHO, the ordering of the .link files is somewhat unfortunate, even though the documentation did try to explain it. Secondly, the Path in the [Match] section was wrong. The examples use pci-:xx:yy.0-* and 'udevadm info /sys/class/net/enp1s0' shows 'ID_PATH=pci-:01:00.0' (exactly what I used, as the man page instructs), but it only started working when I tried 'Path=*:01:00.0*'. # udevadm test-builtin net_setup_link /sys/class/net/enp1s0 calling: test-builtin === trie on-disk === tool version: 219 file size: 6685604 bytes header size 80 bytes strings1715076 bytes nodes 4970448 bytes Load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /etc/systemd/network/enp3s0.link Parsed configuration file /etc/systemd/network/enp2s0.link Parsed configuration file /lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/100-mgmt.link Created link configuration context. device 0xb77f6040 has devpath '/devices/pci:00/:00:04.0/:01:00.0/ne' ID_NET_DRIVER=r8169 device 0xb77f6040 filled with db file data device 0xb77f6940 has devpath '/devices/pci:00/:00:04.0/:01:00.0' Config file /lib/systemd/network/99-default.link applies to device enp1s0 ID_NET_LINK_FILE=/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context. # cat 100-mgmt.link [Match] Path=*:01:00.0* [Link] Name=ManagementPort MACAddressPolicy=persistent Thanks for the help, Lennart! a. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting up network interfaces for containers with --private-network
Lennart Poettering writes: > On Mon, 20.04.15 15:25, Spencer Baugh (sba...@catern.com) wrote: > So far I'd recommend running networkd on the host and in the > container. If you run it on the host, then it will automatically > configure the hos side of each of nspawn's veth links with a new IP > range, and be a DHCP server on it, as well as do IP > masquerading. Connectivity will hence "just work", if you use networkd > in most cases. This is in the case where I use --network-bridge, right? Because otherwise there is no veth to be automatically configured. Yes, in that case, it is of course very simple, but it is not at all configurable. I have one thing and one thing only that I want to configure: The IP address that a given container receives. This seems like a reasonable thing to want to configure; ultimately there have to be fixed IP addresses somewhere, and I have a use for containers that would benefit from having fixed IP addresses. The way I currently fix the IP address that the container receives is by fixing the MAC address of the veth; since I am using IPv6 and radvd, the IP address is deterministically generated from the MAC address. So it would be helpful if there was a way to do fix the MAC address in nspawn. Would you accept a patch to add an option to nspawn to specify a MAC address for the veth? Or is there a better way to go about this? > Of course, if you want to manually set up things, without networkd or > an equivalent service, then a lot of things will be more manual: one > way could be to add some script to ExecStartPre= of the service to set > things up for you each time you start the container. > > Another option could be to use write a service that sets up the > interface, uses PrivateNetwork= and then use JoinsNamespaceOf= on the > container service towards that service, and turn off nspawn's own > private networking switch. That way PID1 would already set up the > joint namespace for your container, and ensure it is set up properly > by your setup service. And as long as either the setup service or the > container is running the network namespace will stay referenced. Hmm, that is an interesting approach... it would be nice to be able to have networkd be setting up the interface here, though. I am interested in using networkd to do these things, but at the moment it doesn't seem to have the required level of power. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] hwdb: add Chromebook pixel (2015) resolution fix
On Mon, Apr 20, 2015 at 06:01:53PM -0400, Benjamin Tissoires wrote: > The atmel driver sets a default resolution of 20 for each touchpads it > creates. On this model, 10 is more appropriate. > > The resolution is not set for the touchscreen by the kernel, so match > the name to both touchpad and touchscreen. > --- > hwdb/60-evdev.hwdb | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/hwdb/60-evdev.hwdb b/hwdb/60-evdev.hwdb > index efa6977..df1986c 100644 > --- a/hwdb/60-evdev.hwdb > +++ b/hwdb/60-evdev.hwdb > @@ -36,6 +36,13 @@ > # If a field is missing the field will be left as-is. Not all fields need to > # be present. e.g. ::45 sets the resolution to 45 units/mm. > > +# Chromebook Pixel (2015) - Samus > +evdev:name:Atmel maXTouch Touch*:dmi:bvn*:bvr*:bd*:svnGOOGLE:pnSamus* > + EVDEV_ABS_00=::10 > + EVDEV_ABS_01=::10 > + EVDEV_ABS_35=::10 > + EVDEV_ABS_36=::10 > + > # Lenovo X230 series > evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pn*ThinkPad*X230* > EVDEV_ABS_01=::100 > -- > 2.3.5 I reshuffled a few things to sort by vendor and add the matching comments, but the content stayed the same. both pushed, thanks. 1f84512..696f1db master -> master Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 0/4] udev: Add builtin and hwdb files for setting pointingstick properties
On Mon, Apr 20, 2015 at 10:24:35AM +0200, David Herrmann wrote:
> Hi
>
> On Fri, Apr 17, 2015 at 4:48 PM, Hans de Goede wrote:
> > Hi All,
> >
> > Here is v4 of my pointstick set.
> >
> > Changes since v3:
> > -Use the existing evdev matching rules
> > -Make setting the sensitivity part of the evdev builtin (which is called
> > keyboard for historical reasons)
> >
> > Changes since v2:
> > -Fix numerous spelling / gramatical errors in commit messages
> > -Add a reference to the kernel sources for the ibm trackpoint sensitivity
> > setting
> >
> > Changes since v1:
> > -Drop the patch to set ID_INPUT_TRACKPOINT, Peter already send almost the
> > same patch to set ID_INPUT_POINTINGSTICK
> > -s/trackpoint/pointingstick/ unlike trackpoint pointingstick is a vendor
> > neutral name, and pointingstick is also what the prop bit is called in
> > linux/input.h Note that a few occurences where not replaced, as those refer
> > specifically to IBM/Lenovo trackpoints
> > -Use ATTR{foo}= to assign sysfs attr value rather then spawning /bin/sh
> > -Dropped S-o-b from the commit messages
>
> Looks all good, apart from my comments on patch #2. Please push!
fixed as requested and pushed (with two typos fixed too), thanks.
15d7b51..1f84512 master -> master
Cheers,
Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] umount: reduce verbosity
On Mon, 13.04.15 13:13, Alban Crequy (alban.cre...@gmail.com) wrote: > From: Alban Crequy > > When a systemd-nspawn container terminates, systemd umounts all bind > mounts that were mounted in the container and generates a log for each > umount. > > This additional log_info was added by > bce93b7ac7642426039863493694d8c12812e2a7 for debugging shutdown. But > surely log_debug is enough. > > I don't want to see them when when systemd is started with --log-target=null. > There are other log_info that I would like to mute on --log-target=null. > Is changing log_info to log_debug the correct approach? Hmm, I kinda like these messages I must say, because they actually help users if the shutdown hangs. Hmm, if you specify --log-target=null then then the messages should go nowhere anyway. We actually pass the log target setting from systemd to the shutdown binary via a command line. Are you suggesting that this doesn't work correctly? That#s something to debug first, I figure? > This patch is useful for: > https://github.com/coreos/rkt/issues/690 > > When rkt is started with --debug, the systemd logs are printed. When rkt > is started without --debug, systemd is started with --log-target=null in > order to mute the logs. That generally sounds a bit extreme... 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] importd: add CAP_DAC_OVERRIDE capability
On Mon, 13.04.15 19:46, Lubomir Rintel (lkund...@v3.sk) wrote: > Fedora's filesystem package ships /usr/bin (and other directories) which are > not writable by its owner. machinectl pull-dkr (and possibly others) are not > able to extract those: Thanks! Applied! > > 14182 mkdirat(3, "usr", 0700) = 0 > 14182 mkdirat(3, "usr/bin", 0500) = 0 > 14182 openat(3, "usr/bin/[", > O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0700) = -1 EACCES > (Permission denied) > ... > --- > units/systemd-importd.service.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/units/systemd-importd.service.in > b/units/systemd-importd.service.in > index a540040..80d97c8 100644 > --- a/units/systemd-importd.service.in > +++ b/units/systemd-importd.service.in > @@ -12,6 +12,6 @@ Documentation=man:systemd-importd.service(8) > [Service] > ExecStart=@rootlibexecdir@/systemd-importd > BusName=org.freedesktop.import1 > -CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER CAP_FSETID CAP_MKNOD CAP_SETFCAP > CAP_SYS_ADMIN CAP_SETPCAP > +CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER CAP_FSETID CAP_MKNOD CAP_SETFCAP > CAP_SYS_ADMIN CAP_SETPCAP CAP_DAC_OVERRIDE > NoNewPrivileges=yes > WatchdogSec=1min > -- > 2.1.0 > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel 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] SD_BUS_VTABLE_CAPABILITY
On Thu, 16.04.15 19:30, Lennart Poettering (lenn...@poettering.net) wrote: > I will grant you though that it is confusing that we use > SD_BUS_CREDS_AUGMENT here like this, and implicitly rely on that the > selinux label is not a field that is being augmented. We should make > this explicit, absolutely. I'll now add some code that will make this > assumption explicit and fails early if the selinux label happens to be > augmented. Of course in real-life this is impossible to trigger, but > it's certainly helps understanding the code. I now added some code for this now, that explicitly verifies that we don't base authorization decisions on augmented creds. As mentioned, this is only a safety net, as this cannot really happen anyway, but let's better be safer than sorry, and let's document our assumption this way explicitly in the code.. 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] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, 21.04.15 09:21, Kyungmin Park (kmp...@infradead.org) wrote: > > Well, we should make sure to not encourage people to write > > suboptimal. And such an external timer-based notification is > > necessarily suboptimal code: a well-behaving daemon would set a timer > > the moment it notices it is idle, and then exit when that timer > > elapses, and cancel the timer if it in between notices it's not idle > > anymore. However, if we externally ping the daemon in external > > intervals, then this is necessarily much earlier or later than > > necessary... > > > > Also, is there really much gained by this? I mean, if you want such a > > notifier framework from systemd towards the daemon, then the daemon > > needs to listen somehow on a socket/fifo/ipc object, accessible via an > > fd. But if it does so it might as well listen on a timerfd directly, > > which is also just an fd, and does not require anything like systemd > > triggering it. > > > > Hence I am not sure what we'd gain by a concept like that? > > > > Note that it's different story from original mail concept. I just > explain my requirement. > > At mobile. some daemon is not doing exact daemon task. it acts like > app. so it's kill-able based on priority. now it can't know it's idle > or not. In the app-like daemon developer, they don't want to exit > since performance reason. but in the view of system admin, it's > resource waste. it's better to kill if it know it's idle. Of course > there are assumption it's activated by other way. so it's no problem > to kill it at idle time. > > if app-like daemon doesn't give any hints, it doesn't know it and > can't handle it. but systemd know it and send idle information. it > would be helpful. > IOW, it's required to know some daemon is idle or not. and systemd is > proper place to know it. Well, but systemd does not actually know it, and can't know it. I mean, consider a word processor app. A good word processor app should make recovery copies of edited documents every now and then as long as the the document is not properly saved. Now, let's say the timer for this is set by the word processor to 30s after the last edit. Now, you configure systemd to kill it 20s after the last time it consumed any CPU. With an automatic killing logic in systemd you'd completely break the recovery logic, because it would kill before the app's own timer. It's really only the app that knows when it is really idle. I mean I can see that for app schemes different policies might apply than to system daemons, but I doubt it's as simple as "didn't consume any CPU in the last 30s"... Instead it could be something like "we are under memory pressure and app is not in the fg and didn't take a kill inhibitor lock" or something like that (which is very close to what android actually does), however, something like that is considerably more complex than what you propose, and i am not sure whether systemd is really the right place to implement a logic like that... 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] Zombie process still exists after stopping gdm.service
On Mon, 20.04.15 18:13, Daniel Drake (dr...@endlessm.com) wrote: > >> 3. gdm simple-slave's signal handler triggers, which causes the > >> mainloop to exit, and it starts to kill and wait for the X server > >> death. I'm not exactly sure why, but quitting the glib mainloop also > >> causes the signal handler to be destroyed, so sigaction() is called > >> here to return SIGTERM to its default behaviour. > >> > >> 4. Moments later we arrive in systemd's service_sigchld_event(), > >> presumably because the main gdm process exited due to SIGTERM. > >> s->main_pid == pid. > > > > If PID 1 gets the SIGCHLD for the main process then it assumes the > > service has finished correctly, and will kill the rest that might remain. > > Even if we already killed the rest just a few milliseconds ago (in > #2)? Sure, we don't want to keep track of which processes we already killed, to distuingish them from the processes newly created in the time between our sending of SIGTERM and receiving SIGCHLD for the main process. We assume that if we get SIGCHLD for the main process that the daemon is down, and everything that is left over then is auxiliary stuff we can kill. 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] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, Apr 21, 2015 at 8:37 AM, Lennart Poettering wrote: > On Tue, 21.04.15 07:56, Kyungmin Park (kmp...@infradead.org) wrote: > >> On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering >> wrote: >> > On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote: >> > >> >> If a service does not consume CPU during some time(can be configured >> >> by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the >> >> service will be stopped. This can be useful if the service provides >> >> some of activation methods. >> > >> > Hmm, I am not convinced this would be a good idea, sorry. >> > >> > The crux of the issue is that it is really hard to detect from the >> > outside if a daemon is really idle. Only the daemon itself knows >> > whether it is truly idle or not. I mean, it could just be waiting for >> > some timer to elapse, or some other external event. >> > >> > I doubt this is really useful unless you have really really simple >> > daemons that purely react on client requests and nothing else, and you >> > know the codebase and that it is OK to terminate the daemon just >> > because its CPU usage is zero. But if you know the codebase that well >> > it would probably be a better idea to just add support for >> > exit-on-idle directly to the daemon in question. >> > >> > exit-on-idle is really something that should be implemented *in* the >> > daemon, and not done externally! >> >> then how about to change the concept? IdleNotifier? >> some daemon users said it's hard to know how long its idle so systemd >> give idle time by notification. >> It will save lots of codes. don't need to implement own timer for idle >> timeout. >> >> it's match your comments. "It should be implemented *in* the daemon". >> when idle notification is comes. daemon decides exit or not. Of course >> daemon will implement defined idle notifier callback. >> >> does it reasonable? > > Well, we should make sure to not encourage people to write > suboptimal. And such an external timer-based notification is > necessarily suboptimal code: a well-behaving daemon would set a timer > the moment it notices it is idle, and then exit when that timer > elapses, and cancel the timer if it in between notices it's not idle > anymore. However, if we externally ping the daemon in external > intervals, then this is necessarily much earlier or later than > necessary... > > Also, is there really much gained by this? I mean, if you want such a > notifier framework from systemd towards the daemon, then the daemon > needs to listen somehow on a socket/fifo/ipc object, accessible via an > fd. But if it does so it might as well listen on a timerfd directly, > which is also just an fd, and does not require anything like systemd > triggering it. > > Hence I am not sure what we'd gain by a concept like that? > Note that it's different story from original mail concept. I just explain my requirement. At mobile. some daemon is not doing exact daemon task. it acts like app. so it's kill-able based on priority. now it can't know it's idle or not. In the app-like daemon developer, they don't want to exit since performance reason. but in the view of system admin, it's resource waste. it's better to kill if it know it's idle. Of course there are assumption it's activated by other way. so it's no problem to kill it at idle time. if app-like daemon doesn't give any hints, it doesn't know it and can't handle it. but systemd know it and send idle information. it would be helpful. IOW, it's required to know some daemon is idle or not. and systemd is proper place to know it. Thank you, Kyungmin Park ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
On Mon, Apr 20, 2015 at 6:04 PM, Lennart Poettering wrote: >> I have stepped through and I think that systemd is being too >> aggressive. Still running with the default KillMode=cgroup, here is >> what happens: >> >> 1. service_enter_stop() is entered which calls: >> service_enter_signal(s, SERVICE_STOP_SIGTERM, >> SERVICE_SUCCESS); >> >> 2. service_enter_signal sends SIGTERM to all gdm processes. > > No, if you use KillMode=mixed (as you say you do) it will only send > SIGTERM to the main process of gdm. Only bleeding edge gdm has KillMode=mixed. I'm using a slightly older version which has the default KillMode=cgroup. Sorry for the confusion. >> 3. gdm simple-slave's signal handler triggers, which causes the >> mainloop to exit, and it starts to kill and wait for the X server >> death. I'm not exactly sure why, but quitting the glib mainloop also >> causes the signal handler to be destroyed, so sigaction() is called >> here to return SIGTERM to its default behaviour. >> >> 4. Moments later we arrive in systemd's service_sigchld_event(), >> presumably because the main gdm process exited due to SIGTERM. >> s->main_pid == pid. > > If PID 1 gets the SIGCHLD for the main process then it assumes the > service has finished correctly, and will kill the rest that might remain. Even if we already killed the rest just a few milliseconds ago (in #2)? >> 7. To make things even worse, after sending the SIGTERMs, >> service_enter_signal hits: >> } else if (state == SERVICE_FINAL_SIGTERM) >> service_enter_signal(s, SERVICE_FINAL_SIGKILL, >> SERVICE_SUCCESS); > > Hmm? if we managed to kill something we'll arm the timeout and wait > for sigchld or cgroup empty or similar. > > These shortcuts only take place if we couldn't kill anything because > there was nothing. And hence the second killing will have no effect > either, but at least we go through the state engine... I added logging to sys_kill at the kernel level, and I definitely observe "systemctl stop gdm" causing PID 1 to kill gdm-simple-slave 3 times (TERM, TERM, KILL) within the space of a few milliseconds. I will look closer tomorrow to explain in more detail what is going on at the code level. Thanks for your help! Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
On Mon, 20.04.15 13:16, Daniel Drake (dr...@endlessm.com) wrote: > On Mon, Apr 20, 2015 at 9:04 AM, Lennart Poettering > wrote: > > maybe the main gdm process is not the one waiting, but a worker > > process is, and the main process kills the worker process without the > > worker process handling that nicely? > > Not really. I removed all the process-killing code from gdm and the > problem is still there. > > I have stepped through and I think that systemd is being too > aggressive. Still running with the default KillMode=cgroup, here is > what happens: > > 1. service_enter_stop() is entered which calls: > service_enter_signal(s, SERVICE_STOP_SIGTERM, > SERVICE_SUCCESS); > > 2. service_enter_signal sends SIGTERM to all gdm processes. No, if you use KillMode=mixed (as you say you do) it will only send SIGTERM to the main process of gdm. > 3. gdm simple-slave's signal handler triggers, which causes the > mainloop to exit, and it starts to kill and wait for the X server > death. I'm not exactly sure why, but quitting the glib mainloop also > causes the signal handler to be destroyed, so sigaction() is called > here to return SIGTERM to its default behaviour. > > 4. Moments later we arrive in systemd's service_sigchld_event(), > presumably because the main gdm process exited due to SIGTERM. > s->main_pid == pid. If PID 1 gets the SIGCHLD for the main process then it assumes the service has finished correctly, and will kill the rest that might remain. > 7. To make things even worse, after sending the SIGTERMs, > service_enter_signal hits: > } else if (state == SERVICE_FINAL_SIGTERM) > service_enter_signal(s, SERVICE_FINAL_SIGKILL, > SERVICE_SUCCESS); Hmm? if we managed to kill something we'll arm the timeout and wait for sigchld or cgroup empty or similar. These shortcuts only take place if we couldn't kill anything because there was nothing. And hence the second killing will have no effect either, but at least we go through the state engine... 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] networkd-218 seems to ignore .link files
On Mon, 20.04.15 13:17, Ian Pilcher (arequip...@gmail.com) wrote: > On 04/20/2015 01:06 PM, Lennart Poettering wrote: > >On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote: > >>I would love to be able to set the MTU of a physical interface in a > >>.network file. Is this possible? (The systemd.network(5) doesn't list > >>it.) > > > >Yes, this is supported via MTU=. This needs documentation indeed. > > Hmm. I've just tried both MTU and MTUBytes with no effect. E.g.: > > [Match] > Name=eno1 > > [Network] > Address=172.31.250.1/24 > Gateway=172.31.250.254 > DNS=172.31.250.254 > MTUBytes=5000 > > (Unless this requires something later than systemd 216 on Fedora 21.) It needs to be in a [Link] section in the .network file. The option is indeed called MTUBytes= though. Oh, and as I see now all this is actually correctly documented in systemd.network(5)... 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] Setting up network interfaces for containers with --private-network
On Mon, 20.04.15 15:25, Spencer Baugh (sba...@catern.com) wrote: > Hi, > > Currently, I can manually set up (or set up with a script) a veth, then > move it in to a systemd-nspawn container with > --network-interface. However, if the container tries to restart (or > exits and needs to be restarted), the network namespace of the container > is destroyed and therefore so is the veth that that namespace > contains. Thus, if the interface isn't recreated by some external force > in the time between stopping and restarting, the next invocation of > systemd-nspawn --network-interface=someif will fail. > > To state the problem again more concretely, if I create a veth, assign > one end of the veth to a container started with systemd-nspawn > --network-interface=veth0, then run "reboot" inside the container, the > container will shut down and fail to come back up, as veth0 is > destroyed. > > Perhaps, I could hack up some shell script to wrap system-nspawn and > make sure that whenever I run it, an appropriate network interface is > created before actually running systemd-nspawn > --network-interface=someif, but I don't think that's really the best > approach. > > I could use --network-bridge on a bridge and get the veth made > automatically, as long as all I wanted to do was add the other end of > the veth to a bridge, and it would be remade whenever the container > restarted. But I think this might be the wrong place for this magic to > live; it's not very configurable and seems rather strange to have > systemd-nspawn doing ad-hoc networking tasks like this. > > I'm curious about how this should be done; it seems very important for > serious use of containers. Perhaps networkd could be used to do > something here? What is the best practice? So far I'd recommend running networkd on the host and in the container. If you run it on the host, then it will automatically configure the hos side of each of nspawn's veth links with a new IP range, and be a DHCP server on it, as well as do IP masquerading. Connectivity will hence "just work", if you use networkd in most cases. Of course, if you want to manually set up things, without networkd or an equivalent service, then a lot of things will be more manual: one way could be to add some script to ExecStartPre= of the service to set things up for you each time you start the container. Another option could be to use write a service that sets up the interface, uses PrivateNetwork= and then use JoinsNamespaceOf= on the container service towards that service, and turn off nspawn's own private networking switch. That way PID1 would already set up the joint namespace for your container, and ensure it is set up properly by your setup service. And as long as either the setup service or the container is running the network namespace will stay referenced. 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] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, 21.04.15 07:56, Kyungmin Park (kmp...@infradead.org) wrote: > On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering > wrote: > > On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote: > > > >> If a service does not consume CPU during some time(can be configured > >> by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the > >> service will be stopped. This can be useful if the service provides > >> some of activation methods. > > > > Hmm, I am not convinced this would be a good idea, sorry. > > > > The crux of the issue is that it is really hard to detect from the > > outside if a daemon is really idle. Only the daemon itself knows > > whether it is truly idle or not. I mean, it could just be waiting for > > some timer to elapse, or some other external event. > > > > I doubt this is really useful unless you have really really simple > > daemons that purely react on client requests and nothing else, and you > > know the codebase and that it is OK to terminate the daemon just > > because its CPU usage is zero. But if you know the codebase that well > > it would probably be a better idea to just add support for > > exit-on-idle directly to the daemon in question. > > > > exit-on-idle is really something that should be implemented *in* the > > daemon, and not done externally! > > then how about to change the concept? IdleNotifier? > some daemon users said it's hard to know how long its idle so systemd > give idle time by notification. > It will save lots of codes. don't need to implement own timer for idle > timeout. > > it's match your comments. "It should be implemented *in* the daemon". > when idle notification is comes. daemon decides exit or not. Of course > daemon will implement defined idle notifier callback. > > does it reasonable? Well, we should make sure to not encourage people to write suboptimal. And such an external timer-based notification is necessarily suboptimal code: a well-behaving daemon would set a timer the moment it notices it is idle, and then exit when that timer elapses, and cancel the timer if it in between notices it's not idle anymore. However, if we externally ping the daemon in external intervals, then this is necessarily much earlier or later than necessary... Also, is there really much gained by this? I mean, if you want such a notifier framework from systemd towards the daemon, then the daemon needs to listen somehow on a socket/fifo/ipc object, accessible via an fd. But if it does so it might as well listen on a timerfd directly, which is also just an fd, and does not require anything like systemd triggering it. Hence I am not sure what we'd gain by a concept like that? 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-commits] man/systemd.netdev.xml src/libsystemd src/network
On Mon, 20.04.15 15:27, Tom Gundersen (tome...@kemper.freedesktop.org) wrote: > > + > +LearnPacketIntvSec,= > + > + Specifies the number of seconds between instances where the > bonding > + driver sends learning packets to each slaves peer switch. > + The valid range is 1 - 0x7fff; the default value is 1. This > Option > + has effect only in balance-tlb and balance-alb modes. > + > + We usually don't abbreviate options unnecessarily. Please use "Interval" instead of "Intv". > + > +FailOverMac= > + > + Specifies whether active-backup mode should set all slaves to > + the same MAC address at enslavement or, when enabled, perform > special handling of the > + bond's MAC address in accordance with the selected policy. The > default policy is none. > + Possible values are > + none, > + active, > + follow > + > + > + The option MACAddress= is currently spelt with an uppercase MAC. In fact most options containing acronyms use uppercase naming. hence FailOverMAC=. That said, shouldn't this be FailOverMACMode= or FailOverMACPolicy= or so? > + > + > +ArpValidate= > + > + Specifies whether or not ARP probes and replies should be > + validated in any mode that supports arp monitoring, or whether > + non-ARP traffic should be filtered (disregarded) for link > + monitoring purposes. Possible values are > + none, > + active, > + backup, > + all > + > + > + Uppercase "ARP" please, see above. ARPValidate= > + > +ArpIntervalSec= > + > + Specifies the ARP link monitoring frequency in milliseconds. > + A value of 0 disables ARP monitoring. The default value is 0. > + > + > + Good that Interval is spelt out this time. But s/Arp/ARP/ please. > + > +ArpIpTargets= > + > + Specifies the IP addresses to use as ARP monitoring peers > when > + ArpIntervalSec is greater than 0. These are the targets of the ARP > request > + sent to determine the health of the link to the targets. > + Specify these values in ipv4 dotted decimal format. At least one IP > + address must be given for ARP monitoring to function. The > + maximum number of targets that can be specified is 16. The > + default value is no IP addresses. > + > + > + s/Arp/ARP/ s/Ip/IP/ Maybe append "Address"? > + > + > +ArpAllTargets= > + > + Specifies the quantity of ArpIpTargets that must be reachable > + in order for the ARP monitor to consider a slave as being up. > + This option affects only active-backup mode for slaves with > + ArpValidate enabled. Possible values are > + any, > + all > + > + > + similar... > + > + > +PrimaryReselect= > + > + Specifies the reselection policy for the primary slave. This > + affects how the primary slave is chosen to become the active slave > + when failure of the active slave or recovery of the primary slave > + occurs. This option is designed to prevent flip-flopping between > + the primary slave and other slaves. Possible values are > + always, > + better, > + failure > + > + > + PrimaryReselectPolicy= or so? > + > + > +ResendIGMP= > + > + Specifies the number of IGMP membership reports to be issued > after > + a failover event. One membership report is issued immediately after > + the failover, subsequent packets are sent in each 200ms interval. > + The valid range is (0 - 255). Defaults to 1. A value of 0 > + prevents the IGMP membership report from being issued in response > + to the failover event. > + > + > + I like the that the "IGMP" name is upper case! > + > +NumGratuitousARP= > + > + Specify the number of peer notifications (gratuitous ARPs and > +unsolicited IPv6 Neighbor Advertisements) to be issued after a > +failover event. As soon as the link is up on the new slave > +a peer notification is sent on the bonding device and each > +VLAN sub-device. This is repeated at each link monitor interval > +(ArpIntervalSec or MIIMonitorSec, whichever is active) if the > number is > +greater than 1. The valid range is (0 - 255). Default value is 1. > +These options affect only the active-backup mode > + > + > + "Num"? Nah, please no unnecessary abbreviations. The last sentence lacks a
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering wrote: > On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote: > >> If a service does not consume CPU during some time(can be configured >> by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the >> service will be stopped. This can be useful if the service provides >> some of activation methods. > > Hmm, I am not convinced this would be a good idea, sorry. > > The crux of the issue is that it is really hard to detect from the > outside if a daemon is really idle. Only the daemon itself knows > whether it is truly idle or not. I mean, it could just be waiting for > some timer to elapse, or some other external event. > > I doubt this is really useful unless you have really really simple > daemons that purely react on client requests and nothing else, and you > know the codebase and that it is OK to terminate the daemon just > because its CPU usage is zero. But if you know the codebase that well > it would probably be a better idea to just add support for > exit-on-idle directly to the daemon in question. > > exit-on-idle is really something that should be implemented *in* the > daemon, and not done externally! then how about to change the concept? IdleNotifier? some daemon users said it's hard to know how long its idle so systemd give idle time by notification. It will save lots of codes. don't need to implement own timer for idle timeout. it's match your comments. "It should be implemented *in* the daemon". when idle notification is comes. daemon decides exit or not. Of course daemon will implement defined idle notifier callback. does it reasonable? Thank you, Kyungmin Park ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] hwdb: add evdev entry for the Lenovo X230 series touchpad
The Lenovo X230 advertize a vertical resolution of 136, which gives a true size of 31 mm. The actual physical size of the touchpad is 40 mm, so override the resolution to 100. --- hwdb/60-evdev.hwdb | 5 + 1 file changed, 5 insertions(+) diff --git a/hwdb/60-evdev.hwdb b/hwdb/60-evdev.hwdb index ae483aa..efa6977 100644 --- a/hwdb/60-evdev.hwdb +++ b/hwdb/60-evdev.hwdb @@ -36,6 +36,11 @@ # If a field is missing the field will be left as-is. Not all fields need to # be present. e.g. ::45 sets the resolution to 45 units/mm. +# Lenovo X230 series +evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pn*ThinkPad*X230* + EVDEV_ABS_01=::100 + EVDEV_ABS_36=::100 + # Macbook5,1 (unibody), aka wellspring3 evdev:input:b0003v05ACp0236* evdev:input:b0003v05ACp0237* -- 2.3.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] hwdb: add Chromebook pixel (2015) resolution fix
The atmel driver sets a default resolution of 20 for each touchpads it creates. On this model, 10 is more appropriate. The resolution is not set for the touchscreen by the kernel, so match the name to both touchpad and touchscreen. --- hwdb/60-evdev.hwdb | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hwdb/60-evdev.hwdb b/hwdb/60-evdev.hwdb index efa6977..df1986c 100644 --- a/hwdb/60-evdev.hwdb +++ b/hwdb/60-evdev.hwdb @@ -36,6 +36,13 @@ # If a field is missing the field will be left as-is. Not all fields need to # be present. e.g. ::45 sets the resolution to 45 units/mm. +# Chromebook Pixel (2015) - Samus +evdev:name:Atmel maXTouch Touch*:dmi:bvn*:bvr*:bd*:svnGOOGLE:pnSamus* + EVDEV_ABS_00=::10 + EVDEV_ABS_01=::10 + EVDEV_ABS_35=::10 + EVDEV_ABS_36=::10 + # Lenovo X230 series evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pn*ThinkPad*X230* EVDEV_ABS_01=::100 -- 2.3.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout
On Mon, Apr 13, 2015 at 3:04 PM, Nir Soffer wrote: > On Sat, Apr 11, 2015 at 6:58 PM, David Herrmann wrote: >>> A program running this tool can detect a timeout (expected) or an error >>> (unexpected), and can change the program flow based on this result. >>> >>> Without this, the only way to detect a timeout is to implement the timeout >>> in the program calling udevadm. >> >> I cannot really see a use-case here. I mean, yeah, the commit-message >> says it warns about timeouts but fails loudly on real errors. But >> again, what's the use-case? Why is a timeout not a real error? Why do >> you need to handle it differently? > > Timeout means that the value I chose may be too small, or the machine > is overloaded. The administrator may need to configure the system > differently. > > Other errors are not expected, and typically unexpected errors in an > underlying tool means getting the developer of the underlying tool > involved. > >> Anyway, if it's only about diagnostics this patch seems fine to me. > > Yes, it is mainly about diagnostics, and making it easier to debug and > support. Wouldn't a better solution be to improve the udevadm logging? If we change the exit codes this is basically ABI. Do we really want to make such promises only for diagnostics? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
On Fri, Apr 3, 2015 at 12:48 AM, Michael Marineau wrote: > On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens wrote: >> hi, sorry for the delay. >> >> from >> http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html: >> >> "By default, it will wait for all links it is aware of and which are >> managed by systemd-networkd.service(8) to be fully configured or >> failed, *and for at least one link to gain a carrier.*". >> >> the import part here is the end of the sentence. without this patch, >> systemd-networkd-wait-online will block until all configured >> interfaces have carrier.. you can reproduce this by running >> systemd-networkd in qemu with two ethernet interfaces, and issue 'info >> network' and then 'set_link down' to simulate no carrier. then >> you can run systemd-networkd-wait-online, and observe that it will >> block until both interfaces are up, not just one. >> >> nick >> >> On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov >> wrote: >>> On Wed, Mar 25, 2015 at 11:49 PM, wrote: From: mischief when checking interface status, systemd-networkd-wait-online will continue to wait if any interface is still configuring or being processed by udev. this patch allows it to return if any one interface is degraded/routable, as per the manual. >>> >>> But current behavior is exactly what manual says: "By default, it will >>> wait for all links it is aware of and which are managed by >>> systemd-networkd.service(8) to be fully configured or failed". Or do I >>> miss something? > > It is worth noting that there may be some issues with tracking > interface states in networkd, there appear to be ways to get an > interface stuck in a 'configuring' state despite the fact that the > interface has no network config and/or has no carrier. Do you have any more info on this? Can you reproduce with current git? There was a fix after the last release which should fix a problem with enumerating devices. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
On Wed, Mar 25, 2015 at 9:49 PM, wrote:
> From: mischief
>
> when checking interface status, systemd-networkd-wait-online
> will continue to wait if any interface is still configuring or
> being processed by udev. this patch allows it to return if any
> one interface is degraded/routable, as per the manual.
Sorry for the delay in getting back to you.
I believe this is currently behaving as intended. The intention is
that all devices managed by networkd must be fully configured (not
simply get a carrier), but if there are no devices managed by networkd
then we wait for at least one device to gain carrier (in this case
something else must be bringing the interface up as networkd is up, so
it makes sure that networkd-wait-online does not get in the way of say
NetworkManager).
Does that make sense?
Cheers,
Tom
> ---
> src/network/networkd-wait-online-manager.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/network/networkd-wait-online-manager.c
> b/src/network/networkd-wait-online-manager.c
> index 1c997a5..1ac162a 100644
> --- a/src/network/networkd-wait-online-manager.c
> +++ b/src/network/networkd-wait-online-manager.c
> @@ -74,13 +74,13 @@ bool manager_all_configured(Manager *m) {
> if (!l->state) {
> log_debug("link %s has not yet been processed by
> udev",
>l->ifname);
> -return false;
> +continue;
> }
>
> if (streq(l->state, "configuring")) {
> log_debug("link %s is being processed by networkd",
>l->ifname);
> -return false;
> +continue;
> }
>
> if (l->operational_state &&
> --
> 2.0.5
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
Daniel Drake endlessm.com> writes: > > So, moments after sending 2 SIGTERMs, SIGKILL is sent to all gdm > processes. There does not seem to be any consideration of giving the > process some time to respond to SIGTERMs, nor the fact that I have > hacked gdm.service to have SendSIGKILL=no as an experiment. > I noticed that too with SendSIGKILL=no. http://lists.freedesktop.org/archives/systemd-devel/2015-March/029933.html http://lists.freedesktop.org/archives/systemd-devel/2015-April/030196.html Squid is not a good example of how a daemon should behave though. -- Marcos ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Mon, Apr 20, 2015 at 8:11 PM, David Herrmann wrote: > Hi > > On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett wrote: >> On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: >>> I'm not convinced that any such broad matches for power management >>> belong into udev at all. Udev can carry specific device matches, or >>> carry data that cannot be determined from the device itself, like the >>> mouse resolution and such, but like in these rules, reading the vendor >>> from the kernel and unconditionally flipping a bit back into the >>> kernel does not look like a task for udev or userspace in general. >> >> Is there any possibility that you can be convinced? > > I'd much prefer if this was hwdb based. This way, we have a sane > database that just sets something like POWER_CONTROL=foobar, which we > can then apply via udev. Given that the power-control issues seem to > be totally random, hwdb really sounds like the nicer solution. > > Any reason why hwdb would not work? The question here is more why systemd/udev should get into the power management business at all. So far, applying unconditional policy sounds like a job for the kernel, not userspace. Either it can be safely ensabled, then it can be done right away by the kernel driver, or it isn't safe, then using udev does not solve any problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Setting up network interfaces for containers with --private-network
Hi, Currently, I can manually set up (or set up with a script) a veth, then move it in to a systemd-nspawn container with --network-interface. However, if the container tries to restart (or exits and needs to be restarted), the network namespace of the container is destroyed and therefore so is the veth that that namespace contains. Thus, if the interface isn't recreated by some external force in the time between stopping and restarting, the next invocation of systemd-nspawn --network-interface=someif will fail. To state the problem again more concretely, if I create a veth, assign one end of the veth to a container started with systemd-nspawn --network-interface=veth0, then run "reboot" inside the container, the container will shut down and fail to come back up, as veth0 is destroyed. Perhaps, I could hack up some shell script to wrap system-nspawn and make sure that whenever I run it, an appropriate network interface is created before actually running systemd-nspawn --network-interface=someif, but I don't think that's really the best approach. I could use --network-bridge on a bridge and get the veth made automatically, as long as all I wanted to do was add the other end of the veth to a bridge, and it would be remade whenever the container restarted. But I think this might be the wrong place for this magic to live; it's not very configurable and seems rather strange to have systemd-nspawn doing ad-hoc networking tasks like this. I'm curious about how this should be done; it seems very important for serious use of containers. Perhaps networkd could be used to do something here? What is the best practice? Thanks, Spencer Baugh ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Don't use ALSA card id in ID_ID
On Mon, Apr 20, 2015 at 2:40 PM, Lennart Poettering wrote: > On Mon, 20.04.15 20:39, Lennart Poettering (lenn...@poettering.net) wrote: > > > On Mon, 20.04.15 20:00, Lennart Poettering (lenn...@poettering.net) > wrote: > > > > > On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote: > > > > > > > The ALSA id sysattr is generated by the sound subsystem and is not > > > > a stable identifier. It is generated though some string manipulation > > > > then made unique if there is a conflict. This means that it is > > > > enumeration-dependent and shouldn't be used for ID_ID. > > > > > > > > If ID_ID is supposed to be system-unique, it is not already since > > > > for firewire it is generated from the guid and there are broken > > > > firewire devices that have duplicate guids across devices. > > > > > > Hmm, this patch pretty much reverts > > > ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e. Now I am not sure if that > > > commit from 6 years ago was a good idea, but we should have some > > > clarity about this. > > > > > > What is ID_ID actually supposed to be? Should it really be system > > > unique? > > > > > > I do have the suspicion this is something that better should be fixed > in > > > PA rather then in these udev rules, so I figure your patch might be a > > > good idea? > > > > > > Opinions? > > > > > > If we apply the patch somebody should at least post a bug report > > > against PA to be aware of this change. > > > > OK, after talking to some folks I think we should merge your > > patch. Any chance you can post a bug to PA though, reference this > > discussion, and then include the bug report in the commit message and > > resend the patch? > > Also, please mention in the commit msg that this is basically a revert > of ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e. > > Thanks, happy to do this. Look for it soon. Adam ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] Add more firewire properties for sound, to be closer to USB and PCI
On Mon, 20.04.15 15:18, Adam Goode (ago...@google.com) wrote:
> On Mon, Apr 20, 2015 at 2:04 PM, Lennart Poettering
> wrote:
>
> > On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote:
> >
> > > USB and PCI soundcards have a nice set of ID_* properties. It would
> > > be handy for firewire soundcards to have the same.
> > > ---
> > > rules/78-sound-card.rules | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
> > > index bd7a994..e529f70 100644
> > > --- a/rules/78-sound-card.rules
> > > +++ b/rules/78-sound-card.rules
> > > @@ -41,9 +41,10 @@ IMPORT{builtin}="hwdb"
> > > SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
> > > SUBSYSTEMS=="usb", GOTO="skip_pci"
> > >
> > > -SUBSYSTEMS=="firewire", ATTRS{vendor_name}=="?*",
> > ATTRS{model_name}=="?*", \
> > > - ENV{ID_BUS}="firewire", ENV{ID_VENDOR}="$attr{vendor_name}",
> > ENV{ID_MODEL}="$attr{model_name}"
> > > -SUBSYSTEMS=="firewire", ATTRS{guid}=="?*",
> > ENV{ID_ID}="firewire-$attr{guid}"
> > > +SUBSYSTEMS=="firewire", ATTRS{guid}=="?*", \
> > > + ENV{ID_BUS}="firewire", ENV{ID_SERIAL}="$attr{guid}",
> > ENV{ID_SERIAL_SHORT}="$attr{guid}", \
> > > + ENV{ID_VENDOR_ID}="$attr{vendor}", ENV{ID_MODEL_ID}="$attr{model}", \
> > > + ENV{ID_VENDOR}="$attr{vendor_name}", ENV{ID_MODEL}="$attr{model_name}"
> >
> > You appear to be removing setting of ID_ID here. Is that intended?
> >
> >
> > I can document with a comment, but by defining ID_SERIAL we get the
> fallthrough to this line below which does what we want (once patch #1 is
> submitted removing $attr{id}):
>
> ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="",
> ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}"
Yes, please add a comment about this. (to the commit msg at least)
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 2/2] Add more firewire properties for sound, to be closer to USB and PCI
On Mon, Apr 20, 2015 at 2:04 PM, Lennart Poettering
wrote:
> On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote:
>
> > USB and PCI soundcards have a nice set of ID_* properties. It would
> > be handy for firewire soundcards to have the same.
> > ---
> > rules/78-sound-card.rules | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
> > index bd7a994..e529f70 100644
> > --- a/rules/78-sound-card.rules
> > +++ b/rules/78-sound-card.rules
> > @@ -41,9 +41,10 @@ IMPORT{builtin}="hwdb"
> > SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
> > SUBSYSTEMS=="usb", GOTO="skip_pci"
> >
> > -SUBSYSTEMS=="firewire", ATTRS{vendor_name}=="?*",
> ATTRS{model_name}=="?*", \
> > - ENV{ID_BUS}="firewire", ENV{ID_VENDOR}="$attr{vendor_name}",
> ENV{ID_MODEL}="$attr{model_name}"
> > -SUBSYSTEMS=="firewire", ATTRS{guid}=="?*",
> ENV{ID_ID}="firewire-$attr{guid}"
> > +SUBSYSTEMS=="firewire", ATTRS{guid}=="?*", \
> > + ENV{ID_BUS}="firewire", ENV{ID_SERIAL}="$attr{guid}",
> ENV{ID_SERIAL_SHORT}="$attr{guid}", \
> > + ENV{ID_VENDOR_ID}="$attr{vendor}", ENV{ID_MODEL_ID}="$attr{model}", \
> > + ENV{ID_VENDOR}="$attr{vendor_name}", ENV{ID_MODEL}="$attr{model_name}"
>
> You appear to be removing setting of ID_ID here. Is that intended?
>
>
> I can document with a comment, but by defining ID_SERIAL we get the
fallthrough to this line below which does what we want (once patch #1 is
submitted removing $attr{id}):
ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="",
ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}"
Thanks,
Adam
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
On Mon, Apr 20, 2015 at 9:04 AM, Lennart Poettering wrote: > maybe the main gdm process is not the one waiting, but a worker > process is, and the main process kills the worker process without the > worker process handling that nicely? Not really. I removed all the process-killing code from gdm and the problem is still there. I have stepped through and I think that systemd is being too aggressive. Still running with the default KillMode=cgroup, here is what happens: 1. service_enter_stop() is entered which calls: service_enter_signal(s, SERVICE_STOP_SIGTERM, SERVICE_SUCCESS); 2. service_enter_signal sends SIGTERM to all gdm processes. 3. gdm simple-slave's signal handler triggers, which causes the mainloop to exit, and it starts to kill and wait for the X server death. I'm not exactly sure why, but quitting the glib mainloop also causes the signal handler to be destroyed, so sigaction() is called here to return SIGTERM to its default behaviour. 4. Moments later we arrive in systemd's service_sigchld_event(), presumably because the main gdm process exited due to SIGTERM. s->main_pid == pid. We respond as follows: case SERVICE_STOP_SIGTERM: case SERVICE_STOP_SIGKILL: if (!control_pid_good(s)) service_enter_stop_post(s, f); 5. Inside service_enter_stop post, there is no command to execute, so we call: service_enter_signal(s, SERVICE_FINAL_SIGTERM, SERVICE_SUCCESS); 6. service_enter_signal causes all remaining gdm processes to receive SIGTERM again, only moments after the previous one. As gdm simple-slave now has the default SIGTERM handler (instant death), it dies, before it has finished the X server cleanup :( 7. To make things even worse, after sending the SIGTERMs, service_enter_signal hits: } else if (state == SERVICE_FINAL_SIGTERM) service_enter_signal(s, SERVICE_FINAL_SIGKILL, SERVICE_SUCCESS); So, moments after sending 2 SIGTERMs, SIGKILL is sent to all gdm processes. There does not seem to be any consideration of giving the process some time to respond to SIGTERMs, nor the fact that I have hacked gdm.service to have SendSIGKILL=no as an experiment. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and process migration
Heya, On 20 April 2015 at 06:59, Adrian Reber wrote: > Using CRIU I have been migrating processes from one system to another > for the last few months (even years). I am now interested in migrating > processes under systemd's control. Before starting to look how to make > it work I wanted to know if there has been any discussion if and how > systemd and CRIU can work together? > > Dumping a process under systemd's control should be no problem. > After criu has dumped the process (and killed it) systemd should know > that it does not need to restart the process, but even if the process is > restarted by systemd it does not hurt the process migration. > > The interesting part happens on the system where the process wants to be > migrated to. After the process has been dumped and transfered from the > source system to the destination system it needs to be restarted. So far > this works with different tested processes (postgresql is my current > test process). If I want to restore the process as a systemd child > process I have the problem that the process would have to be re-parented > to systemd after restarting which is not possible in Linux. Therefore I > need the help of systemd. > > My plan now would be to transfer the process to the destination > system and tell systemd I want to restore a process which should be > under systemd's control after the restore has completed. Therefore > systemd needs to run criu with the option to restore the new process as > a criu sibling. Thus systemd would be the correct parent process. > > Is this something which would be useful to integrate into systemd? > I have some ideas how this could be implemented and how the user > interfaces could look like. Before going in too much detail I want to > find out if this is a direction which makes sense. So systemd has re-exec support. I would go down the route of trying to serialise the systemd state of the process as well on the orginal host, and then deserialise it on the target. I haven't done anything with re-exec serialisation on systemd yet, so no idea how sufficient that would be to "side-load" a process like that. It will be fragile. Going down the route of machinectl api / containers sounds more interesting. As there is more support for importing those. E.g. instead of importing a tarball and execing, it, one unfreezes it. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev interface naming for SR-IOV VFs
On Fri, 17.04.15 14:19, Nir Soffer (nir...@gmail.com) wrote: > - You may wait for unrelated events that happen to trigger in the same > time, waiting after the new interfaces are ready. > > I think you need something like: > > while True: > try: > udevadm.settle(1) > except udevadm.Timeout: > pass > else: > if all devices are ready: > break > time.sleep(1) Please never use udevadm settle in new code. Please instead subscribe to libudev events about network interfaces and don't take rtnl messages into account until the device has been reported via udev, too. THis is for example what networkd does to make sure it doesn't start making use of network interfaces that didn't get fully set up yet by the udev rules. 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] Problem with intermediate target
On 18 April 2015 at 09:39, Christoph Pleger wrote: > Hello, > >>> Why does systemd start this service before /var is mounted, though the >>> service should be executed after remote-fs.target, and remote-fs.target >>> comes after local-fs.target? >>> >> >> Because remote-fs.target is not part of initial transaction. >> >>> And why is this different in my intermediate.target than in >>> multi-user.target, though intermediate.target defines exactly the same >>> requirements, orders and conflicts as multi-user.target? >>> >> >> Because systemd allows to declare extra dependencies that are not >> directly part of unit definition. E.g. remote-fs.target has >> WantedBy=multi-user.target. It is *not* dependencies listed in unit >> configuration of multi-user.target that make it start remote-fs.target. >> >> When initial target is multi-user.target all those "reverse >> dependencies" (for lack of better word) are pulled in and are part of >> initial transaction. With another unit as initial target they are >> skipped. > > Ah, I understand, that makes it clear. The auto-generated pident.service > file only defines that the service should be executed after > remote-fs.target, but it does not require it, and because no other service > or target wants or requires remote-fs.target before pidentd.service > starts, the filesystems are not yet mounted at that point. > > But then, I think that the way how systemd translates LSB init scripts > should be changed. This is the LSB part of /etc/init.d/pidentd: > > ### BEGIN INIT INFO > # Provides: pidentd-run-dir > # Required-Start:$remote_fs > # Required-Stop: $remote_fs > # Default-Start: S > # Default-Stop: > # Short-Description: setup for pidentd > # Description: create /var/run/ident for pidentd > ### END INIT INFO > > As you can see, it defines remote-fs in Required-Start, not in > Should-Start. In my opinion, this should result in an additional > Requires=remote-fs.target in pidentd.service. Early boot sysv scripts are also gone in Ubuntu. That is - they are masked by native upstart jobs or systemd units. For this case, why can't you specify RuntimeDirectory=ident to the whichever unit pidentd is? Either directly in the unit, or as a /lib/systemd/system/ident.service.d/rundir.conf or some such. And ditch the sysv init script? -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Don't use ALSA card id in ID_ID
On Mon, 20.04.15 20:39, Lennart Poettering (lenn...@poettering.net) wrote: > On Mon, 20.04.15 20:00, Lennart Poettering (lenn...@poettering.net) wrote: > > > On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote: > > > > > The ALSA id sysattr is generated by the sound subsystem and is not > > > a stable identifier. It is generated though some string manipulation > > > then made unique if there is a conflict. This means that it is > > > enumeration-dependent and shouldn't be used for ID_ID. > > > > > > If ID_ID is supposed to be system-unique, it is not already since > > > for firewire it is generated from the guid and there are broken > > > firewire devices that have duplicate guids across devices. > > > > Hmm, this patch pretty much reverts > > ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e. Now I am not sure if that > > commit from 6 years ago was a good idea, but we should have some > > clarity about this. > > > > What is ID_ID actually supposed to be? Should it really be system > > unique? > > > > I do have the suspicion this is something that better should be fixed in > > PA rather then in these udev rules, so I figure your patch might be a > > good idea? > > > > Opinions? > > > > If we apply the patch somebody should at least post a bug report > > against PA to be aware of this change. > > OK, after talking to some folks I think we should merge your > patch. Any chance you can post a bug to PA though, reference this > discussion, and then include the bug report in the commit message and > resend the patch? Also, please mention in the commit msg that this is basically a revert of ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e. 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] Don't use ALSA card id in ID_ID
On Mon, 20.04.15 20:00, Lennart Poettering (lenn...@poettering.net) wrote:
> On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote:
>
> > The ALSA id sysattr is generated by the sound subsystem and is not
> > a stable identifier. It is generated though some string manipulation
> > then made unique if there is a conflict. This means that it is
> > enumeration-dependent and shouldn't be used for ID_ID.
> >
> > If ID_ID is supposed to be system-unique, it is not already since
> > for firewire it is generated from the guid and there are broken
> > firewire devices that have duplicate guids across devices.
>
> Hmm, this patch pretty much reverts
> ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e. Now I am not sure if that
> commit from 6 years ago was a good idea, but we should have some
> clarity about this.
>
> What is ID_ID actually supposed to be? Should it really be system
> unique?
>
> I do have the suspicion this is something that better should be fixed in
> PA rather then in these udev rules, so I figure your patch might be a
> good idea?
>
> Opinions?
>
> If we apply the patch somebody should at least post a bug report
> against PA to be aware of this change.
OK, after talking to some folks I think we should merge your
patch. Any chance you can post a bug to PA though, reference this
discussion, and then include the bug report in the commit message and
resend the patch?
Thanks,
Lennart
>
> > ---
> > rules/78-sound-card.rules | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
> > index 295f490..bd7a994 100644
> > --- a/rules/78-sound-card.rules
> > +++ b/rules/78-sound-card.rules
> > @@ -49,8 +49,8 @@ SUBSYSTEMS=="firewire", GOTO="skip_pci"
> > SUBSYSTEMS=="pci", ENV{ID_BUS}="pci", ENV{ID_VENDOR_ID}="$attr{vendor}",
> > ENV{ID_MODEL_ID}="$attr{device}"
> > LABEL="skip_pci"
> >
> > -ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="?*",
> > ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}-$attr{id}"
> > -ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="",
> > ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}-$attr{id}"
> > +ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="?*",
> > ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}"
> > +ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="",
> > ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}"
> >
> > IMPORT{builtin}="path_id"
> >
> > --
> > 2.2.0.rc0.207.ga3a616c
> >
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
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] journal: don't complain about audit socket errors in a container.
On Wed, 15.04.15 00:22, Frank Thalberg (frankthalb...@ruggedinbox.com) wrote: > > nspawn at least grants audit caps to containers. If you don't grant > > audit caps you cannot boot distros like Fedora at all, since much of > > the PAM audit code in Fedora is written to fail completely if audit > > is on in the kernel, but cannot be used. > > My first impression was that container/namespaces aren't supported > inside the audit kernel code at all. Yes. Which is why we suggest to either specify audit=0 on the kernel cmdline, or (on x86-64 only) mask the audit support away via seccomp in nspawn. Is this on 32bit userspace or something like that? Or on non-x86 or so? > I still have to butt in though. There are 2 issues here at hand. > > The first one: It doesn't look to me like the audit subsystem within the > kernel is ready for namespaces. They aren't directly rejected but I > can't see any measurements to separate namespaces. It would be quiet > unfortunate if processes within a namespace could receive audit events > from another namespace. Yes. audit is broken. > The second problem is rather simple: it seems libcap currently doesn't > understand the CAP_AUDIT_READ value so passing it to the --capability= > option is not an (easy) option. Hmm, we actually don't use libcap for converting the caps to strings anymore. it should just work. However, CAP_AUDIT_READ is among the default caps we pass, this should hence be unnecessary anyway. > Given that I would suggest to treat the whole audit subsystem to be > optional and don't fail too hard if it can't be used. Unfortunately > pre-built packages can't offer the option to configure this > behavior. Well, sure, I am all for making audit optional. I am just wondering why this precise error happens for you even though I have never seen it like this elsewhere... > > Hmm, exluding the audit code from the build if HAVE_AUDIT is not set > > is certainly a good idea, but we generally try to keep #ifdeffery out > > of .c files. More specifically, the journald-audit.c file should not > > be compiled and linked at all on non-audit builds, and > > journald-audit.h should contain the #ifdeffery that causes > > server_open_audit() to become a NOP on such builds. Would be happy to > > take a patch for that. > > Can't agree more with you here. Your solution to the problem is a > little more work than I was initially willing to invest into the > problem. I'll gladly provide a better patch for this given the > the interest in handling this. I'd be happy to merge a patch like this! 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] [systemd-commits] 2 commits - src/libsystemd-network
On Tue, 14.04.15 09:33, Thomas H.P. Andersen (pho...@kemper.freedesktop.org)
wrote:
> src/libsystemd-network/sd-dhcp6-client.c |2 ++
> src/libsystemd-network/test-dhcp6-client.c |2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> New commits:
> commit 70c79983e1abae17c46969b024d0b9e6a3b83d00
> Author: Thomas Hindoe Paaboel Andersen
> Date: Tue Apr 14 18:24:00 2015 +0200
>
> test-dhcp6-client: don't unref the event twice
>
> diff --git a/src/libsystemd-network/test-dhcp6-client.c
> b/src/libsystemd-network/test-dhcp6-client.c
> index 9386f31..7618547 100644
> --- a/src/libsystemd-network/test-dhcp6-client.c
> +++ b/src/libsystemd-network/test-dhcp6-client.c
> @@ -701,7 +701,5 @@ int main(int argc, char *argv[]) {
> test_advertise_option(e);
> test_client_solicit(e);
>
> -assert_se(!sd_event_unref(e));
> -
> return 0;
> }
>
> commit 8283c71b7141afc6ad69dc7913311aa01e8221dd
> Author: Thomas Hindoe Paaboel Andersen
> Date: Tue Apr 14 18:02:15 2015 +0200
>
> sd-dhcp6-client: unref lease when freeing the client
>
> diff --git a/src/libsystemd-network/sd-dhcp6-client.c
> b/src/libsystemd-network/sd-dhcp6-client.c
> index 9d88d46..cd33237 100644
> --- a/src/libsystemd-network/sd-dhcp6-client.c
> +++ b/src/libsystemd-network/sd-dhcp6-client.c
> @@ -1205,6 +1205,8 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client
> *client) {
> client_reset(client);
>
> sd_dhcp6_client_detach_event(client);
> +if (client->lease)
> +sd_dhcp6_lease_unref(client->lease);
A quick note: our destructor functions should all accept NULL as
parameter and then become NOPs. sd_dhcp6_lease_unref() does that
correctly, and hence makes the explicit if check by the caller
unnecessary.
Will fix. Will also add a note to CODING_STYLE about 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] Socket activation of container with private network
On Mon, 20.04.15 14:15, Spencer Baugh (sba...@catern.com) wrote: > Lennart Poettering writes: > > On Mon, 20.04.15 13:01, Spencer Baugh (sba...@catern.com) wrote: > >> Lennart Poettering writes: > >> > Hmm, so you say the initial connection does not work but triggers the > >> > container, but the subsequent one will? > >> > >> Not quite; the initial connection seems to actually make it to sshd, as > >> sshd has logs of getting it, but the connection is interrupted at some > >> point by some thing before anything useful can be done. > >> Subsequent connections indeed work fine. > > > > Interrupted? What precisely does sshd in the container log about the > > connection? > > I've just noticed that there are in fact two cases: The case where I > first ssh from the host to the container, and the case where I first ssh > from another unrelated machine with IPv6 connectivity to the > container. Neither works, but they do appear to have different > behavior. In both cases, all subsequent ssh connections work fine no > matter where they originate from. Here are logs for both cases, both ssh > and sshd side. My guess is that this is actually quite simple: when the first connection is set up the first packets arrive on the host, and are thus processed by the host, and processed by the the first TCP socket. Howeverm when the network interface is moved into the container, then all subsequent packets of that connection are instead routed to the container's IP namespace, which cannot make any sense of the packets, and drop them/disconnect the client... The connection from the host hence will not receive any packets anymore... I figure the take-away here is that as of now private networking and socket activated containers don't mix well (And I don't even have an idea how to make them work better)... 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] networkd-218 seems to ignore .link files
On 04/20/2015 01:06 PM, Lennart Poettering wrote: On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote: I would love to be able to set the MTU of a physical interface in a .network file. Is this possible? (The systemd.network(5) doesn't list it.) Yes, this is supported via MTU=. This needs documentation indeed. Hmm. I've just tried both MTU and MTUBytes with no effect. E.g.: [Match] Name=eno1 [Network] Address=172.31.250.1/24 Gateway=172.31.250.254 DNS=172.31.250.254 MTUBytes=5000 (Unless this requires something later than systemd 216 on Fedora 21.) -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Add support for bond option.
Sorry for the delay. Applied. Thanks! Tom On Mon, Mar 9, 2015 at 10:58 AM, Susant Sahani wrote: > This patch adds configurational support for bond option. > > Test conf: > > bond.netdev > > --- > [NetDev] > Name=bond1 > Kind=bond > > [Bond] > ArpAllTargets=all > PrimaryReselect=better > ArpIntervalSec=10s > ArpIpTargets= 192.168.8.102 192.168.8.101 192.168.8.102 > --- > > $cat /proc/net/bonding/bond1 > Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) > > Bonding Mode: load balancing (round-robin) > MII Status: up > MII Polling Interval (ms): 0 > Up Delay (ms): 0 > Down Delay (ms): 0 > ARP Polling Interval (ms): 1 > ARP IP target/s (n.n.n.n form): 192.168.8.100, 192.168.8.101, 192.168.8.102 > --- > man/systemd.netdev.xml | 167 + > src/libsystemd/sd-rtnl/rtnl-types.c | 26 ++- > src/libsystemd/sd-rtnl/rtnl-types.h | 22 +++ > src/network/networkd-netdev-bond.c | 318 > +++- > src/network/networkd-netdev-bond.h | 85 - > src/network/networkd-netdev-gperf.gperf | 13 ++ > 6 files changed, 627 insertions(+), 4 deletions(-) > > diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml > index ef58887..4230d19 100644 > --- a/man/systemd.netdev.xml > +++ b/man/systemd.netdev.xml > @@ -647,7 +647,174 @@ > > > > + > +LearnPacketIntvSec,= > + > + Specifies the number of seconds between instances where the > bonding > + driver sends learning packets to each slaves peer switch. > + The valid range is 1 - 0x7fff; the default value is 1. This > Option > + has effect only in balance-tlb and balance-alb modes. > + > + > + > + > +AdSelect= > + > + Specifies the 802.3ad aggregation selection logic to use. > Possible values are > + stable, > + bandwidth, > + count > + > + > + > + > + > +FailOverMac= > + > + Specifies whether active-backup mode should set all slaves to > + the same MAC address at enslavement or, when enabled, perform > special handling of the > + bond's MAC address in accordance with the selected policy. The > default policy is none. > + Possible values are > + none, > + active, > + follow > + > + > + > + > + > +ArpValidate= > + > + Specifies whether or not ARP probes and replies should be > + validated in any mode that supports arp monitoring, or whether > + non-ARP traffic should be filtered (disregarded) for link > + monitoring purposes. Possible values are > + none, > + active, > + backup, > + all > + > + > + > + > + > +ArpIntervalSec= > + > + Specifies the ARP link monitoring frequency in milliseconds. > + A value of 0 disables ARP monitoring. The default value is 0. > + > + > + > + > + > +ArpIpTargets= > + > + Specifies the IP addresses to use as ARP monitoring peers > when > + ArpIntervalSec is greater than 0. These are the targets of the ARP > request > + sent to determine the health of the link to the targets. > + Specify these values in ipv4 dotted decimal format. At least one IP > + address must be given for ARP monitoring to function. The > + maximum number of targets that can be specified is 16. The > + default value is no IP addresses. > + > + > + > + > + > +ArpAllTargets= > + > + Specifies the quantity of ArpIpTargets that must be reachable > + in order for the ARP monitor to consider a slave as being up. > + This option affects only active-backup mode for slaves with > + ArpValidate enabled. Possible values are > + any, > + all > + > + > + > + > + > +PrimaryReselect= > + > + Specifies the reselection policy for the primary slave. This > + affects how the primary slave is chosen to become the active slave > + when failure of the active slave or recovery of the primary slave > + occurs. This option is designed to prevent flip-flopping between > + the primary slave and other slaves. Possible values are > + always, > + better, > + failure > + > + > + > + > + > +ResendIGMP= > + > + Specifies the number of IGMP membership reports to be issued > after > + a failover event. One membership report is issued immediately after > + the failover, subsequent packets are sent in each 200ms interval. > + The valid range is (0 - 255). Defaults to 1. A value
Re: [systemd-devel] Socket activation of container with private network
Lennart Poettering writes: > On Mon, 20.04.15 13:01, Spencer Baugh (sba...@catern.com) wrote: >> Lennart Poettering writes: >> > Hmm, so you say the initial connection does not work but triggers the >> > container, but the subsequent one will? >> >> Not quite; the initial connection seems to actually make it to sshd, as >> sshd has logs of getting it, but the connection is interrupted at some >> point by some thing before anything useful can be done. >> Subsequent connections indeed work fine. > > Interrupted? What precisely does sshd in the container log about the > connection? I've just noticed that there are in fact two cases: The case where I first ssh from the host to the container, and the case where I first ssh from another unrelated machine with IPv6 connectivity to the container. Neither works, but they do appear to have different behavior. In both cases, all subsequent ssh connections work fine no matter where they originate from. Here are logs for both cases, both ssh and sshd side. Case of sshing from the host to the container: Both sides are hung at the end of these logs. # Log of ssh - on the host root@ipv6-test:~# ssh - 2001:470:8:9d:201:2ff:feaa:bbcd -p 23 OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1k 8 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 2001:470:8:9d:201:2ff:feaa:bbcd [2001:470:8:9d:201:2ff:feaa:bbcd] port 23. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3 # logs of sshd inside the container, when sshing from host root@ipv6-container:/# journalctl -u sshd* -- Logs begin at Mon 2015-04-20 18:08:32 UTC, end at Mon 2015-04-20 18:08:33 UTC. -- Apr 20 18:08:32 ipv6-container systemd[1]: Starting SSH Per-Connection Server for 0 ([2001:470:8:9d:201:2ff:feaa:bbcd]:38383)... Apr 20 18:08:32 ipv6-container systemd[1]: Started SSH Per-Connection Server for 0 ([2001:470:8:9d:201:2ff:feaa:bbcd]:38383). Apr 20 18:08:32 ipv6-container sshd[57]: debug1: inetd sockets after dupping: 3, 4 Apr 20 18:08:32 ipv6-container sshd[57]: Connection from 2001:470:8:9d:201:2ff:feaa:bbcd port 38383 on 2001:470:8:9d:201:2ff:feaa:bbcd port 23 Apr 20 18:08:32 ipv6-container sshd[57]: debug1: Client protocol version 2.0; client software version OpenSSH_6.7p1 Debian-3 Apr 20 18:08:32 ipv6-container sshd[57]: debug1: match: OpenSSH_6.7p1 Debian-3 pat OpenSSH* compat 0x0400 Apr 20 18:08:32 ipv6-container sshd[57]: debug1: Enabling compatibility mode for protocol 2.0 Apr 20 18:08:32 ipv6-container sshd[57]: debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5 Apr 20 18:08:32 ipv6-container sshd[57]: debug2: fd 3 setting O_NONBLOCK Apr 20 18:08:32 ipv6-container sshd[57]: debug3: fd 4 is O_NONBLOCK Apr 20 18:08:32 ipv6-container sshd[57]: debug2: Network child is on pid 64 Apr 20 18:08:32 ipv6-container sshd[57]: debug3: preauth child monitor started Apr 20 18:08:32 ipv6-container sshd[57]: debug3: privsep user:group 104:65534 [preauth] Apr 20 18:08:32 ipv6-container sshd[57]: debug1: permanently_set_uid: 104/65534 [preauth] Apr 20 18:08:32 ipv6-container sshd[57]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Apr 20 18:08:32 ipv6-container sshd[57]: debug1: SSH2_MSG_KEXINIT sent [preauth] Case of sshing from an unrelated machine to the container: The ssh side terminates with the error at the end, but the sshd side appears to just hang. # logs of ssh - on unrelated machine root@lxc0:~# ssh - 2001:470:8:9d:201:2ff:feaa:bbcd -p 23 OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 2001:470:8:9d:201:2ff:feaa:bbcd [2001:470:8:9d:201:2ff:feaa:bbcd] port 23. debug1: Connection established. debug1: permane
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
Hi On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett wrote: > On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: >> I'm not convinced that any such broad matches for power management >> belong into udev at all. Udev can carry specific device matches, or >> carry data that cannot be determined from the device itself, like the >> mouse resolution and such, but like in these rules, reading the vendor >> from the kernel and unconditionally flipping a bit back into the >> kernel does not look like a task for udev or userspace in general. > > Is there any possibility that you can be convinced? I'd much prefer if this was hwdb based. This way, we have a sane database that just sets something like POWER_CONTROL=foobar, which we can then apply via udev. Given that the power-control issues seem to be totally random, hwdb really sounds like the nicer solution. Any reason why hwdb would not work? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd vxlan: Add support for enabling UDP checksums
Sorry for the delay. Applied. Thanks!
Tom
On Thu, Mar 5, 2015 at 5:32 PM, Susant Sahani wrote:
> Add UDPCheckSum option to enable transmitting UDP checksums when doing
> VXLAN/IPv4. Add UDP6ZeroChecksumRx, and UDP6ZeroChecksumTx
> options to enable sending zero checksums and receiving zero
> checksums in VXLAN/IPv6
>
> V2: rename Udp to UDP
> ---
> man/systemd.netdev.xml | 20 +++-
> src/network/networkd-netdev-gperf.gperf | 3 +++
> src/network/networkd-netdev-vxlan.c | 27 +++
> src/network/networkd-netdev-vxlan.h | 3 +++
> 4 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
> index e278aa1..7800dc4 100644
> --- a/man/systemd.netdev.xml
> +++ b/man/systemd.netdev.xml
> @@ -391,7 +391,25 @@
> A boolean. When true
> route short circuit is turned on.
>
>
> -
> +
> +
> UDPCheckSum=
> +
> +A boolean. When true
> transmitting UDP checksums when doing VXLAN/IPv4 is turned on.
> +
> +
> +
> +
> UDP6ZeroChecksumTx=
> +
> + A boolean. When true
> sending zero checksums in VXLAN/IPv6 is turned on.
> +
> +
> +
> +
> UDP6ZeroCheckSumRx=
> +
> + A boolean. When true
> receiving zero checksums in VXLAN/IPv6 is turned on.
> +
> +
> +
>
>
> [Tunnel] Section Options
> diff --git a/src/network/networkd-netdev-gperf.gperf
> b/src/network/networkd-netdev-gperf.gperf
> index 963c47c..c06344c 100644
> --- a/src/network/networkd-netdev-gperf.gperf
> +++ b/src/network/networkd-netdev-gperf.gperf
> @@ -47,6 +47,9 @@ VXLAN.ARPProxy, config_parse_bool,
> 0,
> VXLAN.L2MissNotification, config_parse_bool, 0,
> offsetof(VxLan, l2miss)
> VXLAN.L3MissNotification, config_parse_bool, 0,
> offsetof(VxLan, l3miss)
> VXLAN.RouteShortCircuit, config_parse_bool, 0,
> offsetof(VxLan, route_short_circuit)
> +VXLAN.UDPCheckSum,config_parse_bool, 0,
> offsetof(VxLan, udpcsum)
> +VXLAN.UDP6ZeroCheckSumRx, config_parse_bool, 0,
> offsetof(VxLan, udp6zerocsumrx)
> +VXLAN.UDP6ZeroCheckSumTx, config_parse_bool, 0,
> offsetof(VxLan, udp6zerocsumtx)
> VXLAN.FDBAgeingSec, config_parse_sec, 0,
> offsetof(VxLan, fdb_ageing)
> Tun.OneQueue, config_parse_bool, 0,
> offsetof(TunTap, one_queue)
> Tun.MultiQueue, config_parse_bool, 0,
> offsetof(TunTap, multi_queue)
> diff --git a/src/network/networkd-netdev-vxlan.c
> b/src/network/networkd-netdev-vxlan.c
> index d5128cb..d9b13e3 100644
> --- a/src/network/networkd-netdev-vxlan.c
> +++ b/src/network/networkd-netdev-vxlan.c
> @@ -135,6 +135,30 @@ static int netdev_vxlan_fill_message_create(NetDev
> *netdev, Link *link, sd_rtnl_
> }
> }
>
> +r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_CSUM, v->udpcsum);
> +if (r < 0) {
> +log_netdev_error(netdev,
> + "Could not append IFLA_VXLAN_UDP_CSUM
> attribute: %s",
> + strerror(-r));
> +return r;
> +}
> +
> +r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_ZERO_CSUM6_TX,
> v->udp6zerocsumtx);
> +if (r < 0) {
> +log_netdev_error(netdev,
> + "Could not append
> IFLA_VXLAN_UDP_ZERO_CSUM6_TX attribute: %s",
> + strerror(-r));
> +return r;
> +}
> +
> +r = sd_rtnl_message_append_u8(m, IFLA_VXLAN_UDP_ZERO_CSUM6_RX,
> v->udp6zerocsumrx);
> +if (r < 0) {
> +log_netdev_error(netdev,
> + "Could not append
> IFLA_VXLAN_UDP_ZERO_CSUM6_RX attribu
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote: > On 01/12/2015 05:38 PM, Tom Gundersen wrote: > >Some of the .link settings may make sense to tweak also per-network, > >in which case we support changing them in .network files. > > I would love to be able to set the MTU of a physical interface in a > .network file. Is this possible? (The systemd.network(5) doesn't list > it.) Yes, this is supported via MTU=. This needs documentation indeed. 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 2/2] Add more firewire properties for sound, to be closer to USB and PCI
On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote:
> USB and PCI soundcards have a nice set of ID_* properties. It would
> be handy for firewire soundcards to have the same.
> ---
> rules/78-sound-card.rules | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
> index bd7a994..e529f70 100644
> --- a/rules/78-sound-card.rules
> +++ b/rules/78-sound-card.rules
> @@ -41,9 +41,10 @@ IMPORT{builtin}="hwdb"
> SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
> SUBSYSTEMS=="usb", GOTO="skip_pci"
>
> -SUBSYSTEMS=="firewire", ATTRS{vendor_name}=="?*", ATTRS{model_name}=="?*", \
> - ENV{ID_BUS}="firewire", ENV{ID_VENDOR}="$attr{vendor_name}",
> ENV{ID_MODEL}="$attr{model_name}"
> -SUBSYSTEMS=="firewire", ATTRS{guid}=="?*", ENV{ID_ID}="firewire-$attr{guid}"
> +SUBSYSTEMS=="firewire", ATTRS{guid}=="?*", \
> + ENV{ID_BUS}="firewire", ENV{ID_SERIAL}="$attr{guid}",
> ENV{ID_SERIAL_SHORT}="$attr{guid}", \
> + ENV{ID_VENDOR_ID}="$attr{vendor}", ENV{ID_MODEL_ID}="$attr{model}", \
> + ENV{ID_VENDOR}="$attr{vendor_name}", ENV{ID_MODEL}="$attr{model_name}"
You appear to be removing setting of ID_ID here. Is that intended?
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] networkd-218 seems to ignore .link files
On 01/12/2015 05:38 PM, Tom Gundersen wrote: Some of the .link settings may make sense to tweak also per-network, in which case we support changing them in .network files. I would love to be able to set the MTU of a physical interface in a .network file. Is this possible? (The systemd.network(5) doesn't list it.) -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Don't use ALSA card id in ID_ID
On Fri, 10.04.15 22:27, Adam Goode (ago...@google.com) wrote:
> The ALSA id sysattr is generated by the sound subsystem and is not
> a stable identifier. It is generated though some string manipulation
> then made unique if there is a conflict. This means that it is
> enumeration-dependent and shouldn't be used for ID_ID.
>
> If ID_ID is supposed to be system-unique, it is not already since
> for firewire it is generated from the guid and there are broken
> firewire devices that have duplicate guids across devices.
Hmm, this patch pretty much reverts
ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e. Now I am not sure if that
commit from 6 years ago was a good idea, but we should have some
clarity about this.
What is ID_ID actually supposed to be? Should it really be system
unique?
I do have the suspicion this is something that better should be fixed in
PA rather then in these udev rules, so I figure your patch might be a
good idea?
Opinions?
If we apply the patch somebody should at least post a bug report
against PA to be aware of this change.
> ---
> rules/78-sound-card.rules | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
> index 295f490..bd7a994 100644
> --- a/rules/78-sound-card.rules
> +++ b/rules/78-sound-card.rules
> @@ -49,8 +49,8 @@ SUBSYSTEMS=="firewire", GOTO="skip_pci"
> SUBSYSTEMS=="pci", ENV{ID_BUS}="pci", ENV{ID_VENDOR_ID}="$attr{vendor}",
> ENV{ID_MODEL_ID}="$attr{device}"
> LABEL="skip_pci"
>
> -ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="?*",
> ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}-$attr{id}"
> -ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="",
> ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}-$attr{id}"
> +ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="?*",
> ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}"
> +ENV{ID_SERIAL}=="?*", ENV{ID_USB_INTERFACE_NUM}=="",
> ENV{ID_ID}="$env{ID_BUS}-$env{ID_SERIAL}"
>
> IMPORT{builtin}="path_id"
>
> --
> 2.2.0.rc0.207.ga3a616c
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoos...@gmail.com) wrote: > > > inexperienced poking around the internal default suite of units packaged > > > with systemd. > > > > This is not available, though often requested. But I doubt this can > > ever work, since "running before 'everything'" or "running after > > 'everything'" is not particularly usefully defined as this all breaks > > down as soon as you have two services that want to be run like this > > > Okay, I appreciate that there's no built-in meta-unit that would permit me > to say "start me to the exclusion of absolutely everything else." I agree > that would fail the "what if two processes each tried to play that game?" > test. > > I was just hoping that some unit exists that is synonymous with "the point > upon which all traditional systemd work is dependent." I suppose nothing > still exists matching that kind of weaker description? E.g., ".slice" or > something like that. You could order yourself before "local-fs-pre.target" plus the various early-boot services we ship. That list is pretty limited and relatively stable, but there's nothing nicer currently, no. 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] udev interface naming for SR-IOV VFs
On Tue, Apr 14, 2015 at 12:11 PM, Ido Barkan wrote: > We are implementing support for SR-IOV network cards. Afer the changing of > the number of VFs on the card and programmatically querying for all links > (we use libnl for this) we observe that *during the iteration* over the links > some of them were renamed by udev and still were not. Meanning, some of them > are called 'ethN' and some are called 'enp2sNf2' (where N is an arbitrary > number). Also, there are times that not all of the devices are returned from > libnl. > After a _while_ everything stabilizes (# of interfaces and names). > > My questions: > 1. Is this what you would expect from udev? Meaning, this is just async > behavior? > 2. Is there a way to _know_ programmticaly that everything was probed and > renamed? >Not a heuristic? In short: no. We don't know when the kernel will finish enumerating all the devices. What you can know though, is whether a device you receive over netlink has been fully processed by udev. This is probably what you need, assuming you always keep listening for new devices in your daemon/tool. You can see how we do this in e.g., systemd-networkd where we have exactly the same situation: our main source of information is rtnl, but we need to only start using the devices once udev has renamed them (among other things) so we listen to libudev as well and only start using a device once both rtnl and libudev has announced it is ready. HTH, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Mon, Apr 20, 2015 at 9:11 AM, Lennart Poettering wrote: > On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoos...@gmail.com) wrote: > > > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are > spent > > internal to systemd before any external processes get run for the > > particular embedded CPU I'm using. That gap is a killer at the moment. > > > > I'm sure this is quite the naive question, but: is there a simple option > I > > can insert into my "super-important" first service that would cause all > > other units to be forestalled until my service reports that it's > > initialized? I.e., something like: > > > > [Unit] > > DefaultDependencies=no > > Before=very-first-normal-systemd-unit.service > > > > I didn't have luck identifying such a > > very-first-normal-systemd-unit.service on my own, but I'm admittedly > rather > > inexperienced poking around the internal default suite of units packaged > > with systemd. > > This is not available, though often requested. But I doubt this can > ever work, since "running before 'everything'" or "running after > 'everything'" is not particularly usefully defined as this all breaks > down as soon as you have two services that want to be run like this Okay, I appreciate that there's no built-in meta-unit that would permit me to say "start me to the exclusion of absolutely everything else." I agree that would fail the "what if two processes each tried to play that game?" test. I was just hoping that some unit exists that is synonymous with "the point upon which all traditional systemd work is dependent." I suppose nothing still exists matching that kind of weaker description? E.g., ".slice" or something like that. . > > The right way is usually to simply add the right deps of the stuff you > really want to be run before. > > That all said, I would be open to adding a "priority" concept to > units: if we are about to fork off a large number of processes at the > same time we do so sequentially but provide no control currently about > the order then. I'd be open making this configurable with a priority > values that can ensure we fork off some things before others when both > are runnable. This would not really fix your issue, sicne it wouldn't > really delay any other services, it would only configure the order of > the fork()s, but they'd still take place in a tight loop. > > 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] udev: Fix ping timeout when settle timeout is 0
Hi
On Sun, Apr 19, 2015 at 1:49 AM, Nir Soffer wrote:
> When running udevadm settle --timeout=0, the ping always times out, and
> udevadm will return 0 without checking the queue state.
>
> Since zero timeout is considered as unlimited timeout, we use now
> unlimited ping timeout.
> ---
> src/udev/udevadm-settle.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
> index 2c84ada..424 100644
> --- a/src/udev/udevadm-settle.c
> +++ b/src/udev/udevadm-settle.c
> @@ -107,7 +107,9 @@ static int adm_settle(struct udev *udev, int argc, char
> *argv[]) {
>
> uctrl = udev_ctrl_new(udev);
> if (uctrl != NULL) {
> -if (udev_ctrl_send_ping(uctrl, timeout) < 0) {
> +int ping_timeout = timeout > 0 ? (int)timeout : -1;
> +
> +if (udev_ctrl_send_ping(uctrl, ping_timeout) < 0) {
> log_debug("no connection to daemon");
> udev_ctrl_unref(uctrl);
> return EXIT_SUCCESS;
This looks much more reasonable to me. I'd prefer some sanity-timeout,
though. 1s or 5s or something like this. Kay?
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/2] udev: Skip ping if timeout is 0
Hi
On Sun, Apr 19, 2015 at 2:41 AM, Nir Soffer wrote:
> When running udevadm settle --timeout=0, udev_ctrl_send_ping always
> times out, and settle returns 0 without checking the queue.
>
> Now we skip ping in this case, and return the queue state.
> ---
> src/udev/udevadm-settle.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
> index 437c794..614768f 100644
> --- a/src/udev/udevadm-settle.c
> +++ b/src/udev/udevadm-settle.c
> @@ -102,7 +102,7 @@ static int adm_settle(struct udev *udev, int argc, char
> *argv[]) {
> deadline = now(CLOCK_MONOTONIC) + timeout * USEC_PER_SEC;
>
> /* guarantee that the udev daemon isn't pre-processing */
> -if (getuid() == 0) {
> +if (timeout > 0 && getuid() == 0) {
> struct udev_ctrl *uctrl;
>
> uctrl = udev_ctrl_new(udev);
This looks wrong to me. With this change, we suddenly skip the
validity check that ping was created for. I don't really see why the
udev_ctrl_ping() needs to follow the udev-queue timeout. I mean, this
is really a synchronous call into udev, which really should return in
a suitable timespan. Otherwise, something is really broken.
I think this should pass something like max(timeout, 1) to
udev_ctrl_ping(), so we have at least a 1s timeout.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 1/2] udev: settle should return immediately when timeout is 0
Hi
On Sun, Apr 19, 2015 at 2:41 AM, Nir Soffer wrote:
> udevadm manual says:
>
> A value of 0 will check if the queue is empty and always return
> immediately.
>
> However, currently we ignore the deadline if the value is 0, and wait
> without any limit.
>
> Zero timeout behaved according to the documentation until commit
> ead7c62ab7 (udevadm: settle - kill alarm()). Looking at this patch, it
> seems that the behavior change was unintended.
>
> This patch restores the documented behavior.
> ---
> src/udev/udevadm-settle.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
After a discussion with Kay:
Applied!
Thanks
David
> diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
> index 2c84ada..437c794 100644
> --- a/src/udev/udevadm-settle.c
> +++ b/src/udev/udevadm-settle.c
> @@ -142,7 +142,7 @@ static int adm_settle(struct udev *udev, int argc, char
> *argv[]) {
> break;
> }
>
> -if (timeout > 0 && now(CLOCK_MONOTONIC) >= deadline)
> +if (now(CLOCK_MONOTONIC) >= deadline)
> break;
>
> /* wake up when queue is empty */
> --
> 1.9.3
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Wed, 15.04.15 01:08, Andrew Cooks (aco...@linux.com) wrote: > On Tue, Jan 13, 2015 at 6:46 AM, Jan Engelhardt wrote: > > > > > On Monday 2015-01-12 18:29, Tom Gundersen wrote: > > >> In systemd-218, I have configured the following testcase: > > >> > > >> /etc/systemd/network# ls -al > > >> total 20 > > >> drwxr-xr-x 2 root root 4096 Jan 11 18:14 . > > >> drwxr-xr-x 5 root root 4096 Jan 11 16:23 .. > > >> -rw-r--r-- 1 root root 96 Jan 11 18:14 99a-ether.link > > > > > >Hm, isn't this just a problem of 99a-ether.link being ordered after > > >99-default.link? > > > > Well, the manpage states: "All link files are collectively > > sorted and processed in lexical order", with that, I would assume > > that 99a, being processed after 99, would override 99. > > > > >It works for me when naming it 98-ether.link instead. > > > > Not in my case. I have a feeling networkd won't touch > > [08:00:27:0a:c5:b2]'s interface name because it has already > > been named by udev to enp0s3 before networkd got a chance to run. > > Could that be it? Note that networkd doesn't rename interfaces, only udev does. udev implements .link processing, nothing else. > I'm having a similar problem while running systemd version-219. Did you > work out what was wrong? Maybe this is debian and the saving of interface names is still in place? > # cat /etc/systemd/network/01-mgmt.link > [Match] > Path=pci-:01:00.0 > Type=ether > > [Link] > Name=mgmt > MACAddressPolicy=persistent Consider testing the .link file with "udevadm test-builtin net_setup_link..." 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] udev interface naming for SR-IOV VFs
On Tue, Apr 14, 2015 at 12:11 PM, Ido Barkan wrote: > Hi all, > > I am VDSM developer in the Ovirt project. > > We are implementing support for SR-IOV network cards. Afer the changing of > the number of VFs on the card and programmatically querying for all links > (we use libnl for this) we observe that *during the iteration* over the links > some of them were renamed by udev and still were not. Meanning, some of them > are called 'ethN' and some are called 'enp2sNf2' (where N is an arbitrary > number). Also, there are times that not all of the devices are returned from > libnl. > After a _while_ everything stabilizes (# of interfaces and names). > > My questions: > 1. Is this what you would expect from udev? Meaning, this is just async > behavior? Udev has no specific knowledge, there is nothing really it could provide here. > 2. Is there a way to _know_ programmticaly that everything was probed and > renamed? >Not a heuristic? Only if you know which devices to expect and listen to udev monitor events when they appear and react to them. The device handling is finished before the event is sent out. Udev generally has no idea when things have been probed or what to wait for. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket activation of container with private network
On Fri, 17.04.15 23:27, sba...@catern.com (sba...@catern.com) wrote: > Hi, > > I am having trouble with socket-activated containers, where the socket > is first opened outside the container, on an interface/IP address that > is then passed in to the container. > > In short, when I try to ssh to the IP address of the container, the > container is indeed activated as it should be, but ssh fails with: > > Read from socket failed: Connection reset by peer > > I believe this is due to the ssh connection successfully starting then > being interrupted by something unknown before it can prompt for a > password, but not sure what this unknown thing is - systemd, networking > setup, something else? > > In more detail, I have a script, interface-setup.sh, to create a > veth. (Contents of the script are at the end of this email.) One end of > the veth is added to a bridge, and the other end gets an IPv6 > address. That end will be sent into the container. Outside of the > container, I bind to that address with the following .socket unit. Hmm, so you say the initial connection does not work but triggers the container, but the subsequent one will? This is indication that systemd inside the container does not properly adopt the socket passed in. Can you try to make this work first without using private networking in the container? i.e. just listen on the port on the host, and pass it into the container without using any networking related switches on the nspawn cmdline. After making that work it makes sense to go to the next step. 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] SD_BUS_VTABLE_CAPABILITY
On Apr 20, 2015 9:07 AM, "Lennart Poettering" wrote: > > On Mon, 20.04.15 08:51, Andy Lutomirski (l...@amacapital.net) wrote: > > > > > > I will grant you that they aren't particularly expressive, and I will > > > > > grant you that one day there might be better concepts. But that's not > > > > > a strong reason not to support them really, that's just a reason to > > > > > later add support for something better. > > > > > > > > Technical reasons: > > > > > > > > 1. They can't be usefully delegated to a namespace. > > > > > > Not sure I can parse that. If you use the bus to communicate across > > > namespace boundaries then each side lacks caps for the other. Great, > > > that's how it should be. And same as for uid checks btw... if a uid > > > cannot be translated, then it will not be passed! > > > > No. You're right for nspawn-style namespaces, but not for namespaces more > > broadly. Namespaces are a great way to drop various privileges, but your > > use of caps prevents certain uses (e.g. confining your hypothetical > > time-setting daemon in a namespace). > > I have seen no use of userns for sandboxing normal daemons so far. I > have seen tons of daemons using caps for such sandboxing. Sandstorm.io I bet Chromium will follow suit, and don't forget Docker and similar tools. > > maybe if userns in its current iteration doesn't mix as well as you'd > like it with caps this is indication that userns might need some more > polish, and not that caps are necessarily the bad guy here? > Nope, userns works just fine. > I mean, as the one who added most of the sandboxing features we expose > in systemd .service files currently (including things like > ReadOnlyDirectories=, PrviateTmp=, PrivateNetwork= which are all based > on kernel namespacing), I completely fail to see how we could even > expose user namespace like this in a good way that would hold water? > Capability-based sandboxing on the other hand is much easier to > handle, and in many cases a highly efficient way to sandbox stuff. Two > examples: There's a world outside systemd and, in that world, programs would like to be able to sandbox themselves. Userns is wonderful for that purpose. > > systemd-networkd drops privileges, becomes the "systemd-network" > user, only retains CAP_NET_ADMIN. That's actually already a really > good sandbox! > > systemd-timesyncd drops privileges, becomes the "systemd-timesync" > user, only retains CAP_SYS_TIME. And that's actually a really good > sandbox too! > > Both daemons are network facing, hence sandboxing things like this is > actually of quite some importance, and it *works*! Today! And it is > easy! easy enough for most administrators to grok it easily! And > because of that it is actually *good* security! Except that if it's too coarse-gained, it fails to actually separate privileges. > > And please don't discount these two daemons as irrelevant > examples. They are highly relevant, since they run on a good chunk of > Linux systems, as one of the few daemons that run really everywhere. > > Caps *do* have good uses, please don't claim otherwise. They are a > *lot* more relevant on today's system than userns at least! > > (Note that I am not saying that userns are really a bad idea or so, I > just would like to ask you to keep things in perspective: caps are > *good* -- even though they could be much better. And they are a ton > more useful and used than userns right now) > > > > OK, they are not very expressive, I granted you that already. But they > > > are still more expressive than "uid == 0". > > > > > > That they are not expressive is something I can agree with, as > > > mentioned above, but I don't consider this a real issue not to using > > > them. I mean, it would be great if we had something better in the > > > kernel, like capsicum or whatever, but we don't. And since caps are > > > pretty well supported otherwise on Linux, and they are better then > > > simple uid == 0 checks, I think they should be supported by kdbus too. > > > > This is a bad excuse. Given that you're designing something new, you have > > plenty of room to do better. > > We are not really in the business in designing comprehensive new > access control systems that can be used for in-kernel and in-userspace > subsystems. > > Sure, we also have bus policy, but that given it's non-interactive > logic it's not really suitable for the uses where we need uid or caps > checks, i.e. dynamic access control within called methods that need to > check different privileges dynamically. > > 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] SD_BUS_VTABLE_CAPABILITY
On Mon, 20.04.15 08:51, Andy Lutomirski (l...@amacapital.net) wrote: > > > > I will grant you that they aren't particularly expressive, and I will > > > > grant you that one day there might be better concepts. But that's not > > > > a strong reason not to support them really, that's just a reason to > > > > later add support for something better. > > > > > > Technical reasons: > > > > > > 1. They can't be usefully delegated to a namespace. > > > > Not sure I can parse that. If you use the bus to communicate across > > namespace boundaries then each side lacks caps for the other. Great, > > that's how it should be. And same as for uid checks btw... if a uid > > cannot be translated, then it will not be passed! > > No. You're right for nspawn-style namespaces, but not for namespaces more > broadly. Namespaces are a great way to drop various privileges, but your > use of caps prevents certain uses (e.g. confining your hypothetical > time-setting daemon in a namespace). I have seen no use of userns for sandboxing normal daemons so far. I have seen tons of daemons using caps for such sandboxing. maybe if userns in its current iteration doesn't mix as well as you'd like it with caps this is indication that userns might need some more polish, and not that caps are necessarily the bad guy here? I mean, as the one who added most of the sandboxing features we expose in systemd .service files currently (including things like ReadOnlyDirectories=, PrviateTmp=, PrivateNetwork= which are all based on kernel namespacing), I completely fail to see how we could even expose user namespace like this in a good way that would hold water? Capability-based sandboxing on the other hand is much easier to handle, and in many cases a highly efficient way to sandbox stuff. Two examples: systemd-networkd drops privileges, becomes the "systemd-network" user, only retains CAP_NET_ADMIN. That's actually already a really good sandbox! systemd-timesyncd drops privileges, becomes the "systemd-timesync" user, only retains CAP_SYS_TIME. And that's actually a really good sandbox too! Both daemons are network facing, hence sandboxing things like this is actually of quite some importance, and it *works*! Today! And it is easy! easy enough for most administrators to grok it easily! And because of that it is actually *good* security! And please don't discount these two daemons as irrelevant examples. They are highly relevant, since they run on a good chunk of Linux systems, as one of the few daemons that run really everywhere. Caps *do* have good uses, please don't claim otherwise. They are a *lot* more relevant on today's system than userns at least! (Note that I am not saying that userns are really a bad idea or so, I just would like to ask you to keep things in perspective: caps are *good* -- even though they could be much better. And they are a ton more useful and used than userns right now) > > OK, they are not very expressive, I granted you that already. But they > > are still more expressive than "uid == 0". > > > > That they are not expressive is something I can agree with, as > > mentioned above, but I don't consider this a real issue not to using > > them. I mean, it would be great if we had something better in the > > kernel, like capsicum or whatever, but we don't. And since caps are > > pretty well supported otherwise on Linux, and they are better then > > simple uid == 0 checks, I think they should be supported by kdbus too. > > This is a bad excuse. Given that you're designing something new, you have > plenty of room to do better. We are not really in the business in designing comprehensive new access control systems that can be used for in-kernel and in-userspace subsystems. Sure, we also have bus policy, but that given it's non-interactive logic it's not really suitable for the uses where we need uid or caps checks, i.e. dynamic access control within called methods that need to check different privileges dynamically. 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] SD_BUS_VTABLE_CAPABILITY
On April 20, 2015 8:39:33 AM PDT, Lennart Poettering wrote: >On Fri, 17.04.15 08:52, Josh Triplett (j...@joshtriplett.org) wrote: > >> On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote: >> > Now, to put together a more complex scenario for you: consider a >small >> > web UI that can be used to set the system time. It should realy run >at >> > minimal privileges, after all it has a surface to the web. Hence >you >> > write it as daemon, make it run as a user id of its own, set up a >> > chroot() or a file system namespace, but you do keep CAP_SYS_TIME >and >> > a bus connection open. With that setup the web daemon can pretty >much >> > only set the system clock, and if it exploited cannot be used for >much >> > else. It will not have access to /dev/rtc, due to the file system >> > namespace, but it can nicely set the system clock via timedated >still, >> > and pretty much only that, and the clock will be synced to the RTC >by >> > it. >> > >> > To map this back to your earlier request for an example. In this >case >> > process A is the web UI daemon. Capability B is CAP_SYS_TIME. >Message >> > C is the SetTime() bus call. Daemon D is timedated. >> > >> > If the web UI daemon would not have CAP_SYS_TIME it couldn't change >> > the time like this -- unless of course that web UI daemon would run >as >> > UID 0 all the time, which is certainly much much less desirable, >given >> > that it is a network facing daemon. >> >> I agree with your statement that any process with the ability to do >an >> operation directly (bypassing systemd) should have the ability to do >so >> safely through systemd. However, that doesn't provide a complete >> solution, because the reverse shouldn't necessarily be true: it >should >> be possible to grant a process the ability to do an operation safely >> through systemd *without* granting it permission to do so directly. > >yeah, for that side we have polkit. > >> Now, I can still see the value in saying "if you have permission to >do >> the unsafe thing directly, you can do the safe thing". However, that >> seems like an optional enhancement, rather than core required >> functionality to make sane use of (k)dbus. kdbus without the >> capability-passing mechanism still seems like a wildly useful >> enhancement. > >Well, sure, I mean, the caps stuff are *not* essential to kdbus' mode >of operation. But I do believe they make the system better, and should >be used preferably over broad uid == 0 checks. I'd certainly agree that uid 0 checks are a bad idea, since as little code should run as root as possible. However, rather than handing out capabilities that allow bypassing systemd and talking directly to the kernel, it seems preferable to run unprivileged and grant the necessary permissions to that process. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On Apr 20, 2015 8:22 AM, "Lennart Poettering" wrote: > > On Mon, 20.04.15 08:08, Andy Lutomirski (l...@amacapital.net) wrote: > > > On Apr 20, 2015 7:57 AM, "Lennart Poettering" > > wrote: > > > > > > On Fri, 17.04.15 09:14, Andy Lutomirski (l...@amacapital.net) wrote: > > > > > > > My point here is that there's no real shortage of downsides to this > > > > scheme, and there still appears to be little to no benefit. > > > > > > Well, let's turn this around. You seem to really dislike caps. And you > > > vaguely claim security holes, which we have shown know don't > > > exist. So, now, can you clearly explain why precisely you dislike them > > > so much still? And something more technical then "systemd shouldn't > > > use them" or "i don't like them", or "they should only be used in the > > > kernel", because these are not technical reasons, they are just claims > > > of personal taste. > > > > > > I will grant you that they aren't particularly expressive, and I will > > > grant you that one day there might be better concepts. But that's not > > > a strong reason not to support them really, that's just a reason to > > > later add support for something better. > > > > Technical reasons: > > > > 1. They can't be usefully delegated to a namespace. > > Not sure I can parse that. If you use the bus to communicate across > namespace boundaries then each side lacks caps for the other. Great, > that's how it should be. And same as for uid checks btw... if a uid > cannot be translated, then it will not be passed! No. You're right for nspawn-style namespaces, but not for namespaces more broadly. Namespaces are a great way to drop various privileges, but your use of caps prevents certain uses (e.g. confining your hypothetical time-setting daemon in a namespace). > > > 2. The set of caps that exist is controlled by the kernel, whereas the set > > of dbus methods is large and controlled by userspace. Caps can't scale to > > accommodate flexble userspace policies. > > OK, they are not very expressive, I granted you that already. But they > are still more expressive than "uid == 0". > > That they are not expressive is something I can agree with, as > mentioned above, but I don't consider this a real issue not to using > them. I mean, it would be great if we had something better in the > kernel, like capsicum or whatever, but we don't. And since caps are > pretty well supported otherwise on Linux, and they are better then > simple uid == 0 checks, I think they should be supported by kdbus too. This is a bad excuse. Given that you're designing something new, you have plenty of room to do better. > > > 3. They don't appear to add value, and avoiding unnecessary complexity is > > good. > > Well, I disagree on this. I think they are better because more > fine-grained than "uid == 0" checks. > > > 4. They suck. This is a technical issue -- the kernel doesn't allow > > flexible assignments of caps to processes. This is a problem for kernel > > API users and it will be a problem for you. > > Not a technical reason, unlike you claim. Just a personal taste issue. Sure it is. Caps are defined in the kernel sources and, as seems to have been covered pretty well in this thread, the list of caps is very far from what a userspace dbus service would want to check. --Andy > > Honestly, I don't think the issues you raise are very convincing > > 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] Failed to create directory or subvolume "/var/lib/machines": Invalid argument
On Thu, 16.04.15 18:48, Andrey Wagin (ava...@gmail.com) wrote: > Hello Lennart, > > I read the v218-283-gd7b8eec commit and found that you expected that > BTRFS_IOC_SUBVOL_CREATE returns ENOTTY if sub-volumes are not > supported. But in the compat-mode this ioctl returns EINVAL. > > For example: > ext4_compat_ioctl returns ENOIOCTLCMD, then vfs_ioctl() convert it into > EINVAL. > vfs_ioctl() > error = filp->f_op->unlocked_ioctl(filp, cmd, arg); > if (error == -ENOIOCTLCMD) > error = -EINVAL; > > root@localhost:~# /bin/systemd-tmpfiles --create --remove --boot > --exclude-prefix=/dev > [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", > ignoring. > Failed to create directory or subvolume "/var/lib/machines": Invalid argument Hmm, is this the 32bit ioctl glue that makes 32bit userspace work with a 64bit kernel? If the kernel doesn't translate the ioctls correctly in this case and turns this into -EINVAL, shouldn't it be fixed in the kernel? It appears pretty obvious to me that this should be fixed in the kernel to ensure that 32bit and 64bit userspace both get the same error in these cases, and that should be ENOTTY... Could you file a bug on kernel bugzilla about this please? 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] SD_BUS_VTABLE_CAPABILITY
On Fri, 17.04.15 08:52, Josh Triplett (j...@joshtriplett.org) wrote: > On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote: > > Now, to put together a more complex scenario for you: consider a small > > web UI that can be used to set the system time. It should realy run at > > minimal privileges, after all it has a surface to the web. Hence you > > write it as daemon, make it run as a user id of its own, set up a > > chroot() or a file system namespace, but you do keep CAP_SYS_TIME and > > a bus connection open. With that setup the web daemon can pretty much > > only set the system clock, and if it exploited cannot be used for much > > else. It will not have access to /dev/rtc, due to the file system > > namespace, but it can nicely set the system clock via timedated still, > > and pretty much only that, and the clock will be synced to the RTC by > > it. > > > > To map this back to your earlier request for an example. In this case > > process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message > > C is the SetTime() bus call. Daemon D is timedated. > > > > If the web UI daemon would not have CAP_SYS_TIME it couldn't change > > the time like this -- unless of course that web UI daemon would run as > > UID 0 all the time, which is certainly much much less desirable, given > > that it is a network facing daemon. > > I agree with your statement that any process with the ability to do an > operation directly (bypassing systemd) should have the ability to do so > safely through systemd. However, that doesn't provide a complete > solution, because the reverse shouldn't necessarily be true: it should > be possible to grant a process the ability to do an operation safely > through systemd *without* granting it permission to do so directly. yeah, for that side we have polkit. > Now, I can still see the value in saying "if you have permission to do > the unsafe thing directly, you can do the safe thing". However, that > seems like an optional enhancement, rather than core required > functionality to make sane use of (k)dbus. kdbus without the > capability-passing mechanism still seems like a wildly useful > enhancement. Well, sure, I mean, the caps stuff are *not* essential to kdbus' mode of operation. But I do believe they make the system better, and should be used preferably over broad uid == 0 checks. 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] Problem with intermediate target
On Thu, 16.04.15 17:10, Christoph Pleger (christoph.ple...@cs.tu-dortmund.de) wrote: > Hello, > > I wrote: > > >> Sounds like you want to create intermediate.target, change > >> default.target to point at it, boot all the way up to > >> intermediate.target, and at that point isolate or start > >> multi-user.target. > > > I chose that solution, because from all possible solutions for the > > desired boot order, it seems to be the one which is closest to my idea. > > After setting intermediate.target as default target and defining a service > belonging to intermediate.target that switches to graphical.target, I > discovered the following (which does not happen when graphical.target is > the default target): > > With the package pidentd installed, which does not bring a .service file, > but only an init script that wants to create a directory /var/run/identd, > at boot time some error messages appear on the screen that /var is not > writable. Obviously, /var is not mounted yet when the script is executed. > After booting, this is the content > of/run/systemd/generator.late/pidentd.service: > > # Automatically generated by systemd-sysv-generator > > [Unit] > SourcePath=/etc/init.d/pidentd > Description=LSB: setup for pidentd > DefaultDependencies=no > Before=sysinit.target > After=remote-fs.target Are you using a Debian-derived distro? We explicitly dont support early-boot sysv scripts upstream, because they are unworkable. I know that Debian patches support for this back in, but that's on them. Please ask the Debian guys for help with this. Early-boot sysv scripts are something we explicitly removed support for years ago, for a good reason. If your distro supports this anyway, they need to care for 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] systemd and process migration
On Mon, 20.04.15 15:10, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > On 04/20/2015 02:49 PM, Lennart Poettering wrote: > >On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > > I thought fancy enterprise features like this was on hold until networkd > was > "ready" ? > >>>This is not an enterprise feature. It's a promise one cannot keep. We > >>>will not add code to systemd that works often but not always, and CRIU > >>>is certainly of that kind. > >>"We will not add code to systemd that works often but not always" you need > >>to explain this a bit further since we might have different perception on > >>this since from my perception such code has been added to systemd in more > >>then one occasion anyway I was not advocating for the use/inclusion of CRIU > >>but something built in. > >> > >>We should be able to support non live migration out of the box if live > >>migration is a pandora's box or are you opposed to that as well? > >Well, sure, it would be nice, but I also believe it is not realistic > >to support. For example, if you have network protocols you can > >probably still live with their connections being severed during > >migration, but this is really not the case for local IPC connections, > >like bus connections. Restoring the state for that is an immense > >amount of work, and I am pretty sure that it is not desirable to add > >code for this to all IPC systems like this just because of CRIU. > > > >Also, I doubt this really is such an important thing to have. I mean, > >containers are not VMs, they are easily instantiated and shut > >down. You can socket actviate them, and have them exit-on-idle. If you > >accept that containers are a much more volatile, dynamic thing that > >VMs then live migration becomes much less attractive. > > There are valid migration cases beside live migration ones ( for example > reallocation to a different host(s) due to resources etc ) > > Think in terms of shutting down and disable container on host A, send > relevant units ( including any network related ones ) along with the > underlying filesystem snapshot, in the case of btrfs it would be using btrfs > send/receive feature to host B and start it there. > > What I'm wondering if you would be opposed to supporting those use cases ? Well, but non-live migration is easy: you simply stop the container, transfer the container tree to the destination, and start it there again. We support migrating offline containers like that already to a certain degree with "machinectl export-tar" and "machinectl import-tar". And we probably could even add more support for this, for example I think a "machinectl migrate" command would make a lot of sense that basically connects a local "machinectl export-tar" with a "machinectl import-tar" on another host via ssh. I'd be totally on board with adding more support for things like that. It's really just the *live* migration part I have issues with, because I don't trust we could deliver the promise it makes. 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] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On 04/21/2015 12:10 AM, Lennart Poettering wrote: > On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote: > >> If a service does not consume CPU during some time(can be configured >> by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the >> service will be stopped. This can be useful if the service provides >> some of activation methods. > > Hmm, I am not convinced this would be a good idea, sorry. > > The crux of the issue is that it is really hard to detect from the > outside if a daemon is really idle. Only the daemon itself knows > whether it is truly idle or not. I mean, it could just be waiting for > some timer to elapse, or some other external event. > > I doubt this is really useful unless you have really really simple > daemons that purely react on client requests and nothing else, and you > know the codebase and that it is OK to terminate the daemon just > because its CPU usage is zero. But if you know the codebase that well > it would probably be a better idea to just add support for > exit-on-idle directly to the daemon in question. That's why I sent with [RFC] prefix. :) Thanks for reply. WaLyong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On Mon, 20.04.15 08:08, Andy Lutomirski (l...@amacapital.net) wrote: > On Apr 20, 2015 7:57 AM, "Lennart Poettering" > wrote: > > > > On Fri, 17.04.15 09:14, Andy Lutomirski (l...@amacapital.net) wrote: > > > > > My point here is that there's no real shortage of downsides to this > > > scheme, and there still appears to be little to no benefit. > > > > Well, let's turn this around. You seem to really dislike caps. And you > > vaguely claim security holes, which we have shown know don't > > exist. So, now, can you clearly explain why precisely you dislike them > > so much still? And something more technical then "systemd shouldn't > > use them" or "i don't like them", or "they should only be used in the > > kernel", because these are not technical reasons, they are just claims > > of personal taste. > > > > I will grant you that they aren't particularly expressive, and I will > > grant you that one day there might be better concepts. But that's not > > a strong reason not to support them really, that's just a reason to > > later add support for something better. > > Technical reasons: > > 1. They can't be usefully delegated to a namespace. Not sure I can parse that. If you use the bus to communicate across namespace boundaries then each side lacks caps for the other. Great, that's how it should be. And same as for uid checks btw... if a uid cannot be translated, then it will not be passed! > 2. The set of caps that exist is controlled by the kernel, whereas the set > of dbus methods is large and controlled by userspace. Caps can't scale to > accommodate flexble userspace policies. OK, they are not very expressive, I granted you that already. But they are still more expressive than "uid == 0". That they are not expressive is something I can agree with, as mentioned above, but I don't consider this a real issue not to using them. I mean, it would be great if we had something better in the kernel, like capsicum or whatever, but we don't. And since caps are pretty well supported otherwise on Linux, and they are better then simple uid == 0 checks, I think they should be supported by kdbus too. > 3. They don't appear to add value, and avoiding unnecessary complexity is > good. Well, I disagree on this. I think they are better because more fine-grained than "uid == 0" checks. > 4. They suck. This is a technical issue -- the kernel doesn't allow > flexible assignments of caps to processes. This is a problem for kernel > API users and it will be a problem for you. Not a technical reason, unlike you claim. Just a personal taste issue. Honestly, I don't think the issues you raise are very convincing 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] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Mon, 20.04.15 23:56, WaLyong Cho (walyong@samsung.com) wrote: > If a service does not consume CPU during some time(can be configured > by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the > service will be stopped. This can be useful if the service provides > some of activation methods. Hmm, I am not convinced this would be a good idea, sorry. The crux of the issue is that it is really hard to detect from the outside if a daemon is really idle. Only the daemon itself knows whether it is truly idle or not. I mean, it could just be waiting for some timer to elapse, or some other external event. I doubt this is really useful unless you have really really simple daemons that purely react on client requests and nothing else, and you know the codebase and that it is OK to terminate the daemon just because its CPU usage is zero. But if you know the codebase that well it would probably be a better idea to just add support for exit-on-idle directly to the daemon in question. exit-on-idle is really something that should be implemented *in* the daemon, and not done externally! Sorry, 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 and process migration
On 04/20/2015 02:49 PM, Lennart Poettering wrote: On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: I thought fancy enterprise features like this was on hold until networkd was "ready" ? This is not an enterprise feature. It's a promise one cannot keep. We will not add code to systemd that works often but not always, and CRIU is certainly of that kind. "We will not add code to systemd that works often but not always" you need to explain this a bit further since we might have different perception on this since from my perception such code has been added to systemd in more then one occasion anyway I was not advocating for the use/inclusion of CRIU but something built in. We should be able to support non live migration out of the box if live migration is a pandora's box or are you opposed to that as well? Well, sure, it would be nice, but I also believe it is not realistic to support. For example, if you have network protocols you can probably still live with their connections being severed during migration, but this is really not the case for local IPC connections, like bus connections. Restoring the state for that is an immense amount of work, and I am pretty sure that it is not desirable to add code for this to all IPC systems like this just because of CRIU. Also, I doubt this really is such an important thing to have. I mean, containers are not VMs, they are easily instantiated and shut down. You can socket actviate them, and have them exit-on-idle. If you accept that containers are a much more volatile, dynamic thing that VMs then live migration becomes much less attractive. There are valid migration cases beside live migration ones ( for example reallocation to a different host(s) due to resources etc ) Think in terms of shutting down and disable container on host A, send relevant units ( including any network related ones ) along with the underlying filesystem snapshot, in the case of btrfs it would be using btrfs send/receive feature to host B and start it there. What I'm wondering if you would be opposed to supporting those use cases ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On Apr 20, 2015 7:57 AM, "Lennart Poettering" wrote: > > On Fri, 17.04.15 09:14, Andy Lutomirski (l...@amacapital.net) wrote: > > > My point here is that there's no real shortage of downsides to this > > scheme, and there still appears to be little to no benefit. > > Well, let's turn this around. You seem to really dislike caps. And you > vaguely claim security holes, which we have shown know don't > exist. So, now, can you clearly explain why precisely you dislike them > so much still? And something more technical then "systemd shouldn't > use them" or "i don't like them", or "they should only be used in the > kernel", because these are not technical reasons, they are just claims > of personal taste. > > I will grant you that they aren't particularly expressive, and I will > grant you that one day there might be better concepts. But that's not > a strong reason not to support them really, that's just a reason to > later add support for something better. Technical reasons: 1. They can't be usefully delegated to a namespace. 2. The set of caps that exist is controlled by the kernel, whereas the set of dbus methods is large and controlled by userspace. Caps can't scale to accommodate flexble userspace policies. 3. They don't appear to add value, and avoiding unnecessary complexity is good. 4. They suck. This is a technical issue -- the kernel doesn't allow flexible assignments of caps to processes. This is a problem for kernel API users and it will be a problem for you. --Andy > > 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] SD_BUS_VTABLE_CAPABILITY
On Fri, 17.04.15 13:43, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: > On 16/04/15 15:52, Andy Lutomirski wrote: > > (I really think this dichotomy > > needs to be removed, *especially* since it looks like code already > > exists to try to use both metadata sources. This seems like it's just > > asking for security screw-ups.) > > Would it address this concern if there was an explicit API separation > into "things that can't be faked, suitable for authorization" and > "things that could have been faked, only suitable for debugging" - such > that the uid would be in the first set only, capabilities would be in > the first set on kdbus but absent or in the second set on traditional > D-Bus, and /proc/*/cmdline would always be in the second set? Note that sd-bus exposes an sd_bus_creds API that collects credentials about bus peers. And it by default only includes credentials that can be acquired without races. To augment the data with stuff from /proc you need to pass a special flag (SD_BUS_CREDS_AUGMENT) that it basically the developer's opt-in to saying "I know this is racy, but I want the data anyway". I also prepared a patch that keeps a mask in the object that can be queried later on that will tell you if the data was acquired via this race-ful augmentation from /proc, or can be trusted. I will then update systemd's code to explicitly check this mask, as an extra safety net, and to make explicit in code what we require for authentication and what not. > That's effectively what dbus-daemon has internally: for each > DBusConnection (which in practice wraps an AF_UNIX socket), it tracks > the uid, the pid, and in recent versions the LSM label (all taken from > getsockopt results), and a "log info" string (derived from /proc/$pid). > > The "log info" is mentioned in the syslog message when something is > denied, but is not used for authentication, and is not made available to > dbus-daemon's clients such as polkit. Yeah, it's pretty close to what we exose in sd-bus in that regard. 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 2/3] journal: use audit event names instead of numbers
On Mon, 20.04.15 14:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Mon, Apr 20, 2015 at 04:43:20PM +0200, Lennart Poettering wrote:
> > On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> > wrote:
> >
> > > +const char *audit_type_name(int type,
> > > +char buf[AUDIT_NAME_BUF_SIZE]) {
> > > +const char *s;
> > > +
> > > +s = audit_type_to_string(type);
> > > +if (s)
> > > +return s;
> > > +
> > > +/* This is inspired by DNS TYPEnnn formatting */
> > > +snprintf(buf, AUDIT_NAME_BUF_SIZE, "AUDIT%04i", type);
> > > +return buf;
> >
> > Shouldn't we stick to at least, to stay congruent to what
> > we so far did, at least for the unknown ones?
> I thought the visual difference between the capitalized names and what we
> used so far is too big: e.g. ADD_USER and , and it is better
> to have something visually similar at least.
Hmm, I see. You do have a point, hence go ahead.
> > Also, may turn this into a macro expression using ({}) that returns
> > this as alloca() allocated string?
>
> You mean the whole function? I'll try that. The only downside is it
> cannot be called directly in the args to another function.
Yeah, the whole function.
Make sure to name this in a way that it is clear that this is an
alloca()-based macro, by including an _alloca() suffix or so?
Also see procfs_file_alloca() or inspiration.
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] Zombie process still exists after stopping gdm.service
On Mon, 20.04.15 08:54, Daniel Drake (dr...@endlessm.com) wrote: > gdm git does have KillMode=mixed, but the slightly old gdm I'm running > here also does not have any KillMode assignment. KillMode=mixed means that systemd will SIGKILL all cgroup member processes before "stop" returns. > > I'm investigating further at the moment. I've found a mistake in what > I wrote earlier - when gdm receives SIGTERM it *does* do a > kill/waitpid() on the child X server. > However the process seems to disappear before waitpid() returns - > currently trying to understand why. Ideas welcome. maybe the main gdm process is not the one waiting, but a worker process is, and the main process kills the worker process without the worker process handling that nicely? 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 2/3] journal: use audit event names instead of numbers
On Mon, Apr 20, 2015 at 04:43:20PM +0200, Lennart Poettering wrote:
> On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > +const char *audit_type_name(int type,
> > +char buf[AUDIT_NAME_BUF_SIZE]) {
> > +const char *s;
> > +
> > +s = audit_type_to_string(type);
> > +if (s)
> > +return s;
> > +
> > +/* This is inspired by DNS TYPEnnn formatting */
> > +snprintf(buf, AUDIT_NAME_BUF_SIZE, "AUDIT%04i", type);
> > +return buf;
>
> Shouldn't we stick to at least, to stay congruent to what
> we so far did, at least for the unknown ones?
I thought the visual difference between the capitalized names and what we
used so far is too big: e.g. ADD_USER and , and it is better
to have something visually similar at least.
> Also, may turn this into a macro expression using ({}) that returns
> this as alloca() allocated string?
You mean the whole function? I'll try that. The only downside is it
cannot be called directly in the args to another function.
> > +}
> > diff --git src/journal/audit-type.h src/journal/audit-type.h
> > index 9f37716cd6..a2c98cee80 100644
> > --- src/journal/audit-type.h
> > +++ src/journal/audit-type.h
> > @@ -21,6 +21,11 @@
> >along with systemd; If not, see
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
This will be nice to have.
On Mon, Apr 20, 2015 at 10:56 AM WaLyong Cho
wrote:
> If a service does not consume CPU during some time(can be configured
> by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the
> service will be stopped. This can be useful if the service provides
> some of activation methods.
> ---
> src/core/load-fragment-gperf.gperf.m4 | 2 +
> src/core/service.c| 97
> +++
> src/core/service.h| 5 ++
> src/core/unit.h | 1 +
> 4 files changed, 105 insertions(+)
>
> diff --git a/src/core/load-fragment-gperf.gperf.m4
> b/src/core/load-fragment-gperf.gperf.m4
> index 5305984..60d573e 100644
> --- a/src/core/load-fragment-gperf.gperf.m4
> +++ b/src/core/load-fragment-gperf.gperf.m4
> @@ -229,6 +229,8 @@ Service.BusName,
> config_parse_bus_name, 0,
> Service.FileDescriptorStoreMax, config_parse_unsigned, 0,
>offsetof(Service, n_fd_store_max)
> Service.NotifyAccess,config_parse_notify_access, 0,
>offsetof(Service, notify_access)
> Service.Sockets, config_parse_service_sockets, 0,
>0
> +Service.ExitOnIdle, config_parse_bool, 0,
>offsetof(Service, exit_on_idle)
> +Service.ExitOnIdleSec, config_parse_sec, 0,
>offsetof(Service, exit_on_idle_usec)
> m4_ifdef(`ENABLE_KDBUS',
> `Service.BusPolicy, config_parse_bus_endpoint_policy, 0,
>offsetof(Service, exec_context)',
> `Service.BusPolicy, config_parse_warn_compat,
> DISABLED_EXPERIMENTAL, 0')
> diff --git a/src/core/service.c b/src/core/service.c
> index fa818fc..c8752ae 100644
> --- a/src/core/service.c
> +++ b/src/core/service.c
> @@ -91,6 +91,7 @@ static const UnitActiveState
> state_translation_table_idle[_SERVICE_STATE_MAX] =
> static int service_dispatch_io(sd_event_source *source, int fd, uint32_t
> events, void *userdata);
> static int service_dispatch_timer(sd_event_source *source, usec_t usec,
> void *userdata);
> static int service_dispatch_watchdog(sd_event_source *source, usec_t
> usec, void *userdata);
> +static int service_dispatch_exit_on_idle_timer(sd_event_source *source,
> usec_t usec, void *userdata);
>
> static void service_enter_signal(Service *s, ServiceState state,
> ServiceResult f);
> static void service_enter_reload_by_notify(Service *s);
> @@ -108,6 +109,8 @@ static void service_init(Unit *u) {
> s->socket_fd = -1;
> s->bus_endpoint_fd = -1;
> s->guess_main_pid = true;
> +s->exit_on_idle = false;
> +s->exit_on_idle_usec = 0;
>
> RATELIMIT_INIT(s->start_limit,
> u->manager->default_start_limit_interval,
> u->manager->default_start_limit_burst);
>
> @@ -279,6 +282,56 @@ static void service_release_resources(Unit *u) {
> assert(s->n_fd_store == 0);
> }
>
> +static void service_stop_exit_on_idle_timer(Service *s) {
> +assert(s);
> +
> +s->exit_on_idle_event_source =
> sd_event_source_unref(s->exit_on_idle_event_source);
> +s->exit_on_idle_timestamp = DUAL_TIMESTAMP_NULL;
> +}
> +
> +static void service_start_exit_on_idle_timer(Service *s) {
> +int r;
> +
> +assert(s);
> +
> +if (s->exit_on_idle_usec <= 0)
> +return;
> +
> +if (s->exit_on_idle_event_source) {
> +r =
> sd_event_source_set_time(s->exit_on_idle_event_source,
> s->exit_on_idle_timestamp.monotonic + s->exit_on_idle_usec);
> +if (r < 0) {
> +log_unit_warning(UNIT(s)->id, "%s failed to reset
> exit-on-idle timer: %s", UNIT(s)->id, strerror(-r));
> +return;
> +}
> +
> +r =
> sd_event_source_set_enabled(s->exit_on_idle_event_source, SD_EVENT_ON);
> +} else {
> +r = sd_event_add_time(
> +UNIT(s)->manager->event,
> +&s->exit_on_idle_event_source,
> +CLOCK_MONOTONIC,
> +s->exit_on_idle_timestamp.monotonic +
> s->exit_on_idle_usec, 0,
> +service_dispatch_exit_on_idle_timer, s);
> +if (r < 0) {
> +log_unit_warning(UNIT(s)->id, "%s failed to add
> exit-on-idle timer: %s", UNIT(s)->id, strerror(-r));
> +return;
> +}
> +
> +r =
> sd_event_source_set_priority(s->exit_on_idle_event_source,
> SD_EVENT_PRIORITY_IDLE);
> +}
> +
> +if (r < 0)
> +log_unit_warning(UNIT(s)->id, "%s failed to install
> exit-on-idle timer: %s", UNIT(s)->id, strerror(-r));
> +return;
> +}
> +
> +static
Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY
On Fri, 17.04.15 09:14, Andy Lutomirski (l...@amacapital.net) wrote: > My point here is that there's no real shortage of downsides to this > scheme, and there still appears to be little to no benefit. Well, let's turn this around. You seem to really dislike caps. And you vaguely claim security holes, which we have shown know don't exist. So, now, can you clearly explain why precisely you dislike them so much still? And something more technical then "systemd shouldn't use them" or "i don't like them", or "they should only be used in the kernel", because these are not technical reasons, they are just claims of personal taste. I will grant you that they aren't particularly expressive, and I will grant you that one day there might be better concepts. But that's not a strong reason not to support them really, that's just a reason to later add support for something better. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
If a service does not consume CPU during some time(can be configured
by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the
service will be stopped. This can be useful if the service provides
some of activation methods.
---
src/core/load-fragment-gperf.gperf.m4 | 2 +
src/core/service.c| 97 +++
src/core/service.h| 5 ++
src/core/unit.h | 1 +
4 files changed, 105 insertions(+)
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 5305984..60d573e 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -229,6 +229,8 @@ Service.BusName, config_parse_bus_name,
0,
Service.FileDescriptorStoreMax, config_parse_unsigned, 0,
offsetof(Service, n_fd_store_max)
Service.NotifyAccess,config_parse_notify_access, 0,
offsetof(Service, notify_access)
Service.Sockets, config_parse_service_sockets, 0,
0
+Service.ExitOnIdle, config_parse_bool, 0,
offsetof(Service, exit_on_idle)
+Service.ExitOnIdleSec, config_parse_sec, 0,
offsetof(Service, exit_on_idle_usec)
m4_ifdef(`ENABLE_KDBUS',
`Service.BusPolicy, config_parse_bus_endpoint_policy, 0,
offsetof(Service, exec_context)',
`Service.BusPolicy, config_parse_warn_compat,
DISABLED_EXPERIMENTAL, 0')
diff --git a/src/core/service.c b/src/core/service.c
index fa818fc..c8752ae 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -91,6 +91,7 @@ static const UnitActiveState
state_translation_table_idle[_SERVICE_STATE_MAX] =
static int service_dispatch_io(sd_event_source *source, int fd, uint32_t
events, void *userdata);
static int service_dispatch_timer(sd_event_source *source, usec_t usec, void
*userdata);
static int service_dispatch_watchdog(sd_event_source *source, usec_t usec,
void *userdata);
+static int service_dispatch_exit_on_idle_timer(sd_event_source *source, usec_t
usec, void *userdata);
static void service_enter_signal(Service *s, ServiceState state, ServiceResult
f);
static void service_enter_reload_by_notify(Service *s);
@@ -108,6 +109,8 @@ static void service_init(Unit *u) {
s->socket_fd = -1;
s->bus_endpoint_fd = -1;
s->guess_main_pid = true;
+s->exit_on_idle = false;
+s->exit_on_idle_usec = 0;
RATELIMIT_INIT(s->start_limit,
u->manager->default_start_limit_interval,
u->manager->default_start_limit_burst);
@@ -279,6 +282,56 @@ static void service_release_resources(Unit *u) {
assert(s->n_fd_store == 0);
}
+static void service_stop_exit_on_idle_timer(Service *s) {
+assert(s);
+
+s->exit_on_idle_event_source =
sd_event_source_unref(s->exit_on_idle_event_source);
+s->exit_on_idle_timestamp = DUAL_TIMESTAMP_NULL;
+}
+
+static void service_start_exit_on_idle_timer(Service *s) {
+int r;
+
+assert(s);
+
+if (s->exit_on_idle_usec <= 0)
+return;
+
+if (s->exit_on_idle_event_source) {
+r = sd_event_source_set_time(s->exit_on_idle_event_source,
s->exit_on_idle_timestamp.monotonic + s->exit_on_idle_usec);
+if (r < 0) {
+log_unit_warning(UNIT(s)->id, "%s failed to reset
exit-on-idle timer: %s", UNIT(s)->id, strerror(-r));
+return;
+}
+
+r = sd_event_source_set_enabled(s->exit_on_idle_event_source,
SD_EVENT_ON);
+} else {
+r = sd_event_add_time(
+UNIT(s)->manager->event,
+&s->exit_on_idle_event_source,
+CLOCK_MONOTONIC,
+s->exit_on_idle_timestamp.monotonic +
s->exit_on_idle_usec, 0,
+service_dispatch_exit_on_idle_timer, s);
+if (r < 0) {
+log_unit_warning(UNIT(s)->id, "%s failed to add
exit-on-idle timer: %s", UNIT(s)->id, strerror(-r));
+return;
+}
+
+r = sd_event_source_set_priority(s->exit_on_idle_event_source,
SD_EVENT_PRIORITY_IDLE);
+}
+
+if (r < 0)
+log_unit_warning(UNIT(s)->id, "%s failed to install
exit-on-idle timer: %s", UNIT(s)->id, strerror(-r));
+return;
+}
+
+static void service_reset_exit_on_idle_timer(Service *s) {
+assert(s);
+
+dual_timestamp_get(&s->exit_on_idle_timestamp);
+service_start_exit_on_idle_timer(s);
+}
+
static void service_done(Unit *u) {
Service *s = SERVICE(u);
@@ -
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
On Mon, Apr 20, 2015 at 8:24 AM, Lennart Poettering wrote: > On Sun, 19.04.15 09:34, Andrei Borzenkov (arvidj...@gmail.com) wrote: > >> В Fri, 17 Apr 2015 14:04:18 -0600 >> Daniel Drake пишет: >> >> > Hi, >> > >> > I'm investigating why "systemctl stop gdm; Xorg" usually fails. The >> > new X process complains that X is still running. >> > >> > Here's what I think is happening: >> > >> > 1. systemd sends SIGTERM to gdm to stop the service >> > >> > 2. gdm exits - it has a simple SIGTERM handler which just quits the >> > mainloop without doing any cleanup (as far as I can see, it doesn't >> > make any attempt to kill the child X server) >> > >> > 3. X exits because of PR_SET_PDEATHSIG (i.e. it's set to be >> > automatically killed when the parent goes away). The killed process >> > enters defunct state and is reparented to PID 1, presumably also >> > moving it out of the gdm cgroup. >> > >> >> No, it remains in cgroup. Otherwise systemd service management would >> not be possible at all ... >> >> > 4. systemd notes that gdm's cgroup is empty and decides that gdm is >> > now successfully stopped. >> > >> >> I looked at display-manager.service here and it sets KillMode=process. >> That is better explanation to your observation. > > Hmm, it does? It does not on Fedora. Also "display-manager.service" is > just an alias to "gdm.service" on Fedora. > > Daniel, can you check with "systemctl cat gdm" what your distro > configures there? gdm git does have KillMode=mixed, but the slightly old gdm I'm running here also does not have any KillMode assignment. I'm investigating further at the moment. I've found a mistake in what I wrote earlier - when gdm receives SIGTERM it *does* do a kill/waitpid() on the child X server. However the process seems to disappear before waitpid() returns - currently trying to understand why. Ideas welcome. Thanks for the help. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and process migration
On Mon, 20.04.15 14:43, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > >>I thought fancy enterprise features like this was on hold until networkd was > >>"ready" ? > >This is not an enterprise feature. It's a promise one cannot keep. We > >will not add code to systemd that works often but not always, and CRIU > >is certainly of that kind. > > "We will not add code to systemd that works often but not always" you need > to explain this a bit further since we might have different perception on > this since from my perception such code has been added to systemd in more > then one occasion anyway I was not advocating for the use/inclusion of CRIU > but something built in. > > We should be able to support non live migration out of the box if live > migration is a pandora's box or are you opposed to that as well? Well, sure, it would be nice, but I also believe it is not realistic to support. For example, if you have network protocols you can probably still live with their connections being severed during migration, but this is really not the case for local IPC connections, like bus connections. Restoring the state for that is an immense amount of work, and I am pretty sure that it is not desirable to add code for this to all IPC systems like this just because of CRIU. Also, I doubt this really is such an important thing to have. I mean, containers are not VMs, they are easily instantiated and shut down. You can socket actviate them, and have them exit-on-idle. If you accept that containers are a much more volatile, dynamic thing that VMs then live migration becomes much less attractive. I am pretty sure you can make CRIU work for a lot of cases. But it's obvious that it will fail to save/restore a large number of cases, including any that involve dbus or any other non-trivial IPC (X11, PA, mysql connections, ...), hence it's really a promise you cannot keep, and I will not support something with systemd that is pretty obviously unsupportable. 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 3/3] journal: include user space audit types in the list
On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > +audit_list_includes = -include linux/audit.h > +if HAVE_AUDIT > +audit_list_includes += -include libaudit.h > +endif > And missing.h too here, please (as mentioned in the other review) 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 2/3] journal: use audit event names instead of numbers
On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> +const char *audit_type_name(int type,
> +char buf[AUDIT_NAME_BUF_SIZE]) {
> +const char *s;
> +
> +s = audit_type_to_string(type);
> +if (s)
> +return s;
> +
> +/* This is inspired by DNS TYPEnnn formatting */
> +snprintf(buf, AUDIT_NAME_BUF_SIZE, "AUDIT%04i", type);
> +return buf;
Shouldn't we stick to at least, to stay congruent to what
we so far did, at least for the unknown ones?
Also, may turn this into a macro expression using ({}) that returns
this as alloca() allocated string?
> +}
> diff --git src/journal/audit-type.h src/journal/audit-type.h
> index 9f37716cd6..a2c98cee80 100644
> --- src/journal/audit-type.h
> +++ src/journal/audit-type.h
> @@ -21,6 +21,11 @@
>along with systemd; If not, see
Re: [systemd-devel] systemd and process migration
On 04/20/2015 02:35 PM, Lennart Poettering wrote: On Mon, 20.04.15 14:33, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/20/2015 01:58 PM, Lennart Poettering wrote: systemd has no provisions for anything like this and I have doubts it really should have. I mean, normal programs retain ccess to the cgroup tree, so you could readd whatever you restore back in the cgroups, but that's hardly sufficient to make systemd aware of a process like this properly. Arguably systemd should have this functionality ( along with quite few others like HA etc ) built in ( not using CRIU ) since you want to live migrate at least native containers between hosts. I thought fancy enterprise features like this was on hold until networkd was "ready" ? This is not an enterprise feature. It's a promise one cannot keep. We will not add code to systemd that works often but not always, and CRIU is certainly of that kind. "We will not add code to systemd that works often but not always" you need to explain this a bit further since we might have different perception on this since from my perception such code has been added to systemd in more then one occasion anyway I was not advocating for the use/inclusion of CRIU but something built in. We should be able to support non live migration out of the box if live migration is a pandora's box or are you opposed to that as well? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] journal: add int↔audit type name mapping
On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> +src/journal/audit_type-list.txt:
> + $(AM_V_at)$(MKDIR_P) $(dir $@)
> + $(AM_V_GEN)$(CPP) $(CFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) -dM -include
> linux/audit.h - -n 's/^#define\s+AUDIT_(\w+)\s+([0-9]{4})\s*$$/\1\t\2/p' | sort -k2 >$@
We add some more in missing.h, so this should probably be added, too, here?
> +#include "audit-type.h"
> +
> +static const struct audit_type_name *
> +lookup_audit_type(register const char *str, register unsigned int
> len);
Weird line break...
> +
> +const char *audit_type_to_string(int type);
is this one actually implemented?
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 and process migration
On Mon, 20.04.15 14:33, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > On 04/20/2015 01:58 PM, Lennart Poettering wrote: > >systemd has no provisions for anything like this and I have doubts it > >really should have. I mean, normal programs retain ccess to the cgroup > >tree, so you could readd whatever you restore back in the cgroups, but > >that's hardly sufficient to make systemd aware of a process like this > >properly. > > Arguably systemd should have this functionality ( along with quite few > others like HA etc ) built in ( not using CRIU ) since you want to live > migrate at least native containers between hosts. > > I thought fancy enterprise features like this was on hold until networkd was > "ready" ? This is not an enterprise feature. It's a promise one cannot keep. We will not add code to systemd that works often but not always, and CRIU is certainly of that kind. Sorry, 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 and process migration
On 04/20/2015 01:58 PM, Lennart Poettering wrote: systemd has no provisions for anything like this and I have doubts it really should have. I mean, normal programs retain ccess to the cgroup tree, so you could readd whatever you restore back in the cgroups, but that's hardly sufficient to make systemd aware of a process like this properly. Arguably systemd should have this functionality ( along with quite few others like HA etc ) built in ( not using CRIU ) since you want to live migrate at least native containers between hosts. I thought fancy enterprise features like this was on hold until networkd was "ready" ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Advice on sending patches
On Thu, 16.04.15 15:00, Adam Goode (ago...@google.com) wrote: > Hi, > > I have 2 patches I am interested in getting reviewed. Can someone please > take a look? I am not sure the correct protocol for doing this. > > They are here: > http://lists.freedesktop.org/archives/systemd-devel/2015-April/030543.html > http://lists.freedesktop.org/archives/systemd-devel/2015-April/030544.html > > I also filed a bug on this issue: > https://bugs.freedesktop.org/show_bug.cgi?id=90028 Sending patches to the ML is sufficient, however, we sometimes need a bit more time to reply, we have a huge load of patches to deal with. Sorry for the delays, 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] Zombie process still exists after stopping gdm.service
On Sun, 19.04.15 09:34, Andrei Borzenkov (arvidj...@gmail.com) wrote: > В Fri, 17 Apr 2015 14:04:18 -0600 > Daniel Drake пишет: > > > Hi, > > > > I'm investigating why "systemctl stop gdm; Xorg" usually fails. The > > new X process complains that X is still running. > > > > Here's what I think is happening: > > > > 1. systemd sends SIGTERM to gdm to stop the service > > > > 2. gdm exits - it has a simple SIGTERM handler which just quits the > > mainloop without doing any cleanup (as far as I can see, it doesn't > > make any attempt to kill the child X server) > > > > 3. X exits because of PR_SET_PDEATHSIG (i.e. it's set to be > > automatically killed when the parent goes away). The killed process > > enters defunct state and is reparented to PID 1, presumably also > > moving it out of the gdm cgroup. > > > > No, it remains in cgroup. Otherwise systemd service management would > not be possible at all ... > > > 4. systemd notes that gdm's cgroup is empty and decides that gdm is > > now successfully stopped. > > > > I looked at display-manager.service here and it sets KillMode=process. > That is better explanation to your observation. Hmm, it does? It does not on Fedora. Also "display-manager.service" is just an alias to "gdm.service" on Fedora. Daniel, can you check with "systemctl cat gdm" what your distro configures there? 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] Zombie process still exists after stopping gdm.service
On Fri, 17.04.15 14:04, Daniel Drake (dr...@endlessm.com) wrote: > I'm investigating why "systemctl stop gdm; Xorg" usually fails. The > new X process complains that X is still running. Have you checked what precisely fails? What's the error message you are getting? What is the actual failing routine? > Here's what I think is happening: > > 1. systemd sends SIGTERM to gdm to stop the service > > 2. gdm exits - it has a simple SIGTERM handler which just quits the > mainloop without doing any cleanup (as far as I can see, it doesn't > make any attempt to kill the child X server) > > 3. X exits because of PR_SET_PDEATHSIG (i.e. it's set to be > automatically killed when the parent goes away). The killed process > enters defunct state and is reparented to PID 1, presumably also > moving it out of the gdm cgroup. zombie processes indeed do not belong to any cgroup anymore. > 4. systemd notes that gdm's cgroup is empty and decides that gdm is > now successfully stopped. Note that SIGCHLD is processed with higher prorirty that cgroup empty events by systemd. This means that if both are queued, SIGCHLD and reaping of the PIDs should always happen first. 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] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoos...@gmail.com) wrote: > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent > internal to systemd before any external processes get run for the > particular embedded CPU I'm using. That gap is a killer at the moment. > > I'm sure this is quite the naive question, but: is there a simple option I > can insert into my "super-important" first service that would cause all > other units to be forestalled until my service reports that it's > initialized? I.e., something like: > > [Unit] > DefaultDependencies=no > Before=very-first-normal-systemd-unit.service > > I didn't have luck identifying such a > very-first-normal-systemd-unit.service on my own, but I'm admittedly rather > inexperienced poking around the internal default suite of units packaged > with systemd. This is not available, though often requested. But I doubt this can ever work, since "running before 'everything'" or "running after 'everything'" is not particularly usefully defined as this all breaks down as soon as you have two services that want to be run like this. The right way is usually to simply add the right deps of the stuff you really want to be run before. That all said, I would be open to adding a "priority" concept to units: if we are about to fork off a large number of processes at the same time we do so sequentially but provide no control currently about the order then. I'd be open making this configurable with a priority values that can ensure we fork off some things before others when both are runnable. This would not really fix your issue, sicne it wouldn't really delay any other services, it would only configure the order of the fork()s, but they'd still take place in a tight loop. 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] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, 17.04.15 22:29, Matt Hoosier (matt.hoos...@gmail.com) wrote: > Thanks, I hadn't found that presentation before. My board is essentially a > Panda ES, with gigabytes of RAM. > > A small point of clarification: when I say that systemd takes 1.5 seconds, > I'm referring to the time that elapses between the moment that > /lib/systemd/systemd is exec'ed and the time that the first unit is shown > in the 'systemd-analyze plot'. I haven't done an internal profile on the > systemd binary to see what might be happening during that window > yet. Well, the plot should also show what we spend the time on: running generators, loading/parsing unit files, loading selinux and things like that. Any chance you can figureout what precisely this time is spent on? "systemctl show -a" will also show you various timestamps over the early boot process. 1.5s sounds like quite a bit, even for weaker processes. I think it might be worth eliminating this away before resorting to hacks around using systemd for actually starting things... 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] controlling serial console using a token
On Mon, 20.04.15 13:06, Andrei Borzenkov (arvidj...@gmail.com) wrote: > On Mon, Apr 20, 2015 at 7:15 AM, Praveen kumar R > wrote: > > You mean in the getty-generator.c ? > > I actually mean your own customer generator. For details see: https://wiki.freedesktop.org/www/Software/systemd/Generators/ 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 and process migration
On Mon, 20.04.15 14:59, Adrian Reber (adr...@lisas.de) wrote: > Using CRIU I have been migrating processes from one system to another > for the last few months (even years). I am now interested in migrating > processes under systemd's control. Before starting to look how to make > it work I wanted to know if there has been any discussion if and how > systemd and CRIU can work together? Not that I was aware of. Personally I do not really believe in the idea of CRIU. I mean, I can see that people want the functionality, but given the amount of context processes maintain about the system I find it quite illusionary that this can work for any but the most simple programs. > Dumping a process under systemd's control should be no problem. > After criu has dumped the process (and killed it) systemd should know > that it does not need to restart the process, but even if the process is > restarted by systemd it does not hurt the process migration. > > The interesting part happens on the system where the process wants to be > migrated to. After the process has been dumped and transfered from the > source system to the destination system it needs to be restarted. So far > this works with different tested processes (postgresql is my current > test process). If I want to restore the process as a systemd child > process I have the problem that the process would have to be re-parented > to systemd after restarting which is not possible in Linux. Therefore I > need the help of systemd. > > My plan now would be to transfer the process to the destination > system and tell systemd I want to restore a process which should be > under systemd's control after the restore has completed. Therefore > systemd needs to run criu with the option to restore the new process as > a criu sibling. Thus systemd would be the correct parent process. > > Is this something which would be useful to integrate into systemd? > I have some ideas how this could be implemented and how the user > interfaces could look like. Before going in too much detail I want to > find out if this is a direction which makes sense. systemd has no provisions for anything like this and I have doubts it really should have. I mean, normal programs retain ccess to the cgroup tree, so you could readd whatever you restore back in the cgroups, but that's hardly sufficient to make systemd aware of a process like this properly. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and process migration
Using CRIU I have been migrating processes from one system to another for the last few months (even years). I am now interested in migrating processes under systemd's control. Before starting to look how to make it work I wanted to know if there has been any discussion if and how systemd and CRIU can work together? Dumping a process under systemd's control should be no problem. After criu has dumped the process (and killed it) systemd should know that it does not need to restart the process, but even if the process is restarted by systemd it does not hurt the process migration. The interesting part happens on the system where the process wants to be migrated to. After the process has been dumped and transfered from the source system to the destination system it needs to be restarted. So far this works with different tested processes (postgresql is my current test process). If I want to restore the process as a systemd child process I have the problem that the process would have to be re-parented to systemd after restarting which is not possible in Linux. Therefore I need the help of systemd. My plan now would be to transfer the process to the destination system and tell systemd I want to restore a process which should be under systemd's control after the restore has completed. Therefore systemd needs to run criu with the option to restore the new process as a criu sibling. Thus systemd would be the correct parent process. Is this something which would be useful to integrate into systemd? I have some ideas how this could be implemented and how the user interfaces could look like. Before going in too much detail I want to find out if this is a direction which makes sense. Adrian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] controlling serial console using a token
On Mon, Apr 20, 2015 at 7:15 AM, Praveen kumar R wrote: > You mean in the getty-generator.c ? > > I actually mean your own customer generator. > On Mon, Apr 20, 2015 at 9:14 AM, Andrei Borzenkov > wrote: >> >> В Mon, 20 Apr 2015 09:09:09 +0530 >> Praveen kumar R пишет: >> >> > This is the snippet of the code in the systemV init system that controls >> > the serial console login >> > depending on the token >> > >> > TOKENEXIST=`grep "TOKEN=" /proc/cmdline` >> > TOKEN=0 >> > if [ "X$TOKENEXIST" != "X" ]; then >> >#If token is pass as a command line arg, use it. >> >TOKEN=`sed 's/.*TOKEN=//; s/ .*//' /proc/cmdline` >> > fi >> > >> > TOKENOVERRIDE=`grep "TOKENOVERRIDE=" /proc/cmdline` >> > if [ "X$TOKENOVERRIDE" != "X" ]; then >> >#If token is pass as a command line arg, use it. >> >OVERRIDE=`sed 's/.*TOKENOVERRIDE=//; s/ .*//' /proc/cmdline` >> >let "TOKEN = $TOKEN & $OVERRIDE" >> > fi >> > >> > echo "TOKEN = $TOKEN" >> > >> > let "CONSOLE_LOGIN = $TOKEN & 512" >> > if [ $CONSOLE_LOGIN -ne 0 ]; then >> > echo "[`eval $uptime`]: Begin Console Access" >> > /etc/console_login & >> > echo "eCM console is enabled" >> > export ENABLE_ECM_CONSOLE=y >> > else >> > echo "[`eval $uptime`]: Token doesn't allow console access" >> > export ENABLE_ECM_CONSOLE=n >> > fi >> > >> > >> > >> > I am trying to implement the same in the sytemd init system. >> > >> >> The straightforward approach is to put this code in generator that >> parses command line. It can mask standard console service and create >> unit for your console. >> >> > >> > On Sun, Apr 19, 2015 at 11:48 AM, Andrei Borzenkov >> > wrote: >> > >> > > В Sat, 18 Apr 2015 19:54:50 +0530 >> > > Praveen kumar R пишет: >> > > >> > > > Yes it's a kernel command line arg, it is board specific token >> > > > introduced >> > > > to control the serial console. >> > > > if defined serial console should not be enabled. >> > > > >> > > >> > > Sorry I do not understand this sentence. "define" what? Please give >> > > exact example of kernel command line and explain what behavior you >> > > expect in this case. >> > > >> > > > we have this in place for other system initializing system - sytemV >> > > > , >> > > where >> > > > depending >> > > > >> > > > On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering < >> > > lenn...@poettering.net >> > > > > wrote: >> > > > >> > > > > On Fri, 17.04.15 15:54, Praveen kumar R (praveenrgo...@gmail.com >> > > > > ) wrote: >> > > > > >> > > > > > I have a token passed on by command line argument on which I >> > > > > > need to >> > > > > decide >> > > > > > to start the serial >> > > > > >> > > > > On which command line? Kernel command line? What kind of "token"? >> > > > > >> > > > > > console or not. I plan to tweak the getty*ttyS0.service and add >> > > > > > the >> > > > > > script which validates the token and starts the console. >> > > > > > >> > > > > > Is this the right approach or is there any better way of >> > > > > > handling it >> > > ?? >> > > > > >> > > > > To get a login getty on the serial port its sufficient to add >> > > > > console=ttyS0... to the kernel cmdline. systemd automatically >> > > > > starts a >> > > > > serial getty automatically on the first terminal the kernel >> > > > > console is >> > > > > pointing to. >> > > > > >> > > > > 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] journal: Introduce journal-netlogd
This tiny daemon forwards messages from the journal to other
hosts over the network using the traditional syslog format RFC 5424.
It can be configured to send messages to both unicast and multicast
addresses.
systemd-journal-netlogd runs with own user systemd-journal-netlog.
It starts running after the network is up.
V2: Address Zbigniew's comments
1. Rename binary systemd-journal-syslogd
2. Fixed up man and added example
3. Error code check sd_event_add_signal
4. remove +User=systemd-journal-network from service file
5. remove opterr=0
6. assignment into declaration of mh
V3: Address Lennart's comments
1. add unicast events in the man
2. use fopen_temporary and fflush_and_check().
3. remove if (m->event_journal_input) {
4. use sigprocmask_many
5. fix facility and priority
6. remove IP_MULTICAST_TTL and IP_PKTINFO
7. use safe_atoi
V4:
1. fix mh.msg_name = &m->address.sockaddr.sa and
mh.msg_namelen = sizeof(m->address.sockaddr.sa
2. rename binary to systemd-journal-netlogd
3. Fix man and created two for binary and conf
4. manager_read_journal_input: removed n as it's not used
5. update_cursor_state fixed free
6. "Not available" → "not available".
7. parse_argv(argc, argv);
moved up, so --help works regardless of the user being created.
---
Makefile-man.am | 10 +
Makefile.am | 37 ++
man/journal-netlogd.conf.xml | 115 ++
man/systemd-journal-netlogd.xml | 123 +++
src/journal-remote/journal-netlog-conf.c | 61
src/journal-remote/journal-netlog-conf.h | 39 ++
src/journal-remote/journal-netlog-gperf.gperf | 18 +
src/journal-remote/journal-netlog-manager.c | 498 ++
src/journal-remote/journal-netlog-manager.h | 70
src/journal-remote/journal-netlog-network.c | 201 +++
src/journal-remote/journal-netlogd.c | 234
src/journal-remote/journal-netlogd.conf.in| 2 +
units/systemd-journal-netlogd.service | 18 +
13 files changed, 1426 insertions(+)
create mode 100644 man/journal-netlogd.conf.xml
create mode 100644 man/systemd-journal-netlogd.xml
create mode 100644 src/journal-remote/journal-netlog-conf.c
create mode 100644 src/journal-remote/journal-netlog-conf.h
create mode 100644 src/journal-remote/journal-netlog-gperf.gperf
create mode 100644 src/journal-remote/journal-netlog-manager.c
create mode 100644 src/journal-remote/journal-netlog-manager.h
create mode 100644 src/journal-remote/journal-netlog-network.c
create mode 100644 src/journal-remote/journal-netlogd.c
create mode 100644 src/journal-remote/journal-netlogd.conf.in
create mode 100644 units/systemd-journal-netlogd.service
diff --git a/Makefile-man.am b/Makefile-man.am
index 2f3e5f2..401ea8d 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1380,6 +1380,16 @@ man/systemd-journal-gatewayd.socket.html:
man/systemd-journal-gatewayd.service.h
endif
+MANPAGES += \
+man/journal-netlogd.conf.5 \
+man/systemd-journal-netlogd.8
+MANPAGES_ALIAS += \
+ man/journal-netlogd.conf.d.5 \
+ man/systemd-journal-netlogd.8
+man/systemd-journal-netlogd.5: man/systemd-journal-netlogd.conf.5
+man/journal-netlogd.conf.d.html: man/journal-netlogd.conf.html
+$(html-alias)
+
if HAVE_MYHOSTNAME
MANPAGES += \
man/nss-myhostname.8
diff --git a/Makefile.am b/Makefile.am
index 68d8252..ca86c26 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4397,6 +4397,43 @@ EXTRA_DIST += \
src/journal-remote/journal-upload.conf.in
endif
+systemd_journal_netlogd_SOURCES = \
+ src/journal-remote/journal-netlog-manager.h \
+ src/journal-remote/journal-netlog-manager.c \
+ src/journal-remote/journal-netlog-conf.h \
+ src/journal-remote/journal-netlog-conf.c \
+ src/journal-remote/journal-netlog-network.c \
+ src/journal-remote/journal-netlogd.c
+
+nodist_systemd_journal_netlogd_SOURCES = \
+ src/journal-remote/journal-netlog-gperf.c
+
+EXTRA_DIST += \
+src/journal-remote/journal-netlog-gperf.gperf
+
+CLEANFILES += \
+src/journal-remote/journal-netlog-gperf.c
+
+systemd_journal_netlogd_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-journal-internal.la \
+ libsystemd-shared.la
+
+rootlibexec_PROGRAMS += \
+ systemd-journal-netlogd
+
+nodist_systemunit_DATA += \
+ units/systemd-journal-netlogd.service
+
+EXTRA_DIST += \
+ units/systemd-journal-netlogd.service.in
+
+nodist_pkgsysconf_DATA += \
+ src/journal-remote/journal-netlogd.conf
+
+EXTRA_DIST += \
+ src/journal-remote/journal-netlogd.conf.in
+
# using _CFLAGS = in the conditional below would suppress AM_CFLAGS
journalctl_CFLAGS = \
$(AM_CFLAGS)
diff --g
Re: [systemd-devel] [PATCH] journal: Introduce journal-syslogd
Sorry for the late reply
On 04/14/2015 10:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 09, 2015 at 11:43:15PM +0530, Susant Sahani wrote:
This tiny daemon enables to pull journal entries and push to a UDP
multicast address in syslog RFC 5424 format. systemd-journal-syslogd
runs with own user systemd-journal-syslog. It starts running after
the network is up.
V2: Address Zbigniew's comments
1. Rename binary systemd-journal-syslogd
2. Fixed up man and added example
3. Error code check sd_event_add_signal
4. remove +User=systemd-journal-network from service file
5. remove opterr=0
6. assignment into declaration of mh
V3: Address Lennart's comments
1. add unicast events in the man
2. use fopen_temporary and fflush_and_check().
3. remove if (m->event_journal_input) {
4. use sigprocmask_many
5. fix facility and priority
6. remove IP_MULTICAST_TTL and IP_PKTINFO
7. use safe_atoi
---
Makefile-man.am | 8 +
Makefile.am | 37 ++
man/systemd-journal-syslogd.service.xml | 84 +
man/systemd-journal-syslogd.xml | 156
src/journal-remote/journal-syslog-conf.c | 61
src/journal-remote/journal-syslog-conf.h | 39 ++
src/journal-remote/journal-syslog-gperf.gperf | 18 +
src/journal-remote/journal-syslog-manager.c | 501 ++
src/journal-remote/journal-syslog-manager.h | 70
src/journal-remote/journal-syslog-network.c | 201 +++
src/journal-remote/journal-syslogd.c | 217 +++
src/journal-remote/journal-syslogd.conf.in| 2 +
units/systemd-journal-syslogd.service | 18 +
13 files changed, 1412 insertions(+)
create mode 100644 man/systemd-journal-syslogd.service.xml
create mode 100644 man/systemd-journal-syslogd.xml
create mode 100644 src/journal-remote/journal-syslog-conf.c
create mode 100644 src/journal-remote/journal-syslog-conf.h
create mode 100644 src/journal-remote/journal-syslog-gperf.gperf
create mode 100644 src/journal-remote/journal-syslog-manager.c
create mode 100644 src/journal-remote/journal-syslog-manager.h
create mode 100644 src/journal-remote/journal-syslog-network.c
create mode 100644 src/journal-remote/journal-syslogd.c
create mode 100644 src/journal-remote/journal-syslogd.conf.in
create mode 100644 units/systemd-journal-syslogd.service
diff --git a/Makefile-man.am b/Makefile-man.am
index 2f3e5f2..437d488 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1380,6 +1380,14 @@ man/systemd-journal-gatewayd.socket.html:
man/systemd-journal-gatewayd.service.h
endif
+MANPAGES += \
+man/systemd-journal-syslogd.service.8 \
+man/systemd-journal-syslogd.8
+MANPAGES_ALIAS += \
+man/systemd-journal-syslogd.8
+man/systemd-journal-syslogd.8: man/systemd-journal-syslogd.service.8
+man/systemd-journal-syslogd.html: man/systemd-journal-syslogd.service.html
+
if HAVE_MYHOSTNAME
MANPAGES += \
man/nss-myhostname.8
diff --git a/Makefile.am b/Makefile.am
index 0a57389..0b843ac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4361,6 +4361,43 @@ EXTRA_DIST += \
src/journal-remote/journal-upload.conf.in
endif
+systemd_journal_syslogd_SOURCES = \
+ src/journal-remote/journal-syslog-manager.h \
+ src/journal-remote/journal-syslog-manager.c \
+ src/journal-remote/journal-syslog-conf.h \
+ src/journal-remote/journal-syslog-conf.c \
+ src/journal-remote/journal-syslog-network.c \
+ src/journal-remote/journal-syslogd.c
+
+nodist_systemd_journal_syslogd_SOURCES = \
+ src/journal-remote/journal-syslog-gperf.c
+
+EXTRA_DIST += \
+src/journal-remote/journal-syslog-gperf.gperf
+
+CLEANFILES += \
+src/journal-remote/journal-syslog-gperf.c
+
+systemd_journal_syslogd_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-journal-internal.la \
+ libsystemd-shared.la
+
+rootlibexec_PROGRAMS += \
+ systemd-journal-syslogd
+
+nodist_systemunit_DATA += \
+ units/systemd-journal-syslogd.service
+
+EXTRA_DIST += \
+ units/systemd-journal-syslogd.service.in
+
+nodist_pkgsysconf_DATA += \
+ src/journal-remote/journal-syslogd.conf
+
+EXTRA_DIST += \
+ src/journal-remote/journal-syslogd.conf.in
+
# using _CFLAGS = in the conditional below would suppress AM_CFLAGS
journalctl_CFLAGS = \
$(AM_CFLAGS)
diff --git a/man/systemd-journal-syslogd.service.xml
b/man/systemd-journal-syslogd.service.xml
new file mode 100644
index 000..e837153
--- /dev/null
+++ b/man/systemd-journal-syslogd.service.xml
@@ -0,0 +1,84 @@
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+http://www.w3.org/2001/XInclude";>
+
+
+systemd-journal-syslogd.service
+systemd
+
+
+
+Developer
+Susant
+Sahani
+ssah...
Re: [systemd-devel] [PATCH] udev: Restore udevadm settle timeout
Hi
On Sat, Apr 11, 2015 at 9:38 PM, Nir Soffer wrote:
> On Sat, Apr 11, 2015 at 1:36 PM, David Herrmann wrote:
>> > @@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc,
>> > char *argv[]) {
>> > break;
>> > }
>> >
>> > +if (now(CLOCK_MONOTONIC) >= deadline)
>> > +break;
>> > +
>>
>> Previous udevadm allowed timeout=0 to disable this. I added the condition.
>
> Hi David,
>
> I think the handling of timeout=0 is incorrect now. The manual says:
>
> A value of 0 will check if the queue is empty and always return
> immediately.
>
> In udev-147 (used on rhel6), this was the behavior. If timeout was 0,
> is_timeout was set and settle was returning with rc=1.
>
> This behavior changed in:
>
> http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=ead7c62ab7641e150c6d668f939c102a6771ce60
>
> After this commit, zero timeout results in unlimited wait. Since this
> patch did not
> change the manual or the online help, and the commit message says:
> "udevadm: settle - kill alarm()", I guess this was unintended change.
>
> I don't see the use case for disabling the timeout, so it seems that
> we should fix
> this, restoring the behavior before this commit.
>
> What do you think?
Ok, this is on me, sorry for that. I tried to keep the behavior from
before the code-removal. I wasn't aware that this was not how it is
documented.
I'm actually not sure whether that was an intended change. It does not
look like it was, indeed. Maybe Kay or Tom know more.. I have no idea
whether timeout=0 is used in the wild.
I'll stall your further patches until we've decided on this.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 0/4] udev: Add builtin and hwdb files for setting pointingstick properties
Hi
On Fri, Apr 17, 2015 at 4:48 PM, Hans de Goede wrote:
> Hi All,
>
> Here is v4 of my pointstick set.
>
> Changes since v3:
> -Use the existing evdev matching rules
> -Make setting the sensitivity part of the evdev builtin (which is called
> keyboard for historical reasons)
>
> Changes since v2:
> -Fix numerous spelling / gramatical errors in commit messages
> -Add a reference to the kernel sources for the ibm trackpoint sensitivity
> setting
>
> Changes since v1:
> -Drop the patch to set ID_INPUT_TRACKPOINT, Peter already send almost the
> same patch to set ID_INPUT_POINTINGSTICK
> -s/trackpoint/pointingstick/ unlike trackpoint pointingstick is a vendor
> neutral name, and pointingstick is also what the prop bit is called in
> linux/input.h Note that a few occurences where not replaced, as those refer
> specifically to IBM/Lenovo trackpoints
> -Use ATTR{foo}= to assign sysfs attr value rather then spawning /bin/sh
> -Dropped S-o-b from the commit messages
Looks all good, apart from my comments on patch #2. Please push!
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4 2/4] udev: keyboard-builtin: Add support for setting IBM trackpoint sensitivity
Hi
On Fri, Apr 17, 2015 at 4:48 PM, Hans de Goede wrote:
> IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
> ps/2 command, which changes the range of the deltas sent when using the
> trackpoint.
>
> On some models with normal usage only deltas of 1 or 2 are send, resulting in
> there only being 2 mouse cursor movement speeds, rather than the expected
> fluid
> scale. Changing the sensitivity to a higher level than the bootup default
> fixes
> this.
>
> This commit adds support for setting a POINTINGSTICK_SENSITIVITY value
> in hwdb to allow changing the sensitivity on boot through udev / hwdb.
> ---
> hwdb/70-pointingstick.hwdb | 12
> src/udev/udev-builtin-keyboard.c | 28
> 2 files changed, 40 insertions(+)
>
> diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
> index 8241181..c5bd92d 100644
> --- a/hwdb/70-pointingstick.hwdb
> +++ b/hwdb/70-pointingstick.hwdb
> @@ -41,6 +41,7 @@
> #
> # Allowed properties are:
> # POINTINGSTICK_CONST_ACCEL
> +# POINTINGSTICK_SENSITIVITY
> #
> #
> # POINTINGSTICK_CONST_ACCEL#
> @@ -53,6 +54,17 @@
> # by how much to multiply deltas generated by the pointingstick to get
> # normalized deltas.
> #
> +#
> +# POINTINGSTICK_SENSITIVITY#
> +#
> +#
> +# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
> +#POINTINGSTICK_SENSITIVITY=
> +#
> +# Where is a number between 0 and 255, note this property
> +# only applies to TPPS/2 IBM TrackPoint devices, see
> +# drivers/input/mouse/trackpoint.c in the Linux kernel sources.
> +#
>
> #
> # Sort by by brand, model
> diff --git a/src/udev/udev-builtin-keyboard.c
> b/src/udev/udev-builtin-keyboard.c
> index c7f7f84..e8cc4b8 100644
> --- a/src/udev/udev-builtin-keyboard.c
> +++ b/src/udev/udev-builtin-keyboard.c
> @@ -146,6 +146,32 @@ static void override_abs(int fd, const char *devnode,
> log_error_errno(errno, "Unable to EVIOCSABS device \"%s\"",
> devnode);
> }
>
> +static void set_trackpoint_sensitivity(struct udev_device *dev, const char
> *value)
> +{
> +struct udev_device *pdev;
> +char val_s[DECIMAL_STR_MAX(int) + 1];
DECIMAL_STR_MAX already accounts for a zero byte (we really should fix
that one day..). But you can drop the "+ 1" here, if I'm not mistaken.
> +int r, val_i;
> +
> +/* The sensitivity sysfs attr belongs to the serio parent device */
> +pdev = udev_device_get_parent_with_subsystem_devtype(dev, "serio",
> NULL);
> +if (!pdev) {
> +log_error("Failed to get serio parent for '%s'",
> udev_device_get_devnode(dev));
log_warning()? I mean this will happen if you set a SENSITIVITY for an
unsupported device, which isn't necessarily an error.
Otherwise looks good to me. Please push!
Thanks
David
> +return;
> +}
> +
> +r = safe_atoi(value, &val_i);
> +if (r < 0) {
> +log_error("Unable to parse POINTINGSTICK_SENSITIVITY '%s'
> for '%s'", value, udev_device_get_devnode(dev));
> +return;
> +}
> +
> +xsprintf(val_s, "%d", val_i);
> +
> +r = udev_device_set_sysattr_value(pdev, "sensitivity", val_s);
> +if (r < 0)
> +log_error_errno(r, "Failed to write 'sensitivity' attribute
> for '%s': %m", udev_device_get_devnode(pdev));
> +}
> +
> static int open_device(const char *devnode) {
> int fd;
>
> @@ -223,6 +249,8 @@ static int builtin_keyboard(struct udev_device *dev, int
> argc, char *argv[], boo
> }
>
> override_abs(fd, node, evcode,
> udev_list_entry_get_value(entry));
> +} else if (streq(key, "POINTINGSTICK_SENSITIVITY")) {
> +set_trackpoint_sensitivity(dev,
> udev_list_entry_get_value(entry));
> }
> }
>
> --
> 2.3.5
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sun, Apr 19, 2015 at 10:46:40PM +0100, Matthew Garrett wrote: > > I'm not convinced that any such broad matches for power management > > belong into udev at all. Udev can carry specific device matches, or > > carry data that cannot be determined from the device itself, like the > > mouse resolution and such, but like in these rules, reading the vendor > > from the kernel and unconditionally flipping a bit back into the > > kernel does not look like a task for udev or userspace in general. > > Is there any possibility that you can be convinced? I think they should go into the kernel as well, given that people update their kernel, but don't update their userspace components. Have we tried this in the kernel? How prelevant are problems really going to be that we need to determine stuff like "if this PCI device is present then this mouse way over here can actually be autosuspended?" thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] mounting loop
Hello everybody,
with systemd 219 mounting a filesystem image in loopback mode fails. Using
these command:
# truncate -s 1G /tmp/test.img
# mkfs.ext4 /tmp/test.img
[...]
# mount -o loop /tmp/test.img /mnt/tmp
systemd umounts the image as it thinks it is inactive:
Apr 20 08:54:28 leda systemd[1]: Unit mnt-tmp.mount is bound to inactive
unit. Stopping, too.
Apr 20 08:54:28 leda systemd[1]: Unmounting /mnt/tmp...
Apr 20 08:54:28 leda systemd[1]: Unmounted /mnt/tmp.
However manually assigning a loop device and mounting that works just fine:
# losetup -f /tmp/test.img
# losetup -a
/dev/loop0: [0034]:695793 (/tmp/test.img)
# mount /dev/loop0 /mnt/tmp
I think this is not the intended behavior, no? Any chance to fix that?
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
pgp7OZapXnwTz.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
