[systemd-devel] [PATCH] journald: assert target instead of page
--- 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); if (asprintf(&page, "Please continue to the journal browser.", target) < 0) return respond_oom(connection); -- 1.7.6.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] XDM and systemd --user
On Sat, Sep 29, 2012 at 09:02:11PM +0100, Colin Guthrie wrote: > 'Twas brillig, and Kok, Auke-jan H at 28/09/12 20:09 did gyre and gimble: > > 1) people should fix 'make' to just allow `-j` without an argument > > (seriously, dude ;^) ) > > Going dangerously off-topic, but two points: > > If you're using -j I've always gone under the impression you want the > value to be #cores+1, not #cores. That way you keep your machine working > full tilt. > > But regardless, why not use "make -l" anyway? This way it's tied to > system load which is likely a more prudent method to decide whether or > not new make jobs are issued - e.g. if you happen to be running a make > process that is io-intensive, you likely want to run less of them, but > if you've got a couple jobs one of which is io intensive then some of > your cpu cores might be mostly idle... -l should allow you to max things > out better. Yeah, -l seems better. But than you still want a load of #cores+1, no? And -l requires an argument too, so it has exactly the same inconvinience as -j. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] XDM and systemd --user
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 01/10/12 09:42 did gyre and gimble: > On Sat, Sep 29, 2012 at 09:02:11PM +0100, Colin Guthrie wrote: >> 'Twas brillig, and Kok, Auke-jan H at 28/09/12 20:09 did gyre and gimble: >>> 1) people should fix 'make' to just allow `-j` without an argument >>> (seriously, dude ;^) ) >> >> Going dangerously off-topic, but two points: >> >> If you're using -j I've always gone under the impression you want the >> value to be #cores+1, not #cores. That way you keep your machine working >> full tilt. >> >> But regardless, why not use "make -l" anyway? This way it's tied to >> system load which is likely a more prudent method to decide whether or >> not new make jobs are issued - e.g. if you happen to be running a make >> process that is io-intensive, you likely want to run less of them, but >> if you've got a couple jobs one of which is io intensive then some of >> your cpu cores might be mostly idle... -l should allow you to max things >> out better. > > Yeah, -l seems better. But than you still want a load of #cores+1, no? > And -l requires an argument too, so it has exactly the same > inconvinience as -j. I thought -l was based on the Load Average of the system which is separate from #cores. So if I like keeping my LA below 1.5, I'd just use -l 1.5. and this wouldn't really matter how many cores I have. That said, I'm prepared to be wrong here as I've not really read up about it much! :) 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] XDM and systemd --user
On Mon, Oct 01, 2012 at 10:55:14AM +0100, Colin Guthrie wrote: > 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 01/10/12 09:42 did > gyre and gimble: > > On Sat, Sep 29, 2012 at 09:02:11PM +0100, Colin Guthrie wrote: > >> 'Twas brillig, and Kok, Auke-jan H at 28/09/12 20:09 did gyre and gimble: > >>> 1) people should fix 'make' to just allow `-j` without an argument > >>> (seriously, dude ;^) ) > >> > >> Going dangerously off-topic, but two points: > >> > >> If you're using -j I've always gone under the impression you want the > >> value to be #cores+1, not #cores. That way you keep your machine working > >> full tilt. > >> > >> But regardless, why not use "make -l" anyway? This way it's tied to > >> system load which is likely a more prudent method to decide whether or > >> not new make jobs are issued - e.g. if you happen to be running a make > >> process that is io-intensive, you likely want to run less of them, but > >> if you've got a couple jobs one of which is io intensive then some of > >> your cpu cores might be mostly idle... -l should allow you to max things > >> out better. > > > > Yeah, -l seems better. But than you still want a load of #cores+1, no? > > And -l requires an argument too, so it has exactly the same > > inconvinience as -j. > > I thought -l was based on the Load Average of the system which is > separate from #cores. So if I like keeping my LA below 1.5, I'd just use > -l 1.5. and this wouldn't really matter how many cores I have. That > said, I'm prepared to be wrong here as I've not really read up about it > much! :) I would love to be proved wrong --- i.e. to learn that 'make -l' adapts to the number of cores by itself. But as I understand it, "load" is "the number of running or waiting to run process". If 'make -l' uses the same definition, than one would want #nrcores+1 at least. Zbyszek ___ 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, Sep 29, 2012 at 07:36:54PM +0200, Reindl Harald wrote: > you missunderstood me > > that all mount are in the output is OK > BUT all the years there was a hint taht it is a bind-mount > since systemd/F15 there is no difference There is no difference. The "bind" is an operation, not a special state of any mountpoint. Nowhere in the system is information that the mountpoint has been created by "bind" -- the kernel does not see any difference between the original and bind mount. It's just another reference to the same object (device). mount /dev/sda1 /mnt1 mount /dev/sda1 /mnt2 is exactly the same as: mount /dev/sda1 /mnt1 mount --bind /mnt1 /mnt2 We should not care about "bind" flag in mtab (or another place) at all. The solution is to de-duplicate df(1) output. It's fine to blame systemd guys for all the bad things in the World, but kill the original mtab concept was planned independently on systemd. Karel -- Karel Zak http://karelzak.blogspot.com ___ 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 01.10.2012 13:29, schrieb Karel Zak: > On Sat, Sep 29, 2012 at 07:36:54PM +0200, Reindl Harald wrote: > There is no difference. The "bind" is an operation, not a special > state of any mountpoint. Nowhere in the system is information that > the mountpoint has been created by "bind" -- the kernel does not > see any difference between the original and bind mount. It's just > another reference to the same object (device). > mount /dev/sda1 /mnt1 > mount /dev/sda1 /mnt2 > > is exactly the same as: > > mount /dev/sda1 /mnt1 > mount --bind /mnt1 /mnt2 but there was a difference until F15 came out with systemd > We should not care about "bind" flag in mtab (or another place) at > all. The solution is to de-duplicate df(1) output. and how should "df" do this? how should "df" smell that "/mnt/data" is the one to display? /dev/md2 3814414416 2335948104 1478466312 62% /mnt/data /dev/md2 3814414416 2335948104 1478466312 62% /home /dev/md2 3814414416 2335948104 1478466312 62% /tmp /dev/md2 3814414416 2335948104 1478466312 62% /var/tmp /dev/md2 3814414416 2335948104 1478466312 62% /Volumes/dune/www-servers /dev/md2 3814414416 2335948104 1478466312 62% /Volumes/dune/www-servers/phpincludes > It's fine to blame systemd guys for all the bad things in the World, > but kill the original mtab concept was planned independently on > systemd. however, before killing things which worked fine for decades there should be a thought how to change things internally without change the behavior from the users view only the fact that the named-chroot mounts caused a error message for a normal user proves that there was not much testing/thinking about impacts - this one meant to get error-mails from EVERY cronjob-script using "df" signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Launching a unit in response to a D-Bus signal
I have a requirement to restart squid whenever the VPN goes up or down[1]. Reading around, it seems that the way to do this would be in response to the relevant D-Bus signal, which seems to be this one: signal sender=:1.6 -> dest=(null destination) serial=269 path=/org/freedesktop/NetworkManager/ActiveConnection/2; interface=org.freedesktop.NetworkManager.VPN.Connection; member=VpnStateChanged I expected that systemd would allow me to do this, but as far as I can tell it doesn't (I'm using F17). I can obviously write my own daemon to do this, but it seems to me that a daemon just for this would be a waste. I think this sounds like a good fit for systemd. Is it anything anybody's looked at? Thanks, Matt [1] It's not directly relevant to this post, but the reason is that squid doesn't pick up the new nameservers until it's restarted. P.S. I'm not subscribed. -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ 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 Saturday 2012-09-29 22:21, Reindl Harald wrote: >> >> What is the actual problem? That `df` no longer shows only >> user-initiated mounts? > >df (1p) - report free disk space > >damned - i have ONE /dev/md2 >if i want to list mounts i typ "mount" and NOT "disk free" I think in that case, you should talk to the developers of df (coreutils) and ask for it to show at most one line per device. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nfs mounts and the "nofail" option
'Twas brillig, and Colin Guthrie at 30/09/12 14:03 did gyre and gimble: > Hi, > > As we've discussed the semantics of (specifically) nfs mounts with the > nofail option, it seems that latest libmount+nfs-utils do not handle the > nofail option between them which causes mount failures if it's specified > in the fstab. > > The following patch to util-linux tells libmount to strip off the nofail > option before handing it to the mount helper, but perhaps this is too > general and some mount helpers for different filesystems need to nofail > option to be passed through? > > An alternative is simply to tech nfs-utils about the option. > > Question is: Which is the correct approach? The answer appears to be "neither, just compile nfs-utils against libmount with the --enable-libmount-mount option" which seems to neatly solve the problem (and other one I had too). Thanks Karel for the pointer :) 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
[systemd-devel] XDG_SEAT for kmscon
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? Regards David ___ 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 01.10.2012 14:41, schrieb Jan Engelhardt: > > On Saturday 2012-09-29 22:21, Reindl Harald wrote: >>> >>> What is the actual problem? That `df` no longer shows only >>> user-initiated mounts? >> >> df (1p) - report free disk space >> >> damned - i have ONE /dev/md2 >> if i want to list mounts i typ "mount" and NOT "disk free" > > I think in that case, you should talk to the developers of df > (coreutils) and ask for it to show at most one line per device. and how they should do this after the change that there is no flag? dispaly a RANDOM line? 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] when will mount / df get fixed?
On 10/01/2012 01:10 PM, Reindl Harald wrote: and how they should do this after the change that there is no flag? dispaly a RANDOM line? Is that not something you should be discussing with them? 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?
Am 01.10.2012 15:23, schrieb Jóhann B. Guðmundsson: > On 10/01/2012 01:10 PM, Reindl Harald wrote: >> and how they should do this after the change that there >> is no flag? dispaly a RANDOM line? > > Is that not something you should be discussing with them? so we are turning around in circles there is a bugreport from 2011-05-31 09:19:30 EDT there where many posts more than a year ago on devel-lists YOU say "discuss with coreutils-people" THEY say "requested by systemd guys" you guys all over the distribution are changing permanently things which worked over many years and everybody says some others are responsible finally the users are lost https://bugzilla.redhat.com/show_bug.cgi?id=709351#c12 This "totally idiotic bug" is caused by "harmless" change of /etc/mtab to symlink requested by systemd guys... and solution still discussed upstream... 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] when will mount / df get fixed?
> so we are turning around in circles > there is a bugreport from 2011-05-31 09:19:30 EDT > there where many posts more than a year ago on devel-lists > > YOU say "discuss with coreutils-people" > THEY say "requested by systemd guys" They are right in that the change was requested by systemd, because it is the only decent fix to prevent /etc/mtab of getting out of sync. But this does not mean that systemd _BROKE_ anything. IMHO the behavior of df and mount is 100% correct, and if you disagree, discus this with there developers. > you guys all over the distribution are changing permanently > things which worked over many years and everybody says > some others are responsible > > finally the users are lost > > > > https://bugzilla.redhat.com/show_bug.cgi?id=709351#c12 > > This "totally idiotic bug" is caused by "harmless" change of /etc/mtab to > symlink requested by systemd guys... and > solution still discussed upstream... Indeed, calling somthing that maybe isn't even a bug a "totally idiotic bug" is the way to get things fixed. It's like calling the person that gives you something for free a "total idiot" and expecting them to give you anything you ask for afterwards. So stop biting the hand that feeds you and try to do something constructive. ___ 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 01.10.2012 15:47, schrieb Peeters Simon: >> so we are turning around in circles >> there is a bugreport from 2011-05-31 09:19:30 EDT >> there where many posts more than a year ago on devel-lists >> >> YOU say "discuss with coreutils-people" >> THEY say "requested by systemd guys" > > They are right in that the change was requested by systemd, because it > is the only decent fix to prevent /etc/mtab of getting out of sync. ah and systemd is right because it worked over decades? do not fix things that ain't broken > But this does not mean that systemd _BROKE_ anything. > IMHO the behavior of df and mount is 100% correct, and if you > disagree, discus this with there developers. surely, it broke the over decades useful output of "df" >> https://bugzilla.redhat.com/show_bug.cgi?id=709351#c12 >> >> This "totally idiotic bug" is caused by "harmless" change of /etc/mtab to >> symlink requested by systemd guys... and >> solution still discussed upstream... > > Indeed, calling somthing that maybe isn't even a bug a "totally > idiotic bug" is the way to get things fixed. calling him not so did also not help > It's like calling the person that gives you something for free a > "total idiot" and expecting them to give you anything you ask for > afterwards. i would be happy if "df" output would not be broken for free after introducing systemd > So stop biting the hand that feeds you and try to do something constructive i try to work with my computer which worked fine over years until systemd-developers decided that the foedra world has to turn around them (df, UsrMove, /tmp on tmpfs, broken suspend of vmware-guests on shutdown...) there where much lesser invasive changes what systemd-developers refuse to understand is that their intention making things perfect by changing well known behavior is wasting time of users again and again because since F15 you can not trust any linux documentation you find somewhere before verify that the behavior was not changed before systemd started user-interfaces of the system were stable over many many years, now with each update i have the same question "look what they broke now" - this is not the way to a perfect world 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] when will mount / df get fixed?
2012/10/1 Reindl Harald : > > > Am 01.10.2012 15:47, schrieb Peeters Simon: >>> so we are turning around in circles >>> there is a bugreport from 2011-05-31 09:19:30 EDT >>> there where many posts more than a year ago on devel-lists >>> >>> YOU say "discuss with coreutils-people" >>> THEY say "requested by systemd guys" >> >> They are right in that the change was requested by systemd, because it >> is the only decent fix to prevent /etc/mtab of getting out of sync. > > ah and systemd is right because it worked over decades? > do not fix things that ain't broken > >> But this does not mean that systemd _BROKE_ anything. >> IMHO the behavior of df and mount is 100% correct, and if you >> disagree, discus this with there developers. > > surely, it broke the over decades useful output of "df" If you had read the link to the mailing list posted in the bug you refered to you would know that it is the kernel developers there intention to have this behavior, not systemd's (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f84e3f52 speaks about /etc/mtab as a symlink to /proc/mounts, which dates from February 2008, way before systemd was significant or even existed) So stop annoying the crap out of me. And speak to the people who have something to do with this, _NOT_ systemd. ___ 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 Monday 2012-10-01 15:10, Reindl Harald wrote: What is the actual problem? That `df` no longer shows only user-initiated mounts? >>> >>> df (1p) - report free disk space >>> >>> damned - i have ONE /dev/md2 >>> if i want to list mounts i typ "mount" and NOT "disk free" >> >> I think in that case, you should talk to the developers of df >> (coreutils) and ask for it to show at most one line per device. > >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. ___ 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 01.10.2012 19:22, schrieb Jan Engelhardt: > > On Monday 2012-10-01 15:10, Reindl Harald wrote: > > What is the actual problem? That `df` no longer shows only > user-initiated mounts? df (1p) - report free disk space damned - i have ONE /dev/md2 if i want to list mounts i typ "mount" and NOT "disk free" >>> >>> I think in that case, you should talk to the developers of df >>> (coreutils) and ask for it to show at most one line per device. >> >> 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 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 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] when will mount / df get fixed?
2012/10/1 Reindl Harald : > > 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 You made your point. Can you please just leave it at that? By being an asshole about it, you are just pissing people off and your pet issue is unlikely to get fixed any quicker, on the contrary. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
On Mon, Oct 1, 2012 at 4:58 AM, Matthew Booth wrote: > I have a requirement to restart squid whenever the VPN goes up or down[1]. > Reading around, it seems that the way to do this would be in response to the > relevant D-Bus signal, which seems to be this one: > > signal sender=:1.6 -> dest=(null destination) serial=269 > path=/org/freedesktop/NetworkManager/ActiveConnection/2; > interface=org.freedesktop.NetworkManager.VPN.Connection; > member=VpnStateChanged > > I expected that systemd would allow me to do this, but as far as I can tell > it doesn't (I'm using F17). I can obviously write my own daemon to do this, > but it seems to me that a daemon just for this would be a waste. I think > this sounds like a good fit for systemd. Is it anything anybody's looked at? The problem with listening on a specific DBus message is that it requires you to implement much more of DBus than systemd internally can. I'm not sure it's a good idea to put something that complex into systemd. Your alternatives are to write a simple DBus frontend, or perhaps a Network Manager plugin (if there is such a thing, I know connman has the concept of plugins). You can certainly socket activate a dummy service that doesn't actually listen on DBus but instead executes `systemctl restart squid.service` based on the BusName only. Systemd will likely however not appreciate the unhandled socket, but it may be worth a try. Auke ___ 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 Kok, Auke-jan H : > On Mon, Oct 1, 2012 at 4:58 AM, Matthew Booth wrote: >> I have a requirement to restart squid whenever the VPN goes up or down[1]. >> Reading around, it seems that the way to do this would be in response to the >> relevant D-Bus signal, which seems to be this one: >> >> signal sender=:1.6 -> dest=(null destination) serial=269 >> path=/org/freedesktop/NetworkManager/ActiveConnection/2; >> interface=org.freedesktop.NetworkManager.VPN.Connection; >> member=VpnStateChanged >> >> I expected that systemd would allow me to do this, but as far as I can tell >> it doesn't (I'm using F17). I can obviously write my own daemon to do this, >> but it seems to me that a daemon just for this would be a waste. I think >> this sounds like a good fit for systemd. Is it anything anybody's looked at? > > The problem with listening on a specific DBus message is that it > requires you to implement much more of DBus than systemd internally > can. I'm not sure it's a good idea to put something that complex into > systemd. > > Your alternatives are to write a simple DBus frontend, or perhaps a > Network Manager plugin (if there is such a thing, I know connman has > the concept of plugins). > > You can certainly socket activate a dummy service that doesn't > actually listen on DBus but instead executes `systemctl restart > squid.service` based on the BusName only. Systemd will likely however > not appreciate the unhandled socket, but it may be worth a try. > > Auke 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. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journald.conf vs systemd.journald.conf
I just noticed that it that journald.conf seems to have replaced systemd.journald.conf; am I correct? Also, looking at the man page for journald.conf it seems that some keywords such as "ImportKernel" have been removed or moved elsewhere? My documentation resource is http://www.freedesktop.org/software/systemd/man/. Is this correct? If not please point me in the right direction. 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 ;-) ) Best regards, Dave. ___ 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 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. 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) 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). But I think this is in fact a kernel issue and has nothing to do with systemd - so sorry for the noise here but hopefully someone here can follow my thoughts and cares about fixing/changing this so that systemd won't be blamed for this again.. 8) But at last: I also do not think flaming and crying will help to solve any issue. Thanks and bye marius.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
