Re: [systemd-devel] when will mount / df get fixed?
On Tue, Oct 02, 2012 at 02:00:20AM +0200, Marius Tolzmann wrote: Hi.. On 01.10.2012 20:32, Reindl Harald wrote: and how they should do this after the change that there is no flag? dispaly a RANDOM line? That is a possibility. Based upon that you are only interested in the device anyway, I conclude the mountpoint is irrelevant that makes preety no sense on a server with 100 bind-mounts if everytime any of the admins type df he sees different mountpoints - this is a computer not a gambling machine Can't you just revert the old behavior by removing the symlink and just touching /etc/mtab? Or do I miss something? If your system depends on stuff like that, then just do it the way you need it.. It's open source and you can do what ever you want? I think systemd will just issue a warning that you may just want to ignore. (Or has that changed in the past and systemd enforces this and stops working?) and these are basic things which should be considered BEFORE any invasive change and not after the damage is done since more than a year Actually for me df always showed every bind mounted mountpoint. Since it was recorded in /etc/mtab it also showed which olddir I have mounted on which newdir (mount --bind olddir newdir) like in filesystem size mounted on /mnt/whatever xxx /wherever now instead displaying it as /mnt/whatever it just displays as /dev/sdb3 .. Which is in fact not nice, but hey, it works. This is not as nice, but actually more correct. If the original mountpoint is unmounted, which is certainly possible, than the old line with /mnt/whatever is not true anymore. The line with /dev/whatever is still correct. BTW Is there a way to see what olddir was bind mounted on which newdir with /etc/mtab being a symlink to /proc(/self)/mounts? Does the kernel keep track of this information at all? Should it at all keep track of it? And if not, why not? Is this information present in some kernel structure which is just not exported via procfs? Hey, Kernel guys, please help 8) $ sudo mount --bind /usr/share/info /tmp/info $ findmnt ... └─/tmp/info /dev/mapper/root[/usr/share/info] ext4 rw,noatime,err So, the answer is yes. The data comes from /proc/self/mountinfo. Because I personally think displaying /dev/sdb4 as a device in /proc/mounts for a bind-mount may in fact be wrong. Because i can't use the information displayed there to unmount that mountpoint and mount it again? Or can I? I don't think so, because the information which subdirectory (olddir) was mounted here is not displayed. (I did not yet do any research on this topic - that is just what came to mind while following this discussion) I really think there is some regression after replacing /etc/mtab with a symlink. But I also do think symlinking /etc/mtab was a good thing to do: to keep /etc/mtab up-to-date. IMHO the regression is partially caused by /proc/mounts not showing the olddir information but just the device name (/dev/sdXn, /dev/mdXn, ..). Because it is not /dev/sda1 which is mounted as /. It is / of (the filesystem on) /dev/sda1 which is mounted as /. And it may be /tmp/abc of /dev/sda1 which is mounted as /home/abc/tmp (and not just /dev/sda1 mounted as /home/abc/tmp). The original mountpoint is irrelevant. What you say, that the / of the filesystem is mounted, is true. But by convention, when mounting the / of the filesystem, mount shows it as if the device was mounted. This makes sense because it is certainly the most common case. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
On 10/01/2012 10:53 PM, Mirco Tischler wrote: Systemd isn't really the right place to do network related stuff, imo. Such things are better dealt with in the network connection manager, where the information is already available. NetworkManager has a mechanism to execute custom scripts in /etc/NetworkManager/dispatcher.d on network events. For details take a look at the man page, support for explicit actions on vpn-up/down is mentioned there. Arguably systemd is the correct place under CoreOS to unite and manage network connections JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when will mount / df get fixed?
Hi.. On 10/02/12 10:11, Zbigniew Jędrzejewski-Szmek wrote: filesystem size mounted on /mnt/whatever xxx /wherever now instead displaying it as /mnt/whatever it just displays as /dev/sdb3 .. Which is in fact not nice, but hey, it works. This is not as nice, but actually more correct. If the original mountpoint is unmounted, which is certainly possible, than the old line with /mnt/whatever is not true anymore. The line with /dev/whatever is still correct. That's true. But as long as '/' of the same device is also mounted it may be possible to display it that way. So the mount order is not important. BTW Is there a way to see what olddir was bind mounted on which newdir with /etc/mtab being a symlink to /proc(/self)/mounts? Does the kernel keep track of this information at all? Should it at all keep track of it? And if not, why not? Is this information present in some kernel structure which is just not exported via procfs? Hey, Kernel guys, please help 8) $ sudo mount --bind /usr/share/info /tmp/info $ findmnt ... └─/tmp/info /dev/mapper/root[/usr/share/info] ext4 rw,noatime,err So, the answer is yes. The data comes from /proc/self/mountinfo. Oh I missed that... thank you. I actually looked at /proc/self/mountinfo but misinterpreted the output. And my findmnt seems to be out of date, because it does not show this information. ;) Because it is not /dev/sda1 which is mounted as /. It is / of (the filesystem on) /dev/sda1 which is mounted as /. And it may be /tmp/abc of /dev/sda1 which is mounted as /home/abc/tmp (and not just /dev/sda1 mounted as /home/abc/tmp). The original mountpoint is irrelevant. What you say, that the / of the filesystem is mounted, is true. But by convention, when mounting the / of the filesystem, mount shows it as if the device was mounted. This makes sense because it is certainly the most common case. I agree, it is irrelevant if you mount the root (/). ;) But to focus again to the original problem, where df does not work (because systemd is evil and broke it ;) ) I think (given your information) that it may be possible to fix the original issue where a symlinked mtab pollutes df output just by using the information provided by the kernel itself and not depending on some maybe-out-of-date-/etc/mtab. If no file name is given, the space available on all currently mounted file systems is shown. (from df(1)). If this is intended, then it was broken before, because it only showed filesystems recorded in /etc/mtab and not all mounted filesystems 8). So maybe neither (symlinked) /etc/mtab nor df needs to be fixed. There is just a tool missing, showing only the diskusage / available space of all currently used/mounted block devices (only once)? (Or a filter in df: df -b or df --block-devices) ..or whatever.. but it is not a systemd issue at all and I think there is no need to continue the flamewar, since all the information needed to fix this, is available under /proc ;) regards, marius.. -- Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de --.-- MPI f. molekulare Genetik | Ihnestrasse 63-73, D-14195 Berlin | == MarIuX GNU/Linux == Phone: +49 (0)30 8413 1709| --^-- God put me on earth to accomplish a certain number of things. Right now I am so far behind.. ..I will never die. by calvin from calvinhobbes ;) smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
2012/10/2 Jóhann B. Guðmundsson johan...@gmail.com: On 10/01/2012 10:53 PM, Mirco Tischler wrote: Systemd isn't really the right place to do network related stuff, imo. Such things are better dealt with in the network connection manager, where the information is already available. NetworkManager has a mechanism to execute custom scripts in /etc/NetworkManager/dispatcher.d on network events. For details take a look at the man page, support for explicit actions on vpn-up/down is mentioned there. Arguably systemd is the correct place under CoreOS to unite and manage network connections JBG How do you do that? systemd doesn't have any support to manage network connections. It lacks information about the state of the network devices and cannot configure them as well. In Matthew's case creating a dispatcher script that issues a systemctl restart squid.service on vpn state changes looks like a correct solution to me. Do you have a better idea? Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: assert target instead of page
On Mon, Oct 01, 2012 at 09:53:33AM +0200, Lukas Nykryn wrote: --- src/journal/journal-gatewayd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/journal/journal-gatewayd.c b/src/journal/journal-gatewayd.c index b7acfba..0957dcb 100644 --- a/src/journal/journal-gatewayd.c +++ b/src/journal/journal-gatewayd.c @@ -399,7 +399,7 @@ static int request_handler_redirect( int ret; assert(connection); -assert(page); +assert(target); Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald.conf vs systemd.journald.conf
On Mon, 01.10.12 18:13, David Lambert (d...@lambsys.com) wrote: I just noticed that it that journald.conf seems to have replaced systemd.journald.conf; am I correct? No. systemd-journald.conf has been renamed to journald.conf. We simply dropped the prefix of this, since it was implied by the configuration path (/etc/systemd), and since it never is visible outside (unlike the names of the binaries in /usr/lib/systemd, which will show up in ps as comm field of the processes). 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] journald.conf vs systemd.journald.conf
On Tue, 02.10.12 15:23, Lennart Poettering (lenn...@poettering.net) wrote: On Tue, 02.10.12 09:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I find that being able to turn off kernel chatter using ImportKernel=no, was a very useful feature especially on embedded systems with limited resources (and buggy kernel drivers ;-) ) Yeah, doesn't seem to be possible ATM. In general we really want only those configurations that are really necessary and the primary solution for a specific usecase. That's why we dropped ImportKernel=. s/configurations/configuration options/. Sorry for the confusion. 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] XDG_SEAT for kmscon
On Mon, 01.10.12 15:08, David Herrmann (dh.herrm...@googlemail.com) wrote: Hi I am currently working on making kmscon a drop-in replacement for agetty and was wondering how XDG_SEAT has to be set to correctly mark the seat-name for new logins? I currently simply spawn /bin/login from kmscon, but it doesn't set up the seat-name correctly (it simply passes ). Setting XDG_SEAT=seat0 for /bin/login doesn't work. Is there any documentation on this variable? Just for completeness of the mailing list archives' sake: systemd in git will now check XDG_SEAT both via pam_getenv() and via getenv() (only as fallback), so that this should work correctly. 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] when will mount / df get fixed?
On Sat, 29.09.12 18:28, Reindl Harald (h.rei...@thelounge.net) wrote: Reindl, there is really no need to word your questions the way you are doing. I will ban you from this mailing list if you don't stop being so dramatic and insulting. The simple fact is that systemd was merely the messenger of something that has changed in the kernel long ago. Don't yell at the messenger. To me it appears that the right fix is to patch df to coalesce the lines of the various mount points of the same backing fs. it should just show them as the rightmost column, comma separated, and if there are too many, it should just allipsize the list instead of showing them all. Anyway, this is mostly something between coreutils and the kernel, and the way how df parses and presents the information of the kernel. systemd has no role in this. Please (politely!) ask the coreutils maintainers to coalesce mounts like this. will this behavior get fixed in my lifetime? the alias for df is a dirty solution Try being constructive for once: if there's an itch you really want to have scratched then there's always the option to just fix it yourself and send a patch upstream. This is how open source works, after all. Anyway, please stop posting things in the style you are posting them in here. This is not LKML, and in contrast to LKML we do not reward insulting people here. 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] Keeping console messages on VT1
On Thu, 27.09.12 00:02, Henrik /KaarPoSoft (hen...@kaarposoft.dk) wrote: Dear all, I am a NOOB when it comes to systemd; hope you don't mind a stupid question... When systemd is starting, it shows log messages (i.e. console output) on Virtual Terminal 1 (VT1). However: (1) When logind is starting, it shows a login prompt on VT1. This prompt may come in the middle of the console messages, messing up the display. tty1 is actually not managed by logind (it will only manage TTYs 2 and up). Simply remove /etc/systemd/system/getty.target.wants/getty@tty1.service and no getty will be started on tty1. (2) When switching to another VT, e.g. VT2, and logging in here, log messages (i.e. console output) are shown on VT2. This is quite annoying, in particular when editing a file with vi or similar. console=tty1 on the kernel cmdline should make this work. systemd's boot status display prints on /dev/console, and hence is also influenced by console= on the kernel cmdline. 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] Launching a unit in response to a D-Bus signal
On 10/02/2012 12:47 PM, Mirco Tischler wrote: How do you do that? systemd doesn't have any support to manage network connections. It lacks information about the state of the network devices and cannot configure them as well. Today systemd cant but in the future it might depending on how things progress. From my point of view an single network management application should be integrated into the init system in this case systemd/CoreOS. It just begs the question to what extent as to complexity. In the end the solution what ever it might be needs to be something that can be light enough to be on embedded but flexible enough to handle complex server environment with the desktop falling somewhere between those two. I'm very well that a lot of people think forking is fun but I just dont tend to agree with that for something that is fundamental part of the underlying OS as network management is and should be from my pov. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature suggestion: journalctrl -b n
On Wed, 26.09.12 23:51, Henrik /KaarPoSoft (hen...@kaarposoft.dk) wrote: Dear all, journalctrl -b shows messages from the current boot. However, I often find it useful to look at messages from the previous boot. Hence I would like to propose a new feature: journalctrl -b n should show messages from the n'th previous boot, default being n=0, i.e. current boot. What do you think about this? Sounds like a good idea. Added this to the TODO list. PS: It might also be useful to have an option to show all boot-ID's in the journal, maybe showing first and last timestamp of the log, and number of entries. And maybe having an option like journalctrl -b boot-ID Yes, it is actually our plan to implement work-alikes for last, lastlog and suchlike to systemd that simply take the data out of the journal for that. A similar tool could be one that inspects boot IDs like you suggest. To make this work nicely we need a minor update of the journal indexing logic however (which is already there in the format, but not implemented) 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] Feature suggestion: journalctrl -b n
On Sat, 29.09.12 02:11, David Strauss (da...@davidstrauss.net) wrote: On Wed, Sep 26, 2012 at 2:51 PM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: Hence I would like to propose a new feature: journalctrl -b n should show messages from the n'th previous boot, default being n=0, i.e. current boot. What do you think about this? Rather than add a special case for boots, I'd prefer moving to a mechanism more like git or Bazaar has for specifying revision ranges. There would be various specification approaches, all of which translate into (if they aren't intrinsically) a cursor position. Then, it's modular for specifying the range by date, boot number, or any other monotonic property of the journal entries. --since=boot:-1 --until=date:2012-09-29 --since=date:2012-09-29 --until=some-entry-id I'll look into how hard this would be to add. Any other monotonic features we could use as a range for journal entries? The monotonic feature is important so it's possible to discover the first or last qualifying item in an efficient way like a binary search. I recently added support for --cursor= to journalctl, but this is not complete yet. It is my intention to add some kind of time based seeking as well. 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] journalctl and entries from the initramfs
On Thu, 27.09.12 01:49, Malte Starostik (li...@malte.homeip.net) wrote: Hi, after upgrading from 189 to 192, I noticed journalctl will no longer include the journal entries from the initramfs bootup unless -m is passed. Assuming this is caused by this 190-change: * journalctl will only show local log output by default now. Use --merge (-m) to show remote log output, too. makes me wonder if that's an intended side effect or more of a bug? i.e. is early userspace officially included in remote or should its ephemeral machine- id maybe be special cased to show up even without -m? I guess building the initramfs as hostonly would fix this surprise as /etc/machine-id is then copied from the host, but hostonly implies many unwanted things. Hmm, let me understand this right: do you use persistent journal logging (i.e. do you have /var/log/journal around?). If so journald should have flushed *all* of /run/log/journal to /var/log/journal after /var became available. If you are not using persistent logging, then I grok the problem, but in that case maybe the fix is to simply enable persistent logging? 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] journald.conf vs systemd.journald.conf
Thanks Lennart. That makes a lot of sense. Unfortunately MaxLevelStore etc. does not appear to work on my system, although ImportKernel=no does. My journald.conf is attached, and my version of systemd is: root@argus-base:~# systemctl --version systemd 44 angstrom +PAM +LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP Any ideas? Is this a version issue? TIA, Dave. root@argus-base:~# On 10/02/2012 08:23 AM, Lennart Poettering wrote: On Tue, 02.10.12 09:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I find that being able to turn off kernel chatter using ImportKernel=no, was a very useful feature especially on embedded systems with limited resources (and buggy kernel drivers ;-) ) Yeah, doesn't seem to be possible ATM. In general we really want only those configurations that are really necessary and the primary solution for a specific usecase. That's why we dropped ImportKernel=. If you want to lower the amount of chatter you get then I'd recommend using stuff like MaxLevelStore= to simply store less data on disk. Lennart # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # See system-journald.conf(5) for details [Journal] Storage=volatile #Compress=yes #RateLimitInterval=10s #RateLimitBurst=200 #SystemMaxUse= #SystemKeepFree= #SystemMaxFileSize= #SystemMinFileSize= RuntimeMaxUse=1M #RuntimeKeepFree= #RuntimeMaxFileSize= #RuntimeMinFileSize= ForwardToSyslog=no #ForwardToKMsg=no #ForwardToConsole=no ImportKernel=no MaxLevelKMsg=4 MaxLevelConsole=4 MaxLevelStore=4 MaxLevelSyslog=4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald.conf vs systemd.journald.conf
On Tue, 02.10.12 10:33, David Lambert (d...@lambsys.com) wrote: Thanks Lennart. That makes a lot of sense. Unfortunately MaxLevelStore etc. does not appear to work on my system, although ImportKernel=no does. My journald.conf is attached, and my version of systemd is: root@argus-base:~# systemctl --version systemd 44 angstrom +PAM +LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP Any ideas? Is this a version issue? Might be. Please try a newer systemd version. If it doesn't work there, please file a bug. Thanks! 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] when will mount / df get fixed?
]] Reindl Harald Am 02.10.2012 16:13, schrieb Lennart Poettering: On Sat, 29.09.12 18:28, Reindl Harald (h.rei...@thelounge.net) wrote: there is really no need to word your questions the way you are doing. I will ban you from this mailing list if you don't stop being so dramatic and insulting. seems like people on mailing-lists are a little hypersensitive Or maybe you're coming across as more aggressive than you intend. [...] To me it appears that the right fix is to patch df to coalesce the lines of the various mount points of the same backing fs. it should just show them as the rightmost column, comma separated, and if there are too many, it should just allipsize the list instead of showing them all. no need for any additional output df = DISK free mount = mounts This is clearly not correct, given df shows the amount of free space on file systems (or maybe subvolumes), not disks. So, using the name of the program as defined back in the 1970s isn't terribly useful. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Feature suggestion: journalctrl -b n
On 10/02/12 17:06, Lennart Poettering wrote: On Wed, 26.09.12 23:51, Henrik /KaarPoSoft (hen...@kaarposoft.dk) wrote: Dear all, journalctrl -b shows messages from the current boot. However, I often find it useful to look at messages from the previous boot. Hence I would like to propose a new feature: journalctrl -b n should show messages from the n'th previous boot, default being n=0, i.e. current boot. What do you think about this? Sounds like a good idea. Added this to the TODO list. Great! Thank you. PS: It might also be useful to have an option to show all boot-ID's in the journal, maybe showing first and last timestamp of the log, and number of entries. And maybe having an option like journalctrl -b boot-ID Yes, it is actually our plan to implement work-alikes for last, lastlog and suchlike to systemd that simply take the data out of the journal for that. A similar tool could be one that inspects boot IDs like you suggest. To make this work nicely we need a minor update of the journal indexing logic however (which is already there in the format, but not implemented) Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Keeping console messages on VT1
On 10/02/12 16:51, Lennart Poettering wrote: On Thu, 27.09.12 00:02, Henrik /KaarPoSoft (hen...@kaarposoft.dk) wrote: Dear all, I am a NOOB when it comes to systemd; hope you don't mind a stupid question... When systemd is starting, it shows log messages (i.e. console output) on Virtual Terminal 1 (VT1). However: (1) When logind is starting, it shows a login prompt on VT1. This prompt may come in the middle of the console messages, messing up the display. tty1 is actually not managed by logind (it will only manage TTYs 2 and up). Simply remove /etc/systemd/system/getty.target.wants/getty@tty1.service and no getty will be started on tty1. Thank you very much for the clarification. (2) When switching to another VT, e.g. VT2, and logging in here, log messages (i.e. console output) are shown on VT2. This is quite annoying, in particular when editing a file with vi or similar. console=tty1 on the kernel cmdline should make this work. systemd's boot status display prints on /dev/console, and hence is also influenced by console= on the kernel cmdline. Yes, I can now manage to have all messages on tty1, and login on tty2,3,etc. However, GDM 3.4.1 still puts an X11 server on tty1. Presumably because it is not busy, as nothing is running there. GDM once had a FirstVT config option, but it seems gone now. Anyways I guess that GDM is Off Topic, so I shall not persue it further here... /Henrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when will mount / df get fixed?
Am 02.10.2012 19:26, schrieb Tollef Fog Heen: To me it appears that the right fix is to patch df to coalesce the lines of the various mount points of the same backing fs. it should just show them as the rightmost column, comma separated, and if there are too many, it should just allipsize the list instead of showing them all. no need for any additional output df = DISK free mount = mounts This is clearly not correct, given df shows the amount of free space on file systems (or maybe subvolumes), not disks. So, using the name of the program as defined back in the 1970s isn't terribly useful. a bind-mount is NOT a file-system nor a subvolume 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] journald.conf vs systemd.journald.conf
Looks like it is a version issue, so no bug report. While on the subject; is systemd tolerant to deprecated options, or will it fail? If tolerant, I can make a config file common to all versions, if not, is there a way of conditionalizing within the config file? Best, Dave. On 10/02/2012 10:45 AM, Lennart Poettering wrote: On Tue, 02.10.12 10:33, David Lambert (d...@lambsys.com) wrote: Thanks Lennart. That makes a lot of sense. Unfortunately MaxLevelStore etc. does not appear to work on my system, although ImportKernel=no does. My journald.conf is attached, and my version of systemd is: root@argus-base:~# systemctl --version systemd 44 angstrom +PAM +LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP Any ideas? Is this a version issue? Might be. Please try a newer systemd version. If it doesn't work there, please file a bug. Thanks! Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald.conf vs systemd.journald.conf
On Tue, 02.10.12 15:36, David Lambert (d...@lambsys.com) wrote: Looks like it is a version issue, so no bug report. While on the subject; is systemd tolerant to deprecated options, or will it fail? If tolerant, I can make a config file common to all versions, if not, is there a way of conditionalizing within the config file? We ignore options we don't understand, but will mention this in the logs. Hence this should be quite robust to updates. 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] Keeping console messages on VT1
'Twas brillig, and Henrik /KaarPoSoft at 02/10/12 20:13 did gyre and gimble:
Yes, I can now manage to have all messages on tty1, and login on
tty2,3,etc.
However, GDM 3.4.1 still puts an X11 server on tty1.
Presumably because it is not busy, as nothing is running there.
GDM once had a FirstVT config option, but it seems gone now.
Anyways I guess that GDM is Off Topic, so I shall not persue it further
here...
The general plan here is that Graphical DEs should use tty1 through 5
for user logins (more than 5 is relatively unlikely) whereas 6 is
reserved for text.
Now days gdm.service (or even prefdm.service before it in at least
Fedora and (because we nicked it) Mageia will actively conflict with
getty@tty1.service to prevent a text console appearing there. As
getty@tty{2,3,4,5}.service are only started on demand these days, if a
second gdm is spawned later it should just use tty2 (unless you've
manually switched to it already and triggered a getty to startup.
HTHs
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] journalctl and entries from the initramfs
Am Dienstag, 2. Oktober 2012, 17:12:00 schrieb Lennart Poettering: On Thu, 27.09.12 01:49, Malte Starostik (li...@malte.homeip.net) wrote: after upgrading from 189 to 192, I noticed journalctl will no longer include the journal entries from the initramfs bootup unless -m is passed. Assuming this is caused by this 190-change: * journalctl will only show local log output by default now. Use --merge (-m) to show remote log output, too. makes me wonder if that's an intended side effect or more of a bug? i.e. is early userspace officially included in remote or should its ephemeral machine- id maybe be special cased to show up even without -m? I guess building the initramfs as hostonly would fix this surprise as /etc/machine-id is then copied from the host, but hostonly implies many unwanted things. Hmm, let me understand this right: do you use persistent journal logging (i.e. do you have /var/log/journal around?). If so journald should have flushed *all* of /run/log/journal to /var/log/journal after /var became available. D'oh! With a persistent journal, all is well. In order not to litter the journal files with messages from all kinds of test runs, I had that disabled but didn't consider it a cause for the above. If you are not using persistent logging, then I grok the problem, but in that case maybe the fix is to simply enable persistent logging? Indeed, thanks for the nudge in the right direction. Malte ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] logind lid default configuration feedback
Greetings, I'm here to complain about a bad decision to default configuration keys HandleLidSwitch to suspend (instead of ignore) and LidSwitchIgnoreInhibited to yes (instead of no). Many of users use desktop environments handle this action and its configuration (like XFCE in my case). Aside of rather obvious point of overlap of responsibilities, which is a problem rather diplomatical and hard to solve - not point of my call, the problem I have is that Systemd's Logind makes a certain assumption about user wants and forces it down on them. Not everyone wants their laptop to suspend to RAM when the lid is close. After an update of my system (which in this case brought logind on) I expected my system to work at least like it worked before (if not better), respecting my configuration choices, I closed my laptop lid and walked away for an hour or so, I expected it to crunch data, I lost that time due to bad logind default config decision, fortunately not that a big deal, but the principle holds. I hope any new software developments will have more of that respect. Best Regards, Jiri Prochazka signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
