[systemd-devel] Most important changes the last 15 months
About 15 months ago I gave a presentation about systemd/journald. I am asked to give another presentation about systemd/journald. What are the most important changes I should integrate into my presentation? -- Cecil Westerhof ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsckd: Couldn't connect to plymouth: Connection refused
Le 14/03/2015 21:37, Mikhail Morfikov a écrit : This is the full log I got when I tried to mount the device: Mar 14 20:46:08 morfikownia polkitd(authority=local)[1266]: Registered Authentication Agent for unix-process:11439:94979 (system bus name :1.41 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Mar 14 20:46:08 morfikownia systemd[1]: Starting Cryptography Setup for grafi... Mar 14 20:46:08 morfikownia cryptdisks_start[11444]: Starting crypto disk...grafi (starting)... Mar 14 20:46:11 morfikownia cryptdisks_start[11444]: grafi (started)...done. Mar 14 20:46:11 morfikownia systemd[1]: Started Cryptography Setup for grafi. Mar 14 20:46:11 morfikownia systemd[1]: Found device /dev/mapper/grafi. Mar 14 20:46:11 morfikownia systemd[1]: Starting File System Check on /dev/mapper/grafi... Mar 14 20:46:11 morfikownia systemd[1]: Started File System Check Daemon to report status. Mar 14 20:46:11 morfikownia systemd[1]: Starting File System Check Daemon to report status... Mar 14 20:46:12 morfikownia systemd-fsck[11515]: grafi has been mounted 22 times without being checked, check forced. Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:12 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:13 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:13 morfikownia systemd-fsck[11515]: grafi: 21194/1966080 files (4.9% non-contiguous), 7743265/7863808 blocks Mar 14 20:46:13 morfikownia systemd-fsckd[11517]: Couldn't connect to plymouth: Connection refused Mar 14 20:46:13 morfikownia systemd[1]: Started File System Check on /dev/mapper/grafi. Mar 14 20:46:13 morfikownia systemd[1]: Mounting /media/Grafi... Mar 14 20:46:13 morfikownia systemd[1]: Mounted /media/Grafi. Mar 14 20:46:13 morfikownia kernel: EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: errors=remount-ro,commit=10 Mar 14 20:46:13 morfikownia polkitd(authority=local)[1266]: Unregistered Authentication Agent for unix-process:11439:94979 (system bus name :1.41, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) That's an encrypted partition, and I open it sometimes after I log into the system because most of the time I don't need it, and I don't want it to be mounted at boot automatically. The device works well after mounting, but what about the systemd-fsckd message? Is there a way to get rid of that? Hey, This message is due to plymouth not running when systemd-fsckd is starts to get some output to print (it will reconnect to plymouth as soon as plymouth is starting). The message is harmless in itself. I've written a patch to only try to connect if the pid plymouth file is present (http://lists.freedesktop.org/archives/systemd-devel/2015-March/029174.html). This one triggered a more profound discussion on systemd-fsckd and I applied Lennart's advice (with this change as well) in the thread including http://lists.freedesktop.org/archives/systemd-devel/2015-March/029269.html. This set of patches is waiting for reviews since. Cheers, Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Most important changes the last 15 months
On 03/16/2015 10:05 AM, Cecil Westerhof wrote: About 15 months ago I gave a presentation about systemd/journald. I am asked to give another presentation about systemd/journald. What are the most important changes I should integrate into my presentation? -- Would you share your slides? ;-) I'm also asked the samt. Thank you. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Hi folks, > udev seems to create a problem here with the hostap (prism2) kernel > driver. Unlike many wifi devices, the hostap device driver always > creates paired interfaces, a raw interface (wifiX) and a network > interface (wlanX) that represents the configured network. > > Unfortunately, udev (or hostap?) does not seem to be aware of this > linkage, and hence, if you have two wifi radios in your system, may > rename the second (wlanX) without the first (wifiX), and hence causing a > name mismatch between the two. > > In general, this is not a problem, however, wpa_supplicant seems to > depend on the linkage of the names. Hence, if wifiX does not match > wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a > hostap driven wifi connection. > > Even worse, the complete procedure is completely untransparent to the > user, i.e. neither wpa_supplicant (nor network-manager, depending on > wpa_supplicant) nor network-manager provide a useful error message. > > Any chance of fixing this problem? Is this "only" a configuration issue? > Is this an issue of hostap? Is this an issue of wpa_supplicant? > > Either way, it took me several hours of figuring out what was wrong One day passed, no useful pointers. Folks, sorry to say, but it is unacceptable if udev *breaks* the prism wifi. So long, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Mon, Mar 16, 2015 at 10:26 AM, Thomas Richter wrote: > Hi folks, > >> udev seems to create a problem here with the hostap (prism2) kernel >> driver. Unlike many wifi devices, the hostap device driver always >> creates paired interfaces, a raw interface (wifiX) and a network >> interface (wlanX) that represents the configured network. >> >> Unfortunately, udev (or hostap?) does not seem to be aware of this >> linkage, and hence, if you have two wifi radios in your system, may >> rename the second (wlanX) without the first (wifiX), and hence causing a >> name mismatch between the two. >> >> In general, this is not a problem, however, wpa_supplicant seems to >> depend on the linkage of the names. Hence, if wifiX does not match >> wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a >> hostap driven wifi connection. >> >> Even worse, the complete procedure is completely untransparent to the >> user, i.e. neither wpa_supplicant (nor network-manager, depending on >> wpa_supplicant) nor network-manager provide a useful error message. >> >> Any chance of fixing this problem? Is this "only" a configuration issue? >> Is this an issue of hostap? Is this an issue of wpa_supplicant? >> >> Either way, it took me several hours of figuring out what was wrong > > One day passed, no useful pointers. Folks, sorry to say, but it is > unacceptable if udev *breaks* the prism wifi. > I'm not convinced it is udev problem at all. For a start, hostap driver allows to select different prefix instead if "wlan". If your applications cannot handle it, they will be broken irrespectively of udev. If they can handle it, where is the difference? I would expect sysfs structure to reflect relationships between two interfaces. In which case applications should use this information to find matching interfaces. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Mon, Mar 16, 2015 at 08:26:00AM +0100, Thomas Richter wrote: > Hi folks, > > > udev seems to create a problem here with the hostap (prism2) kernel > > driver. Unlike many wifi devices, the hostap device driver always > > creates paired interfaces, a raw interface (wifiX) and a network > > interface (wlanX) that represents the configured network. > > > > Unfortunately, udev (or hostap?) does not seem to be aware of this > > linkage, and hence, if you have two wifi radios in your system, may > > rename the second (wlanX) without the first (wifiX), and hence causing a > > name mismatch between the two. > > > > In general, this is not a problem, however, wpa_supplicant seems to > > depend on the linkage of the names. Hence, if wifiX does not match > > wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a > > hostap driven wifi connection. > > > > Even worse, the complete procedure is completely untransparent to the > > user, i.e. neither wpa_supplicant (nor network-manager, depending on > > wpa_supplicant) nor network-manager provide a useful error message. > > > > Any chance of fixing this problem? Is this "only" a configuration issue? > > Is this an issue of hostap? Is this an issue of wpa_supplicant? > > > > Either way, it took me several hours of figuring out what was wrong > > One day passed, no useful pointers. Folks, sorry to say, but it is > unacceptable if udev *breaks* the prism wifi. A Sunday passed, and you are upset that no one fixed a problem for an obsolete kernel driver? What kind of free software support are you used to? Anyway, which exact kernel driver is this? Is it prism2_usb? Or something else? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Am 16.03.2015 um 09:04 schrieb Greg KH: > On Mon, Mar 16, 2015 at 08:26:00AM +0100, Thomas Richter wrote: >> Hi folks, >> >>> udev seems to create a problem here with the hostap (prism2) kernel >>> driver. Unlike many wifi devices, the hostap device driver always >>> creates paired interfaces, a raw interface (wifiX) and a network >>> interface (wlanX) that represents the configured network. >>> >>> Unfortunately, udev (or hostap?) does not seem to be aware of this >>> linkage, and hence, if you have two wifi radios in your system, may >>> rename the second (wlanX) without the first (wifiX), and hence causing a >>> name mismatch between the two. >>> >>> In general, this is not a problem, however, wpa_supplicant seems to >>> depend on the linkage of the names. Hence, if wifiX does not match >>> wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a >>> hostap driven wifi connection. >>> >>> Even worse, the complete procedure is completely untransparent to the >>> user, i.e. neither wpa_supplicant (nor network-manager, depending on >>> wpa_supplicant) nor network-manager provide a useful error message. >>> >>> Any chance of fixing this problem? Is this "only" a configuration issue? >>> Is this an issue of hostap? Is this an issue of wpa_supplicant? >>> >>> Either way, it took me several hours of figuring out what was wrong >> >> One day passed, no useful pointers. Folks, sorry to say, but it is >> unacceptable if udev *breaks* the prism wifi. > > A Sunday passed, and you are upset that no one fixed a problem for an > obsolete kernel driver? What kind of free software support are you used > to? > > Anyway, which exact kernel driver is this? Is it prism2_usb? Or > something else? It's regular PCI based prism2, thank you. I'm not expecting *you* to fix things in prism2, for sure. This is not the hostap mailing list. But look, if udev can take a working kernel driver (and prism2 surely is), and breaks its interfaces, then apparently something changed in the interface from back then when prism2 was written and working, to now, where it no longer is. Of course we can now move responsibility around: It's wpa_supplicant's fault, it's prism2's fault, ... but in the end, it doesn't help. The driver is still not working, because udev silently changed the interface. IOW, if you change interfaces, I believe a robust software development should probably check whether that breaks anything, and if it does, it's probably saver to assume that *not* renaming an interface is probably the better choice unless you know that the corresponding kernel driver *can* handle this. I believe a safer default assumption would be not rename anything *unless proven safely*, but that decision was not taken. I'm completely unaware of the inner workings of udev or the kernel driver for that matter. I'm only reporting a problem, and a problem that an average user is completely unable to solve. I don't know how to configure udev to "keep its hands off prism2", but that would be a start, and it would be a suitable default configuration for udev that should probably ship with it. A better solution would probably to have an indicator somewhere whether a device can be safely renamed or not, and prism2 apparently cannot, and in that case not to attempt to rename it. One way or another, you have a design problem here, namely that udev moves things around without really knowing enough about the device in question and whether this renaming does any good for a particular device. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Mon, Mar 16, 2015 at 09:32:17AM +0100, Thomas Richter wrote: > Am 16.03.2015 um 09:04 schrieb Greg KH: > > On Mon, Mar 16, 2015 at 08:26:00AM +0100, Thomas Richter wrote: > >> Hi folks, > >> > >>> udev seems to create a problem here with the hostap (prism2) kernel > >>> driver. Unlike many wifi devices, the hostap device driver always > >>> creates paired interfaces, a raw interface (wifiX) and a network > >>> interface (wlanX) that represents the configured network. > >>> > >>> Unfortunately, udev (or hostap?) does not seem to be aware of this > >>> linkage, and hence, if you have two wifi radios in your system, may > >>> rename the second (wlanX) without the first (wifiX), and hence causing a > >>> name mismatch between the two. > >>> > >>> In general, this is not a problem, however, wpa_supplicant seems to > >>> depend on the linkage of the names. Hence, if wifiX does not match > >>> wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a > >>> hostap driven wifi connection. > >>> > >>> Even worse, the complete procedure is completely untransparent to the > >>> user, i.e. neither wpa_supplicant (nor network-manager, depending on > >>> wpa_supplicant) nor network-manager provide a useful error message. > >>> > >>> Any chance of fixing this problem? Is this "only" a configuration issue? > >>> Is this an issue of hostap? Is this an issue of wpa_supplicant? > >>> > >>> Either way, it took me several hours of figuring out what was wrong > >> > >> One day passed, no useful pointers. Folks, sorry to say, but it is > >> unacceptable if udev *breaks* the prism wifi. > > > > A Sunday passed, and you are upset that no one fixed a problem for an > > obsolete kernel driver? What kind of free software support are you used > > to? > > > > Anyway, which exact kernel driver is this? Is it prism2_usb? Or > > something else? > > It's regular PCI based prism2, thank you. I'm not expecting *you* to fix > things in prism2, for sure. This is not the hostap mailing list. Which exact kernel driver is this? I don't see a prism2 PCI driver in the latest kernel source tree, but I'm probably looking in the wrong place. Pointers to it would be appreciated so we can see exactly what is different about it's user/kernel interfaces that is causing problems here. > But look, if udev can take a working kernel driver (and prism2 surely > is), and breaks its interfaces, then apparently something changed in the > interface from back then when prism2 was written and working, to now, > where it no longer is. When did things break? What previous version of udev worked properly? What changed on your system that caused this problem to show up? Did you upgrade the kernel? Whole system? Something else? What distro is this? We need a bit more information here please. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Mon, Mar 16, 2015 at 8:26 AM, Thomas Richter wrote: > Hi folks, > >> udev seems to create a problem here with the hostap (prism2) kernel >> driver. Unlike many wifi devices, the hostap device driver always >> creates paired interfaces, a raw interface (wifiX) and a network >> interface (wlanX) that represents the configured network. >> >> Unfortunately, udev (or hostap?) does not seem to be aware of this >> linkage, and hence, if you have two wifi radios in your system, may >> rename the second (wlanX) without the first (wifiX), and hence causing a >> name mismatch between the two. >> >> In general, this is not a problem, however, wpa_supplicant seems to >> depend on the linkage of the names. Hence, if wifiX does not match >> wlanX, wpa_supplicant will be unable to provide a WPA2 connection over a >> hostap driven wifi connection. >> >> Even worse, the complete procedure is completely untransparent to the >> user, i.e. neither wpa_supplicant (nor network-manager, depending on >> wpa_supplicant) nor network-manager provide a useful error message. >> >> Any chance of fixing this problem? Is this "only" a configuration issue? >> Is this an issue of hostap? Is this an issue of wpa_supplicant? >> >> Either way, it took me several hours of figuring out what was wrong Thanks for the report. This reminds me that I need to resubmit the kernel patch which (probably) would fix this for you. In the meantime you can (in recent systemd versions) create a new file /etc/systemd/network/prism.link file with a [Match] section that matches your device(s). If you leave NamePolicy= unset in your new file, the interface name will not be changed. See systemd.link(5) for details on how to match .link files to network devices. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Am 16.03.2015 um 09:54 schrieb Greg KH: >> >> It's regular PCI based prism2, thank you. I'm not expecting *you* to fix >> things in prism2, for sure. This is not the hostap mailing list. > > Which exact kernel driver is this? I don't see a prism2 PCI driver in > the latest kernel source tree, but I'm probably looking in the wrong > place. Pointers to it would be appreciated so we can see exactly what > is different about it's user/kernel interfaces that is causing problems > here. It's the hostap driver (also known as prism2/2.5/3), which is because the wifi can also act as an access point with software available in the kernel. To be precise, it is drivers/net/wireless/hostap/hostap_hw.c and drivers/net/wireless/hostap/hostap_pci.c. >> But look, if udev can take a working kernel driver (and prism2 surely >> is), and breaks its interfaces, then apparently something changed in the >> interface from back then when prism2 was written and working, to now, >> where it no longer is. > > When did things break? What previous version of udev worked properly? I highly doubt that this ever worked correctly with udev at all. The things "broke" the time udev came into the show. As already said, the trouble with the hostap adapter is that it has two network interfaces, the wifiX and the wlanX, one is the raw radio (wifiX) and one is the network interface that acts as an end-point once the connection is established. > What changed on your system that caused this problem to show up? I installed a hostap PCI adapter, quite simple. The problem is really that: The laptop in question had a ipw2200 card installed, which was configured by udev as wlan0 (obviously). This card got replaced (basically, due to another bug in ipw2200 which is unrelated to udev), and "obviously" udev picked a new name for the adapter, which now became wlan1. Unfortunately, udev *did not* change the name of the raw radio (wifi0), which should have become wifi1 to make wpa_supplicant happy. > Did > you upgrade the kernel? No. > Whole system? No. > Something else? The wifi, from ipw2200 to a prism2 PCI card. Actually, mini-pci. > What distro is > this? Debian wheezy, as stated. Actually, I gave that information above, but no matter, here we are again. But that's not the debian kernel. Debian ships with a kernel that's *too old* for this system (another story, i830GM graphics was broken and only fixed in 3.18 lately). Thus, the machine runs with a custom 3.18.7. But this kernel did not change in the process of exchanging the ipw2200 to the hostap/prism chipset. Actually, it is rather typical use case udev *should* handle, namely replacement of hardware. The problem is really that udev is unaware of the linkage between wifiX and wlanX (paired devices) hostap offers. Greetings, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Mon, Mar 16, 2015 at 10:34 AM, Thomas Richter wrote: > The laptop in question had a ipw2200 card installed, which was > configured by udev as wlan0 (obviously). This card got replaced > (basically, due to another bug in ipw2200 which is unrelated to udev), > and "obviously" udev picked a new name for the adapter, which now became > wlan1. Unfortunately, udev *did not* change the name of the raw radio > (wifi0), which should have become wifi1 to make wpa_supplicant happy. udev would never pick the names wlan0 or wlan1 automatically, this is not how it (ever) worked. wlan0 and wlan1 are the sort of names the kernel sets, and at most udev (in very old versions) might have tried to remember these names between reboots and reapply them. This scheme is no longer in place though, so unless your distro is shipping some non-standard stuff or you have some old rule files lying around in /etc/udev/rules.d you should not be affected by that (and even if you are, I don't see how this would cause your current problem). Are you sure that udev is even renaming your devices at all? Booting with debug logging will tell you. You should see "Renamed network interface 'foo' to 'bar'" in your logs. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Am 16.03.2015 um 10:53 schrieb Tom Gundersen: > On Mon, Mar 16, 2015 at 10:34 AM, Thomas Richter > wrote: >> The laptop in question had a ipw2200 card installed, which was >> configured by udev as wlan0 (obviously). This card got replaced >> (basically, due to another bug in ipw2200 which is unrelated to udev), >> and "obviously" udev picked a new name for the adapter, which now became >> wlan1. Unfortunately, udev *did not* change the name of the raw radio >> (wifi0), which should have become wifi1 to make wpa_supplicant happy. > > udev would never pick the names wlan0 or wlan1 automatically, this is > not how it (ever) worked. wlan0 and wlan1 are the sort of names the > kernel sets, and at most udev (in very old versions) might have tried > to remember these names between reboots and reapply them. This scheme > is no longer in place though, so unless your distro is shipping some > non-standard stuff or you have some old rule files lying around in > /etc/udev/rules.d you should not be affected by that (and even if you > are, I don't see how this would cause your current problem). > > Are you sure that udev is even renaming your devices at all? Booting > with debug logging will tell you. You should see "Renamed network > interface 'foo' to 'bar'" in your logs. Yup, I'm exactly seeing this message. "Renamed interface wlan0 to wlan1". I'll go back to you tonight with the precise wording, but that's pretty much the same kind of message you describe. Yes, of course the old "rules" file from the ipw2200 installation date was still in place when I installed the prism2 card. It had (obviously) the wlan0 assigned to the now (no longer available) ipw2200. Again, if I edit the /etc/rules.d/70-persistent-net.rules file, and throw out the ipw adapter and the udev rule for hostap there, and let udev recreate it, everything is fine, but how would average Joe User would possibly get to this point? In the end, the problem is really that wpa_supplicant seems to expect a naming convention (so it seems) between wifi and wlan, and udev does not respect this. Is this a wpa_supplicant bug or a udev bug? I don't know, but at least it's a completely frustrating problem that costed me one sleepless night. Greetings, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
On Mon, Mar 16, 2015 at 11:01 AM, Thomas Richter wrote: > Am 16.03.2015 um 10:53 schrieb Tom Gundersen: >> On Mon, Mar 16, 2015 at 10:34 AM, Thomas Richter >> wrote: >>> The laptop in question had a ipw2200 card installed, which was >>> configured by udev as wlan0 (obviously). This card got replaced >>> (basically, due to another bug in ipw2200 which is unrelated to udev), >>> and "obviously" udev picked a new name for the adapter, which now became >>> wlan1. Unfortunately, udev *did not* change the name of the raw radio >>> (wifi0), which should have become wifi1 to make wpa_supplicant happy. >> >> udev would never pick the names wlan0 or wlan1 automatically, this is >> not how it (ever) worked. wlan0 and wlan1 are the sort of names the >> kernel sets, and at most udev (in very old versions) might have tried >> to remember these names between reboots and reapply them. This scheme >> is no longer in place though, so unless your distro is shipping some >> non-standard stuff or you have some old rule files lying around in >> /etc/udev/rules.d you should not be affected by that (and even if you >> are, I don't see how this would cause your current problem). >> >> Are you sure that udev is even renaming your devices at all? Booting >> with debug logging will tell you. You should see "Renamed network >> interface 'foo' to 'bar'" in your logs. > > Yup, I'm exactly seeing this message. "Renamed interface wlan0 to > wlan1". I'll go back to you tonight with the precise wording, but > that's pretty much the same kind of message you describe. > > Yes, of course the old "rules" file from the ipw2200 installation date > was still in place when I installed the prism2 card. It had (obviously) > the wlan0 assigned to the now (no longer available) ipw2200. > > Again, if I edit the /etc/rules.d/70-persistent-net.rules file, and > throw out the ipw adapter and the udev rule for hostap there, and let > udev recreate it, everything is fine, but how would average Joe User > would possibly get to this point? He wouldn't. That's why we don't do that stuff any more. Maybe debian does downstream, but they really should not (IMHO). So this particular issue has been fixed upstream long ago (by dropping the writing of rules to /etc). As mentioned earlier there may still be an issue left to solve with our new naming scheme, which I'll take to the kernel people. > In the end, the problem is really that wpa_supplicant seems to expect a > naming convention (so it seems) between wifi and wlan, and udev does not > respect this. > > Is this a wpa_supplicant bug or a udev bug? I don't know, but at least > it's a completely frustrating problem that costed me one sleepless night. FTR: udev should not know anything about any naming scheme that wpa_supplicant has. At most we'll detect that wpa_supplicant set a name, and just leave it alone. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] bootloader time on a non-EFI bootloader
Hi, I would like to pass the time it was spent in bootloader to systemd. Is there a kernel command line to pass this information on non EFI bootloader? Or is there an another way? Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
Just a short update: I managed to get my machine image to (kind of) boot in systemd-nspawn this weekend. Kind-of as it tries to mount some drives that are obviously not there in the container. But apart from that it seems to boot fine:-) On real hardware I am not so lucky: Once I get to system-switch-root.service I get lots of output about missing nodes in dev (/dev/ttyX mostly). This might be due to me messing up the configuration, arch's mkinitcpio being unprepared to handle a stateless system or some problem in systemd. At this time I am not sure which. I am rather positive that this will be really straight forward to figure out once I can actually get a shell in the initrd, which unfortunately seems harder than expected on Arch Linux (provided you use systemd HOOK in /etc/mkinitcpio.conf, which is not the recommended way of doing things):-/ Best Regards, Tobias PS: Any hints on systemd-in-initrd debugging in arch linux would be appreciated at this point:-) On Fri, Mar 13, 2015 at 2:20 PM, Tobias Hunger wrote: > Hi Zbyszek, > > I would expect the machine-id to be written before mount units are > processed, so for that to work I would need to mount /var in the > initrd, wouldn't I? > > Currently I am trying to just write the machine-id to /etc in the > initrd. This makes systemd loose the understanding that /etc is empty > though, which might have some side-effects that I am not yet > anticipating. > > Isn't systemd started from inside the initrd once the new root has > been set up? Maybe I could set $container_uuid and feed the machine-id > to systemd that way? I am afraid that this will lead to some other > side-effects, because systemd might assume to be running inside a > container. Looks like I will have to do some testing over the > weekend:-) > > Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. > > Best Regards, > Tobias > > On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek > wrote: >> On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: >>> On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger >>> wrote: >>> >> presets and machined ID are applied by PID 1, before it begins with >>> >> starting any units, hence *really* early on. Note though that actually >>> >> /etc/machine-id is used as flag for "is /etc empty". If the file >>> >> exists it is assumed that /etc is provisioned properly. If it is >>> >> missing PID 1 will generate the machiend id and apply presets. >>> > >>> > An OS installer could put the machine-id into /usr just fine (and so >>> > can I) and systemd could just get it from there if available before >>> > generating a new one. >>> > >>> > It would be nice if the machine-id did not change during to a factory >>> > reset: It is used in the logs and changing it will basically make >>> > historical log data much harder to analyze. IIRC networkd also uses it >>> > to generate persistent MAC addresses for containers and such. >>> > >>> > So far this seems to be the only critical piece of information that >>> > can not get restored via tmpfiles.d. >>> >>> Thinking about this a bit longer: /usr does not seem like a good idea. >>> The machine-id is supposed to be unique and usr-images are meant to be >>> reused. >>> >>> Maybe provide a kernel command line option to force the machine-id if >>> none is set yet? >> I think this could be an option. We currently check >> /var/lib/dbus/machine-id, $container_uuid, and >> /sys/class/dmi/id/product_uuid. >> I think that the first should work for your use case, since you keep /var. >> But we also check some commandline option, this seems useful for some >> use cases. >> >> Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootloader time on a non-EFI bootloader
On Mon, Mar 16, 2015 at 11:29 AM, Umut Tezduyar Lindskog wrote: > I would like to pass the time it was spent in bootloader to systemd. > Is there a kernel command line to pass this information on non EFI > bootloader? Or is there an another way? No, there isn't anything I know of. The kernel boot protocol should probably be extended to accept a block of values to be passed from the loader to the OS, and be exported somewhere by the kernel itself to userspace. Overloading the kernel command line with that does not sound like the right approach. We should not support anything like that from systemd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] hwdb: change 60-keyboard.hwdb matches
Hi Hans & Martin I've pushed some patches that change the hwdb 60-keyboard matching logic. This was needed to support bluetooth devices, and then I just went ahead and cleaned up the other rules. This email is meant as a heads-up to you guys, as you are the most frequent contributors to that file. Two notes: 1) Both of you added keyboard:usb:* matches that match on the USB interface. This was now dropped in: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b26e4ced91d0ac0eabdce1c505228ccafc65a23f If this was intentional, we can re-add it, but it looked like a safety-net to me, rather than an explicit interface match. Please let me know if it is required! 2) The keyboard:dmi:* matches are now merged with the platform fallback, as the platform-fallback is a superset of the dmi-match: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ba76ee29bc02879fb42c048132af8889b00220d5 With the new rules, we can now support all kinds of input-devices. Note that the input-driver needs to support the evdev setkeycode ioctl (all HID drivers do!). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] hwdb: change 60-keyboard.hwdb matches
Hi, On 16-03-15 12:31, David Herrmann wrote: Hi Hans & Martin I've pushed some patches that change the hwdb 60-keyboard matching logic. This was needed to support bluetooth devices, and then I just went ahead and cleaned up the other rules. This email is meant as a heads-up to you guys, as you are the most frequent contributors to that file. Two notes: 1) Both of you added keyboard:usb:* matches that match on the USB interface. This was now dropped in: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b26e4ced91d0ac0eabdce1c505228ccafc65a23f If this was intentional, we can re-add it, but it looked like a safety-net to me, rather than an explicit interface match. Please let me know if it is required! I just copy pasted the interface check from existing rules, I don't believe it is required for any keyboards I've added. 2) The keyboard:dmi:* matches are now merged with the platform fallback, as the platform-fallback is a superset of the dmi-match: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ba76ee29bc02879fb42c048132af8889b00220d5 With the new rules, we can now support all kinds of input-devices. Note that the input-driver needs to support the evdev setkeycode ioctl (all HID drivers do!). OK, thanks for letting us know about these changes. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Hi On Mon, Mar 16, 2015 at 11:09 AM, Tom Gundersen wrote: > On Mon, Mar 16, 2015 at 11:01 AM, Thomas Richter > wrote: >> Am 16.03.2015 um 10:53 schrieb Tom Gundersen: >>> On Mon, Mar 16, 2015 at 10:34 AM, Thomas Richter >>> wrote: The laptop in question had a ipw2200 card installed, which was configured by udev as wlan0 (obviously). This card got replaced (basically, due to another bug in ipw2200 which is unrelated to udev), and "obviously" udev picked a new name for the adapter, which now became wlan1. Unfortunately, udev *did not* change the name of the raw radio (wifi0), which should have become wifi1 to make wpa_supplicant happy. >>> >>> udev would never pick the names wlan0 or wlan1 automatically, this is >>> not how it (ever) worked. wlan0 and wlan1 are the sort of names the >>> kernel sets, and at most udev (in very old versions) might have tried >>> to remember these names between reboots and reapply them. This scheme >>> is no longer in place though, so unless your distro is shipping some >>> non-standard stuff or you have some old rule files lying around in >>> /etc/udev/rules.d you should not be affected by that (and even if you >>> are, I don't see how this would cause your current problem). >>> >>> Are you sure that udev is even renaming your devices at all? Booting >>> with debug logging will tell you. You should see "Renamed network >>> interface 'foo' to 'bar'" in your logs. >> >> Yup, I'm exactly seeing this message. "Renamed interface wlan0 to >> wlan1". I'll go back to you tonight with the precise wording, but >> that's pretty much the same kind of message you describe. >> >> Yes, of course the old "rules" file from the ipw2200 installation date >> was still in place when I installed the prism2 card. It had (obviously) >> the wlan0 assigned to the now (no longer available) ipw2200. >> >> Again, if I edit the /etc/rules.d/70-persistent-net.rules file, and >> throw out the ipw adapter and the udev rule for hostap there, and let >> udev recreate it, everything is fine, but how would average Joe User >> would possibly get to this point? > > He wouldn't. That's why we don't do that stuff any more. Maybe debian > does downstream, but they really should not (IMHO). > > So this particular issue has been fixed upstream long ago (by dropping > the writing of rules to /etc). As mentioned earlier there may still be > an issue left to solve with our new naming scheme, which I'll take to > the kernel people. > >> In the end, the problem is really that wpa_supplicant seems to expect a >> naming convention (so it seems) between wifi and wlan, and udev does not >> respect this. >> >> Is this a wpa_supplicant bug or a udev bug? I don't know, but at least >> it's a completely frustrating problem that costed me one sleepless night. > > FTR: udev should not know anything about any naming scheme that > wpa_supplicant has. At most we'll detect that wpa_supplicant set a > name, and just leave it alone. I don't see how we can fix that via name_assign_type. Sure, we could set this to NET_NAME_PREDICTABLE and udev would no longer rename it. But the name is *NOT* predictable, so it would be a hack. The other fix would be to tell udev to never rename hostap devices as they will break. However, that's just due to wpa_supplicant relying on matching names. I'd prefer if we could tell wpa_supplicant to find the wlanX <->wifiY relation via /sys, instead of relying on the matching names. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Am 16.03.2015 um 12:53 schrieb David Herrmann: > I don't see how we can fix that via name_assign_type. Sure, we could > set this to NET_NAME_PREDICTABLE and udev would no longer rename it. > But the name is *NOT* predictable, so it would be a hack. > > The other fix would be to tell udev to never rename hostap devices as > they will break. However, that's just due to wpa_supplicant relying on > matching names. > > I'd prefer if we could tell wpa_supplicant to find the wlanX <->wifiY > relation via /sys, instead of relying on the matching names. > FYI, I also reported this on the wpa_supplicant mailing list, but there's no reaction on this yet. Apparently, it tries to "rfkill" the seemingly dead wifiX radio, and fails if the radio isn't where it is expected - or so it seems. Greetings, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Create journal-remote.conf.xml to document the format of the configuration file for systemd-journal-remote
--- man/journal-remote.conf.xml| 111 + man/systemd-journal-remote.xml | 1 + 2 files changed, 112 insertions(+) create mode 100644 man/journal-remote.conf.xml diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml new file mode 100644 index 000..84e07ee --- /dev/null +++ b/man/journal-remote.conf.xml @@ -0,0 +1,111 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + + + +http://www.w3.org/2001/XInclude";> + +journal-remote.conf +systemd + + + +Developer +Chris +Morgan +chmor...@gmail.com + + + + + +journal-remote.conf +5 + + + +journal-remote.conf +Journal remote service configuration files + + + +/etc/systemd/journal-remote.conf +/etc/journal-remote.conf +/run/journal-remote.conf +/usr/local/lib/journal-remote.conf +/usr/lib/journal-remote.conf + + + +Description + +These files configure various parameters of the systemd-remote-journal +application, + systemd-journal-remote8. + + + + +Options + +All options are configured in the +[Journal] section: + + + + +SplitMode= + +One of host or none. + + + + +ServerKeyFile= + +SSL key in PEM format + + + +ServerCertificateFile= + +SSL CA certificate in PEM format. + + + +TrustedCertificateFile= + +SSL CA certificate. + + + + + + + + See Also + + systemd-journal-remote1 + + + + diff --git a/man/systemd-journal-remote.xml b/man/systemd-journal-remote.xml index 2687662..d5bda63 100644 --- a/man/systemd-journal-remote.xml +++ b/man/systemd-journal-remote.xml @@ -310,6 +310,7 @@ systemd-journal-remote --url http://some.host:19531/ journalctl1, systemd-journald.service8, systemd-journal-gatewayd.service8 + journal-remote.conf5 -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Most important changes the last 15 months
On Mon, Mar 16, 2015 at 08:05:07AM +0100, Cecil Westerhof wrote: > About 15 months ago I gave a presentation about systemd/journald. I am > asked to give another presentation about systemd/journald. What are the > most important changes I should integrate into my presentation? There is NEWS. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reliably waiting for udevd to finish processing triggered events
Hi On Mon, Mar 9, 2015 at 8:58 PM, Ray Strode wrote: >> No, applications should not watch the queue. And the file is internal >> to udev anyway. If you watch it, you get to keep the pieces. > udev recently gained public api for monitoring the queue. > Regardless, I think using a timeout is a better way to go anyway. > > key points: > > 1) if boot is less than say 5 seconds we shouldn't show anything but > black (which we accomplish today with the ShowSplashDelay config key) > 2) if boot takes much more than 5 seconds then we need some sort of > indication that > boot is progressing, so if graphics isn't ready by then we should fall > back to text > splash (right now we only fall back after we think "coldplug > completes", so we need fixes here) > 3) we shouldn't ever upgrade from text to graphics on any given > output, since that > would look weird (this works today, but we could do better by allowing > different splashes on different outputs) > 4) relying on the udev queue to drain to decide on falling back is > wrong and we should stop doing that > > Still, there's may be another problem...is there a decent sized hole > in boot time between udev exiting in the initrd and then starting back > up on the main root filesystem? If so, graphics that don't manage to > get marked initialized in the initrd, may not get marked initialized > until some seconds later after they would otherwise be ready to go, > and from one boot to the next the user may get graphics or text mode. > maybe udev should stick around and switch into the root filesystem on > its own (and i guess potentially re-exec itself once it gets there), > so it doesn't have to blow it's queue and retrigger? This should not be an issue. udev is part of base.target and should not experience any large delays during transition. Sure, anything involving timeouts is non-deterministic, but I would bother much unless someone reports such issues. Anyway, your description sounds about right. But I still think we should drop vgacon, which makes text-mode useless in plymouth (as it would only work on fbdev, which could be used for graphics mode by plymouth). But if people wanna keep vgacon, I'm not going to force them to switch.. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't change removed devices to state "tentative" [was: Re: [PATCH] unit: When stopping due to BindsTo=, log which unit caused it]
On Mon, Mar 16, 2015 at 10:28:36AM +0100, Martin Pitt wrote: > would you mind pushing for me? Pushed. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "systemd --test" fails
Lennart Poettering wrote >> This is a SLES 12 system. Any idea what I'm doing wrong? What permissions >> does the user need to run the test mode? Adding him to the root group >> didn't suffice. > > 210 is really old. THis has been fixed a while back in newer > versions. Please update or ask your distribution to backport the fixes. I got a backport for SLES 12 from the SuSE support and now the test mode works fine. Thanks for the hint :-) cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Minimal unit monitoring daemon
Inspired by https://github.com/joonty/systemd_mon I wrote a more minimal (1 file, <150 line) systemd unit monitor: https://github.com/Rendaw/sysd_minmon It really just forwards state change events to a user provided script. It is my humble wish that someone perhaps will find this useful, and that I will in turn become rich and famous. Cheers, Rendaw ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Hi On Mon, Mar 16, 2015 at 1:04 PM, Thomas Richter wrote: > Am 16.03.2015 um 12:53 schrieb David Herrmann: > >> I don't see how we can fix that via name_assign_type. Sure, we could >> set this to NET_NAME_PREDICTABLE and udev would no longer rename it. >> But the name is *NOT* predictable, so it would be a hack. >> >> The other fix would be to tell udev to never rename hostap devices as >> they will break. However, that's just due to wpa_supplicant relying on >> matching names. >> >> I'd prefer if we could tell wpa_supplicant to find the wlanX <->wifiY >> relation via /sys, instead of relying on the matching names. >> > > FYI, I also reported this on the wpa_supplicant mailing list, but > there's no reaction on this yet. Apparently, it tries to "rfkill" the > seemingly dead wifiX radio, and fails if the radio isn't where it is > expected - or so it seems. I wrote a patch that fixes the kernel hostap driver to report the correct name-assign-type: https://gist.github.com/dvdhrm/0a04ef4ad07ecfe7443e I will wrap it up and submit it upstream. However, it would be nice if you could describe your issues in more detail. In particular, I cannot see any "wifiX" to "wlanX" issue. The hostap driver exports a "wlanX" device as a base and multiple sub-devices with a special suffix if requested by user-space. Therefore, your system should have a "wlanX" device, and a "wlanXap" / "wlanXsta" device, and maybe multiple "wlanXwdsY" devices. Can you list the devices you see (with renaming enabled, if possible) so I can figure out what exactly goes wrong? I cannot see why you'd have a "wifiX" device. Even the wpa_supplicant driver_hostap.c file uses "wlanXap", not "wifiX". Can you elaborate on that, please? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Am 16.03.2015 um 16:28 schrieb David Herrmann: > > However, it would be nice if you could describe your issues in more > detail. In particular, I cannot see any "wifiX" to "wlanX" issue. The > hostap driver exports a "wlanX" device as a base and multiple > sub-devices with a special suffix if requested by user-space. > Therefore, your system should have a "wlanX" device, and a "wlanXap" / > "wlanXsta" device, and maybe multiple "wlanXwdsY" devices. Can you > list the devices you see (with renaming enabled, if possible) so I can > figure out what exactly goes wrong? Sure. The prism2pci (actually, hostap_pci) driver creates paired devices. Without udev coming into play, it gets the names wlan0 and wifi0, and "ifconfig" reports both of them. "wifi0" is, as far as I understand the story, the raw "radio", and the hostapd user space daemon sits on top of it for creating the access point. For reasons unclear to me, wpa_supplicant *also* accesses both, apparently because it has a dedicated driver model for hostap, besides the generic wifi model (or so it seems). It then tries an rfkill on the wifi0 driver, and if that does not exist, it falls over. Actually, wpa_cli does not give much details about what exactly it pukes about, only that it fails. I only found by experimenting. If udev comes into play, it renames wlan0 to wlan1, because wlan0 was already taken from a previously installed ipw2200 card that is no longer in the system. Hence, I have now the network interfaces wifi0 and wlan1, and that confuses wpa_supplicant to an amount that it can no longer authenticate the connection. Why precisely that is the case I do not know, but naming both interfaces the same resolves the problem. > I cannot see why you'd have a "wifiX" device. Even the wpa_supplicant > driver_hostap.c file uses "wlanXap", not "wifiX". Can you elaborate on > that, please? Actually, what's probably part of the confusion (likely) is that "hostap" is the name of the kernel driver for the prism2/2.5/3 chipsets, and their special feature is that they can *also* act as host-driven access point (hence the name). To enable this feature, you also need an additional user-space daemon, but that is not involved in the whole problem. It may create additional network interfaces, though this is not relevant for the matter at hand. The same problem also appears for PCMCIA-driven prism2 chipsets, here specifically for old "LinkSys" wifi PCMCIA cards. They are handled by hostap_cs. Same problem, it creates two interfaces, not one, the radio at "wifi0", and the configured network at "wlan0". All the hostap drivers seem to be in supported state, i.e. they are not part of the "stagging" kernel. Greetings, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd does not shutdown system, it is waiting for a serial tty to show up
Hi, On some of the ARM boards I work on in my spare time I've done "systemctl enable getty@ttyGS0.service" to get a getty on the usb gadget serial port which I've configured on the devices otg controller. This serial port device node /dev/ttyGS0 shows up as soon as the gadget serial port driver loads, but is only usable when I plug in a the mini B end of a mini B -> A usb cable where the A end is plugged into an active usb host. "ps aux" shows something peculiar here, when I do "ps aux" before the cable is plugged in it shows "(agetty)" in the args column of the output, when I then plug in the cable the output changes to "/sbin/agetty --noclear ttyGS0 vt220" note this is the same process, as before the cable was plugged, I've a feeling that somehow the process is stuck halfway exec or some such ... ?? If I plug in the cable I get a getty on the other end of the usb gadget serial connection and everything more or less works. I say more or less because it seems that part of the welcome header from getty gets lost, and sometimes getty acts as if it has received some garbage on its stdin. I mention this because it may be related, but it may also very well be a bug in the usb stack somewhere. The problem which I have why I'm sending this mail is that halt (-p) or reboot does not work when there is no usb cable plugged into the otg connector. "halt -p" just sits there for a long time, and then exits with a dbus timeout error. If I plug in the cable while it is doing this, then it continues and starts shutting down. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Hi On Mon, Mar 16, 2015 at 4:48 PM, Thomas Richter wrote: > If udev comes into play, it renames wlan0 to wlan1, because wlan0 was > already taken from a previously installed ipw2200 card that is no longer > in the system. Hence, I have now the network interfaces wifi0 and wlan1, > and that confuses wpa_supplicant to an amount that it can no longer > authenticate the connection. Why precisely that is the case I do not > know, but naming both interfaces the same resolves the problem. Ok, forget my previous mail, your issue is only related to the wext driver, not the hostap extensions. Up front, upstream udev never renames wlan0 to wlan1. This is a downstream problem. The problem is the following: Kernel hostap creates both, wlan%d and wifi%d net-devs. wpa_supplicant doesn't know which is in use and therefore sets wifi%d as secondary ifindex for any wlan%d device. That is, if wlan5 is probed and wifi5 exists, it adds wifi5 as secondary index to wlan5 (see wpa_driver_wext_finish_drv_init() in hostap/src/driver_wext.c). This is for compatibility with legacy drivers. It is not needed today and should be dropped. Now if wlan5 *and* wifi5 exist, but are not related, things will go wrong. On the kernel side, hostap creates one netdev on device initialization (wifi%d in prism2_init_local_data()), and one after probing is done (wlan%d in hostap_hw_ready()). Both pass "%d" to the networking core, which means, the suffix is allocated dynamically! On both names! If you have more than one wireless card, there is no guarantee at all that the suffix IDs will be identical for wlan%d and wifi%d. The assumption wpa_supplicant places on the kernel-names is just wrong. The first netdev-renaming-scheme in udev used to save udev-rules to make wlan%d names consistent. This was soon considered broken and deprecated. Upstream udev hasn't shipped this for quite a long time. I recommend fixing the netdev-renaming rules in debian or telling the wpa_supplicant developers, that those netdev suffixes are not stable at all. Or update to systemd-udevd. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
2015-03-16 17:25 GMT+01:00 David Herrmann : > Hi > > On Mon, Mar 16, 2015 at 4:48 PM, Thomas Richter > wrote: >> If udev comes into play, it renames wlan0 to wlan1, because wlan0 was >> already taken from a previously installed ipw2200 card that is no longer >> in the system. Hence, I have now the network interfaces wifi0 and wlan1, >> and that confuses wpa_supplicant to an amount that it can no longer >> authenticate the connection. Why precisely that is the case I do not >> know, but naming both interfaces the same resolves the problem. > > Ok, forget my previous mail, your issue is only related to the wext > driver, not the hostap extensions. > > Up front, upstream udev never renames wlan0 to wlan1. Well, "current" upstream udev, with persistent interface naming enabled, would rename italso, it would just chose a different name, one which is not in the same wlanX namespace. If that alone is suffcient to not trigger Thomas problem, I dunno. That said, Thomas is talking about udev 175 (Debian wheezy), where udev upstream did infact still ship the udev rules which renamed wlan interface within the same namespace. This is a > downstream problem. Please don't be so quick always blaming downstream. Thanks, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: Remove explicit Plymouth integration
Even if plymouth is running, it might have not displayed the splash yet,
so we'll see a few lines on fbcon when we should have otherwise had
nothing.
Plymouth integration was added to systemd in commit
6faa11140bf776cdaeb8d22d01816e6e48296971. That same day, Plymouth got
systemd integration [0]. As such, the Plymouth integration has always
been obsolete, and was probably only for older Plymouth's. But I can't
imagine anybody running a Plymouth from 2011 with a systemd from 2015.
Remove the Plymouth/systemd integration, and let Plymouth's code tell
systemd to print the details.
[0]
http://cgit.freedesktop.org/plymouth/commit/?id=537c16422cd49f1beeaab1ad39846a00018faec1
Signed-off-by: Jasper St. Pierre
Cc: Daniel Drake
Cc: Ray Strode
---
src/core/main.c| 2 +-
src/core/manager.c | 4 +---
src/shared/util.c | 4
src/shared/util.h | 2 --
4 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 2d393de..dd8b650 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1561,7 +1561,7 @@ int main(int argc, char *argv[]) {
}
if (arg_running_as == SYSTEMD_SYSTEM && !skip_setup) {
-if (arg_show_status > 0 || plymouth_running())
+if (arg_show_status > 0)
status_welcome();
hostname_setup();
diff --git a/src/core/manager.c b/src/core/manager.c
index d33112d..1afd359 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -3009,9 +3009,7 @@ static bool manager_get_show_status(Manager *m,
StatusType type) {
if (m->show_status > 0)
return true;
-/* If Plymouth is running make sure we show the status, so
- * that there's something nice to see when people press Esc */
-return plymouth_running();
+return false;
}
void manager_set_first_boot(Manager *m, bool b) {
diff --git a/src/shared/util.c b/src/shared/util.c
index 5cbbe8f..3f3ca90 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -4228,10 +4228,6 @@ bool nulstr_contains(const char*nulstr, const char
*needle) {
return false;
}
-bool plymouth_running(void) {
-return access("/run/plymouth/pid", F_OK) >= 0;
-}
-
char* strshorten(char *s, size_t l) {
assert(s);
diff --git a/src/shared/util.h b/src/shared/util.h
index d229e1e..749bd0e 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -549,8 +549,6 @@ int kill_and_sigcont(pid_t pid, int sig);
bool nulstr_contains(const char*nulstr, const char *needle);
-bool plymouth_running(void);
-
bool hostname_is_valid(const char *s) _pure_;
char* hostname_cleanup(char *s, bool lowercase);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Am 16.03.2015 um 17:25 schrieb David Herrmann: > Ok, forget my previous mail, your issue is only related to the wext > driver, not the hostap extensions. > > Up front, upstream udev never renames wlan0 to wlan1. This is a > downstream problem. > > The problem is the following: > Kernel hostap creates both, wlan%d and wifi%d net-devs. wpa_supplicant > doesn't know which is in use and therefore sets wifi%d as secondary > ifindex for any wlan%d device. That is, if wlan5 is probed and wifi5 > exists, it adds wifi5 as secondary index to wlan5 (see > wpa_driver_wext_finish_drv_init() in hostap/src/driver_wext.c). This > is for compatibility with legacy drivers. It is not needed today and > should be dropped. > Now if wlan5 *and* wifi5 exist, but are not related, things will go wrong. > > On the kernel side, hostap creates one netdev on device initialization > (wifi%d in prism2_init_local_data()), and one after probing is done > (wlan%d in hostap_hw_ready()). Both pass "%d" to the networking core, > which means, the suffix is allocated dynamically! On both names! If > you have more than one wireless card, there is no guarantee at all > that the suffix IDs will be identical for wlan%d and wifi%d. The > assumption wpa_supplicant places on the kernel-names is just wrong. > > The first netdev-renaming-scheme in udev used to save udev-rules to > make wlan%d names consistent. This was soon considered broken and > deprecated. Upstream udev hasn't shipped this for quite a long time. > > I recommend fixing the netdev-renaming rules in debian or telling the > wpa_supplicant developers, that those netdev suffixes are not stable > at all. Or update to systemd-udevd. Thanks, that's approximately what I was afraid of. I reminded the wpa_supplicant folks again of the problem, then I'll check with the debian supporter. It's probably all new in sid, but the problem persists at least in wheezy. I'll come back as soon as I know a bit more. Greetings, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Remove explicit Plymouth integration
Thanks! Enthusiastically applied.
Tom
PS
There is still some plymouth integration left in case anyone wants to
work on getting rid of that.
On Mon, Mar 16, 2015 at 5:34 PM, Jasper St. Pierre
wrote:
> Even if plymouth is running, it might have not displayed the splash yet,
> so we'll see a few lines on fbcon when we should have otherwise had
> nothing.
>
> Plymouth integration was added to systemd in commit
> 6faa11140bf776cdaeb8d22d01816e6e48296971. That same day, Plymouth got
> systemd integration [0]. As such, the Plymouth integration has always
> been obsolete, and was probably only for older Plymouth's. But I can't
> imagine anybody running a Plymouth from 2011 with a systemd from 2015.
>
> Remove the Plymouth/systemd integration, and let Plymouth's code tell
> systemd to print the details.
>
> [0]
> http://cgit.freedesktop.org/plymouth/commit/?id=537c16422cd49f1beeaab1ad39846a00018faec1
>
> Signed-off-by: Jasper St. Pierre
> Cc: Daniel Drake
> Cc: Ray Strode
> ---
> src/core/main.c| 2 +-
> src/core/manager.c | 4 +---
> src/shared/util.c | 4
> src/shared/util.h | 2 --
> 4 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/src/core/main.c b/src/core/main.c
> index 2d393de..dd8b650 100644
> --- a/src/core/main.c
> +++ b/src/core/main.c
> @@ -1561,7 +1561,7 @@ int main(int argc, char *argv[]) {
> }
>
> if (arg_running_as == SYSTEMD_SYSTEM && !skip_setup) {
> -if (arg_show_status > 0 || plymouth_running())
> +if (arg_show_status > 0)
> status_welcome();
>
> hostname_setup();
> diff --git a/src/core/manager.c b/src/core/manager.c
> index d33112d..1afd359 100644
> --- a/src/core/manager.c
> +++ b/src/core/manager.c
> @@ -3009,9 +3009,7 @@ static bool manager_get_show_status(Manager *m,
> StatusType type) {
> if (m->show_status > 0)
> return true;
>
> -/* If Plymouth is running make sure we show the status, so
> - * that there's something nice to see when people press Esc */
> -return plymouth_running();
> +return false;
> }
>
> void manager_set_first_boot(Manager *m, bool b) {
> diff --git a/src/shared/util.c b/src/shared/util.c
> index 5cbbe8f..3f3ca90 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -4228,10 +4228,6 @@ bool nulstr_contains(const char*nulstr, const char
> *needle) {
> return false;
> }
>
> -bool plymouth_running(void) {
> -return access("/run/plymouth/pid", F_OK) >= 0;
> -}
> -
> char* strshorten(char *s, size_t l) {
> assert(s);
>
> diff --git a/src/shared/util.h b/src/shared/util.h
> index d229e1e..749bd0e 100644
> --- a/src/shared/util.h
> +++ b/src/shared/util.h
> @@ -549,8 +549,6 @@ int kill_and_sigcont(pid_t pid, int sig);
>
> bool nulstr_contains(const char*nulstr, const char *needle);
>
> -bool plymouth_running(void);
> -
> bool hostname_is_valid(const char *s) _pure_;
> char* hostname_cleanup(char *s, bool lowercase);
>
> --
> 2.1.0
>
> ___
> 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] udev breaks hostap linkage of raw/user interfaces, causing wpa_supplicant problems
Hi On Mon, Mar 16, 2015 at 5:35 PM, Michael Biebl wrote: > 2015-03-16 17:25 GMT+01:00 David Herrmann : >> Hi >> >> On Mon, Mar 16, 2015 at 4:48 PM, Thomas Richter >> wrote: >>> If udev comes into play, it renames wlan0 to wlan1, because wlan0 was >>> already taken from a previously installed ipw2200 card that is no longer >>> in the system. Hence, I have now the network interfaces wifi0 and wlan1, >>> and that confuses wpa_supplicant to an amount that it can no longer >>> authenticate the connection. Why precisely that is the case I do not >>> know, but naming both interfaces the same resolves the problem. >> >> Ok, forget my previous mail, your issue is only related to the wext >> driver, not the hostap extensions. >> >> Up front, upstream udev never renames wlan0 to wlan1. > > Well, "current" upstream udev, with persistent interface naming > enabled, would rename italso, it would just chose a different name, > one which is not in the same wlanX namespace. > If that alone is suffcient to not trigger Thomas problem, I dunno. If it's not named "wlanX" the bug will not appear. Please have a look at hostap-git/src/driver_wext.c wpa_driver_wext_finish_drv_init() as mentioned in my previous mail. > That said, Thomas is talking about udev 175 (Debian wheezy), where > udev upstream did infact still ship the udev rules which renamed wlan > interface within the same namespace. > > This is a >> downstream problem. > > Please don't be so quick always blaming downstream. Ok. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd does not shutdown system, it is waiting for a serial tty to show up
Hi Hans On Mon, Mar 16, 2015 at 5:15 PM, Hans de Goede wrote: > Hi, > > On some of the ARM boards I work on in my spare time I've > done "systemctl enable getty@ttyGS0.service" to get a getty > on the usb gadget serial port which I've configured on the > devices otg controller. > > This serial port device node /dev/ttyGS0 shows up as soon > as the gadget serial port driver loads, but is only usable > when I plug in a the mini B end of a mini B -> A usb cable > where the A end is plugged into an active usb host. > > "ps aux" shows something peculiar here, when I do "ps aux" > before the cable is plugged in it shows "(agetty)" in > the args column of the output, when I then plug in the > cable the output changes to "/sbin/agetty --noclear ttyGS0 vt220" > note this is the same process, as before the cable was plugged, > I've a feeling that somehow the process is stuck halfway > exec or some such ... ?? We rename the process to "()" directly after fork(). So if it is still "(agetty)", something blocks before we can exec(). Can you run strace to figure out what call blocks? Furthermore, what state is the process in? Thanks David > If I plug in the cable I get a getty on the other end of > the usb gadget serial connection and everything more or less > works. I say more or less because it seems that part of > the welcome header from getty gets lost, and sometimes getty > acts as if it has received some garbage on its stdin. I mention > this because it may be related, but it may also very well be a > bug in the usb stack somewhere. > > The problem which I have why I'm sending this mail is that > halt (-p) or reboot does not work when there is no usb cable > plugged into the otg connector. > > "halt -p" just sits there for a long time, and then exits with > a dbus timeout error. If I plug in the cable while it is doing > this, then it continues and starts shutting down. > > Regards, > > Hans > ___ > 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] core: Remove explicit Plymouth integration
Le 16/03/2015 17:53, Tom Gundersen a écrit :
Thanks! Enthusiastically applied.
Tom
PS
There is still some plymouth integration left in case anyone wants to
work on getting rid of that.
Hey Tom, Jasper,
Note that systemd-fsckd (in the new set of patch posted last week on
that ML to address Lennart's concerns) is using the plymouth_running()
check to prevent some warning when the socket isn't there. I can copy
the function back there, but maybe you can put that the
plymouth_running() in util.c?
Cheers,
Didier
On Mon, Mar 16, 2015 at 5:34 PM, Jasper St. Pierre
wrote:
Even if plymouth is running, it might have not displayed the splash yet,
so we'll see a few lines on fbcon when we should have otherwise had
nothing.
Plymouth integration was added to systemd in commit
6faa11140bf776cdaeb8d22d01816e6e48296971. That same day, Plymouth got
systemd integration [0]. As such, the Plymouth integration has always
been obsolete, and was probably only for older Plymouth's. But I can't
imagine anybody running a Plymouth from 2011 with a systemd from 2015.
Remove the Plymouth/systemd integration, and let Plymouth's code tell
systemd to print the details.
[0]
http://cgit.freedesktop.org/plymouth/commit/?id=537c16422cd49f1beeaab1ad39846a00018faec1
Signed-off-by: Jasper St. Pierre
Cc: Daniel Drake
Cc: Ray Strode
---
src/core/main.c| 2 +-
src/core/manager.c | 4 +---
src/shared/util.c | 4
src/shared/util.h | 2 --
4 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 2d393de..dd8b650 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1561,7 +1561,7 @@ int main(int argc, char *argv[]) {
}
if (arg_running_as == SYSTEMD_SYSTEM && !skip_setup) {
-if (arg_show_status > 0 || plymouth_running())
+if (arg_show_status > 0)
status_welcome();
hostname_setup();
diff --git a/src/core/manager.c b/src/core/manager.c
index d33112d..1afd359 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -3009,9 +3009,7 @@ static bool manager_get_show_status(Manager *m,
StatusType type) {
if (m->show_status > 0)
return true;
-/* If Plymouth is running make sure we show the status, so
- * that there's something nice to see when people press Esc */
-return plymouth_running();
+return false;
}
void manager_set_first_boot(Manager *m, bool b) {
diff --git a/src/shared/util.c b/src/shared/util.c
index 5cbbe8f..3f3ca90 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -4228,10 +4228,6 @@ bool nulstr_contains(const char*nulstr, const char
*needle) {
return false;
}
-bool plymouth_running(void) {
-return access("/run/plymouth/pid", F_OK) >= 0;
-}
-
char* strshorten(char *s, size_t l) {
assert(s);
diff --git a/src/shared/util.h b/src/shared/util.h
index d229e1e..749bd0e 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -549,8 +549,6 @@ int kill_and_sigcont(pid_t pid, int sig);
bool nulstr_contains(const char*nulstr, const char *needle);
-bool plymouth_running(void);
-
bool hostname_is_valid(const char *s) _pure_;
char* hostname_cleanup(char *s, bool lowercase);
--
2.1.0
___
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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Remove explicit Plymouth integration
On Mon, Mar 16, 2015 at 6:15 PM, Didier Roche wrote: > Le 16/03/2015 17:53, Tom Gundersen a écrit : >> >> Thanks! Enthusiastically applied. >> >> Tom >> >> PS >> >> There is still some plymouth integration left in case anyone wants to >> work on getting rid of that. > > Hey Tom, Jasper, > > Note that systemd-fsckd (in the new set of patch posted last week on that ML > to address Lennart's concerns) is using the plymouth_running() check to > prevent some warning when the socket isn't there. I can copy the function > back there, but maybe you can put that the plymouth_running() in util.c? Hi Didier, Just noticed this, sorry about that. I'll revert this hunk before applying your patches. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] path-lookup: use secure_getenv()
Hi On Sun, Mar 15, 2015 at 12:36 PM, Ronny Chevalier wrote: > 2015-03-15 3:27 GMT+01:00 Shawn Landden : >> All these except user_data_home_dir() are certainly vectors for >> arbitrary code execution. These should use secure_getenv() >> --- > > Hi, > > I don't see why secure_getenv() is appropriate here? These functions > are never used in the libraries systemd provides, they are mostly used > by systemctl and the dbus manager. Can you provide more details? You're right, but on the other hand secure_getenv() is usually sufficient (we don't use setuid() nor fs-caps). So secure_getenv() wouldn't hurt. But I don't really care.. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/5] fsckd: check if plymouth is running before attempting connection
On Tue, Mar 10, 2015 at 6:00 PM, Didier Roche wrote: > Le 10/03/2015 11:44, Lennart Poettering a écrit : >> >> On Tue, 10.03.15 11:34, Didier Roche (didro...@ubuntu.com) wrote: >> >> I think it would make more sense to return 0 when ply isn't running, >> and 1 if it is, no? > > > Did this in the attached patch. Due to this, I needed then to return 1 even > if we did not reconnect to plymouth but was already connected, which > slightly break the paradigm of "return 0 if we did nothing, and 1 if the > action changed something and is successful". > Is that ok? This looks good to me. Applied (with the needed revert). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] parsing audit messages
Hi On Sun, Mar 15, 2015 at 3:49 AM, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > I was looking at some debug logs, and the audit messages are > semi-useless in their current undecoded form: > > mar 14 22:24:02 fedora22 audit[1]: pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 > msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" > hostname=? addr=? terminal=? res=success' > mar 14 22:24:05 fedora22 audit: > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D0069707461626C655F7365637572697479 > > You added code to parse this, and I think we should make use of it and > put msg= field as MESSAGE=, and maybe store the original message as > _AUDIT= or something. If there's no msg field, like with proctitle, > print all fields that are in the message, but using our cescape, and > not this hexadecimal form which is unreadable for humans. Audit messages cannot be parsed reliably. They don't do escaping and it's really a big mess. I'm not saying we shouldn't try it, but just as a heads-up, this might cause some troubles. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] fsckd: Don't use strjoina on gettext() call
Looks good. Pushed.
Thanks.
Tom
On Wed, Mar 11, 2015 at 2:25 PM, Didier Roche wrote:
> Le 11/03/2015 09:34, Didier Roche a écrit :
>>
>> Le 11/03/2015 09:29, Martin Pitt a écrit :
>>>
>>> Hello all,
>>>
>>> Didier Roche [2015-03-10 17:56 +0100]:
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -272,7 +272,7 @@ static int plymouth_send_message(int plymouth_fd,
const char *message, bool upda
}
static int manager_send_plymouth_message(Manager *m, const char
*message) {
-const char *plymouth_cancel_message = NULL;
+_cleanup_free_ const char *plymouth_cancel_message = NULL,
*l10n_cancel_message = NULL;
int r;
>>>
>>> As far as I can see, this would free(l10n_cancel_message) on exit, but
>>> you must never free the result of gettext(). So split this into
>>>
>>>_cleanup_free_ const char *plymouth_cancel_message = NULL;
>>>const char *l10n_cancel_message;
>>
>>
>> Indeed (weird I didn't get a double free crash), but the man page says
>> it's statically allocated. Will fix it and report while bringing up the
>> other patch with the architecture modification.
>> Thanks!
>
>
> Actually, none of then needed a cleanup_free as the second is a strjoina().
>
> Here is the updated patch, thanks!
> Didier
>
> ___
> 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] core: Remove explicit Plymouth integration
Le 16/03/2015 18:23, Tom Gundersen a écrit : On Mon, Mar 16, 2015 at 6:15 PM, Didier Roche wrote: Le 16/03/2015 17:53, Tom Gundersen a écrit : Thanks! Enthusiastically applied. Tom PS There is still some plymouth integration left in case anyone wants to work on getting rid of that. Hey Tom, Jasper, Note that systemd-fsckd (in the new set of patch posted last week on that ML to address Lennart's concerns) is using the plymouth_running() check to prevent some warning when the socket isn't there. I can copy the function back there, but maybe you can put that the plymouth_running() in util.c? Hi Didier, Just noticed this, sorry about that. I'll revert this hunk before applying your patches. No worry, thanks! :) Cheers, Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] parsing audit messages
On Mon, Mar 16, 2015 at 06:33:39PM +0100, David Herrmann wrote: > Hi > > On Sun, Mar 15, 2015 at 3:49 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > Hi, > > > > I was looking at some debug logs, and the audit messages are > > semi-useless in their current undecoded form: > > > > mar 14 22:24:02 fedora22 audit[1]: pid=1 uid=0 auid=4294967295 > > ses=4294967295 subj=system_u:system_r:init_t:s0 > > msg='unit=systemd-udev-trigger comm="systemd" > > exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > > mar 14 22:24:05 fedora22 audit: > > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D0069707461626C655F7365637572697479 > > > > You added code to parse this, and I think we should make use of it and > > put msg= field as MESSAGE=, and maybe store the original message as > > _AUDIT= or something. If there's no msg field, like with proctitle, > > print all fields that are in the message, but using our cescape, and > > not this hexadecimal form which is unreadable for humans. > > Audit messages cannot be parsed reliably. They don't do escaping and > it's really a big mess. I'm not saying we shouldn't try it, but just > as a heads-up, this might cause some troubles. Lennart already implemented parsing. I'm sure it's not perfect, but it doesn't really have to be. If we can parse the most common messages than it would already be a big improvement. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/fsckd src/shared
On Mon, Mar 16, 2015 at 10:33:54AM -0700, Tom Gundersen wrote:
> src/fsckd/fsckd.c | 13 ++---
> src/shared/util.c |4
> src/shared/util.h |2 ++
> 3 files changed, 16 insertions(+), 3 deletions(-)
>
> New commits:
> commit e26169bd48c64753510a1194abdf4fb5dc907123
> Author: Didier Roche
> Date: Tue Mar 10 10:05:19 2015 +0100
>
> fsckd: check if plymouth is running before attempting connection
>
> diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
> index f24715c..6b35fc2 100644
> --- a/src/fsckd/fsckd.c
> +++ b/src/fsckd/fsckd.c
> @@ -231,9 +231,12 @@ static int manager_connect_plymouth(Manager *m) {
> union sockaddr_union sa = PLYMOUTH_SOCKET;
> int r;
>
> +if (!plymouth_running())
> +return 0;
Why do we need to do this check? We try to connect right below, and
we'll get a connection error if plymouth is not running.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] path-lookup: use secure_getenv()
Hi, On Mon, Mar 16, 2015 at 06:31:29PM +0100, David Herrmann wrote: > Hi > > On Sun, Mar 15, 2015 at 12:36 PM, Ronny Chevalier > wrote: > > 2015-03-15 3:27 GMT+01:00 Shawn Landden : > >> All these except user_data_home_dir() are certainly vectors for > >> arbitrary code execution. These should use secure_getenv() > >> --- > > > > Hi, > > > > I don't see why secure_getenv() is appropriate here? These functions > > are never used in the libraries systemd provides, they are mostly used > > by systemctl and the dbus manager. Can you provide more details? > > You're right, but on the other hand secure_getenv() is usually > sufficient (we don't use setuid() nor fs-caps). So secure_getenv() > wouldn't hurt. > But I don't really care.. Yeh, perhaps just push them and forget about them even if they are called later from libraries or copy+past into a library call... ?! > Thanks > David > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/fsckd src/shared
Le 16/03/2015 18:41, Zbigniew Jędrzejewski-Szmek a écrit :
On Mon, Mar 16, 2015 at 10:33:54AM -0700, Tom Gundersen wrote:
src/fsckd/fsckd.c | 13 ++---
src/shared/util.c |4
src/shared/util.h |2 ++
3 files changed, 16 insertions(+), 3 deletions(-)
New commits:
commit e26169bd48c64753510a1194abdf4fb5dc907123
Author: Didier Roche
Date: Tue Mar 10 10:05:19 2015 +0100
fsckd: check if plymouth is running before attempting connection
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index f24715c..6b35fc2 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -231,9 +231,12 @@ static int manager_connect_plymouth(Manager *m) {
union sockaddr_union sa = PLYMOUTH_SOCKET;
int r;
+if (!plymouth_running())
+return 0;
Why do we need to do this check? We try to connect right below, and
we'll get a connection error if plymouth is not running.
The issue is that we are raising a warning if we can't communicate to
the socket while connecting. This behavior puzzled some users looking at
their logs when they didn't get plymouth running early enough or at all
(repeating connection warnings).
There were 2 options:
- downgrading the warning to a debug, which may never give a hint if the
user is expecting to see something in plymouth and never get any connection
- have the plymouth_running() check.
(More refs at
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029174.html)
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd does not shutdown system, it is waiting for a serial tty to show up
Hi,
On 16-03-15 18:12, David Herrmann wrote:
Hi Hans
On Mon, Mar 16, 2015 at 5:15 PM, Hans de Goede wrote:
Hi,
On some of the ARM boards I work on in my spare time I've
done "systemctl enable getty@ttyGS0.service" to get a getty
on the usb gadget serial port which I've configured on the
devices otg controller.
This serial port device node /dev/ttyGS0 shows up as soon
as the gadget serial port driver loads, but is only usable
when I plug in a the mini B end of a mini B -> A usb cable
where the A end is plugged into an active usb host.
"ps aux" shows something peculiar here, when I do "ps aux"
before the cable is plugged in it shows "(agetty)" in
the args column of the output, when I then plug in the
cable the output changes to "/sbin/agetty --noclear ttyGS0 vt220"
note this is the same process, as before the cable was plugged,
I've a feeling that somehow the process is stuck halfway
exec or some such ... ??
We rename the process to "()" directly after fork(). So if it is
still "(agetty)", something blocks before we can exec(). Can you run
strace to figure out what call blocks?
strace -p says:
write(3, "\33[r\33[H\33[2J", 10
And then when I plug in the cable (the ") = 10" is the write finishing) :
)= 10
close(3)= 0
open("/dev/null", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
dup2(3, 0) = 0
close(3)= 0
socket(PF_LOCAL, SOCK_STREAM, 0)= 3
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/stdout"}, 29) = 0
shutdown(3, SHUT_RD)= 0
getsockopt(3, SOL_SOCKET, SO_SNDBUF, [163840], [4]) = 0
setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = 0
fstat64(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6e0f000
_llseek(3, 0, 0xbee70fc8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "agetty\ngetty@ttyGS0.service\n30\n1"..., 39) = 39
munmap(0xb6e0f000, 4096)= 0
dup2(3, 1) = 1
close(3)= 0
dup2(1, 2) = 2
fstatat64(AT_FDCWD, "/sys/fs/cgroup/systemd", {st_mode=S_IFDIR|0555, st_size=0,
...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/systemd/system.slice/system-getty.slice/getty@ttyGS0.service/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_GETFL) = 0x20001 (flags O_WRONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6e0f000
write(3, "379\n", 4)= 4
close(3)= 0
munmap(0xb6e0f000, 4096)= 0
fstatat64(AT_FDCWD, "/sys/fs/cgroup/cpu", {st_mode=S_IFLNK|0777, st_size=11,
...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/cpu/system.slice/system-getty.slice/getty@ttyGS0.service/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
fstatat64(AT_FDCWD, "/sys/fs/cgroup/cpu", {st_mode=S_IFLNK|0777, st_size=11,
...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/cpu/system.slice/system-getty.slice/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
fstatat64(AT_FDCWD, "/sys/fs/cgroup/cpu", {st_mode=S_IFLNK|0777, st_size=11,
...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/cpu/system.slice/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_GETFL) = 0x20001 (flags O_WRONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6e0f000
write(3, "379\n", 4)= 4
close(3)= 0
munmap(0xb6e0f000, 4096)= 0
fstatat64(AT_FDCWD, "/sys/fs/cgroup/cpuacct", {st_mode=S_IFLNK|0777,
st_size=11, ...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/cpuacct/system.slice/system-getty.slice/getty@ttyGS0.service/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
fstatat64(AT_FDCWD, "/sys/fs/cgroup/cpuacct", {st_mode=S_IFLNK|0777,
st_size=11, ...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/cpuacct/system.slice/system-getty.slice/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
fstatat64(AT_FDCWD, "/sys/fs/cgroup/cpuacct", {st_mode=S_IFLNK|0777,
st_size=11, ...}, AT_SYMLINK_NOFOLLOW) = 0
open("/sys/fs/cgroup/cpuacct/system.slice/cgroup.procs",
O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_GETFL) = 0x20001 (flags O_WRONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6e0f000
write(3, "379\n", 4)= 4
close(3)= 0
munmap(0xb6e0f000, 4096)
Re: [systemd-devel] [PATCH] path-lookup: use secure_getenv()
2015-03-16 18:31 GMT+01:00 David Herrmann : > Hi > > On Sun, Mar 15, 2015 at 12:36 PM, Ronny Chevalier > wrote: >> 2015-03-15 3:27 GMT+01:00 Shawn Landden : >>> All these except user_data_home_dir() are certainly vectors for >>> arbitrary code execution. These should use secure_getenv() >>> --- >> >> Hi, >> >> I don't see why secure_getenv() is appropriate here? These functions >> are never used in the libraries systemd provides, they are mostly used >> by systemctl and the dbus manager. Can you provide more details? > > You're right, but on the other hand secure_getenv() is usually > sufficient (we don't use setuid() nor fs-caps). So secure_getenv() > wouldn't hurt. I think it would hurt in a SELinux environment. Because if the AT_SECURE flag is set, secure_getenv will return NULL and tools like systemctl will fail for certain tasks. > But I don't really care.. > > Thanks > David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes
On 2015-03-16 04:12, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 10, 2015 at 09:07:41PM +0100, Goffredo Baroncelli wrote:
>> Allow systemd-tmpfiles to set the file/directory attributes, like chattr(1)
>> does. Two more commands are added: 'H' and 'h' to set the attributes,
>> recursively and not.
>> ---
>> src/tmpfiles/tmpfiles.c | 140
>>
>> 1 file changed, 140 insertions(+)
>>
>> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
>> index c948d4d..165605f 100644
>> --- a/src/tmpfiles/tmpfiles.c
>> +++ b/src/tmpfiles/tmpfiles.c
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "log.h"
>> #include "util.h"
>> @@ -90,6 +91,8 @@ typedef enum ItemType {
>> ADJUST_MODE = 'm', /* legacy, 'z' is identical to this */
>> RELABEL_PATH = 'z',
>> RECURSIVE_RELABEL_PATH = 'Z',
>> +SET_ATTRIB = 'h',
>> +RECURSIVE_SET_ATTRIB = 'H',
>> } ItemType;
>>
>> typedef struct Item {
>> @@ -108,12 +111,15 @@ typedef struct Item {
>> usec_t age;
>>
>> dev_t major_minor;
>> +int attrib_value;
>> +int attrib_mask;
>>
>> bool uid_set:1;
>> bool gid_set:1;
>> bool mode_set:1;
>> bool age_set:1;
>> bool mask_perms:1;
>> +bool attrib_set:1;
>>
>> bool keep_first_level:1;
>>
>> @@ -762,6 +768,115 @@ static int path_set_acls(Item *item, const char *path)
>> {
>> return 0;
>> }
>>
>> +static int get_attrib_from_arg(Item *item) {
>> +static const struct { int value; char ch; } attributes[] = {
>> +{ FS_NOATIME_FL, 'A' }, /* do not update atime */
>> +{ FS_SYNC_FL, 'S' }, /* Synchronous updates */
>> +{ FS_DIRSYNC_FL, 'D' }, /* dirsync behaviour (directories
>> only) */
>> +{ FS_APPEND_FL, 'a' },/* writes to file may only append
>> */
>> +{ FS_COMPR_FL, 'c' }, /* Compress file */
>> +{ FS_NODUMP_FL, 'd' },/* do not dump file */
>> +{ FS_EXTENT_FL, 'e'}, /* Top of directory hierarchies*/
>> +{ FS_IMMUTABLE_FL, 'i' }, /* Immutable file */
>> +{ FS_JOURNAL_DATA_FL, 'j' }, /* Reserved for ext3 */
>> +{ FS_SECRM_FL, 's' }, /* Secure deletion */
>> +{ FS_UNRM_FL, 'u' }, /* Undelete */
>> +{ FS_NOTAIL_FL, 't' },/* file tail should not be merged
>> */
>> +{ FS_TOPDIR_FL, 'T' },/* Top of directory hierarchies*/
>> +{ FS_NOCOW_FL, 'C' }, /* Do not cow file */
>> +{ 0, 0 }
>> +};
>> +char *p = item->argument;
>> +enum {
>> +MODE_ADD,
>> +MODE_DEL,
>> +MODE_SET
>> +} mode = MODE_ADD;
>> +unsigned long value = 0, mask = 0;
>> +
>> +if (!p) {
>> +log_error("\"%s\": setting ATTR need an argument",
>> item->path);
>> +return -EINVAL;
>> +}
>> +
>> +if (*p == '+') {
>> +mode = MODE_ADD;
>> +p++;
>> +} else if (*p == '-') {
>> +mode = MODE_DEL;
>> +p++;
>> +} else if (*p == '=') {
>> +mode = MODE_SET;
>> +p++;
>> +}
>> +
>> +if (!*p && mode != MODE_SET) {
>> +log_error("\"%s\": setting ATTR: argument is empty",
>> item->path);
>> +return -EINVAL;
>> +}
>> +for (; *p ; p++) {
>> +int i;
>> +for (i = 0; attributes[i].ch && attributes[i].ch != *p; i++)
>> +;
> Why not order the table the other way:
>
> static const int attributes[] = {
>[(uint8_t)'A'] = FS_NOATIME_FL, /* do not update atime */
>...
> };
>
> if ((uint8_t)*p > ELEMENTSOF(attributes) || attributes[(uint8_t)*p]
> == 0)
> log_error("\"%s\": setting ATTR: unknown attr '%c'",
> item->path, *p);
> return -EINVAL;
> }
>
> Not looping is always nicer.
I find this idea very elegant, my only concern was the memory occupation: the
ascii code
for the 't' letter is about 120, this means that the array will have a size of
~240 bytes...
Ok that the PC have several GBs
>
>> +if (!attributes[i].ch) {
>> +log_error("\"%s\": setting ATTR: unknown attr
>> '%c'", item->path, *p);
>> +return -EINVAL;
>> +}
>> +if (mode == MODE_ADD || mode == MODE_SET)
>> +value |= attributes[i].value;
>> +else
>> +value &= ~attributes[i].value;
>> +mask |= attributes[i].value;
>> +}
>> +
>> +
Re: [systemd-devel] [PATCH 3/4] Update the man page of tmpfiles.d(5), to document the new h/H command.
On 2015-03-16 04:24, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 10, 2015 at 09:07:42PM +0100, Goffredo Baroncelli wrote: >> Update the man page of tmpfiles.d(5), to document the new h/H command. >> --- >> man/tmpfiles.d.xml | 32 >> 1 file changed, 32 insertions(+) >> >> diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml >> index 8815bf9..469deeb 100644 >> --- a/man/tmpfiles.d.xml >> +++ b/man/tmpfiles.d.xml >> @@ -303,6 +303,37 @@ >> >> >> >> + h >> + Set file/directory attributes. Lines of this type >> + accept shell-style globs in place of normal path names. >> + >> + The format of the argument field is >> [+-=][aAcCdDeijsStTu] >> + >> + >> + The prefix + causes the >> + attribute(s) to be added; - causes the >> + attribute(s) to be removed; = >> + causes the attributes to set exactly as the following >> letters. > What happens if neither of the three prefix lettes is used? This > should be documented. ok > >> + The letters 'aAcCdDeijsStTu' select the new > instead of ''. ok > >> + attributes for the files, see >> + chattr >> + 1 for further information. >> + >> + Passing only = as argument, >> + reset all the file attributes. > resets > > So, is this description accurate? Operations on the attributes are > explicitly limited to the ones corresponding to the letters above (by > using a mask). But files can have other attributes, and the kernel might > define new attributes as some point. So maybe add a sentence like > "When operating on attributes, system-tmpfiles limits itself to the > attributes corresponding to the letters listed above. All other attributes > will be left untouched, even with =." > > Zbyszek You are right, good catch ! > >> + >> + >> + >> + >> + >> + H >> + Recursively set file/directory attributes. Lines >> + of this type accept shell-style globs in place of normal >> + path names. >> + >> + >> + >> + >>a >>a+ >>Set POSIX ACLs (access control lists). If >> @@ -529,6 +560,7 @@ >>> project='man-pages'>setfattr1, >>> project='man-pages'>setfacl1, >>> project='man-pages'>getfacl1 >> + > project='man-pages'>chattr1 >> >> >> >> -- >> 2.1.4 >> >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] path-lookup: use secure_getenv()
On Mon, Mar 16, 2015, at 02:31 PM, Ronny Chevalier wrote: > I think it would hurt in a SELinux environment. Because if the > AT_SECURE flag is set, secure_getenv will return NULL and tools like > systemctl will fail for certain tasks. Yeah, beware the possible regressions here, see e.g.: https://bugs.freedesktop.org/show_bug.cgi?id=52202#c25 Last time I looked at this I ended up deciding it was the responsibility of setuid binaries to whitelist their environment. Libraries may use choose to use secure_getenv() from the start, but *changing* an existing libary that way also changes the semantics of all setuid binaries using it, and needs evaluatoin. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/6] refactor in_addr_to_string()
2015-03-11 16:13 GMT+01:00 Shawn Landden :
> ---
Hi,
> src/resolve/resolved-dns-rr.c | 6 ++
> src/shared/in-addr-util.c | 32 +++-
> 2 files changed, 13 insertions(+), 25 deletions(-)
>
> diff --git a/src/resolve/resolved-dns-rr.c b/src/resolve/resolved-dns-rr.c
> index 78d9e4a..a73ccd7 100644
> --- a/src/resolve/resolved-dns-rr.c
> +++ b/src/resolve/resolved-dns-rr.c
> @@ -527,13 +527,11 @@ int dns_resource_record_to_string(const
> DnsResourceRecord *rr, char **ret) {
> break;
>
> case DNS_TYPE_A: {
> -_cleanup_free_ char *x = NULL;
> -
> -r = in_addr_to_string(AF_INET, (const union in_addr_union*)
> &rr->a.in_addr, &x);
> +r = in_addr_to_string(AF_INET, (const union in_addr_union*)
> &rr->a.in_addr, &t);
> if (r < 0)
> return r;
>
> -s = strjoin(k, " ", x, NULL);
> +s = strjoin(k, " ", t, NULL);
> if (!s)
> return -ENOMEM;
> break;
> diff --git a/src/shared/in-addr-util.c b/src/shared/in-addr-util.c
> index b7532a6..f23b343 100644
> --- a/src/shared/in-addr-util.c
> +++ b/src/shared/in-addr-util.c
> @@ -22,6 +22,7 @@
> #include
>
> #include "in-addr-util.h"
> +#include "socket-util.h"
>
> int in_addr_is_null(int family, const union in_addr_union *u) {
> assert(u);
> @@ -179,31 +180,20 @@ int in_addr_prefix_next(int family, union in_addr_union
> *u, unsigned prefixlen)
> }
>
> int in_addr_to_string(int family, const union in_addr_union *u, char **ret) {
> -char *x;
> -size_t l;
> +union sockaddr_union sa;
>
> -assert(u);
> -assert(ret);
> +sa.sa.sa_family = family;
>
> -if (family == AF_INET)
> -l = INET_ADDRSTRLEN;
> -else if (family == AF_INET6)
> -l = INET6_ADDRSTRLEN;
> -else
> -return -EAFNOSUPPORT;
> +if (sa.sa.sa_family == AF_INET) {
> +sa.in.sin_addr = u->in;
>
> -x = new(char, l);
> -if (!x)
> -return -ENOMEM;
> +return sockaddr_pretty(&sa.sa, (socklen_t)sizeof(sa.in),
> false, false, ret);
> +} else if (family == AF_INET6) {
> +sa.in6.sin6_addr = u->in6;
>
> -errno = 0;
> -if (!inet_ntop(family, u, x, l)) {
> -free(x);
> -return errno ? -errno : -EINVAL;
> -}
> -
> -*ret = x;
> -return 0;
> +return sockaddr_pretty(&sa.sa, (socklen_t)sizeof(sa.in6),
> false, false, ret);
> +} else
> +return -EAFNOSUPPORT;
> }
>
I don't see the benefit of refactoring this way.
sockaddr_pretty internally uses inet_ntop for AF_INET6 according to
the parameters you gave it, and for AF_INET it will gave us exactly
the same output without using inet_ntop. So in the end it would be the
same output, but it will add some overhead from sockaddr_pretty.
Could you elaborate?
Ronny
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/4] Update the man page of tmpfiles.d(5), to document the new h/H command.
From: Goffredo Baroncelli Update the man page of tmpfiles.d(5), to document the new h/H command. --- man/tmpfiles.d.xml | 36 1 file changed, 36 insertions(+) diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml index 8815bf9..a532f91 100644 --- a/man/tmpfiles.d.xml +++ b/man/tmpfiles.d.xml @@ -303,6 +303,41 @@ + h + Set file/directory attributes. Lines of this type + accept shell-style globs in place of normal path names. + + The format of the argument field is [+-=][aAcCdDeijsStTu] + + + The prefix + (the default one) causes the + attribute(s) to be added; - causes the + attribute(s) to be removed; = + causes the attributes to set exactly as the following letters. + The letters aAcCdDeijsStTu select the new + attributes for the files, see + chattr + 1 for further information. + + Passing only = as argument, + resets all the file attributes listed above. It has to be pointed + out that the = prefix, limits itself to the + attributes corresponding to the letters listed here. All other + attributes will be left untouched. + + + + + + + H + Recursively set file/directory attributes. Lines + of this type accept shell-style globs in place of normal + path names. + + + + a a+ Set POSIX ACLs (access control lists). If @@ -529,6 +564,7 @@ setfattr1, setfacl1, getfacl1 + chattr1 -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes
From: Goffredo Baroncelli
Allow systemd-tmpfiles to set the file/directory attributes, like chattr(1)
does. Two more commands are added: 'H' and 'h' to set the attributes,
recursively and not.
---
src/tmpfiles/tmpfiles.c | 140
1 file changed, 140 insertions(+)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index c948d4d..e1a22f5 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "log.h"
#include "util.h"
@@ -90,6 +91,8 @@ typedef enum ItemType {
ADJUST_MODE = 'm', /* legacy, 'z' is identical to this */
RELABEL_PATH = 'z',
RECURSIVE_RELABEL_PATH = 'Z',
+SET_ATTRIB = 'h',
+RECURSIVE_SET_ATTRIB = 'H',
} ItemType;
typedef struct Item {
@@ -108,12 +111,15 @@ typedef struct Item {
usec_t age;
dev_t major_minor;
+int attrib_value;
+int attrib_mask;
bool uid_set:1;
bool gid_set:1;
bool mode_set:1;
bool age_set:1;
bool mask_perms:1;
+bool attrib_set:1;
bool keep_first_level:1;
@@ -762,6 +768,115 @@ static int path_set_acls(Item *item, const char *path) {
return 0;
}
+static int get_attrib_from_arg(Item *item) {
+static const unsigned attributes[] = {
+[(uint8_t)'A'] = FS_NOATIME_FL,/* do not update atime */
+[(uint8_t)'S'] = FS_SYNC_FL, /* Synchronous updates */
+[(uint8_t)'D'] = FS_DIRSYNC_FL, /* dirsync behaviour
(directories only) */
+[(uint8_t)'a'] = FS_APPEND_FL,/* writes to file may only
append */
+[(uint8_t)'c'] = FS_COMPR_FL, /* Compress file */
+[(uint8_t)'d'] = FS_NODUMP_FL,/* do not dump file */
+[(uint8_t)'e'] = FS_EXTENT_FL,/* Top of directory
hierarchies*/
+[(uint8_t)'i'] = FS_IMMUTABLE_FL, /* Immutable file */
+[(uint8_t)'j'] = FS_JOURNAL_DATA_FL, /* Reserved for ext3 */
+[(uint8_t)'s'] = FS_SECRM_FL, /* Secure deletion */
+[(uint8_t)'u'] = FS_UNRM_FL, /* Undelete */
+[(uint8_t)'t'] = FS_NOTAIL_FL,/* file tail should not be
merged */
+[(uint8_t)'T'] = FS_TOPDIR_FL,/* Top of directory
hierarchies*/
+[(uint8_t)'C'] = FS_NOCOW_FL, /* Do not cow file */
+};
+const unsigned all_flags = FS_NOATIME_FL|FS_SYNC_FL|FS_DIRSYNC_FL|
+FS_APPEND_FL|FS_COMPR_FL|FS_NODUMP_FL|FS_EXTENT_FL|
+FS_IMMUTABLE_FL|FS_JOURNAL_DATA_FL|FS_SECRM_FL|FS_UNRM_FL|
+FS_NOTAIL_FL|FS_TOPDIR_FL|FS_NOCOW_FL;
+char *p = item->argument;
+enum {
+MODE_ADD,
+MODE_DEL,
+MODE_SET
+} mode = MODE_ADD;
+unsigned long value = 0, mask = 0;
+
+if (!p) {
+log_error("\"%s\": setting ATTR need an argument", item->path);
+return -EINVAL;
+}
+
+if (*p == '+') {
+mode = MODE_ADD;
+p++;
+} else if (*p == '-') {
+mode = MODE_DEL;
+p++;
+} else if (*p == '=') {
+mode = MODE_SET;
+p++;
+}
+
+if (!*p && mode != MODE_SET) {
+log_error("\"%s\": setting ATTR: argument is empty",
item->path);
+return -EINVAL;
+}
+for (; *p ; p++) {
+if ((uint8_t)*p > ELEMENTSOF(attributes) ||
attributes[(uint8_t)*p] == 0) {
+log_error("\"%s\": setting ATTR: unknown attr '%c'",
item->path, *p);
+return -EINVAL;
+}
+if (mode == MODE_ADD || mode == MODE_SET)
+value |= attributes[(uint8_t)*p];
+else
+value &= ~attributes[(uint8_t)*p];
+mask |= attributes[(uint8_t)*p];
+}
+
+if (mode == MODE_SET)
+mask |= all_flags;
+
+assert(mask);
+
+item->attrib_mask = mask;
+item->attrib_value = value;
+item->attrib_set = true;
+
+return 0;
+
+}
+
+static int path_set_attrib(Item *item, const char *path) {
+_cleanup_close_ int fd = -1;
+int r;
+unsigned f;
+struct stat st;
+
+/* do nothing */
+if (item->attrib_mask == 0 || !item->attrib_set)
+return 0;
+/*
+ * It is OK to ignore an lstat() error, because the error
+ * will be catch by the open() below anyway
+ */
+if (lstat(path, &st) == 0 &&
+!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
+return 0;
+}
+
+fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
+
+if (fd < 0)
+
[systemd-devel] [PATCH 1/4] Add change_attr_fd()
From: Goffredo Baroncelli
Add change_attr_fd() function to modify the file/directory attribute.
---
src/shared/util.c | 22 ++
src/shared/util.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index ba035ca..56097ec 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -7832,6 +7832,28 @@ int chattr_path(const char *p, bool b, unsigned mask) {
return chattr_fd(fd, b, mask);
}
+int change_attr_fd(int fd, unsigned value, unsigned mask) {
+unsigned old_attr, new_attr;
+
+assert(fd >= 0);
+
+if (mask == 0)
+return 0;
+
+if (ioctl(fd, FS_IOC_GETFLAGS, &old_attr) < 0)
+return -errno;
+
+new_attr = (old_attr & ~mask) |(value & mask);
+
+if (new_attr == old_attr)
+return 0;
+
+if (ioctl(fd, FS_IOC_SETFLAGS, &new_attr) < 0)
+return -errno;
+
+return 0;
+}
+
int read_attr_fd(int fd, unsigned *ret) {
assert(fd >= 0);
diff --git a/src/shared/util.h b/src/shared/util.h
index a83b588..a0bc883 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -1052,6 +1052,7 @@ int same_fd(int a, int b);
int chattr_fd(int fd, bool b, unsigned mask);
int chattr_path(const char *p, bool b, unsigned mask);
+int change_attr_fd(int fd, unsigned value, unsigned mask);
int read_attr_fd(int fd, unsigned *ret);
int read_attr_path(const char *p, unsigned *ret);
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
From: Goffredo Baroncelli Add a new tmpfiles.d snippets to set the NOCOW attributes for the journal files. This allow better perfomance when the root file system is BTRFS. Pay attention that the NOCOW flags disables the checksum and prevent scrub to rebuild a corrupted journal. --- tmpfiles.d/journal-nocow.conf | 12 1 file changed, 12 insertions(+) create mode 100644 tmpfiles.d/journal-nocow.conf diff --git a/tmpfiles.d/journal-nocow.conf b/tmpfiles.d/journal-nocow.conf new file mode 100644 index 000..43a4f2b --- /dev/null +++ b/tmpfiles.d/journal-nocow.conf @@ -0,0 +1,12 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +# See tmpfiles.d(5) for details + + +# set the journal file as NOCOW; only valid for BTRFS filesystem +h /var/log/journal/%m - - - - +C -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH V4] Allow systemd-tmpfiles to set file/directory attributes
Hi all, This set of patches add two new line types to the tmpfiles files format. These new types of line are 'h' and 'H' (the recursively version), and allow to change the file/directory attributes, like chattr(1) does. One of the motivation of these patches is to get rid of the commit 11689d2a which force the NOCOW flag for the journal files. This was needed because systemd-journald has very poor performance when the filesytem is BTRFS due to its the COW behavior. My concern is that the NOCOW flag also prevent BTRFS to rebuild a corrupted file from a good copy if it is available. With this patch, now the NOCOW flag can be set by systemd-tmpfiles. See [1] for further information. BR G.Baroncelli Changelog: v1: first issue v2: accepted several suggestion on the style; added function change_attr_fd(); used the _cleanup_close_; returned negative errno; v3: swapped arguments of change_attr_fd() in path_set_attrib() v4:-changed the tables of attributes in function path_set_acls() -added a comment about the reason to ignore an error from lstat() -improved the man page of tmpfiles.d.5 highlighting that systemd-tmpfiles updates only the listed attributes in the man page [1] Re: [systemd-devel] [RFC][PATCH] Add option to enable COW for journal file https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28724.html -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd does not shutdown system, it is waiting for a serial tty to show up
Hi On Mon, Mar 16, 2015 at 7:32 PM, Hans de Goede wrote: > Hi, > > On 16-03-15 18:12, David Herrmann wrote: >> >> Hi Hans >> >> On Mon, Mar 16, 2015 at 5:15 PM, Hans de Goede >> wrote: >>> >>> Hi, >>> >>> On some of the ARM boards I work on in my spare time I've >>> done "systemctl enable getty@ttyGS0.service" to get a getty >>> on the usb gadget serial port which I've configured on the >>> devices otg controller. >>> >>> This serial port device node /dev/ttyGS0 shows up as soon >>> as the gadget serial port driver loads, but is only usable >>> when I plug in a the mini B end of a mini B -> A usb cable >>> where the A end is plugged into an active usb host. >>> >>> "ps aux" shows something peculiar here, when I do "ps aux" >>> before the cable is plugged in it shows "(agetty)" in >>> the args column of the output, when I then plug in the >>> cable the output changes to "/sbin/agetty --noclear ttyGS0 vt220" >>> note this is the same process, as before the cable was plugged, >>> I've a feeling that somehow the process is stuck halfway >>> exec or some such ... ?? >> >> >> We rename the process to "()" directly after fork(). So if it is >> still "(agetty)", something blocks before we can exec(). Can you run >> strace to figure out what call blocks? > > > strace -p says: > > write(3, "\33[r\33[H\33[2J", 10 Ok, this is vt_disallocate() running, which reminded me that you have to use serial-getty@.service for serial ttys. getty@.service is only for VTs. Can you check whether this solves your issues? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - src/fsckd src/shared
Hi
On Mon, Mar 16, 2015 at 6:58 PM, Didier Roche wrote:
> Le 16/03/2015 18:41, Zbigniew Jędrzejewski-Szmek a écrit :
>>
>> On Mon, Mar 16, 2015 at 10:33:54AM -0700, Tom Gundersen wrote:
>>>
>>> src/fsckd/fsckd.c | 13 ++---
>>> src/shared/util.c |4
>>> src/shared/util.h |2 ++
>>> 3 files changed, 16 insertions(+), 3 deletions(-)
>>>
>>> New commits:
>>> commit e26169bd48c64753510a1194abdf4fb5dc907123
>>> Author: Didier Roche
>>> Date: Tue Mar 10 10:05:19 2015 +0100
>>>
>>> fsckd: check if plymouth is running before attempting connection
>>>
>>> diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
>>> index f24715c..6b35fc2 100644
>>> --- a/src/fsckd/fsckd.c
>>> +++ b/src/fsckd/fsckd.c
>>> @@ -231,9 +231,12 @@ static int manager_connect_plymouth(Manager *m) {
>>> union sockaddr_union sa = PLYMOUTH_SOCKET;
>>> int r;
>>> +if (!plymouth_running())
>>> +return 0;
>>
>> Why do we need to do this check? We try to connect right below, and
>> we'll get a connection error if plymouth is not running.
>
>
> The issue is that we are raising a warning if we can't communicate to the
> socket while connecting. This behavior puzzled some users looking at their
> logs when they didn't get plymouth running early enough or at all (repeating
> connection warnings).
> There were 2 options:
> - downgrading the warning to a debug, which may never give a hint if the
> user is expecting to see something in plymouth and never get any connection
> - have the plymouth_running() check.
Why not check the error-code of connect()? Not sure what unix-sockets
return for unknown entries, but should be easy to figure out. Probably
EHOSTDOWN or EHOSTUNREACH? You'd safe a system-call and helper
function this way.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: ship ids-update.pl & sdio.ids in the release tarballs.
This makes it easier to apply stable branch patches on top of the release tarball. --- Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 856accb..0ed35ac 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \ hwdb/70-touchpad.hwdb EXTRA_DIST += \ - units/systemd-hwdb-update.service.in + units/systemd-hwdb-update.service.in \ + hwdb/ids-update.pl \ + hwdb/sdio.ids SYSINIT_TARGET_WANTS += \ systemd-hwdb-update.service -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl & sdio.ids in the release tarballs.
Hi Dimitri, > This makes it easier to apply stable branch patches on top of the > release tarball. > --- > Makefile.am | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index 856accb..0ed35ac 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -3877,7 +3877,9 @@ dist_udevhwdb_DATA = \ > hwdb/70-touchpad.hwdb > > EXTRA_DIST += \ > - units/systemd-hwdb-update.service.in > + units/systemd-hwdb-update.service.in \ > + hwdb/ids-update.pl \ > + hwdb/sdio.ids I do not think that these files belong in the tarball. Especially the sdio.ids is not something that should be in the tarball. If it is missing locally, a script can always download it rom systemd.git tree. That is where the source is for these and not the tarball. If you want to apply patches from git, then you can always tell git to exclude these files and it will happily apply the rest of the patch. So I do not see a good enough reason to do this. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
