Re: [systemd-devel] [PATCH] shorten_uuid: use proper table size
10.06.2014 at 19:20 Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.05.14 11:24, Maciej Wereski (m.were...@partner.samsung.com) wrote: When the function is called the buffer is filled with 36 chars, and we then strip the non-hex-chars, so that 34 chars result. But the function signature should still indicate that we need 36 chars initially.. Lennart Well, i ( 36) is used for source and j ( 32) is used for destination. After the loop destination[32] and destination[33] is set. Also shorten_uuid() is used in two places, where id[34] is passed as destination. So it looked for me like destination should be 34. I am an idiot and you are right... I now merged a patch that turns both strings into arrays and we speciy both sizes. I hope that cleans up the confusion. Please check! Lennart Looks good, thanks. regards, -- Maciej Wereski Samsung RD Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] HandleLidSwitch v204
On Mon, 09.06.14 23:09, Justin Brown (justin.br...@fandingo.org) wrote: I need to run Fedora 19 (systemd 204) for a particular piece of software on a laptop, and I'm having trouble disabling suspend when I shut the screen. My default target is multi-user.target, and the laptop is not connected to any external monitors. I made the following change to /etc/systemd/logind.conf and rebooted: HandleLidSwitch=ignore However, the systemd is still suspending. What else do I need to change to disable this behavior? Are you sure it's logind that issues the suspend? Do you see any logs from logind when you try to suspend? it should normally log if it is responsible for the suspend. Try journalctl -u systemd-logind. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
On Mon, 09.06.14 20:05, Jan Alexander Steffens (heftig) (jan.steff...@gmail.com) wrote: They shouldn't be executable nor world-readable. I have now committed a different set of patches to clean this up for good: I have made m a true alias of z since it was pretty much a non-globbing version of z, and hence redundant. I have also removed m from the docs, so that people use only z from now on. I have also introduced a new syntax for access modes: if the access mode is prefixed with ~ it will be masked by the executability, readability, and writability of the existing node. Also, the suid/sgid/sticky bits will be masked if the existing node is a directory. This makes Z a lot more useful, for recursively applying access modes. Then, I have changed journald to always create /run/log/journal/%m as 0750 (i.e. dropped world-readability), so that unpriviliged processes don't even get access to the dir at all. /var/log/journal/%m keeps the 0755 however, since on /var we do the per-user ACL magic, and hence unpriviliged users need read access to the dir after all... I have also downgraded the Z to z for /var/log/journal/%m, since that might get expensive, since there might be a lot of files in there. Also, given the we never write to the dir befor tmpfiles ran (and thus the sgid bit was set) it appears unnecessary to recursively adjust the mode/user/group of all files in the dir. This is different for /run/log/journal/%m of course, since that is volatile, and we start writing to it very early on. This should settle all the confusion and chaos around the handling of the journal files in tmpfiles. Please test if everything works correctly now! Anway, thanks for the patch! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
On Tue, 10.06.14 10:13, Brandon Philips (bran...@ifup.co) wrote: Can you please point me to the implementation? All I've seen is this: https://github.com/coreos/go-systemd/blob/master/journal/send.go Which only handles writes via the Unix socket. The implementation we're prototyping supports journal queries in ways that (to my knowledge) aren't possible without either forking to external tools (e.g. journalctl) or linking to sd-journal. The reason I didn't implement the sd-journal binding originally was because I thought that the journal DBus API would be coming sooner. I think adding this is great as-is and would happily merge it back upstream. We just have to be aware that eventually this API will need to expose a KDBus API too. Note that the kdbus API of journald will probably never allow you to read the journal files. It will provide APIs to log, but for reading the files we want to avoid the price for IPC and just always go directly via file system accesses. Hence going via sd-journal to access the files should be future-proof. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Detecting failed units based on active state
Hi, We have written a component that detects failing units in the system. This registers for the PropertiesChanged signal, to be notified whenever the ActiveState of a unit changes. However this signal is sent without the property values. This can result in a problem when a unit is restarted fast (i.e. RestartSec=0) because we miss the FailedState and can not distinguish between a failed unit and a unit that was intentionally stopped and restarted. We looked at using the InactiveEnterTimestamp however there we also can not make the distinction. Does anyone have any ideas on how we could handle this problem (i.e. other properties that could be used)? In case there is no solution we wondered about introducing a new property (UnitFailedCount) to track the number of failures within the current lifecycle. Any thoughts?? Thanks Dave Software Architect System Software I IC RD G SW SSW HKT Continental Automotive GmbH Interior Infotainment Connectivity Philipsstrasse 1, 35576 Wetzlar, Germany Telefon/Phone: +49 6441 370-8289 Mobile/Handy: +49 151 6522 9102___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Hi Lennart, However, if we do this, then this needs to be a passive target, see systemd.special(7), under Special passive system units, and it should be documented in that section. Passive means it is pulled it by the units that implement a pre job, not by the units that implement the networking stack. This way it doesn't get added to the initial transaction unless there's actually some service that needs to be pulled in. See the man page for further discussion on this. I figure we don't really need network-pre.target, as units that want to run before the network is up should just use: Before=systemd-networkd.service basic.target From my v3 patch cover letter in reply to Zbyszek: Before=basic.target means lots of totally unrelated units can't be started in parallel to the firewall. More importantly, you'd also need RequiredBy=basic.target to make the network fail closed if e.g. iptables can't load a module. But then you end up with a stump of a system. I don't know if this property can be fit into the passive unit model. Maybe the target should have a different name? THis is enough since network management services like NM are normal services, and networkd is the exception in being available from earliest boot on, including in the initrd. I've never used systemd inside an initrd, but wouldn't DefaultDependencies=false make the target work in both both early and late systemd? Rusty signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Tue, 10.06.14 22:16, Michael Biebl (mbi...@gmail.com) wrote: 2014-06-10 19:44 GMT+02:00 Lennart Poettering lenn...@poettering.net: I figure we don't really need network-pre.target, as units that want to run before the network is up should just use: Before=systemd-networkd.service basic.target THis is enough since network management services like NM are normal services, and networkd is the exception in being available from earliest boot on, including in the initrd. This means, that any firewall service that wants to cover this must be a early-boot service (i.e. DefaultDependencies=no), and thus ordering itself before networkd and basic.target should suffice... If one day there's another network management solution that is capable of running this early during boot, then we can revisit this, but otherwise, the ordering mentioned above should be above, and generic enough since it requires no explicit mentioning of units we wouldn't ship with systemd anyway. Debian's ifupdown does run during early boot, i.e. in sysinit.target. Hmm.. OK. OK. I added this now, with a different patch, and made it a passive unit as discussed. I have also changed systemd-networkd to make use of it properly. Somebody should update the other network management services too like this i figure... I have also updated http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ to describe the entire new behaviour we have now in place. It would be great if somebody could proof-read that (and fix typos immediately, though I mostly interested in technical feedback). Hope this settles this topic! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Wed, 11.06.14 10:18, Rusty Bird (rustyb...@openmailbox.org) wrote: Hi Lennart, However, if we do this, then this needs to be a passive target, see systemd.special(7), under Special passive system units, and it should be documented in that section. Passive means it is pulled it by the units that implement a pre job, not by the units that implement the networking stack. This way it doesn't get added to the initial transaction unless there's actually some service that needs to be pulled in. See the man page for further discussion on this. I figure we don't really need network-pre.target, as units that want to run before the network is up should just use: Before=systemd-networkd.service basic.target From my v3 patch cover letter in reply to Zbyszek: Before=basic.target means lots of totally unrelated units can't be started in parallel to the firewall. Well, true. But we that's the deal wth basic.target. It abstracts the early-boot stuff away, making things a lot easier, at the price of slightly less parallelization. More importantly, you'd also need RequiredBy=basic.target to make the network fail closed if e.g. iptables can't load a module. But then you end up with a stump of a system. I don't know if this property can be fit into the passive unit model. Maybe the target should have a different name? I am not convinced that the firewall being broken should break the boot. If that's deserible, then people should use: OnFailure=emergency.target OnFailureJobMode=replace-irreversibly Which puts the system in emergency mode if the firewall is fucked up. But again, I am pretty sure that should not be the default logic, but just some specific configuration for special setups. Anyway, this is implemented now, please have a look (see other mail). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] doc: specify kernel configs for cpushares
On Tue, 10.06.14 23:29, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Applied! Thanks! --- README |4 1 file changed, 4 insertions(+) diff --git a/README b/README index f01087f..011c7f6 100644 --- a/README +++ b/README @@ -80,6 +80,10 @@ REQUIREMENTS: CONFIG_TMPFS_XATTR CONFIG_SECCOMP +Required for CPUShares in resource control unit settings + CONFIG_CGROUP_SCHED + CONFIG_FAIR_GROUP_SCHED + For systemd-bootchart, several proc debug interfaces are required: CONFIG_SCHEDSTATS CONFIG_SCHED_DEBUG Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting failed units based on active state
Hmm, didn't this get fixed in recent versions? I seem to remember that after the sd-bus port systemd started sending changed_properties with values, not just invalidated_properties... -- Mantas Mikulėnas graw...@gmail.com // sent from phone On Jun 11, 2014 12:59 PM, david.ya...@continental-corporation.com wrote: Hi, We have written a component that detects failing units in the system. This registers for the PropertiesChanged signal, to be notified whenever the ActiveState of a unit changes. However this signal is sent without the property values. This can result in a problem when a unit is restarted fast (i.e. RestartSec=0) because we miss the FailedState and can not distinguish between a failed unit and a unit that was intentionally stopped and restarted. We looked at using the InactiveEnterTimestamp however there we also can not make the distinction. Does anyone have any ideas on how we could handle this problem (i.e. other properties that could be used)? In case there is no solution we wondered about introducing a new property (UnitFailedCount) to track the number of failures within the current lifecycle. Any thoughts?? Thanks Dave Software Architect System Software I IC RD G SW SSW HKT Continental Automotive GmbH Interior Infotainment Connectivity Philipsstrasse 1, 35576 Wetzlar, Germany Telefon/Phone: +49 6441 370-8289 Mobile/Handy: +49 151 6522 9102 ___ 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] systemd not initializing
Hi, I am working on the Freescale hardware. I am using u-boot and uImage provided with hardware. When I try to boot the Tizen on my board, It boots u-boot and kernel uImage loads fine. But it stops at Freeing Init Memory: 244k and does not do anything. I wanted to know how does the kernel contact systemd for initialization? I checked the kernel configurations and made is suitable for systemd initialization, but still the same problem remains. I don't get login prompt , so I can't debug what's going on during initialization process through sysctl . Could anybody suggest what could I be missing or any help on explanation on how kernel passes command to system initialization? Thanks, Jay ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com http://www.igate.com. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Lennart Poettering: I am not convinced that the firewall being broken should break the boot. It shouldn't! But there should be at least an option (arguably the default) to break *connectivity*. With the v1-v3 patches that's decided by the firewall service, which chooses if it is RequiredBy=, or WantedBy=, network-pre.target. Anyway, this is implemented now, please have a look (see other mail). Please don't release this as is. Fail-open firewall activation will get many people in trouble. Rusty signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not initializing
On Wed, Jun 11, 2014 at 2:04 PM, Jay D Bhatt jay.bh...@igate.com wrote: Hi, I am working on the Freescale hardware. I am using u-boot and uImage provided with hardware. When I try to boot the Tizen on my board, It boots u-boot and kernel uImage loads fine. But it stops at “Freeing Init Memory: 244k” and does not do anything. I wanted to know how does the kernel contact systemd for initialization? I checked the kernel configurations and made is suitable for systemd initialization, but still the same problem remains. I don’t get login prompt , so I can’t debug what’s going on during initialization process through sysctl . Could anybody suggest what could I be missing or any help on explanation on how kernel passes command to system initialization? It works the same way as other init systems: If you use an initramfs, the kernel looks for an /init program inside, and executes it as PID 1. (The initramfs /init then mounts real root and exec's /sbin/init found there.) Without an initramfs, the kernel looks for /sbin/init, /etc/init, /bin/init directly on the root filesystem (can be overridden using the init=... option) (The initramfs /init itself can be systemd, though most distros have it as just a shell script.) Try the boot options loglevel=6, systemd.log_level=debug, or init=/bin/sh. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Wed, 11.06.14 11:13, Rusty Bird (rustyb...@openmailbox.org) wrote: Lennart Poettering: I am not convinced that the firewall being broken should break the boot. It shouldn't! But there should be at least an option (arguably the default) to break *connectivity*. well, but that's better solved with the firewalling logic itself. For example by first installing a drop-all rule in the tables, which is finally removed when all updated have been made. Should the script fail, then the firewall will not let any data through, and you should be fine. I am not convinced that the init system should be involved in such a logic. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detecting failed units based on active state
On Wed, 11.06.14 13:43, Mantas Mikulėnas (graw...@gmail.com) wrote: Hmm, didn't this get fixed in recent versions? I seem to remember that after the sd-bus port systemd started sending changed_properties with values, not just invalidated_properties... This is indeed the case. In more recent versions most properties will send out change messages with the full contnets, only very few just used the invalidation thing. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] NEWS: fix directory name
--- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 54d9e9e..1effaf5 100644 --- a/NEWS +++ b/NEWS @@ -52,7 +52,7 @@ CHANGES WITH 214: transports. Instead it is assumed the kernel loads them automatically when required. This only works correctly on very new kernels. On older kernels, please consider adding - the kernel modules to /etc/load-modules.d/ as a work-around. + the kernel modules to /etc/modules-load.d/ as a work-around. * The resolv.conf file systemd-resolved generates has been moved to /run/systemd/resolve/, if you have a symlink from -- 2.0.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Lennart Poettering: On Wed, 11.06.14 11:13, Rusty Bird (rustyb...@openmailbox.org) wrote: Lennart Poettering: I am not convinced that the firewall being broken should break the boot. It shouldn't! But there should be at least an option (arguably the default) to break *connectivity*. well, but that's better solved with the firewalling logic itself. For example by first installing a drop-all rule in the tables, which is finally removed when all updated have been made. Should the script fail, then the firewall will not let any data through, and you should be fine. I don't think it's possible to implement a fail-closed logic inside the firewall payload: For example, the netfilter module could be missing after a kernel upgrade, or a dynamically linked iptables binary could be broken by a library upgrade, etc. Then you'll be unable to insert a drop-all rule. I am not convinced that the init system should be involved in such a logic. Isn't it troubling that the status quo requires so much unintuitive and undocumented busywork from each user? For a security-critical component! I mean, let's survey the landscape: - Arch and Gentoo ship unsafe iptables-restore services, as do probably most other distros. - Folks on this mailing list who are more familiar with systemd than I'll ever be proposed sensible looking dependency specifications, but they turned out to be unsafe, too. These DIY contraptions have some razor sharp edges. So why not factor out the correct logic, at seemingly no cost beyond the minimal overhead for an empty target? Rusty signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
On Wed, Jun 11, 2014 at 10:53:53AM +0200, Lennart Poettering wrote: On Mon, 09.06.14 20:05, Jan Alexander Steffens (heftig) (jan.steff...@gmail.com) wrote: They shouldn't be executable nor world-readable. I have now committed a different set of patches to clean this up for good: I have made m a true alias of z since it was pretty much a non-globbing version of z, and hence redundant. I have also removed m from the docs, so that people use only z from now on. I have also introduced a new syntax for access modes: if the access mode is prefixed with ~ it will be masked by the executability, readability, and writability of the existing node. Also, the suid/sgid/sticky bits will be masked if the existing node is a directory. This makes Z a lot more useful, for recursively applying access modes. Then, I have changed journald to always create /run/log/journal/%m as 0750 (i.e. dropped world-readability), so that unpriviliged processes don't even get access to the dir at all. /var/log/journal/%m keeps the 0755 however, since on /var we do the per-user ACL magic, and hence unpriviliged users need read access to the dir after all... I have also downgraded the Z to z for /var/log/journal/%m, since that might get expensive, since there might be a lot of files in there. Also, given the we never write to the dir befor tmpfiles ran (and thus the sgid bit was set) it appears unnecessary to recursively adjust the mode/user/group of all files in the dir. This is different for /run/log/journal/%m of course, since that is volatile, and we start writing to it very early on. This should settle all the confusion and chaos around the handling of the journal files in tmpfiles. Please test if everything works correctly now! Nice, that sounds like a much better change. I'll test this all out soon to make sure a first boot on a clean system works properly. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
'Twas brillig, and Dave Reisner at 10/06/14 18:10 did gyre and gimble: Traditional configuration files have their own content. They can be hashed and tracked by your package manager. On upgrade, you can make an intelligent decision about what to do with the new file (replace, ignore, merge) based on the original and current hash of the existing file, and the has of the incoming file. Symlinks are more of a binary decision -- either they exist, or they don't. But, they're still configuration in this context. There's no way to track this on/off bit, so distros (well, speaking of Arch) simply nuke the symlinks and add back what they see as sane defaults during installation (explicitly leaving the symlinks untracked). Yeah, this can be a pain. For us in RPM, we have to recreate the new symlinks that have been added with a conditional trigger (i.e. when upgrading from a version older an X, then add this new symlink but also duplicate the symlink creation for the fresh install case too - here a preset file would be useful, but special care would need to be taken when doing version upgrades to make sure any changes to the presets were properly factored into the version-conditional triggers too). I mean, ideally we'd just invoke systemctl preset for these things, but for the sake of cross-compilation we can avoid this easily. We probably should ship make sure to ship the very same symlinks we create with make install with a preset file though... Sadly reapplying a preset on upgrade isn't really an option as it will restore things users have specifically removed. Is there some magic RPM trick I'm missing here? I mean we don't package these symlinks as such, they are all created in %post... I think that's how it's done in Fedora too right? As mentioned above the preset would be useful for the fresh install scenario, but upgrades still have to be handled quite carefully and explicitly. Don't get me wrong, it's not that much effort, but it's still a gotcha to worry about! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert flop...@gentoo.org wrote: On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Again, that's exactly what happens for configuration files too if you use automake: on make install they are replaced by the original, upstream versions. Why is recreating the symlinks bad, if overriding the config files isn't? People don't generally remove config files; they just make changes. On the other hand, removing the symlinks would be a very typical action due to the way systemctl disable works. There is some ambiguity as to what a missing symlink means: did the sysadmin remove it, or did it never exist in the first place? But there is `equery f`, so it shouldn't be too hard to figure this out, right? If systemctl disable would do something like create a symlink to /dev/null, that would be easier to detect. I suppose we should implement something like Debian's conffiles to protect file removals, but that's probably not going to be a very high priority given the small number of packages for which it really matters. ___ 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] [PATCH 1/2] connection: fix cpu stall by checking kdbus item alignment
Fix the following stall triggered by a policy holder hello:
call test/kdbus-util.c:kdbus_hello_registrar() and pass
KDBUS_HELLO_POLICY_HOLDER as a flag.
While we are it make sure that kdbus_cmd_conn_update() also checks for
proper 8 byte alignment.
[ 142.731011] INFO: rcu_sched self-detected stall on CPU { 3} (t=65000
jiffies g=3085 c=3084 q=4316)
[ 142.731011] sending NMI to all CPUs:
[ 142.731011] NMI backtrace for cpu 3
[ 142.731011] CPU: 3 PID: 1352 Comm: test-kdbus-poli Tainted: G OE
3.15.0-0.rc8.git4.1.fc21.x86_64 #1
[ 142.731011] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 142.731011] task: 88005a2719d0 ti: 88004587c000 task.ti:
88004587c000
[ 142.731011] RIP: 0010:[81055a12] [81055a12]
flat_send_IPI_all+0x92/0xd0
[ 142.731011] RSP: 0018:88005dc03dc0 EFLAGS: 00010006
[ 142.731011] RAX: RBX: 0c00 RCX:
[ 142.731011] RDX: 0c00 RSI: RDI: 0300
[ 142.731011] RBP: 88005dc03dd8 R08: 0001 R09: 0001
[ 142.731011] R10: 81e5d720 R11: 0001 R12: 0046
[ 142.731011] R13: 000f R14: 81e86880 R15: 0003
[ 142.731011] FS: 7f4b9d727740() GS:88005dc0()
knlGS:
[ 142.731011] CS: 0010 DS: ES: CR0: 8005003b
[ 142.731011] CR2: 00401312 CR3: 5b66f000 CR4: 06e0
[ 142.731011] Stack:
[ 142.731011] 2710 81e86880 81fa3e40
88005dc03df0
[ 142.731011] 81050654 88005ddcf000 88005dc03e48
8111a194
[ 142.731011] 7fff 0046
10dc
[ 142.731011] Call Trace:
[ 142.731011] IRQ
[ 142.731011] [81050654] arch_trigger_all_cpu_backtrace+0x64/0xa0
[ 142.731011] [8111a194] rcu_check_callbacks+0x584/0x850
[ 142.731011] [810a74a7] update_process_times+0x47/0x70
[ 142.731011] [81126765] tick_sched_handle.isra.19+0x25/0x60
[ 142.731011] [81127061] tick_sched_timer+0x41/0x60
[ 142.731011] [810c7446] __run_hrtimer+0x86/0x460
[ 142.731011] [81127020] ? tick_sched_do_timer+0x40/0x40
[ 142.731011] [810c809f] hrtimer_interrupt+0x10f/0x260
[ 142.731011] [8104e55a] local_apic_timer_interrupt+0x3a/0x60
[ 142.731011] [8180089f] smp_apic_timer_interrupt+0x3f/0x50
[ 142.731011] [817ff1f2] apic_timer_interrupt+0x72/0x80
[ 142.731011] EOI
[ 142.731011] [817f42b3] ? retint_restore_args+0x13/0x13
[ 142.731011] [a02a666b] ? kdbus_conn_new+0x25b/0xf20 [kdbus]
[ 142.731011] [a02a6741] ? kdbus_conn_new+0x331/0xf20 [kdbus]
[ 142.731011] [a02a8161] kdbus_handle_ioctl+0x221/0xad0 [kdbus]
[ 142.731011] [81361a31] ? inode_has_perm.isra.47+0x51/0x90
[ 142.731011] [81251f60] do_vfs_ioctl+0x2f0/0x520
[ 142.731011] [81252211] SyS_ioctl+0x81/0xa0
[ 142.731011] [817fe4e9] system_call_fastpath+0x16/0x1b
Signed-off-by: Djalal Harouni tix...@opendz.org
---
I've checked all the other calls, the remaining one is:
connection.c:kdbus_conn_payload_add() it seems that it fakes the size
and hanldes the alignment, if I've more time I'll try to check it. This
one is tricky!
connection.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/connection.c b/connection.c
index 3f27889..3e8c5de 100644
--- a/connection.c
+++ b/connection.c
@@ -1784,12 +1784,18 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
{
const struct kdbus_item *item;
bool policy_provided = false;
+ u64 attach_flags = 0;
int ret;
KDBUS_ITEMS_FOREACH(item, cmd-items, KDBUS_ITEMS_SIZE(cmd, items)) {
+
+ if (!KDBUS_ITEM_VALID(item, cmd-items,
+ KDBUS_ITEMS_SIZE(cmd, items)))
+ return -EINVAL;
+
switch (item-type) {
case KDBUS_ITEM_ATTACH_FLAGS:
- conn-attach_flags = item-data64[0];
+ attach_flags = item-data64[0];
break;
case KDBUS_ITEM_NAME:
case KDBUS_ITEM_POLICY_ACCESS:
@@ -1798,6 +1804,11 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
}
}
+ if (!KDBUS_ITEMS_END(item, cmd-items, KDBUS_ITEMS_SIZE(cmd, items)))
+ return -EINVAL;
+
+ conn-attach_flags = attach_flags;
+
if (!policy_provided)
return 0;
@@ -1862,6 +1873,11 @@ int kdbus_conn_new(struct kdbus_ep *ep,
KDBUS_ITEMS_FOREACH(item, hello-items,
KDBUS_ITEMS_SIZE(hello, items)) {
+
+ if (!KDBUS_ITEM_VALID(item, hello-items,
+ KDBUS_ITEMS_SIZE(hello, items)))
+ return
[systemd-devel] [PATCH 2/2] kdbus-test: fix kdbus item alignment in kdbus_hello_registrar()
Currently running the test-kdbus-activator test will fail with -EINVAL
To fix this, remove the redundant offsetof() macros since it is already
handled. The KDBUS_ITEM_SIZE() will expand into KDBUS_ITEM_HEADER_SIZE()
which expands into an offsetof() one.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
test/kdbus-util.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 5316263..7a6f272 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -117,20 +117,19 @@ kdbus_hello_registrar(const char *path, const char *name,
struct kdbus_item *item, *items;
size_t i, size;
- size = KDBUS_ITEM_SIZE(offsetof(struct kdbus_item, str) + strlen(name)
+ 1)
- + num_access * KDBUS_ITEM_SIZE(offsetof(struct kdbus_item,
policy_access) +
- sizeof(struct
kdbus_policy_access));
+ size = KDBUS_ITEM_SIZE(strlen(name) + 1)
+ + num_access * KDBUS_ITEM_SIZE(sizeof(struct
kdbus_policy_access));
items = alloca(size);
item = items;
- item-size = offsetof(struct kdbus_item, str) + strlen(name) + 1;
+ item-size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
item-type = KDBUS_ITEM_NAME;
strcpy(item-str, name);
item = KDBUS_ITEM_NEXT(item);
for (i = 0; i num_access; i++) {
- item-size = offsetof(struct kdbus_item, policy_access) +
+ item-size = KDBUS_ITEM_HEADER_SIZE +
sizeof(struct kdbus_policy_access);
item-type = KDBUS_ITEM_POLICY_ACCESS;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] connection: fix cpu stall by checking kdbus item alignment
Hi,
The tests are not clean... just a copy/past if you want to confirm this
one! they are attached.
patch with policy-holder.patch
then run: test-kdbus-policy-holder
You should hit it!
On Wed, Jun 11, 2014 at 05:27:58PM +0100, Djalal Harouni wrote:
Fix the following stall triggered by a policy holder hello:
call test/kdbus-util.c:kdbus_hello_registrar() and pass
KDBUS_HELLO_POLICY_HOLDER as a flag.
While we are it make sure that kdbus_cmd_conn_update() also checks for
proper 8 byte alignment.
[ 142.731011] INFO: rcu_sched self-detected stall on CPU { 3} (t=65000
jiffies g=3085 c=3084 q=4316)
[ 142.731011] sending NMI to all CPUs:
[ 142.731011] NMI backtrace for cpu 3
[ 142.731011] CPU: 3 PID: 1352 Comm: test-kdbus-poli Tainted: G OE
3.15.0-0.rc8.git4.1.fc21.x86_64 #1
[ 142.731011] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 142.731011] task: 88005a2719d0 ti: 88004587c000 task.ti:
88004587c000
[ 142.731011] RIP: 0010:[81055a12] [81055a12]
flat_send_IPI_all+0x92/0xd0
[ 142.731011] RSP: 0018:88005dc03dc0 EFLAGS: 00010006
[ 142.731011] RAX: RBX: 0c00 RCX:
[ 142.731011] RDX: 0c00 RSI: RDI:
0300
[ 142.731011] RBP: 88005dc03dd8 R08: 0001 R09:
0001
[ 142.731011] R10: 81e5d720 R11: 0001 R12:
0046
[ 142.731011] R13: 000f R14: 81e86880 R15:
0003
[ 142.731011] FS: 7f4b9d727740() GS:88005dc0()
knlGS:
[ 142.731011] CS: 0010 DS: ES: CR0: 8005003b
[ 142.731011] CR2: 00401312 CR3: 5b66f000 CR4:
06e0
[ 142.731011] Stack:
[ 142.731011] 2710 81e86880 81fa3e40
88005dc03df0
[ 142.731011] 81050654 88005ddcf000 88005dc03e48
8111a194
[ 142.731011] 7fff 0046
10dc
[ 142.731011] Call Trace:
[ 142.731011] IRQ
[ 142.731011] [81050654] arch_trigger_all_cpu_backtrace+0x64/0xa0
[ 142.731011] [8111a194] rcu_check_callbacks+0x584/0x850
[ 142.731011] [810a74a7] update_process_times+0x47/0x70
[ 142.731011] [81126765] tick_sched_handle.isra.19+0x25/0x60
[ 142.731011] [81127061] tick_sched_timer+0x41/0x60
[ 142.731011] [810c7446] __run_hrtimer+0x86/0x460
[ 142.731011] [81127020] ? tick_sched_do_timer+0x40/0x40
[ 142.731011] [810c809f] hrtimer_interrupt+0x10f/0x260
[ 142.731011] [8104e55a] local_apic_timer_interrupt+0x3a/0x60
[ 142.731011] [8180089f] smp_apic_timer_interrupt+0x3f/0x50
[ 142.731011] [817ff1f2] apic_timer_interrupt+0x72/0x80
[ 142.731011] EOI
[ 142.731011] [817f42b3] ? retint_restore_args+0x13/0x13
[ 142.731011] [a02a666b] ? kdbus_conn_new+0x25b/0xf20 [kdbus]
[ 142.731011] [a02a6741] ? kdbus_conn_new+0x331/0xf20 [kdbus]
[ 142.731011] [a02a8161] kdbus_handle_ioctl+0x221/0xad0 [kdbus]
[ 142.731011] [81361a31] ? inode_has_perm.isra.47+0x51/0x90
[ 142.731011] [81251f60] do_vfs_ioctl+0x2f0/0x520
[ 142.731011] [81252211] SyS_ioctl+0x81/0xa0
[ 142.731011] [817fe4e9] system_call_fastpath+0x16/0x1b
Signed-off-by: Djalal Harouni tix...@opendz.org
---
I've checked all the other calls, the remaining one is:
connection.c:kdbus_conn_payload_add() it seems that it fakes the size
and hanldes the alignment, if I've more time I'll try to check it. This
one is tricky!
connection.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/connection.c b/connection.c
index 3f27889..3e8c5de 100644
--- a/connection.c
+++ b/connection.c
@@ -1784,12 +1784,18 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
{
const struct kdbus_item *item;
bool policy_provided = false;
+ u64 attach_flags = 0;
int ret;
KDBUS_ITEMS_FOREACH(item, cmd-items, KDBUS_ITEMS_SIZE(cmd, items)) {
+
+ if (!KDBUS_ITEM_VALID(item, cmd-items,
+ KDBUS_ITEMS_SIZE(cmd, items)))
+ return -EINVAL;
+
switch (item-type) {
case KDBUS_ITEM_ATTACH_FLAGS:
- conn-attach_flags = item-data64[0];
+ attach_flags = item-data64[0];
break;
case KDBUS_ITEM_NAME:
case KDBUS_ITEM_POLICY_ACCESS:
@@ -1798,6 +1804,11 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
}
}
+ if (!KDBUS_ITEMS_END(item, cmd-items, KDBUS_ITEMS_SIZE(cmd, items)))
+ return -EINVAL;
+
+ conn-attach_flags = attach_flags;
+
if (!policy_provided)
return 0;
@@ -1862,6
Re: [systemd-devel] [PATCH] NEWS: fix directory name
On Wed, 11.06.14 17:09, Mantas Mikulėnas (graw...@gmail.com) wrote: Ah, grrr. Didn't see your mail before the release. :-( Anyway, commited now! Thanks! --- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 54d9e9e..1effaf5 100644 --- a/NEWS +++ b/NEWS @@ -52,7 +52,7 @@ CHANGES WITH 214: transports. Instead it is assumed the kernel loads them automatically when required. This only works correctly on very new kernels. On older kernels, please consider adding - the kernel modules to /etc/load-modules.d/ as a work-around. + the kernel modules to /etc/modules-load.d/ as a work-around. * The resolv.conf file systemd-resolved generates has been moved to /run/systemd/resolve/, if you have a symlink from Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to Restrict device in systemd?
By the way, reading throw the NEWS I thought you might be interested in `InaccessibleDirectories=/` or something like that -- Кирилл Елагин On Wed, Jun 4, 2014 at 1:18 PM, Mohit Agrawal moagr...@redhat.com wrote: Hi, Thanks to share the example of unit file,now query is resolved. Regards Mohit Agrawal - Original Message - From: Kirill Elagin kirela...@gmail.com To: Mohit Agrawal moagr...@redhat.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Sent: Wednesday, June 4, 2014 1:03:47 PM Subject: Re: [systemd-devel] How to Restrict device in systemd? Here is a proof that this kind of limiting for devices actually works. This service is trying to read the first byte of `/dev/sda1` but is allowed to access `/dev/zero` only: ~~~ [Unit] Description=test [Service] Type=oneshot ExecStart=/bin/head /dev/sda1 -c 1 DeviceAllow=/dev/zero r DevicePolicy=strict ~~ ~ # systemctl start bar.service Job for bar.service failed. See 'systemctl status bar.service' and 'journalctl -xn' for details. # systemctl status bar.service ... Jun 04 11:30:53 kirNote head[26237]: /bin/head: cannot open ‘/dev/sda1’ for reading: Operation not permitted Jun 04 11:30:53 kirNote systemd[1]: bar.service: main process exited, code=exited, status=1/FAILURE Jun 04 11:30:53 kirNote systemd[1]: Failed to start test. Jun 04 11:30:53 kirNote systemd[1]: Unit bar.service entered failed state. -- Кирилл Елагин On Wed, Jun 4, 2014 at 11:29 AM, Kirill Elagin kirela...@gmail.com wrote: Well, first of all, your `DeviceAllow` syntax is still wrong. “Takes two space-separated strings: a device node path (such as /dev/null) followed by a combination of r, w, m”. But that's not the main issue here. The main issue here is that devices.allow and devices.deny control access to _devices_. Your own user doesn't have write access to `/dev/sda`, but, somehow, you still can create files in your home directory, right? That's because file creation (and actually all the filessytem access) is done through kernel interfaces, not by reading/writing devices nodes directly (that would be kind insecure, right?). I can't come up with a proper solution to limit FS access if your process will be running as root. -- Кирилл Елагин On Wed, Jun 4, 2014 at 11:16 AM, Mohit Agrawal moagr...@redhat.com wrote: Hi Kirill, Thanks for your valuable reply.As per man page DeviceAllow(Use to control access to specific device nodes by the executed process,This also controls the devices.allow and devices.deny both My query is how it is controls the device.deny),I am assuming after update DevicePolicy to strict means only process can be used allowed type of devices no other devices but after add the DevicePolicy also it is trying to create the file on /root/file_1. DeviceAllow= Control access to specific device nodes by the executed processes. Takes two space-separated strings: a device node path (such as /dev/null) followed by a combination of r, w, m to control reading, writing, or creation of the specific device node by the unit (mknod), respectively. This controls the devices.allow and devices.deny control group attributes. For details about these control group attributes, see devices.txt[4]. DevicePolicy=auto|closed|strict Control the policy for allowing device access: strict means to only allow types of access that are explicitly specified. [Unit] Description=mydevblock [Service] DeviceAllow=/dev/zero DevicePolicy=strict ExecStart=/usr/bin/dd if=/dev/zero of=/root/file_1 bs=1M count=400 Restart=always [Install] WantedBy=multi-user.target I believe it should restrict to create the file . Regards Mohit Agrawal - Original Message - From: Kirill Elagin kirela...@gmail.com To: Mohit Agrawal moagr...@redhat.com Cc: systemd Mailing List systemd-devel@lists.freedesktop.org Sent: Wednesday, June 4, 2014 12:17:46 PM Subject: Re: [systemd-devel] How to Restrict device in systemd? First of all, according to docs, `DeviceAllow` syntax is somewhat different from what you have. Second, you might want to check `DevicePolicy`, as now your unit has access not only to `/dev/zero`, but also to four other devices. And hm, I thought, those directives control access to device nodes. Why are you expecting them to limit access to the filesystem? -- Кирилл Елагин On Wed, Jun 4, 2014 at 10:18 AM, Mohit Agrawal moagr...@redhat.com wrote: Hi, I want to block the device through the systemd cgroup so I have created a below unit file [Unit] Description=mydevblock [Service] DeviceAllow=/dev/zero ExecStart=/usr/bin/dd if=/dev/zero
Re: [systemd-devel] [ANNOUNCE] systemd 214
11.06.2014 23:00, Lennart Poettering wrote: CHANGES WITH 214: * As an experimental feature, udev now tries to lock the disk device node (flock(LOCK_SH|LOCK_NB)) while it executes events for the disk or any of its partitions. Applications like partitioning programs can lock the disk device node (flock(LOCK_EX)) and claim temporary device ownership that way; udev will entirely skip all event handling for this disk and its partitions. If the disk was opened for writing, the close will trigger a partition table rescan in udev's watch facility, and if needed synthesize change events for the disk and all its partitions. This is now unconditionally enabled, if it turns out to cause major problems, we might turn it on only for specific devices, or might need to disable it entirely. Device-mapper devices are excluded from this logic. If we have one exception, I think it is safe to ask another: all block devices starting with zram. The reason is documented at http://lists.freedesktop.org/archives/systemd-devel/2014-June/019838.html : it breaks a (mis-?)documented way to integrate zram swap and systemd. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tests: add missing XDG_RUNTIME_DIR env variable
Otherwise the test fails because specifier_runtime() returns -ENOTSUP
when XDG_RUNTIME_DIR is not set.
---
src/test/test-unit-name.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/test/test-unit-name.c b/src/test/test-unit-name.c
index fff3e16..bff4319 100644
--- a/src/test/test-unit-name.c
+++ b/src/test/test-unit-name.c
@@ -145,6 +145,7 @@ static int test_unit_printf(void) {
assert_se(setenv(USER, root, 1) == 0);
assert_se(setenv(HOME, /root, 1) == 0);
+assert_se(setenv(XDG_RUNTIME_DIR, /run/user/1/, 1) == 0);
assert_se(u = unit_new(m, sizeof(Service)));
assert_se(unit_add_name(u, blah.service) == 0);
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Wed, Jun 11, 2014 at 12:15 PM, Kirill Elagin kirela...@gmail.com wrote: On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert flop...@gentoo.org wrote: On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Again, that's exactly what happens for configuration files too if you use automake: on make install they are replaced by the original, upstream versions. Why is recreating the symlinks bad, if overriding the config files isn't? People don't generally remove config files; they just make changes. On the other hand, removing the symlinks would be a very typical action due to the way systemctl disable works. There is some ambiguity as to what a missing symlink means: did the sysadmin remove it, or did it never exist in the first place? But there is `equery f`, so it shouldn't be too hard to figure this out, right? It is one thing to query the package database with a tool designed for users. It is quite another to modify our package manager to use the information in an intelligent way. Patches are welcome, as always. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Slow startup of systemd-journal on BTRFS
Hi all, I would like to share a my experience about a slowness of systemd when used on BTRFS. My boot time was very high (about ~50 seconds); most of time it was due to NetworkManager which took about 30-40 seconds to start (this data came from systemd-analyze plot). I make several attempts to address this issue. Also I noticed that sometime this problem disappeared; but I was never able to understand why. However this link https://bugzilla.redhat.com/show_bug.cgi?id=1006386 suggested me that the problem could be due to a bad interaction between systemd and btrfs. NetworkManager was innocent. It seems that systemd-journal create a very hight fragmented files when it stores its log. And BTRFS it is know to behave slowly when a file is highly fragmented. This had caused a slow startup of systemd-journal, which in turn had blocked the services which depend by the loggin system. In fact after I de-fragmented the files under /var/log/journal [*], my boot time decreased of about 20second (from 50s to 30s). Unfortunately I don't have any data to show. The next time I will try to collect more information. But I am quite sure that when the log are highly fragmented systemd-journal becomes very slow on BTRFS. I don't know if the problem is more on the systemd side or btrfs side. What I know is that both the projects likely will be important in the near futures, and both must work well together. I know that I can chattr +C to avoid COW for some files; but I don't want to lost also the checksum protection. If someone is able to suggest me how FRAGMENT the log file, I can try to collect more scientific data. BR G.Baroncelli [*] # btrfs fi defrag /var/log/journal/*/* -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it 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-network-wait-online symlinks to systemd-networkd
On Wed, Jun 11, 2014 at 4:56 PM, Mike Gilbert flop...@gentoo.org wrote: On Wed, Jun 11, 2014 at 12:15 PM, Kirill Elagin kirela...@gmail.com wrote: On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert flop...@gentoo.org wrote: On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Again, that's exactly what happens for configuration files too if you use automake: on make install they are replaced by the original, upstream versions. Why is recreating the symlinks bad, if overriding the config files isn't? People don't generally remove config files; they just make changes. On the other hand, removing the symlinks would be a very typical action due to the way systemctl disable works. There is some ambiguity as to what a missing symlink means: did the sysadmin remove it, or did it never exist in the first place? But there is `equery f`, so it shouldn't be too hard to figure this out, right? It is one thing to query the package database with a tool designed for users. It is quite another to modify our package manager to use the information in an intelligent way. Patches are welcome, as always. Actually, I think I have talked myself into working on such an enhancement myself. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
You're welcome. Please, tell the PMS guys to add this to the spec and ask the Paludis guys to implement this as well. -- Кирилл Елагин On Thu, Jun 12, 2014 at 1:33 AM, Mike Gilbert flop...@gentoo.org wrote: On Wed, Jun 11, 2014 at 4:56 PM, Mike Gilbert flop...@gentoo.org wrote: On Wed, Jun 11, 2014 at 12:15 PM, Kirill Elagin kirela...@gmail.com wrote: On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert flop...@gentoo.org wrote: On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Again, that's exactly what happens for configuration files too if you use automake: on make install they are replaced by the original, upstream versions. Why is recreating the symlinks bad, if overriding the config files isn't? People don't generally remove config files; they just make changes. On the other hand, removing the symlinks would be a very typical action due to the way systemctl disable works. There is some ambiguity as to what a missing symlink means: did the sysadmin remove it, or did it never exist in the first place? But there is `equery f`, so it shouldn't be too hard to figure this out, right? It is one thing to query the package database with a tool designed for users. It is quite another to modify our package manager to use the information in an intelligent way. Patches are welcome, as always. Actually, I think I have talked myself into working on such an enhancement myself. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: fix searching for configs in alternate roots
Commit 12ed81d9 changed path_strv_canonicalize_absolute's behavior to
return a directory list without the root prefix if one was given but did
not update other users of the function to the new behavior. This broke
the --root option in systemd-tmpfiles, a regression in v213.
To better reflect that path_strv_canonicalize_absolute does not return
fully resolved paths any more as canonicalize may imply it is now simply
called path_strv_cleanup.
---
Resending this patch since it didn't make it in for v314. :(
src/shared/conf-files.c | 18 +-
src/shared/path-lookup.c | 6 +++---
src/shared/path-util.c | 6 +++---
src/shared/path-util.h | 4 ++--
src/shared/util.c| 7 +--
5 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/src/shared/conf-files.c b/src/shared/conf-files.c
index 5201782..6f1dc7f 100644
--- a/src/shared/conf-files.c
+++ b/src/shared/conf-files.c
@@ -37,10 +37,18 @@
#include hashmap.h
#include conf-files.h
-static int files_add(Hashmap *h, const char *dirpath, const char *suffix) {
+static int files_add(Hashmap *h, const char *dirpath, const char *suffix,
const char *root) {
_cleanup_closedir_ DIR *dir = NULL;
+_cleanup_free_ char *fullpath = NULL;
-dir = opendir(dirpath);
+if (root)
+fullpath = strappend(root, dirpath);
+else
+fullpath = strdup(dirpath);
+if (!fullpath)
+return -ENOMEM;
+
+dir = opendir(fullpath);
if (!dir) {
if (errno == ENOENT)
return 0;
@@ -63,7 +71,7 @@ static int files_add(Hashmap *h, const char *dirpath, const
char *suffix) {
if (!dirent_is_file_with_suffix(de, suffix))
continue;
-p = strjoin(dirpath, /, de-d_name, NULL);
+p = strjoin(fullpath, /, de-d_name, NULL);
if (!p)
return -ENOMEM;
@@ -100,7 +108,7 @@ static int conf_files_list_strv_internal(char ***strv,
const char *suffix, const
assert(suffix);
/* This alters the dirs string array */
-if (!path_strv_canonicalize_absolute_uniq(dirs, root))
+if (!path_strv_cleanup_uniq(dirs, root))
return -ENOMEM;
fh = hashmap_new(string_hash_func, string_compare_func);
@@ -108,7 +116,7 @@ static int conf_files_list_strv_internal(char ***strv,
const char *suffix, const
return -ENOMEM;
STRV_FOREACH(p, dirs) {
-r = files_add(fh, *p, suffix);
+r = files_add(fh, *p, suffix, root);
if (r == -ENOMEM) {
hashmap_free_free(fh);
return r;
diff --git a/src/shared/path-lookup.c b/src/shared/path-lookup.c
index e072fd6..1a497f9 100644
--- a/src/shared/path-lookup.c
+++ b/src/shared/path-lookup.c
@@ -284,7 +284,7 @@ int lookup_paths_init(
}
}
-if (!path_strv_canonicalize_absolute_uniq(p-unit_path, root_dir))
+if (!path_strv_cleanup_uniq(p-unit_path, root_dir))
return -ENOMEM;
if (!strv_isempty(p-unit_path)) {
@@ -338,10 +338,10 @@ int lookup_paths_init(
return -ENOMEM;
}
-if (!path_strv_canonicalize_absolute_uniq(p-sysvinit_path,
root_dir))
+if (!path_strv_cleanup_uniq(p-sysvinit_path, root_dir))
return -ENOMEM;
-if (!path_strv_canonicalize_absolute_uniq(p-sysvrcnd_path,
root_dir))
+if (!path_strv_cleanup_uniq(p-sysvrcnd_path, root_dir))
return -ENOMEM;
if (!strv_isempty(p-sysvinit_path)) {
diff --git a/src/shared/path-util.c b/src/shared/path-util.c
index 5863429..37490be 100644
--- a/src/shared/path-util.c
+++ b/src/shared/path-util.c
@@ -238,7 +238,7 @@ char **path_strv_make_absolute_cwd(char **l) {
return l;
}
-char **path_strv_canonicalize_absolute(char **l, const char *prefix) {
+char **path_strv_cleanup(char **l, const char *prefix) {
char **s;
unsigned k = 0;
bool enomem = false;
@@ -323,12 +323,12 @@ char **path_strv_canonicalize_absolute(char **l, const
char *prefix) {
return l;
}
-char **path_strv_canonicalize_absolute_uniq(char **l, const char *prefix) {
+char **path_strv_cleanup_uniq(char **l, const char *prefix) {
if (strv_isempty(l))
return l;
-if (!path_strv_canonicalize_absolute(l, prefix))
+if (!path_strv_cleanup(l, prefix))
return NULL;
return strv_uniq(l);
diff --git a/src/shared/path-util.h b/src/shared/path-util.h
index 6882d78..b523bcc 100644
--- a/src/shared/path-util.h
+++ b/src/shared/path-util.h
@@ -47,8 +47,8 @@ char* path_startswith(const char *path, const char *prefix)
_pure_;
bool path_equal(const char *a, const
Re: [systemd-devel] Slow startup of systemd-journal on BTRFS
On Jun 11, 2014, at 3:28 PM, Goffredo Baroncelli kreij...@libero.it wrote: If someone is able to suggest me how FRAGMENT the log file, I can try to collect more scientific data. So long as you're not using compression, filefrag will show you fragments of systemd-journald journals. I can vouch for the behavior you experience without xattr +C or autodefrag, but further it also causes much slowness when reading journal contents. LIke if I want to search all boots for a particular error message to see how far back it started, this takes quite a bit longer than on other file systems. So far I'm not experiencing this problem with autodefrag or any other negative side effects, but my understanding is this code is still in flux. Since the journals have their own checksumming I'm not overly concerned about setting xattr +C. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Slow startup of systemd-journal on BTRFS
On Jun 11, 2014, at 7:21 PM, Dave Chinner da...@fromorbit.com wrote: On Wed, Jun 11, 2014 at 11:28:54PM +0200, Goffredo Baroncelli wrote: Hi all, I would like to share a my experience about a slowness of systemd when used on BTRFS. My boot time was very high (about ~50 seconds); most of time it was due to NetworkManager which took about 30-40 seconds to start (this data came from systemd-analyze plot). I make several attempts to address this issue. Also I noticed that sometime this problem disappeared; but I was never able to understand why. However this link https://bugzilla.redhat.com/show_bug.cgi?id=1006386 suggested me that the problem could be due to a bad interaction between systemd and btrfs. NetworkManager was innocent. systemd has a very stupid journal write pattern. It checks if there is space in the file for the write, and if not it fallocates the small amount of space it needs (it does *4 byte* fallocate calls!) and then does the write to it. All this does is fragment the crap out of the log files because the filesystems cannot optimise the allocation patterns. Yup, it fragments journal files on XFS, too. http://oss.sgi.com/archives/xfs/2014-03/msg00322.html IIRC, the systemd developers consider this a filesystem problem and so refused to change the systemd code to be nice to the filesystem allocators, even though they don't actually need to use fallocate... Cheers, Dave. -- Dave Chinner da...@fromorbit.com On Jun 11, 2014, at 7:37 PM, Dave Chinner da...@fromorbit.com wrote: BTW, the systemd list is subscriber only, so thay aren't going to see anything that we comment on from a cross-post to the btrfs list. Unless a subscriber finds something really interesting, quotes it, and cross posts it. Chris murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
El Wed, 11 de Jun 2014 a las 10:00 AM, Lennart Poettering lenn...@poettering.net escribió: Hi! http://www.freedesktop.org/software/systemd/systemd-214.tar.xz Here it is, version 214. Stuffed with great new features, improvements in all areas, 1 I would think that removing m from the documentation entirely would make it hard for people looking at old tmpfile configurations to understand what m does. Why not keep it in the docs, but clearly mark it as deprecated? Awesome release, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not initializing
Hi Mantas, Thanks for your reply. I tried putting boot options boot options loglevel=6, systemd.log_level=debug But it got stuck as before. So I added init=/bin/sh to the arguments and removed system.log_level=debug. Then I could have the Shell command line but it gave some messages before giving shell command: Sh: cannot set terminal process group (-1): Inappropriate ioctl for device Sh: no job control in this shell I saw that system.log_level=debug does not have any impact here. Also when I gave path of my init file init=/sbin/init, it still hangs as previously. Though my file is present in that path, I don't understand why it does not take it. I don't have inittab file in /etc/. Is that the reason, since init might not be able to find inittab and gets lost or something. Thanks, Jay ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of softwar e viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com http://www.igate.com. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
