- Arch-general - lists.archlinux.org

[arch-general] khugepaged hangs and filesystem unresponsive
by pants 28 Aug '12

28 Aug '12

Good evening, I just experienced a major problem with my system while listening to a music file in mpd from an xfs filesystem over a mdadm raid6. A kernel error was thrown, with the following error.log entry: output: /var/log/error.log > Aug 26 23:34:50 localhost kernel: [283781.061258] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:50 localhost kernel: [283781.062268] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:50 localhost kernel: [283781.063273] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:50 localhost kernel: [283781.064245] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:51 localhost kernel: [283782.058901] timeout: still 1 active urbs.. > Aug 26 23:38:48 localhost kernel: [284019.080666] INFO: task mpd:707 blocked for more than 120 seconds. > Aug 26 23:38:48 localhost kernel: [284019.080696] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071419] INFO: task khugepaged:32 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071451] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071589] INFO: task mpd:525 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071613] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071721] INFO: task mpd:707 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071744] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071943] INFO: task mplayer:28316 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071968] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062189] INFO: task khugepaged:32 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062220] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062358] INFO: task mpd:525 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062382] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062489] INFO: task mpd:702 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062512] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062688] INFO: task mpd:703 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062712] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062829] INFO: task mpd:704 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062852] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Attempts to access other files on the same filesystem after the incident caused the applications used to also go into interruptible sleep (see the mplayer processes that appear later in the log). I was forced to kill and unmount what I could, then force the system down. Afterwards, I could replicate the error by attempting to read the file in question at the same point Even if you have no solution, pointing me towards the relevant kernel mailing list would be very helpful. Thanks, pants.

2 2

[arch-general] systemd boot errors
by Arno Gaboury 28 Aug '12

28 Aug '12

Dear list, I am testing systemd. I have the following errors at boot: 1-failed to start packet filtering framework iptables is installed on my system 2-boot hangs on at: reached target graphical interface i do not use any login manager. runlevel 3 + startx 3-systemd can't write to journal. I have a message at boot: /var/log/journal/d564e939c66712bce792b0710000017f/fss file does not exist. I have in fact /var/log/journal/d564e939c66712bce792b0710000017f/system.journal. Thank you for any help.

3 2

[arch-general] [PSA] change to locale handling
by Tom Gundersen 28 Aug '12

28 Aug '12

Hi guys, We recently (in [testing]) refactored our locale handling. This should hopefully resolve some long-standing issues, so I though I'd bring it to everyone's attention. For some details see: <https://plus.google.com/114015603831160344127/posts/2zKCcnTWDpa>. Please report any issues/bugs/regressions on the bug tracker. Cheers, Tom

1 0

[arch-general] [signoff] syslinux-4.05-7
by Tobias Powalowski 28 Aug '12

28 Aug '12

Hi, we still miss a signoff for i686 anyone who wants to signoff? thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] Arch Linux and systemd
by Myra Nelson 28 Aug '12

28 Aug '12

There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate how I perceive this situation. Are We Removing What Defines Arch Linux? Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM It's not about a single file, ie rc.conf (well not completely), it's about the simplicity of the system. Controversy #2 – The demise of /etc/rc.conf While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included… But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux: “In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.” “Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.” My question becomes, are we trading the simplicity and ease of setting up a single individuals computer, not corporate or work machine, or a set of two or three home machines for the trappings of the corporate desktop? Are we trading learning the shell (bash or otherwise) and learning to write bug free shell scripts, for learning a set or arbitrary and possibly arcane rules, decided upon in a building somewhere in the world, by someone who knows how to use your computer better than you do? We've already seen the likes of those already seen with polkit and consolekit. Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination. As to the standardization mentioned, does not such standardization remove one's freedom? I'm not an RMS fan, so don't go there. However, I am old enough to remember when there was no choice for home computers, and a commercial by Apple for the first Mac using the idea of breaking out of 1984 and the dull boring corporate world. Now here we are moving the one OS that's stayed somewhat of a maverick into the stable, then out to pasture to graze with with the rest of the corporate world. At least IMHO. It's not about changing Arch, it's about becoming part of the corporate structure and playing nice with everyone else. You can read that line with the knowledge "Old hippies die hard. And I still don't trust the establishment as far a I can throw my house!" Interoperability is necessary in today's world, but I think it can be done with out sacrificing the heart and soul of Linux. When it comes to the move of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the system. I've never really cared for the mess of the LSB. IMHO systemd is for administrators who, unlike Judd Vinet, want to hide the system setup from the user with fancy gui's and not allow anyone but the sysadmin to make any changes. I laud the devs who are working on this project, but I ask you to consider "Is it better for Arch to lead one of the last bastion's of freedom when using Linux into lock step with the the PTB's, or would it be better to develop an alternative that keeps, not just Arch Linux, but Linux a viable alternative to OSX, Windows, any Unix/BSD environment, and the corporate world?" I know it's the simpler, and probably less stressfull solution, but is it the better solution? I firmly believe more discussions like this on the ml would be more productive than the brawls we've seen lately. It also might provide the dev's an opportunity to participate more instead of throwing their hands up in the air and saying never again. To me the mailing list has become reactive. Too many responses, I've been guilty of this, come from predetermined ideas which may or may not be rooted in fact. They may be rooted in the users experience which may have been affected by other circumstances such as the dependency hell being created by the tighter and tighter upstream integration by KDE and Gnome. This again signals the move towards a "corporate desktop environment". A wise unix guru, can't remember the name right now, said something to the effect "the system should be a set of well written programs loosely connected programs, each doing one thing and doing it well". Something many of today's programs don't accomplish. As I said on the arch-general mailing list. These are the battles that have spawned many a linux distro and there is always LFS, even though they moved to use udev inside systemd. Myra Nelson To those who I bcc'd this to; I would like to humbly appologize if I intruded on your personal space, but I wanted to make sure it would be read by you in your own private space without the need to filter through the BS that's likely to occur on the ml. -- Life's fun when your sick and psychotic!

