Re: [arch-general] [wpa_actiond 1.4] slow disconnects
Am 04.03.2013 21:26, schrieb Leonid Isaev: Hi, With testing/wpa_actiond-1.4 I am having a minor problem when shutting down net-auto-wireless.service: 'systemctl stop net-auto-wireless.service' pauses for ~10sec before finally disconnecting. Of course, this also occurs on normal system poweroff (which is usually ~5sec). The wifi network is WPA enterprise (important entries in wpa_supplicant.conf: key_mgmt=WPA-EAP; eap=PEAP; phase1=peaplabel=0; phase2=auth=MSCHAPV2), and piece of daemon.log after the above delay has elapsed: I've seen this too, but I didn't determine yet that is was wpa_actiond's fault. There are several issues here: 1) I am unsure what exactly terminates wpa_actiond. 2) net-auto-wireless.service is Type=forking, but has no proper MainPID detected, so systemd doesn't know what exactly to kill. This change however seems to be related to Pali's changed, so I'm CC'ing him to see if he knows what this might be about. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Gotta be a stupid gnome-terminal problem
On Sat, 02 Mar 2013 19:47:22 -0700 Matthew Monaco dgbale...@0x01b.net wrote: Sorry, I don't have definitive answer. You can check ~/.xession-errors and $ journalctl -bp warning for clues. (If you use GDM .xsession-errors might have been moved recently. I only have a ~/.xsession, not .xsession-errors. journalctl -bp requires an argument for the p option; I didn't know what to give it, so I just said journalctl -b, searched for 'gnome-terminal', 'gnome', and 'terminal', and basically came up empty. I'm guessing *this*, the only result I found, is not relevant: Mar 02 08:30:20 graton2 gnome-session[330]: WARNING: Detected that screensaver has left the bus Mar 02 08:30:20 graton2 gnome-session[330]: CRITICAL: gsm_manager_set_phase: assertion `GSM_IS_MANAGER (manager)' failed Thanks anyway!
Re: [arch-general] Gotta be a stupid gnome-terminal problem
2013/3/3 David Benfell benf...@parts-unknown.org On Sat, 02 Mar 2013 19:47:22 -0700 Matthew Monaco dgbale...@0x01b.net wrote: Sorry, I don't have definitive answer. You can check ~/.xession-errors and $ journalctl -bp warning for clues. (If you use GDM .xsession-errors might have been moved recently. I only have a ~/.xsession, not .xsession-errors. journalctl -bp requires an argument for the p option; I didn't know what to give it, so I just said journalctl -b, searched for 'gnome-terminal', 'gnome', and 'terminal', and basically came up empty. I'm guessing *this*, the only result I found, is not relevant: The argument is warning: $ journalctl -bp warning Mar 02 08:30:20 graton2 gnome-session[330]: WARNING: Detected that screensaver has left the bus Mar 02 08:30:20 graton2 gnome-session[330]: CRITICAL: gsm_manager_set_phase: assertion `GSM_IS_MANAGER (manager)' failed Thanks anyway!
Re: [arch-general] Forced to run fsck manually on unattended system
Hi, On 6 March 2013 02:31, edd_smith edwardmbsm...@gmail.com wrote: I have noticed that over time the boxes are showing file system errors and getting stuck during the boot phase requiring manual intervention (Either press Control-D to continue - resulting in failure or log in to the start up shell using the root password and run fsck manually). I simply answer yes to every prompt from fsck and the errors are resolved, the box reboots and runs fine. It may *appear* fine, and technically it may be correct, but your data is more than likely not in the state that you're expecting. I need to be able to force an 'fsck -y' type command at every boot as visiting these boxes manually isn't an option. I have already moved the partitions to ext2 as this seemed to show a mild improvement and also set 0 1 flags in /etc/fstab but still I'm seeing the freezing on boot. You can do this by creating /forcefsck on each boot. A systemd service like this should do (untested): [Unit] Description=Create /forcefsck to force fsck on next reboot [Service] Type=oneshot ExecStart=touch /forcefsck First of all should I be re-partitioning my drives to something which can handle these kinds of sudden power outages or removing the swap space or something? If you want to avoid data loss at the cost of performance, don't do any disk write caching. If I recall correctly, you can do this with `hdparm -W 0'. Best, Chris
