Re: [systemd-devel] WISHLIST: systemd git-like CLI/ui/command interface
Colin Guthrie gm...@colin.guthr.ie writes: I don't think this really applies here. The day-to-day commands are really systemctl, journalctl and loginctl (although the last one is likely not often used). I think it's a bit annoying that systemctl is a) so long, and b) tab-completes poorly 'sc'? -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v196
Thierry Reding thierry.red...@avionic-design.de writes: Hi, Would anyone know why the latest releases no longer work on 3.1 kernels? I tried to update from 187 to 196 today and booting the system on a vendor kernel based on 3.1.10 no longer gets to the boot prompt. It hangs somewhere near where it should actually be spawning a getty on the serial port. Booting systemd 196 on a kernel based on linux-next doesn't have this issue. I've gone over the NEWS entries between 187 and 196, but nothing obvious stood out. Any ideas? I'm running 196 just fine on a 3.0 vendor kernel, so it's not a universal problem. I also use getty on the serial port, with no local modifications. I believe the requirement for a 3.4 (or something) kernel came in 188 for some logging bits, although I'm not sure. systemd should work just fine without it, though. -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v196
On Fri, Nov 23, 2012 at 10:29:53AM +0100, Henrik Grindal Bakken wrote: Any ideas? I'm running 196 just fine on a 3.0 vendor kernel, so it's not a universal problem. I also use getty on the serial port, with no local modifications. I believe the requirement for a 3.4 (or something) kernel came in 188 for some logging bits, although I'm not sure. systemd should work just fine without it, though. v189 NEWS: * Support for reading kernel messages from /proc/kmsg has now been removed. If you want kernel messages in the journal make sure to run a recent kernel (= 3.5) that supports reading structured messages from /dev/kmsg (see above). -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] WISHLIST: systemd git-like CLI/ui/command interface
On 11/23/2012 02:27 AM, Henrik Grindal Bakken wrote: Colin Guthrie gm...@colin.guthr.ie writes: I don't think this really applies here. The day-to-day commands are really systemctl, journalctl and loginctl (although the last one is likely not often used). I think it's a bit annoying that systemctl is a) so long, and b) tab-completes poorly 'sc'? I think this is easy to personalize, and doesn't need to be done upstream at this point. I have sd = systemctl --system ud = systemctl --user log = journalctl loginctl hasn't bothered me yet. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What does it take to make test-engine working again?
On Wed, Nov 21, 2012 at 2:26 PM, Holger Freyther hol...@freyther.de wrote: Koen pointed me to a jenkins but it doesn't run make check. I have it configured right now to run make test, which does nothing in systemd builds. I'm happy to update it to include a proper post-build test, but I'd like consensus on what it should be. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd
I am just starting to experiment with systemd. My first 'problem' is that the build process does not seem to properly obey the --prefix= directive. I get some stuff installed where I tell it with --prefix, and some other stuff installed in /usr/bin and /usr/lib. I can get around this easily enough, but it maybe should be fixed. I hate it when installs put stuff anywhere other than where directed: it makes it immensely more difficult to maintain visibility of what is going on. Thank you. By the way, my first boot with /sbin/init symlinked to 'systemd' executable; and without any other configuration at all didn't complete the boot (as expected), but did produce intelligent and intelligible messages, so I am greatly heartened and quite excited! Regards, David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question about journal: how to collect log messages from various /dev/log sockets, of chrooted services
Hi, My distribution has many isolated services with his /dev/log are disposed within the environment of isolation, for example: /var/lib/ldap/dev/log /var/lib/openvpn/dev/log /var/spool/postfix/dev/log How to configure a journalD, which he could read such isolated sockets? Now I see only one solution: to add the necessary sockets in systemd-journald.socket file, but this approach is not distributive. I would like to have the analog /etc/syslog.d which are symbolic links to the insulated sockets or any other convenient method. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What does it take to make test-engine working again?
On Fri, 23.11.12 04:31, David Strauss (da...@davidstrauss.net) wrote: On Wed, Nov 21, 2012 at 2:26 PM, Holger Freyther hol...@freyther.de wrote: Koen pointed me to a jenkins but it doesn't run make check. I have it configured right now to run make test, which does nothing in systemd builds. I'm happy to update it to include a proper post-build test, but I'd like consensus on what it should be. make check is the command to invoke, not make test. 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] Properly handling rngd's complex dependencies
On Thu, 22.11.12 11:19, Shea Levy (s...@shealevy.com) wrote: Hi all, rngd currently supports three sources of randomness to increase the kernel's entropy pool: The hwrng device, the trusted platform module device, and the RdRand x86 instruction. We don't want to start the daemon when none of the sources are available (as it will fail), but we want to start it as early as possible after some source is available so that programs requiring randomness have a good entropy pool available to them. Is there any way to express the following start-up behavior: If the cpu supports RdRand*, then start rngd as soon as possible, otherwise start rngd as soon as either a hwrng device or a tpm device comes online? One solution I thought of was to change rngd to listen for uevents and add to its list of used randomness sources on-the-fly. Then we could just start rngd as soon as possible, it will use RdRand if available and otherwise idle until a usable randomness source comes online. The downside to this is that it will complicate rngd (which from my brief perusal of the code is currently single-threaded) and that it might make users think they have a decent entropy source available but rngd is just sitting there. Thoughts? Mantas' suggestion is the way to go. That said, what's the reason for having a userspace component for this at all? Why isn't all of this done inside the kernel? I mean, the kernel /dev/random stuff already has hooks into various subsystems to get entropy, it sounds trivial to also hook up RDRAND with it? Maintaing complex userspace infrastructure where a 20 line kernel patch or so would suffice too, doesn't sound ideal to me? 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] logind: multiseat without framebuffer graphic cards
On Thu, 22.11.12 13:27, Thomas Bächler (tho...@archlinux.org) wrote: For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). seat-master sounds like a good name for this. I'd be happy to merge a patch that changes logind so that it watches for devices tagged with this, and spawns an X server the moment such a device appears. The second step is to make multi-seat-x support custom configurations: If an X server is to be spawned on on a seat named seatN and /etc/X11/xorg.conf_seatN exists, then that configuration file is used and multi-seat-x doesn't generate one. (Over time, maybe multi-seat-x can be extended to support more setups automatically, but that is a very low priority for me, as figuring out the correct configuration with the proprietary nvidia driver is not straight-forward.) Can't this be done in X instead? IIRC X already has some matching thing in the configuration file format. Maybe this could be extended to allow matching by seat name? Then, people could just drop per-seat configuration as normal snippets into /etc/X11/xorg.conf.d/ and add a match line to them and that would be it? 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] logind: multiseat without framebuffer graphic cards
On Thu, 22.11.12 23:04, Oleg Samarin (osamari...@gmail.com) wrote: В Ср., 21/11/2012 в 20:23 +0100, Lennart Poettering пишет: I think there are other ways thinkable, where we don't have to add explicit nvidia-compatibility switches. For example, instead of explicitly watching for fb devices to show up before we consider a seat to be around, we could instead look for devices that are tagged with a special tag (tag as in udev's TAG= construct) -- we'd then tag all fb devices out-of-the-box this way, and people who want to use the nvidia binary driver can attach that tag to some kernel device the nvidia driver exposes, but I wouldn't have to care about that, and systemd upstream wouldn't need to know what people do locally. And maybe you could even convince Nvidia to ship the udev rule that attaches this tag in their drivers. By doing things this way we'd not introduce the race that your patch would introduce, but we'd not hardcode anything directly to fb devices. Note that in systemd we generally try to fix this things properly, and not work-around things. Now, your global swicth didn't appear as a proper fix to me, due to the race issues. But the solution with a udev tag otoh sounds like a worthwile fix that makes logind cleaner -- and which as a side-effect allows you to integrate things with your nvidia driver. Does that make some sense? OK. So we need two changes: (1). Introduce a new udev tag that means master device for the seat. Support it with logind.c. Add an udev rule that sets this tag for all framebuffer device Yes, and please name this tag seat-master. (2). multi-seat-x should not trigger an error if there is no framebufer device exist on the seat. It is a temporary stuff until X can get device from -seat, so it may look for a specially named config file or just start X without any addition parameters (or with -sharevts only) I'd much prefer if this was done in X instead. i.e. via matching the -seat parameter when parsing configuration files. i.e. xorg.conf currently already knows: MatchProduct MatchDevicePath MatchTag MatchDriver Maybe introducing a MatchSeat construct in this style would be the best solution? 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] Properly handling rngd's complex dependencies
El 23/11/12 11:38, Lennart Poettering escribió: That said, what's the reason for having a userspace component for this at all? Why isn't all of this done inside the kernel? I mean, the kernel /dev/random stuff already has hooks into various subsystems to get entropy, it sounds trivial to also hook up RDRAND with it? Maintaing complex userspace infrastructure where a 20 line kernel patch or so would suffice too, doesn't sound ideal to me? Unfortunately kernel developers seem to insist in pushing into userspace stuff that belongs to the kernel (notable exception on this is RDRAND that is actually used by the kernel to feed the entropy pool...) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v196
On Fri, Nov 23, 2012 at 10:29:53AM +0100, Henrik Grindal Bakken wrote: Thierry Reding thierry.red...@avionic-design.de writes: Hi, Would anyone know why the latest releases no longer work on 3.1 kernels? I tried to update from 187 to 196 today and booting the system on a vendor kernel based on 3.1.10 no longer gets to the boot prompt. It hangs somewhere near where it should actually be spawning a getty on the serial port. Booting systemd 196 on a kernel based on linux-next doesn't have this issue. I've gone over the NEWS entries between 187 and 196, but nothing obvious stood out. Any ideas? I'm running 196 just fine on a 3.0 vendor kernel, so it's not a universal problem. I also use getty on the serial port, with no local modifications. I believe the requirement for a 3.4 (or something) kernel came in 188 for some logging bits, although I'm not sure. systemd should work just fine without it, though. Okay, maybe there's an issue with this particular version of the kernel or something's odd with my configuration. I'll have to dig deeper. Thanks for the information. Thierry pgpqfoyZHu51D.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v196
On Fri, Nov 23, 2012 at 10:41:20AM +0100, Tomasz Torcz wrote: On Fri, Nov 23, 2012 at 10:29:53AM +0100, Henrik Grindal Bakken wrote: Any ideas? I'm running 196 just fine on a 3.0 vendor kernel, so it's not a universal problem. I also use getty on the serial port, with no local modifications. I believe the requirement for a 3.4 (or something) kernel came in 188 for some logging bits, although I'm not sure. systemd should work just fine without it, though. v189 NEWS: * Support for reading kernel messages from /proc/kmsg has now been removed. If you want kernel messages in the journal make sure to run a recent kernel (= 3.5) that supports reading structured messages from /dev/kmsg (see above). Okay, that doesn't sound very much like a general incompatibility. The way I read that, the worst that will happen on older kernels is that kernel messages don't make it to the journal. But the boot process shouldn't be hanging because of it. Thierry pgp7PBZnrWkMu.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix --full for journalctl zsh completion
---
shell-completion/systemd-zsh-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/systemd-zsh-completion.zsh
index 7799bf6..a58f4ae 100644
--- a/shell-completion/systemd-zsh-completion.zsh
+++ b/shell-completion/systemd-zsh-completion.zsh
@@ -77,7 +77,7 @@ _ctls()
{-n,--lines=}'[Number of journal entries to show]:integer' \
'--no-tail[Show all lines, even in follow mode]' \
{-o,--output=}'[Change journal output mode]:output
modes:_outputmodes' \
-{--full}'[Show long fields in full]' \
+'--full[Show long fields in full]' \
{-a,--all}'[Show all fields, including long and unprintable]' \
{-q,--quiet}[Don't show privilege warning] \
'--no-pager[Do not pipe output into a pager]' \
--
1.8.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev 182 and kernel 3.6.7
On Saturday 2012-11-24 06:08, Nelson wrote: Currently on Slackware 14.0 and that came with udev 182 and kernel 3.2.29. Under this configuration udev works properly, specifically /etc/udev/rules.d/70-persistent-cd.rules gets recreated if it doesn't exist and it is also USED to create certain links and dev nodes such as /dev/dvdrom. Once I move onto kernel 3.6.7 udev begins to act weird. /etc/udev/rules.d/70-persistent-cd.rules does not seem to be used at all, nor is it recreated if it gets removed. Somewhat related to the problem is that, starting with systemd-183, 70-persistent-cd.rules does not get created *at all* anymore, because the write_cd_rules script has been removed by Kay Sievers in commit 3e2147858f21943d5f4a781c60f33ac22c6096ed (move imported udev into place), but the commit messages leaves no trace as to why some files were removed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is unmounting of filesystem synchronized with stopping services using these filesystems?
According to bootup(7) stopping services and unmounting of filesystems happens in parallel. Is there any sort of implicit dependencies between running services and filesystems? I do not see anything besides dependencies explicitly listed in unit files. So am I right to assume that systemd just continues to attempt to unmount each filesystem until it succeeds? In this case I'm just curious how it happens. As far as I can tell, mount_stop() always succeeds, so stop job is always completed. After /bin/umount completes, mount_sigchld_event() checks whether filesystem is gone or not, and if it is still present it reenters it again in list of active units. At which point it immediately conflicts with umount.target and it starts all over again. Is the above algorithm correct? TIA -andrey ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev 182 and kernel 3.6.7
While my issue is still with udev 182 and kernel 3.6.7, does 70-persistent-cd.rules even get USED at all if it was created beforehand with 183? On Sat, Nov 24, 2012 at 12:35 AM, Jan Engelhardt jeng...@inai.de wrote: On Saturday 2012-11-24 06:08, Nelson wrote: Currently on Slackware 14.0 and that came with udev 182 and kernel 3.2.29. Under this configuration udev works properly, specifically /etc/udev/rules.d/70-persistent-cd.rules gets recreated if it doesn't exist and it is also USED to create certain links and dev nodes such as /dev/dvdrom. Once I move onto kernel 3.6.7 udev begins to act weird. /etc/udev/rules.d/70-persistent-cd.rules does not seem to be used at all, nor is it recreated if it gets removed. Somewhat related to the problem is that, starting with systemd-183, 70-persistent-cd.rules does not get created *at all* anymore, because the write_cd_rules script has been removed by Kay Sievers in commit 3e2147858f21943d5f4a781c60f33ac22c6096ed (move imported udev into place), but the commit messages leaves no trace as to why some files were removed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
