Well done F18 devs

mps2006 · #1 11th December 2012, 01:35 PM

Just made a very smooth upgrade to F18 from F17 using yum --dstrosync. Very nice! Was the smoothest upgrade of fedora I have had since I started in FC5 days. Had to reinstall chrome and virtualbox, and a few texlive dependency things, but basically excellent. net install of 17 and then upgrade could be a fall back if anaconda doesn't work out in time...

One niggle: while overall gnome seems much smoother, there is now an appreciable delay in the notification bar appearing when you move the mouse to the bottom of the screen. Any idea how to shorten that?

Cheesr
M.

Dutchy · #2 11th December 2012, 02:07 PM

You can hit the Super-key + m combination to bring it up, that's about it afaik unfortunately.

secipolla · #3 11th December 2012, 04:12 PM

Upgrade went fine here too but for people using non-en_US keyboard/locale they might want to double check if everything migrated accordingly as the way these things are set changed.

***DBelton*** · #4 11th December 2012, 04:22 PM

Even considering some of the changes to system config files and several other major things, Fedora 18 has been a very smooth running OS here for me ever since pre-alpha.

Once you get past Anaconda, Fedora is a solid OS.

Edit:

There is one little bug (actually a pretty big one, but is encountered rarely here) where a normal user can totally lock up a complete system, and it's not specific to Fedora 18.

The problem is that a normal user can use up every bit of tmpfs and then the system starts doing really weird things since systemd uses tmpfs for quite a lot of things as well. I have really noticed it here because /tmp is now mounted as tmpfs by default in F18, and some media players still cache video to /tmp.

I had a case where gnome-mplayer crashed a couple of times and left the cache files in /tmp, and soon I wan't able to do much without getting strange errors.

If this ever happens, about all you can do is reboot the system. Deleting the offending files doesn't fix it.

***glennzo*** · #5 11th December 2012, 06:01 PM

18 has been pretty solid for me too. I'm running the last Beta offering. No major issues to date. Well, there was that one random self-reboot. The thing just up and rebooted all on it's own. Pulled the rug right out from under me, it did. Other than that all is well. I so pleased with it that Fedora 17 is quickly becoming a distant memory.

***DBelton*** · #6 11th December 2012, 06:13 PM

Wanna lock up your system, glennzo?

as a regular user you can just use a simple dd command and start getting some weird things happening.

dd if=/dev/zero of=/tmp/test.tmp

Let it run until it runs out of space... Now try mounting a filesystem, or anything that systemd requires tmpfs for, and you are going to have problems.

Don't do that unless you want to reboot to fix things, though. I have tried deleting the file created, and still had issues due to no tmpfs space left.

And yes, bug has been reported for a few years now, and I reported it again about 6 months ago.

nonamedotc · #7 11th December 2012, 06:21 PM

Yup! Fedora 18 has been really smooth ever since alpha for me. Even anaconda is far more stable now compared to what it was alpha-ish stages ..

Quote:

Originally Posted by DBelton

The problem is that a normal user can use up every bit of tmpfs and then the system starts doing really weird things since systemd uses tmpfs for quite a lot of things as well. I have really noticed it here because /tmp is now mounted as tmpfs by default in F18, and some media players still cache video to /tmp.

Please correct me if I am wrong -

This would be a problem only if /tmp is a separate partition that is not too big and runs out of space, right? If /tmp is not a separate partition, this wouldn't be a problem? For example, typically / would be ~50 GB and a significant portion of that would be free (say, 20 GB). This should not be a problem, right?

I am mainly asking because I remember reading in the tmpfs-tmp page on Fedoraproject wiki about large files being a potential problem and now DBelton has also mentioned this. But, I have not seen it (yet) and so I am confused (and happy

).

***DBelton*** · #8 11th December 2012, 06:39 PM

With Fedora 18, /tmp is now mounted tmpfs by default.

You can solve the problem with /tmp by mounting it as a regular filesystem in /etc/fstab, but the problem is still there because a normal user has write access to /run/user/<usernumber> which is also mounted tmpfs.

The bug I am referring to affects tmpfs since you can't put quotas on it. If you had /tmp as a regular filesystem, either mounted under / or a separate fielsystem, you could put a quota on it to prevent someone from eating up all of your disk space. But with tmpfs, you can't do that, and someone could take all of the tmpfs (which by default is sized as half of your system RAM), quite a few system processes (especially in systemd) need tmpfs to work right.

***glennzo*** · #9 11th December 2012, 07:38 PM

Quote:

Originally Posted by DBelton

Wanna lock up your system, glennzo?

Muhahaha!!! 21st century forkbomb!

nonamedotc · #10 11th December 2012, 07:51 PM

Quote:

Originally Posted by DBelton

[ ... ]

But with tmpfs, you can't do that, and someone could take all of the tmpfs (which by default is sized as half of your system RAM), quite a few system processes (especially in systemd) need tmpfs to work right.

That clears it up for me! Thanks for the explanation DBelton!

**AdamW** · #11 12th December 2012, 10:54 PM

In general, nothing should write anything of significant size to /tmp . You should file a bug against any app which is doing this - like gnome-mplayer, apparently. Large stuff should get written to /var/tmp .

**AdamW** · #12 12th December 2012, 10:55 PM

mps2006: the delay is in fact intentional - lots of people were complaining about triggering the notification bar unintentionally, apparently, and the delay is to guard against that.

You can always access the notification bar simply by accessing the overview - so not even super+M, just super will do it.

***DBelton*** · #13 12th December 2012, 11:33 PM

Linux filesystem hierarchy says nothing about /tmp not being for large files. The only thing it specifies is that there should not be files written to /tmp that are expected to be there over a reboot. And Gnome-mplayer cache files aren't expected to be there over a reboot, so it complies with the Linux filesystem heirarchy specifications. So, where's the bug? The application really doesn't have a bug.

Quote:

1.20. /tmp

This directory contains mostly files that are required temporarily. Many programs use this to create lock files and for temporary storage of data. Do not remove files from this directory unless you know exactly what you are doing! Many of these files are important for currently running programs and deleting them may result in a system crash. Usually it won't contain more than a few KB anyway. On most systems, this directory is cleared out at boot or at shutdown by the local system. The basis for this was historical precedent and common practice. However, it was not made a requirement because system administration is not within the scope of the FSSTND. For this reason people and programs must not assume that any files or directories in /tmp are preserved between invocations of the program. The reasoning behind this is for compliance with IEEE standard P1003.2 (POSIX, part 2).

But the bug really isn't about any application in particular. The big bug is the security/stability risk of the entire system

A normal user without any admin permissions can bring the entire system to it's knees in just a few seconds.

A normal user has write privledges to /tmp and /run/user/<user number> So a normal user could completey fill up tmpfs which systemd depends upon having for various tasks. So, effectively a normal user can shut down a mission critical server if it's running systemd.