[systemd-devel] PrivateTmp and multiple Exec* lines
Hi all, I'm trying to make native systemd units for bootchart2 (see: https://github.com/mmeeks/bootchart). I ran into the following problem. The unit bootchart-done.service has to execute two tasks: run a binary that generates some files in a private tmp directory: PrivateTmp=true ExecStart=/lib/bootchart/bootchart-collector -c --dump /tmp then tar the generated files together and save them somewhere the user can find them: ExecStart=/bin/tar -zcf $BOOTLOG_DEST /tmp/header /tmp/dmesg /tmp/*.log This does not work, as each of the ExecStart lines will get a different private namespace for their /tmp dir, so the second line will not find the files generated by the first. Is this a bug or by design? To me it would make sense if a service stays inside the same namespace until it is stopped or restarted. What do you think? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] crypto: to show stars or not to show them
On Wed, Mar 16, 2011 at 9:21 AM, Jan Engelhardt jeng...@medozas.de wrote: On Wednesday 2011-03-16 04:30, Lennart Poettering wrote: After X is up all password prompts do give input feedback The presence of X does not change behavior of console programs. Well, as I mentioned earlier, certain implementations use a three-star-per-character so that there is at least some feedback. How about using that? Or, something crazy that just came to my mind is using one (or more) U+2501 per input character. Provided you have a proper font, this will produce a continuous line which is harder to estimate than chars having blank pixels between them. I agree with lennart, this paranoia is worthless. If you want to be paranoid then do the right thing and use a big pass phrase and avoid people reading your screen altogether, if it's a laptop use proper screen films to avoid other problems. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Wed, Mar 16, 2011 at 07:18, Michael Biebl mbi...@gmail.com wrote: 2011/3/16 Lennart Poettering lenn...@poettering.net: On Sat, 12.03.11 16:31, Andrey Borzenkov (arvidj...@mail.ru) wrote: Attached patch preserves full syslog facility marker and simply emits it back. So userspace is free to feed any facility it deems appropriate, not only LOG_USER. This is a good approach. Kay has independently prepped a patch for this now and it is already on its way into the kernel. It is hence very likely that pretty soon there's no reason anymore to strip the facility from the log messages before echoing them into /proc/kmsg. As soon as that patch is in the standard kernel I'll fix systemd to no longer strip the facility. Kay will do the same for udev. And Harald hopefully for Dracut too. And then all messages should contain the same amount of information regardless which way the took to the syslog daemon: directly via the /dev/log socket, or indirectly via the kmsg queue. What happens if you run udev/dracut/systemd on a kernel without this patch? The kernel will not recognize the prefix, add the default one and keep the old prefix in the message: Before: $ echo '14text' /dev/kmsg $ dmesg -r 4[135159.594810] 14text After: $ echo '14text' /dev/kmsg $ dmesg -r 14[ 50.750654] text Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] ask-password: mention magic key to start over
On Wed, 16.03.11 13:24, Jan Engelhardt (jeng...@medozas.de) wrote: On Wednesday 2011-03-16 04:43, Lennart Poettering wrote: Well, all these keycodes are actually handled by the kernel and in the terminal layer as part of ICANON (^U is VKILL to be precise). See tcsetattr(3) for more information. I'd argue that tools which redefine ^U and ^H and ^C to unrelated operations have made very poor choices What about handling the other tty keys in systemd, like ^W? Yes ^W probably makes sense to support. The only reason we are currently not supporting it is laziness on my side, but I'd be happy to merge a patch! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch] Fix systemd-readahead-collect on mips platform
On Wed, 16.03.11 11:46, fykc...@gmail.com (fykc...@gmail.com) wrote: Hi all, Attachment is the patch fixing broken systemd-readahead-collect on mips. The patch is actually fixing the fanotify syscall on mips: 1. Adjust to correct syscall number. 2. Using directly fanotify syscall instead of syscall(__NR_FANOTIFY_MARK), which is broken on the test platform. Hmm, what precisely is broken? the syscall() implementation in your glibc? If so I'd very much prefer if glibc is fixed instead. We generally prefer fixing bugs where they are instead of taping over them in other software. BTW, I enabled systemd-readahead-collect.service, systemd-readahead-replay.service, they were both in default.target. I also link systemd-readahead-done.service to default.target, is that correct? Yes, the belong into default.target. systemd-readahead-collect.service pulls in systemd-readahead-done.timer, which triggers systemd-readahead-done.service after boot. You should not pull in the latter service directly because then you end up with stopping the collector right-away. A simple systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service should be sufficient to enable everything. Note that in embedded use cases it might be a good idea to enable the collector only once and then disable it for subsequent boots since the data collected probably won't change much for all future boots. This is different on normal desktop machines where new software is installed, new hardware plugged in all the time and we hence need to collect readahead data at every boot. It seems these services exit quickly, and wasn't observed a boot time speed-up. The size of /.readahead is around 30K. Any idea? Yes, you appear to terminating the collector right after you are starting it, so that it collects no data at all. ;-) Note that the effect of readahead varies. The speedup might be minimal if you start very little anyway. And if you have SSD the speedup will be much smaller than on rotating media. (Though according to Kay's most recent measurements actually still quite impressive) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] crypto: to show stars or not to show them
On Wed, 16.03.11 13:21, Jan Engelhardt (jeng...@medozas.de) wrote: On Wednesday 2011-03-16 04:30, Lennart Poettering wrote: After X is up all password prompts do give input feedback The presence of X does not change behavior of console programs. Well, as I mentioned earlier, certain implementations use a three-star-per-character so that there is at least some feedback. How about using that? I am not sure I follow here, if we always show 3 asterisks then it should be much easier to get an idea how long your password is. What some programs do is randomly pick between 1 and 3 asterisks for each char. That probably does make some sense, though might be quite confusing to the user, dunno? Or, something crazy that just came to my mind is using one (or more) U+2501 per input character. Provided you have a proper font, this will produce a continuous line which is harder to estimate than chars having blank pixels between them. Well, but we cannot rely that the terminal used is unicode-capable. Note that this prompt might be shown on serial terminals with weirdo Windows-based software on the other side, which almost definitely cannot to UTF-8. The only continuous line in 7 bit ascii we could draw is with underscores, but that might be irritating, too? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Wed, 16.03.11 07:18, Michael Biebl (mbi...@gmail.com) wrote: 2011/3/16 Lennart Poettering lenn...@poettering.net: On Sat, 12.03.11 16:31, Andrey Borzenkov (arvidj...@mail.ru) wrote: Attached patch preserves full syslog facility marker and simply emits it back. So userspace is free to feed any facility it deems appropriate, not only LOG_USER. This is a good approach. Kay has independently prepped a patch for this now and it is already on its way into the kernel. It is hence very likely that pretty soon there's no reason anymore to strip the facility from the log messages before echoing them into /proc/kmsg. As soon as that patch is in the standard kernel I'll fix systemd to no longer strip the facility. Kay will do the same for udev. And Harald hopefully for Dracut too. And then all messages should contain the same amount of information regardless which way the took to the syslog daemon: directly via the /dev/log socket, or indirectly via the kmsg queue. What happens if you run udev/dracut/systemd on a kernel without this patch? You mean a new udev/dracut/systemd on an old kernel? The messages they print would look a bit weird if they are used together with log msg timestamping the way the kernel does it, since the kernel doesn't recognize the prefix. (See Kay's post about this). But besides these cosmetic issues nothing should really go wrong. (I wonder if we can find a nice way to detect whether the kernel is new enough for this, so that we could strip the facility automatically for older ones. Explcitily checking for kernel versions at runtime is evil though... I can't think of a good way though...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Wed, 16.03.11 10:58, Andrey Borzenkov (arvidj...@mail.ru) wrote: convinced that rsyslog.service should hook itself into syslog.target. What is syslog.target then good for? I consider it to be more of a virtual provide for specific syslog implementation. My look on the whole situation is actually that these targets are stopgaps in a world where not all daemons are socket activatable and where some daemons are written in a way that they assume that the network is always up and does not change dynamically. In a world where where all services are socket activatable and all daemons subscribe properly to netlink we don't need neither syslog.target nor network.target, because the syslog daemon is always accessible and it doesn't matter anymore when the network is configured and when not. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptosetup units must have timeout
On Sat, 19.02.11 10:14, Andrey Borzenkov (arvidj...@gmail.com) wrote: [root@localhost ~]# systemctl status cryptsetup@secrets.service cryptsetup@secrets.service - Cryptography Setup for secrets Loaded: loaded (/dev/.systemd/generator-ImgwKs/cryptsetup@secrets.service) Active: activating (start) since Mon, 21 Feb 2011 21:21:48 -0500; 11min ago Main PID: 670 (systemd-cryptse) CGroup: name=systemd:/system/cryptsetup@.service/secrets └ 670 /lib/systemd/systemd-cryptsetup attach secrets /de... [root@localhost ~]# date Mon Feb 21 21:33:23 EST 2011 Well, the problem is, these units are appeared to be stuck forever in activating state even if user never supplied password; and in this case the block shutdown for 3 minutes. Which is not good. There was a bug in the password query logic which miscalculated the time to sleep and hung forever. This has been fixed a while back. You can configure with timeout=xxx in the crypttab file how long we shall wait for a specific password. The default is 1min, and I just changed that to 3 min as default, to sync the time we wait for devices to show up with the time we wait for passwords to be entered. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inactive/dead services that are enabled are indistinguishable from unused or oneshot services
On Thu, 24.02.11 13:55, Mike Kazantsev (mk.frag...@gmail.com) wrote: Something like systemctl --enabled would certainly be much more useful for such cases than the current systemctl --all, yet there will still be a lot of oneshot stuff, which are supposed to be dead, so a separate state for !oneshot enabled exited services like stopped (in place of inactive) and maybe a view like systemctl --stopped would be of a great help from my sysadmin's perspective. Hmm, thinking about this: wouldn't it be a lot more useful for your case if we add an option which cuases services to enter fail if a service exits cleanly, but does so for no reason, i.e. without being asked to do that from systemd? or maybe that should even be the default for most services? After all only services which implement exit-on-idle would otherwise exit cleanly just for fun without being asked for that... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How rpcbind.target is supposed to be pulled in?
On Thu, 03.03.11 08:22, Andrey Borzenkov (arvidj...@gmail.com) wrote: How is it supposed to be activated? May be, at least for legacy case of SysV scripts systemd should automatically add rpcinfo.target to transaction if it sees Provides: $portmap in any active service? We currently don't have a nice answer for this. It's the same story as with syslog.target of course. it might make sense to just ignore the prob and use a patched rpcbind with socket activation, which I posted a while back... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl is-enabled...
On Tue, 08.03.11 21:23, Andrey Borzenkov (arvidj...@mail.ru) wrote: On Mon, Mar 7, 2011 at 4:00 AM, Lennart Poettering lenn...@poettering.net wrote: What about this solution consisting of these 4 rules together: 1. A service residing in /lib with no [Install] section will unconditionally be considered enabled. 2. A service which has at least one symlink to it in /etc is considered enabled. 3. Symlinks in /lib are irrelevant 4. We'd not recursively traverse tree That way dbus would always appear enabled due to rule #1. What to do with aliases? [root@localhost ~]# systemctl -p Names -p Id --no-pager show dm.service Id=prefdm.service Names=display-manager.service prefdm.service dm.service [root@localhost ~]# systemctl is-enabled dm.service dm.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig dm [root@localhost ~]# echo $? 1 Well ... dm.service is obviously enabled; even if it is enabled under different alias Hmm, I guess that's a reason why Names= are a bad idea to use. People should place proper symlinks if they want to establish additional names. If people use symlink aliases, then we can use them to find the files. If people use Names= then we can use them only in systemd itself and only if the service has been loaded. TBH, i am tempted to remove Names= entirely from systemd, as I fail to see a non-confusing really good usecase for this right now. BTW /etc/init.d/dm actually is enabled ... just in different run level. We invoke chkconfig --level=3 right now. Given that 5 is usually a superset of 1,2,3,4 using 5 here is probably a safer choice if we need to make one. /me changes that. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inactive/dead services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17 Mar 2011 01:39:19 +0100 Lennart Poettering lenn...@poettering.net wrote: On Thu, 24.02.11 13:55, Mike Kazantsev (mk.frag...@gmail.com) wrote: Something like systemctl --enabled would certainly be much more useful for such cases than the current systemctl --all, yet there will still be a lot of oneshot stuff, which are supposed to be dead, so a separate state for !oneshot enabled exited services like stopped (in place of inactive) and maybe a view like systemctl --stopped would be of a great help from my sysadmin's perspective. Hmm, thinking about this: wouldn't it be a lot more useful for your case if we add an option which cuases services to enter fail if a service exits cleanly, but does so for no reason, i.e. without being asked to do that from systemd? or maybe that should even be the default for most services? After all only services which implement exit-on-idle would otherwise exit cleanly just for fun without being asked for that... I think it'd be an improvement, but that'd also give failed state a bit more ambiguity, although maybe it's not such a bad thing. Experiencing several reboots on a machine with 50+ enabled daemons I've noticed that some of them (mostly the ones, started via some laucher script like apachectl, pg_ctl, ejabberdctl, etc) tend to cleanly fail randomly on start just because GuessMainPID= mechanism fails and systemd actually kills the service. Proposed solution should at least be useful to detect this (quite common) cases. These are mostly one-time issues however, showing a bug in systemd unit file. Shortcoming of this approach is that cleanly stopped but enabled services still won't be shown anywhere, so you can't really assert that all the services I've requested are running, which kinda beats the purpose of such display - you still can't trust it (or rather it doesn't show what you need) and have to either deploy software to work around this shortcoming or check status of all the services manually. I understand that there's a limited number of reasons for such clean stop (manual interaction, units like rsyslog.service, Conflicts=, isolate, etc), but still it's a wrong way to approach the particular problem. I've solved the problem for myself by writing a simple dbus-python script (http://goo.gl/V6e7V). It shows exactly everything that's enabled and not active (with oneshot exception), not some random subset of this. Unfortunately, new rsyslog.service (and services using systemctl stop directly) can affect such display, which I think shows the flawed assumption that enabled in systemd means should be active, period (with the exception of oneshot units) on my part, and I don't know easy solution to this, short of adding another enabled-like state. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