26 54

[arch-general] simple trick to make dealing with python 2/3 scripts easier
by Ben Booth 28 Aug '12

28 Aug '12

Lots of python scripts still use #!/usr/bin/python instead of explicitly stating which version of python to use. Here's quick trick to make running various python version 2 or 3 scripts easier: remove the /usr/bin/python symlink and replace with this shell script: #!/usr/bin/env bash exec /usr/bin/"${PYTHON:-python3}" "$@" Now you can set the PYTHON environment variable to be either python2 or python3, depending on which version of python the script expects. Just don't set PYTHON=python, or you'll get a recursive loop! The only problem with this approach is that /usr/bin/python is owned by the python package, so if you upgrade the python package it might create problems. Any one know of some way to work around this problem?

8 15

Re: [arch-general] xf86-video-intel-2.20.5
by Tobias Jansson 27 Aug '12

27 Aug '12

Hello. I run the Asus Zenbook UX31E sporting a Intel HD 3000. For me the upgrade posed no issues. It won't help you fix your problems, but at least other users could try upgrading knowing that not all users have issues. Regards, Tobias

2 1

Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
by Geert Hendrickx 27 Aug '12

27 Aug '12

On Sun, Aug 26, 2012 at 17:15:39 -0400, Dave Reisner wrote: > Hi, > > I apologize for this being somewhat after-the-fact. It was discussed on > IRC, but that of course doesn't necessarily cater to a wide enough > audience. Some of you have probably already noticed that systemd 189 now > provides, conflicts, and replaces libsystemd and systemd-tools. This is > the next logical step since systemd will eventually be in base once we > have sufficient unit coverage. > > As an added bonus, maybe this will encourage people who haven't switched > over yet to do so. ;) A systemd upgrade question (not related to this particular update), do you generally need to reboot when systemd is upgraded? Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

2 1

[arch-general] Think twice before moving to systemd
by Felipe Contreras 26 Aug '12

26 Aug '12

Hi, I just became aware that Arch Linux plans to switch to systemd, and this worries me for several reasons. I tried systemd a while ago in a brand new machine with Arch Linux and the boot was *much slower*. After some exchanges with Lennart Poettering and other people in Google+[1], it became clear I was on my own. Eventually I found the culprit: Fedora uses CONFIG_HZ_1000, and Arch Linux uses CONFIG_HZ_300. It became clear to me that systemd was not ready for prime time, it wasn't thoroughly tested in a lot of machines, and if you have problems Lennart Poettering will blame you (PulseAudio sounds familiar?). systemd was the reason I stopped using Fedora in the first place; when they moved to it my machine stopped booting reliably. My configuration was non-standard (a single encrypted partition), so I guess they never tested that. Similarly, I expect many Arch Linux users to bite these corner-cases. Finally, it's much harder to debug. If you have a problem you will not be able to open a script and figure out what is happening, and perhaps modify it, and debug it. You would be greeted with an unmodified binary, and the source code would be along these lines: http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c I'm sure in due time systemd will be ready, and will have nice advantages, but I doubt that's the case right now. Has anybody looked into the CONFIG_HZ issue? I doubt that. I was expecting more from the Arch Linux community, something along the lines of Google's analysis to pick to mercurial[2], but so far I have only seen a couple of people saying +1 in the development mailing list, with barely any explanation at all. Such an important move (one that might make users' machines stop booting) should warrant at least an analysis of some sort, with clear advantages. Would it not? At the moment I am unconvinced; does systemd has any *real* advantage? I don't think so; the potential of breakage outweighs the "supposed" advantages, and I think a proper analysis would show that. Cheers. [1] https://plus.google.com/108736516888538655285/posts/BTG39o6YoGS [2] http://code.google.com/p/support/wiki/DVCSAnalysis -- Felipe Contreras

22 62

[arch-general] /etc/dbus-1/systemd/cups.conf and /usr/lib/systemd/system/cups.socket files
by Myra Nelson 26 Aug '12

26 Aug '12

After my research on sysvinit, the simple version, I'm working my way through systemd. Two things I noticed about the cups configuration: 1: The cups.conf file in /etc/dbus-1/systemd reads <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig>  <policy user="root"> <allow send_interface="com.redhat.PrinterSpooler"/> </policy>  <policy context="default"> <allow receive_interface="com.redhat.PrinterSpooler"/> </policy> </busconfig> Do the allow send and allow receive interfaces need to be changed, or is this taken into account by the rest of systemd? 2. The /usr/lib/systemd/system/cups.socket reads [Unit] Description=CUPS Printing Service Sockets [Socket] ListenStream=/var/run/cups/cups.sock ListenStream=631 ListenDatagram=0.0.0.0:631 BindIPv6Only=ipv6-only [Install] WantedBy=sockets.target What is the recommended best practice for dealing with this when you have no access to IPv6? Our satellite console supports IPv4 only so previously everything has been set up on 192.168.???.??. With the newer version of cups depending on avahi and the differences in the avahi hosts file and the hosts file, avahi uses gandalf.local while hosts still uses .localdomain. https://lwn.net/Articles/485617/ I'm not trying to be dense here, but some of this seems to be at cross purposes. That or this is something sysadmins on large systems do all the time and those of us with small installations haven't had to deal with yet. As with some of my other posts, trashing systemd etc and those behind it accomplishes nothing. If you can't say anything constructive, STFU. I apologize for offending anyone, but this would be easier with out all the BS, and I don't mean bikeshed. Myra -- Life's fun when your sick and psychotic!

2 3