Re: [gentoo-user] udevd boot messages
On 2012-05-26 01:52, Peter Humphrey wrote: $ elogviewer --help File /usr/local/bin/elogviewer, line 11 ^ SyntaxError: invalid syntax Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some overlay) is installed in /usr/bin/... Have you changed the install path or installed it through some other means? Best regards Peter K
Re: [gentoo-user] udevd boot messages
On Saturday 26 May 2012 09:36:50 pk wrote: On 2012-05-26 01:52, Peter Humphrey wrote: $ elogviewer --help File /usr/local/bin/elogviewer, line 11 ^ SyntaxError: invalid syntax Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some overlay) is installed in /usr/bin/... So is mine (same version), so I don't know why it's looking in /usr/local/bin. I have no alias mentioning elogviewer. $ find /usr -name elogviewer 2 /dev/null /usr/portage/app-portage/elogviewer /usr/bin/elogviewer $ $ grep /local/ /usr/bin/elogviewer $ Have you changed the install path or installed it through some other means? Nope. Unless I did something odd in 2007, I suppose. I don't like mysteries :-( -- Rgds Peter Portage 2.1.10.49 (default/linux/amd64/10.0, gcc-4.5.3, glibc-2.14.1-r3, 3.2.12-gentoo x86_64) = System uname: Linux-3.2.12-gentoo-x86_64-Intel-R-_Core-TM-_i5_CPU_750_@_2.67GHz-with-gentoo-2.1 Timestamp of tree: Fri, 25 May 2012 08:15:01 + app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r1, 3.2.3 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc:4.5.3-r2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool:2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 3.1 (virtual/os-headers) sys-libs/glibc: 2.14.1-r3 Repositories: gentoo ACCEPT_KEYWORDS=amd64 ACCEPT_LICENSE=* -@EULA dlj-1.1 sun-bcla-java-vm PUEL AdobeFlash-10.3 googleearth CBUILD=x86_64-pc-linux-gnu CFLAGS=-O2 -march=core2 -pipe CHOST=x86_64-pc-linux-gnu CONFIG_PROTECT=/etc /usr/share/config /usr/share/gnupg/qualified.txt CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/init.d /etc/pam.d /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo CXXFLAGS=-O2 -march=core2 -pipe DISTDIR=/usr/portage/distfiles EMERGE_DEFAULT_OPTS=--with-bdeps=y --autounmask=n --nospinner --keep-going --load-average=8 FEATURES=assume-digests binpkg-logs buildpkg buildsyspkg distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox FFLAGS= GENTOO_MIRRORS=http://distfiles.gentoo.org; LANG=en_GB.UTF-8 LDFLAGS=-Wl,-O1 -Wl,--as-needed LINGUAS=en_GB en MAKEOPTS=-j8 -l8 PKGDIR=/usr/portage/packages PORTAGE_COMPRESS= PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages PORTAGE_TMPDIR=/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY= SYNC=rsync://serv.prhnet/gentoo-portage USE=X acl acpi alsa amd64 bash-completion bzip2 cli cracklib crypt cups cxx dbus dri dts dvd exif ffmpeg flac fxsr gdbm gpm iconv ipv6 jpeg jpeg2k kde mad mmx mng modules mp3 mp4 mudflap multilib ncurses nls nptl opengl openmp pae pam pcre pdf png policykit pppd pulseaudio readline sdl semantic-desktop session smp sse sse2 ssl ssse3 svg symlink tcpd theora tidy tiff truetype udev unicode vorbis wmf xorg zlib ALSA_CARDS=hda-intel ALSA_PCM_PLUGINS=adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol APACHE2_MODULES=actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias APACHE2_MPMS=prefork CALLIGRA_FEATURES=kexi words flow plan sheets stage tables krita karbon braindump CAMERAS=fuji COLLECTD_PLUGINS=df interface irq load memory rrdtool swap syslog ELIBC=glibc GPSD_PROTOCOLS=ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx INPUT_DEVICES=evdev KERNEL=linux LCD_DEVICES=bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text LIBREOFFICE_EXTENSIONS=presenter-console presenter-minimizer LINGUAS=en_GB en PHP_TARGETS=php5-3 PYTHON_TARGETS=python3_2 python2_7 RUBY_TARGETS=ruby18 USERLAND=GNU VIDEO_CARDS=nouveau XTABLES_ADDONS=quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account Unset:
Re: [gentoo-user] udevd boot messages
On 05/26/2012 10:34 AM, Peter Humphrey wrote: On Saturday 26 May 2012 09:36:50 pk wrote: On 2012-05-26 01:52, Peter Humphrey wrote: $ elogviewer --help File /usr/local/bin/elogviewer, line 11 ^ SyntaxError: invalid syntax Huh? Mine (latest stable 0.5.2-r2, official Gentoo portage - not some overlay) is installed in /usr/bin/... So is mine (same version), so I don't know why it's looking in /usr/local/bin. I have no alias mentioning elogviewer. $ find /usr -name elogviewer 2 /dev/null /usr/portage/app-portage/elogviewer /usr/bin/elogviewer $ $ grep /local/ /usr/bin/elogviewer $ Have you changed the install path or installed it through some other means? Nope. Unless I did something odd in 2007, I suppose. I don't like mysteries :-( Portage *never* installs anything in /usr/local. My best bet is that you have been experimenting back in 2007 and probably copied the original file in /usr/local. Remove it and then emerge elogviewer again ;) -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-user] Re: make of gentoo-sources-3.2.12 fails
on 2012-05-14 at 08:52 ny6...@gmail.com wrote: 9. DO NOT TOP-POST and DO trim your replies!!! why don't you observe these yourself? you quoted the whole message you replied to, which itself contained another full quote, which itself... many people here complain against top-posting, but few observe the DO trim your replies rule. see below, from your own post: Posting a me too comment at the bottom of a 100+ line message is no better because people, have to scroll all the way down through 100+ lines they've already read in order to see your one-liner. One word comes to mind for that: frustrating.
[gentoo-user] {OT} hire a programmer or company?
I'm debating whether I should hire an expert programmer for $X/hour, or a company of expert programmers for $2X/hour. It makes sense from a financial perspective to hire programmers directly, but I wonder if there are benefits to hiring a really good company. I'm sorry this is OT, but I bet you guys have some seriously good insight on this. Thanks, Grant
Re: [gentoo-user] Re: make of gentoo-sources-3.2.12 fails
on 2012-05-14 at 22:54 Alan McKinnon wrote: (getting old...) you don't say, really? what a coincidence, it's happening to me too. anyone else getting older around here? is anyone actually getting *younger*?
Re: [gentoo-user] {OT} hire a programmer or company?
Am 26.05.2012 13:26, schrieb Grant: I'm debating whether I should hire an expert programmer for $X/hour, or a company of expert programmers for $2X/hour. It makes sense from a financial perspective to hire programmers directly, but I wonder if there are benefits to hiring a really good company. I'm sorry this is OT, but I bet you guys have some seriously good insight on this. Thanks, Grant For starters, you could give us a bit more insight into the kind of project we are talking about. What's the expected development effort, what are the services you pay for (binaries, source code, testing, maintenance, ...)? Regarding programmer vs. company, I'd say it depends on what you expect and pay for. If you just want it coded, then the lone programmer is probably as good as the company (since programming itself doesn't really scale well with the number of devs). Extensive testing, on the other hand, is something a team should do. Sure, the lone programmer can write you some unit tests and conduct a system test, but testing itself is a profession of its own and should be done by a second person with the relevant training. But in the end, these issues a minor. It really boils down to whom you trust more. Ask for references, look at their previous work, talk to them, etc. All things being equal, paying 1*x instead of 2*x gives you the chance to pay another 1*x to a second developer if things don't work out with the first one. ;-) Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] udevd boot messages
On Saturday 26 May 2012 10:37:38 Markos Chandras wrote: Portage *never* installs anything in /usr/local. Indeed so. My best bet is that you have been experimenting back in 2007 and probably copied the original file in /usr/local. Remove it and then emerge elogviewer again ;) As I said before, I've already done that - twice or three times now. I get the same result. Something is apparently causing bash to seek the file in /usr/local/bin/ instead of in /usr/bin/ . [OT] I have a more pressing problem now - someone has hacked into a supposedly protected part of my website, so I must find what's failed and fix it, or else find another package. No sleep for the wicked... [/OT] -- Rgds Peter
Re: [gentoo-user] Re: make of gentoo-sources-3.2.12 fails
On Sat, May 26, 2012 at 08:18:32AM -0300, luis jure wrote: on 2012-05-14 at 08:52 ny6...@gmail.com wrote: 9. DO NOT TOP-POST and DO trim your replies!!! why don't you observe these yourself? you quoted the whole message you replied to, which itself contained another full quote, which itself... many people here complain against top-posting, but few observe the DO trim your replies rule. see below, from your own post: Posting a me too comment at the bottom of a 100+ line message is no better because people, have to scroll all the way down through 100+ lines they've already read in order to see your one-liner. One word comes to mind for that: frustrating. Thank you for the timely reminder. It _was_ an error on my part. Terry
[gentoo-user] How can I control size of /run (tmpfs)?
Hi, after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Jarry wrote: Hi, after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage So, between those two, I could run out of ram since I have 16Gbs. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On 26-May-12 22:01, Dale wrote: Jarry wrote: after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage So, between those two, I could run out of ram since I have 16Gbs. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol Dale I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Jarry wrote: On 26-May-12 22:01, Dale wrote: Jarry wrote: after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage So, between those two, I could run out of ram since I have 16Gbs. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol Dale I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... Jarry I had no idea it was doing this either until your post. I got the same questions as you do. Why is it there? Why so much is allocated to it? Where can we change the settings for this questionable feature? I'm hoping someone will come along and answer both our questions. I'm really hoping for a place we can change the settings. I don't mind it being there so much if it is useful. I would like to know its purpose tho. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, May 26, 2012 at 8:08 PM, Jarry mr.ja...@gmail.com wrote: On 26-May-12 22:01, Dale wrote: Jarry wrote: after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage So, between those two, I could run out of ram since I have 16Gbs. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol Dale I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... If /var/run is described in /etc/fstab, then you can use mount options to control the maximum size of the tmpfs. http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt -- :wq
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote: I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. It is, but that is the default maximum size, a tmpfs filesystem uses only as much memory as its contents require. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... It makes sure that /run is available and writeable early in the boot process, whereas /var/run may not be and / may be mounted ro. -- Neil Bothwick Of all the people I've met you're certainly one of them signature.asc Description: PGP signature
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, May 26, 2012 at 8:28 PM, Dale rdalek1...@gmail.com wrote: [snip] I had no idea it was doing this either until your post. I got the same questions as you do. Why is it there? tmpfs is frequently used in places where data doesn't need to persist across reboots. /var/run meets this description, because it usually contains files that have PID numbers for running daemons. (i.e. an init script spawns acpid, saves the PID of that instance into a file under /var/run, and consults that file on future runs to see if the daemon it's responsible for is running). It also appears to be where udev keeps its current understanding of the running host machine. Why so much is allocated to it? It's not, really. That's a *maximum* theoretical size, which is only reached if files are placed there. From here, I'm currently booted into the Gentoo LiveDVD (2012.1). /run is mounted tmpfs, and contains 668K of files. Where can we change the settings for this questionable feature? It's not so bad. Really. I'm hoping someone will come along and answer both our questions. I'm really hoping for a place we can change the settings. I don't mind it being there so much if it is useful. I would like to know its purpose tho. A pretty straightforward read: http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt Incidentally, with tmpfs, infrequently-used files may be swapped to disk, at which point tmpfs starts behaving like a non-persistent disk-based filesystem. i.e., it becomes useful for things you'd like cleaned up on reboot. -- :wq
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Dale writes: Jarry wrote: On 26-May-12 22:01, Dale wrote: Jarry wrote: after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Just try it :) I don't know if this would work, probably yes. But you can change it later with mount -o remount,size=128m /run Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage Now have a look at /dev/shm... So, between those two, I could run out of ram since I have 16Gbs. But only if you copy stuff to /run yourself, otherwise this will never happen. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol It doesn't need it, it's just the maximum sitze, which it will never reach. I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... In case of power failure or lockup, the contents are lost, and will not cause confusion on the next reboot when /run is still populated by stuff. Just an idea, I do not know if it would really matter. But it does no harm, so why not juest keep it like it is. I had no idea it was doing this either until your post. I got the same questions as you do. Why is it there? Why so much is allocated to it? Where can we change the settings for this questionable feature? I'm hoping someone will come along and answer both our questions. I'm really hoping for a place we can change the settings. I don't mind it being there so much if it is useful. I would like to know its purpose tho. I don't know the details, but I'd think it does not matter. There will nothing be put into /run that uses a lot of memory, so it will never actually use its default size of half of your RAM. Wonko
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Am 26.05.2012 22:28, schrieb Dale: Jarry wrote: On 26-May-12 22:01, Dale wrote: Jarry wrote: after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage So, between those two, I could run out of ram since I have 16Gbs. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol Dale I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... Jarry I had no idea it was doing this either until your post. I got the same questions as you do. Why is it there? Why so much is allocated to it? Where can we change the settings for this questionable feature? I'm hoping someone will come along and answer both our questions. I'm really hoping for a place we can change the settings. I don't mind it being there so much if it is useful. I would like to know its purpose tho. As Michael Mol already said, tmpfs for the run dir is not a bad thing, it, it does not eat all your ram :) I however have a different question: Why do we need a new /run when we already have /var/run. There's no mention of /run in the FHS either. I only see udev stuff under /run - So it's another crazy udev thing? :)
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, May 26, 2012 at 9:02 PM, Michael Hampicke gentoo-u...@hadt.biz wrote: [snip] As Michael Mol already said, tmpfs for the run dir is not a bad thing, it, it does not eat all your ram :) I however have a different question: Why do we need a new /run when we already have /var/run. There's no mention of /run in the FHS either. I only see udev stuff under /run - So it's another crazy udev thing? :) Neil had the best response to that, IMO: It makes sure that /run is available and writeable early in the boot process, whereas /var/run may not be and / may be mounted ro. -- :wq
[gentoo-user] Re: How can I control size of /run (tmpfs)?
On 26/05/12 22:46, Jarry wrote: Hi, after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Id doesn't make any sense to change the default: a) tmpfs doesn't use RAM if there are no files in it b) If you make /run smaller and then it fills up, you're fucked So with a basic application of logic, there is no reason to change it.
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Neil Bothwick wrote: On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote: I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. It is, but that is the default maximum size, a tmpfs filesystem uses only as much memory as its contents require. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... It makes sure that /run is available and writeable early in the boot process, whereas /var/run may not be and / may be mounted ro. Mine wouldn't be since I have /var on a separate partition. I guess the devs are getting ready for the ultimate screwup udev and friends is putting in place. Oh well. This is life. I just hope it never goes bonkers and tries to use half my ram. lol If it did that while compiling LOo, that could be interesting. :/ Thanks for the info from all the replies. . Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, 26 May 2012 17:17:54 -0500, Dale wrote: It makes sure that /run is available and writeable early in the boot process, whereas /var/run may not be and / may be mounted ro. Mine wouldn't be since I have /var on a separate partition. I guess the devs are getting ready for the ultimate screwup udev and friends is putting in place. No, it's avoiding a screwup. If you have /var on a separate partition, as I do, and something early in the boot process writes to /var/run (or /var/lock) whatever is written disappears when the var filesystem is mounted on /var. Using a tmpfs in / prevent this. The alternative is to require /var is on the same filesystem as / or mounted from an initramfs. ISTR you were rather against such a move. This move makes perfect sense, volatile but essential data is kept in ram rather than on a filesystem that may not always be available. If you are really bothered about the maximum size, remount it, although an option to specify this in rc.conf may possibly be useful in some situations. -- Neil Bothwick (A)bort, (R)etry, (P)retend this never happened... signature.asc Description: PGP signature
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, May 26, 2012 at 10:17 PM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote: I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. It is, but that is the default maximum size, a tmpfs filesystem uses only as much memory as its contents require. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... It makes sure that /run is available and writeable early in the boot process, whereas /var/run may not be and / may be mounted ro. Mine wouldn't be since I have /var on a separate partition. I guess the devs are getting ready for the ultimate screwup udev and friends is putting in place. Oh well. This is life. TBH, there are other occasions for / to be read-only. LiveCDs, for example, where your entire filesystem is (at least initially) R/O. A read-only network filesystem (or disk image) mount in thin clients. That kind of thing. I just hope it never goes bonkers and tries to use half my ram. lol If it did that while compiling LOo, that could be interesting. :/ tmpfs specifically allows pages in it to be swapped out to disk, so if you have a large amount of swap, you shouldn't have a problem. FWIW, I try to avoid swap on my servers, but I try to keep my desktop and dual-role boxes with at least 1xRAM in SWAP, just in case I someday decide to experiment with suspend-to-disk. I rarely (if ever) touch it, but it's there if I need it. -- :wq
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Neil Bothwick wrote: On Sat, 26 May 2012 17:17:54 -0500, Dale wrote: It makes sure that /run is available and writeable early in the boot process, whereas /var/run may not be and / may be mounted ro. Mine wouldn't be since I have /var on a separate partition. I guess the devs are getting ready for the ultimate screwup udev and friends is putting in place. No, it's avoiding a screwup. If you have /var on a separate partition, as I do, and something early in the boot process writes to /var/run (or /var/lock) whatever is written disappears when the var filesystem is mounted on /var. Using a tmpfs in / prevent this. The alternative is to require /var is on the same filesystem as / or mounted from an initramfs. ISTR you were rather against such a move. This move makes perfect sense, volatile but essential data is kept in ram rather than on a filesystem that may not always be available. If you are really bothered about the maximum size, remount it, although an option to specify this in rc.conf may possibly be useful in some situations. I was talking about the /usr and/or /var being needed and the init thingy. I was not talking about /run using tmpfs or even being used. In other words, the /usr and/or /var being needed very early in the boot process is the screwup, not /run being used and on tmpfs. It appears that /run is sort of a temp thing while booting and just sort of sticks around after getting booted, since it is there anyway. Why not use it? Sort of hard to explain my thinking sometimes. lol I have those days, quite often I'm afraid. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, 26 May 2012 18:17:38 -0500 Dale rdalek1...@gmail.com wrote: It appears that /run is sort of a temp thing while booting and just sort of sticks around after getting booted, since it is there anyway. Why not use it? No, that is incorrect. /run is a deliberate design decision (and a damn good one that should always have been there IMHO) and it sticks around because it is supposed to. It's not an after-effect that just happens to be useful, it's the entire objective. Think of it in the same way you think of /dev, /proc and /sys: There are there, there are guaranteed to be there with certain behaviours, and you can't change that (neither should you want to). -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sat, 26 May 2012 23:02:13 +0200 Michael Hampicke gentoo-u...@hadt.biz wrote: Am 26.05.2012 22:28, schrieb Dale: Jarry wrote: On 26-May-12 22:01, Dale wrote: Jarry wrote: after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted as tmpfs. But I can not find any mount-option for controlling how much memory is (or could be) used for it. Filesystem 1K-blocksUsed Available Use% Mounted on tmpfs8223848 224 8223624 1% /run I know it does not use 8GB right now, yet I'd like to reduce it to some lower value, not half of my physical memory. How can I do it? Can I simply add line in fstab like: none /run tmpfs size=128m 0 0 ??? Jarry Holy smoke ! Mine is doing the same thing. tmpfs 7.9G 260K 7.9G 1% /run But I also have this: tmpfs 7.9G 0 7.9G 0% /var/tmp/portage So, between those two, I could run out of ram since I have 16Gbs. There is now TWO people that needs a answer to this question. Why does it need that much anyway? It looks to me like a few hundred Mbs, like Jarry posted, would be plenty. Jeepers creepers. lol Dale I suppose default size for tmpfs is half of physical memory, if it is not configured somewhere else. BTW, is there any way to turn this great feature off? What is it good for? I do not see any advantage in having /run on tmpfs... Jarry I had no idea it was doing this either until your post. I got the same questions as you do. Why is it there? Why so much is allocated to it? Where can we change the settings for this questionable feature? I'm hoping someone will come along and answer both our questions. I'm really hoping for a place we can change the settings. I don't mind it being there so much if it is useful. I would like to know its purpose tho. As Michael Mol already said, tmpfs for the run dir is not a bad thing, it, it does not eat all your ram :) I however have a different question: Why do we need a new /run when we already have /var/run. There's no mention of /run in the FHS either. I only see udev stuff under /run - So it's another crazy udev thing? :) /var can fail to mount, then you have no /var/run. FHS isn't much as standards go. It's a bunch of good ideas (some less so than others but it has always been just good (unenforceable) ideas. As to why only udev stuff is in /run, that's because udev is the only thing you have that's using it (currently). That might change, but it's up to individual package authors. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Alan McKinnon wrote: On Sat, 26 May 2012 18:17:38 -0500 Dale rdalek1...@gmail.com wrote: It appears that /run is sort of a temp thing while booting and just sort of sticks around after getting booted, since it is there anyway. Why not use it? No, that is incorrect. /run is a deliberate design decision (and a damn good one that should always have been there IMHO) and it sticks around because it is supposed to. It's not an after-effect that just happens to be useful, it's the entire objective. Think of it in the same way you think of /dev, /proc and /sys: There are there, there are guaranteed to be there with certain behaviours, and you can't change that (neither should you want to). What I was saying tho, since it appears to be needed now, since /var may not be mounted yet, it was created and is used during booting up. Since it is there, why not use it, even AFTER the system is booted. After all, the files are already there since they were put there during boot up. No need moving them and all that when they are already created and available. Plus, as someone said, I think it was you in another reply, what if /var fails to mount at all? At that point, it still works since /run is there already. Since /run is on tmpfs, if it fails to mount for some reason, you got issues already. ;-) I don't mind it being there, I just hope udev, or whatever else may use it later on, doesn't get memory hungry. Actually, maybe some other small directories could be placed there as well. The lock files would be a good one to start with. Just thinking. May want to duck tho. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On May 27, 2012 7:19 AM, Dale rdalek1...@gmail.com wrote: Alan McKinnon wrote: On Sat, 26 May 2012 18:17:38 -0500 Dale rdalek1...@gmail.com wrote: It appears that /run is sort of a temp thing while booting and just sort of sticks around after getting booted, since it is there anyway. Why not use it? No, that is incorrect. /run is a deliberate design decision (and a damn good one that should always have been there IMHO) and it sticks around because it is supposed to. It's not an after-effect that just happens to be useful, it's the entire objective. Think of it in the same way you think of /dev, /proc and /sys: There are there, there are guaranteed to be there with certain behaviours, and you can't change that (neither should you want to). What I was saying tho, since it appears to be needed now, since /var may not be mounted yet, it was created and is used during booting up. Since it is there, why not use it, even AFTER the system is booted. After all, the files are already there since they were put there during boot up. No need moving them and all that when they are already created and available. Plus, as someone said, I think it was you in another reply, what if /var fails to mount at all? At that point, it still works since /run is there already. Since /run is on tmpfs, if it fails to mount for some reason, you got issues already. ;-) I don't mind it being there, I just hope udev, or whatever else may use it later on, doesn't get memory hungry. Actually, maybe some other small directories could be placed there as well. The lock files would be a good one to start with. Just thinking. May want to duck tho. lol You mean /var/lock ? Hasn't it transmogrified to /run/lock now? Rgds,
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Pandu Poluan wrote: On May 27, 2012 7:19 AM, Dale rdalek1...@gmail.com What I was saying tho, since it appears to be needed now, since /var may not be mounted yet, it was created and is used during booting up. Since it is there, why not use it, even AFTER the system is booted. After all, the files are already there since they were put there during boot up. No need moving them and all that when they are already created and available. Plus, as someone said, I think it was you in another reply, what if /var fails to mount at all? At that point, it still works since /run is there already. Since /run is on tmpfs, if it fails to mount for some reason, you got issues already. ;-) I don't mind it being there, I just hope udev, or whatever else may use it later on, doesn't get memory hungry. Actually, maybe some other small directories could be placed there as well. The lock files would be a good one to start with. Just thinking. May want to duck tho. lol You mean /var/lock ? Hasn't it transmogrified to /run/lock now? Rgds, Well, the /run/lock directory is there but there is nothing in it on mine. It does look to me like they would move the files from /var/lock, or any other lock files, there tho. They appear to be small here since it takes up so little space. root@fireball / # du -shc /var/lock/ 32K /var/lock/ 32K total root@fireball / # That would total up to be less than 300K for what is there and /var/lock on my machine. I dunno. Just makes sense to me. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sun, May 27, 2012 at 3:06 AM, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: On May 27, 2012 7:19 AM, Dale rdalek1...@gmail.com What I was saying tho, since it appears to be needed now, since /var may not be mounted yet, it was created and is used during booting up. Since it is there, why not use it, even AFTER the system is booted. After all, the files are already there since they were put there during boot up. No need moving them and all that when they are already created and available. Plus, as someone said, I think it was you in another reply, what if /var fails to mount at all? At that point, it still works since /run is there already. Since /run is on tmpfs, if it fails to mount for some reason, you got issues already. ;-) I don't mind it being there, I just hope udev, or whatever else may use it later on, doesn't get memory hungry. Actually, maybe some other small directories could be placed there as well. The lock files would be a good one to start with. Just thinking. May want to duck tho. lol You mean /var/lock ? Hasn't it transmogrified to /run/lock now? Rgds, Well, the /run/lock directory is there but there is nothing in it on mine. It does look to me like they would move the files from /var/lock, or any other lock files, there tho. They appear to be small here since it takes up so little space. root@fireball / # du -shc /var/lock/ 32K /var/lock/ 32K total root@fireball / # That would total up to be less than 300K for what is there and /var/lock on my machine. I dunno. Just makes sense to me. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n Well, given that it's there, it cleans up after itself, and it avoids issues in the instance where /var isn't available early on, is there much reason _not_ to link /var/run and /var/lock over to their respective equivalents on /run? And both with and without /var mounted (so they exist and are writable even if /var doesn't come up)? If I recall its purpose properly, /var exists to hold data that _needs_ to be writable in an actively running system, logs, lock files, caches, etc.. but as tmpfs didn't exist back when it was thought up, no separation was explicitly defined between persistent and non-persistent data. With /run around now, there's an explicitly defined lack of persistence that would suit /var/run and /var/lock rather well, since stale service pids, lock files, and the like can wreak havoc on an unplanned restart (which tends to be bad enough with the prospect of, say, a failed UPS as it is). Also, any inconsistencies in the above rambling curiosity (as well as the rambling itself, I should note) are the result of having been awake far too early for a Saturday, and still being awake for the start of Sunday, so apologies may be required on my part. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] How can I control size of /run (tmpfs)?
Joshua Murphy wrote: Well, given that it's there, it cleans up after itself, and it avoids issues in the instance where /var isn't available early on, is there much reason _not_ to link /var/run and /var/lock over to their respective equivalents on /run? And both with and without /var mounted (so they exist and are writable even if /var doesn't come up)? If I recall its purpose properly, /var exists to hold data that _needs_ to be writable in an actively running system, logs, lock files, caches, etc.. but as tmpfs didn't exist back when it was thought up, no separation was explicitly defined between persistent and non-persistent data. With /run around now, there's an explicitly defined lack of persistence that would suit /var/run and /var/lock rather well, since stale service pids, lock files, and the like can wreak havoc on an unplanned restart (which tends to be bad enough with the prospect of, say, a failed UPS as it is). Also, any inconsistencies in the above rambling curiosity (as well as the rambling itself, I should note) are the result of having been awake far too early for a Saturday, and still being awake for the start of Sunday, so apologies may be required on my part. Well, I don't see why not. As you say, lack of a proper clean up after a bad shutdown can cause problems. Anything in /run would disappear after a shutdown, clean or not, since it is in tmpfs. It doesn't seem to use much ram either. I really don't know of a reason why it couldn't be set that way. I'm not the sharpest tool in the shed tho. lol As for one of us setting it to do that manually, I guess one could do that. If I recall correctly, /var/lock is *supposed* to be cleaned up when booting but that was a good long while ago. This may be something the devs are already getting ready for. I get the feeling that they are taking what I call baby steps. I noticed a upgrade to baselayout and I think OpenRC as well not long ago. I'm not sure what decided to put stuff in /run. I would think it would be one of those but it could be some other package. I guess udev could be one that could have made it as well. It does have a directory in there that has stuff in it. The rest are empty. I'd wait for a serious guru to reply before changing anything tho, just to be safe. ;-) You think being up late at night is bad. You should see me when my meds are making me goofy. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] How can I control size of /run (tmpfs)?
On Sun, May 27, 2012 at 4:51 AM, Dale rdalek1...@gmail.com wrote: Joshua Murphy wrote: snip Well, I don't see why not. As you say, lack of a proper clean up after a bad shutdown can cause problems. Anything in /run would disappear after a shutdown, clean or not, since it is in tmpfs. It doesn't seem to use much ram either. I really don't know of a reason why it couldn't be set that way. I'm not the sharpest tool in the shed tho. lol As for one of us setting it to do that manually, I guess one could do that. If I recall correctly, /var/lock is *supposed* to be cleaned up when booting but that was a good long while ago. This may be something the devs are already getting ready for. I get the feeling that they are taking what I call baby steps. I noticed a upgrade to baselayout and I think OpenRC as well not long ago. I'm not sure what decided to put stuff in /run. I would think it would be one of those but it could be some other package. I guess udev could be one that could have made it as well. It does have a directory in there that has stuff in it. The rest are empty. I'd wait for a serious guru to reply before changing anything tho, just to be safe. ;-) You think being up late at night is bad. You should see me when my meds are making me goofy. lol Dale :-) :-) I would try it right now, but a) the only proper 'desktop' I have running is a windows box, the rest of my systems, netbook, laptops, and servers, are stripped down to the bare essentials and are likely to continue skipping along smoothly for a long while regardless of what I do to them, hardly a useful test for something that could potentially cause catastrophic breakage for more 'normal' systems, and b) if it *did* break, I would dread it as I went about trying to remember my exact steps to get there after I wake up tomorrow, especially with the fact that I'm aiming to head to the office when I wake, rather than toy around with fixing things here at home. Maybe tomorrow evening on a couple systems, if the idea itself doesn't bring about any don't do this, you'll break x responses between now and then (and, depending on the severity of the potential breakage, may still have to poke it with a stick). -- Poison [BLX] Joshua M. Murphy
