[gentoo-user] Fcron question
Hi, I want to start a script via fcron, which collects all EPG informations into an xml- and into a text-file. To do so, tzap needs to be run. This implies, that noone is using the dvb-t interface under /dev. This cannot quaranteed for all cases in the future. Can I instruct fcron to retry the execution of a script - say - 30 minutes after the time of the original scheduled start, if the script returns with an rc != 0 ? Thank you very much in advance for any help! Best regards mcc
Re: [gentoo-user] Fcron question
Am 17.10.2010 11:27, schrieb meino.cra...@gmx.de: Hi, I want to start a script via fcron, which collects all EPG informations into an xml- and into a text-file. To do so, tzap needs to be run. This implies, that noone is using the dvb-t interface under /dev. This cannot quaranteed for all cases in the future. Can I instruct fcron to retry the execution of a script - say - 30 minutes after the time of the original scheduled start, if the script returns with an rc != 0 ? Hmm, I don't think so. Its man-page doesn't show such an option. I think your best bet is to create a wrapper script which tests the existence and stats of some file for checking it. Then let fcron run that script every 30 minutes. The attached file should get you going. Hope this helps, Florian Philipp 12h.sh Description: Bourne shell script signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: X programs as root
On Mon, Oct 4, 2010 at 10:22 PM, Andrey Vul andrey@gmail.com wrote: sudoers(5): ... ## Run X applications through sudo Defaults env_keep += DISPLAY HOME ... sudo visudo; paste; done Except that in the heavily-commented version of the sudoers file that I have, the corresponding line does not include the DISPLAY variable, and it happens to work fine that way. Try just keeping HOME. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Fcron question
Florian Philipp li...@f_philipp.fastmail.net [10-10-17 13:52]: Am 17.10.2010 11:27, schrieb meino.cra...@gmx.de: Hi, I want to start a script via fcron, which collects all EPG informations into an xml- and into a text-file. To do so, tzap needs to be run. This implies, that noone is using the dvb-t interface under /dev. This cannot quaranteed for all cases in the future. Can I instruct fcron to retry the execution of a script - say - 30 minutes after the time of the original scheduled start, if the script returns with an rc != 0 ? Hmm, I don't think so. Its man-page doesn't show such an option. I think your best bet is to create a wrapper script which tests the existence and stats of some file for checking it. Then let fcron run that script every 30 minutes. The attached file should get you going. Hope this helps, Florian Philipp Hi FLorian, thank you for your support! :) I will check it. Have a nice sunday! mcc
[gentoo-user] Re: X programs as root
On 09/22/2010 09:48 PM, Andrey Vul wrote: When I launch X programs via sudo, I get the following: $sudo gui-admin No protocol specified gui-admin: cannot connect to X server :0 ( Assume gui-admin is an X program ) But (gk|kde)su(do)? works. This is somewhat confusing. I just discovered something. Keeping HOME is not really recommended, because the programs that run as root will then use your user's configuration files and sometimes will set 'root' as their owner. As you can imagine, this is not a good thing. It seems what X programs really need is the .Xauthority file of the current X session. All you have to do is add this line to your ~/.bashrc: export XAUTHORITY=$HOME/.Xauthority Then you don't have to configure sudoers to keep the HOME env var.
[gentoo-user] Re: X programs as root
On 10/17/2010 04:00 PM, Nikos Chantziaras wrote: On 09/22/2010 09:48 PM, Andrey Vul wrote: When I launch X programs via sudo, I get the following: $sudo gui-admin No protocol specified gui-admin: cannot connect to X server :0 ( Assume gui-admin is an X program ) But (gk|kde)su(do)? works. This is somewhat confusing. I just discovered something. Keeping HOME is not really recommended, because the programs that run as root will then use your user's configuration files and sometimes will set 'root' as their owner. As you can imagine, this is not a good thing. It seems what X programs really need is the .Xauthority file of the current X session. All you have to do is add this line to your ~/.bashrc: export XAUTHORITY=$HOME/.Xauthority Then you don't have to configure sudoers to keep the HOME env var. (I have the tendency to press the Send button too soon...) Setting XAUTHORITY in the user's .bashrc also means that you don't have to modify /etc/sudoers *in any way*, not even DISPLAY needs to be kept. Setting XAUTHORITY is *all* what is needed.
Re: [gentoo-user] Re: Trying to configure Radeon card
On Sat, 2010-10-16 at 14:28 -0400, Jeff Cranmer wrote: On Sat, 2010-10-16 at 14:51 +1100, Adam Carter wrote: I use an xorg.conf, and have the following; Section Files ModulePath /usr/lib64/xorg/modules ModulePath /usr/lib64/opengl/xorg-x11/extensions/ EndSection Your xorg cant find the dri and dri2 modules because its not looking in the second directory. Also, it might be worth trying the latest driver, so # echo x11-drivers/ati-drivers ~amd64 /etc/portage/package.keywords Then emerge ati-drivers again. If that doesnt help, send the X11 log again after you've made those changes. I made the changes above, and added the fbdev entry to VIDEO_CARDS from Nikos' e-mail. I also added fglrx to my /etc/modules.autoload.d/kernel-2.6 file. It's a bit overkill but next I did emerge -Dav system and emerge -Dav world before running emerge -NDuav system and emerge -NDuav world. I rebooted the machine, ran startx and it looks like success. I reinstalled xdm to the default runlevel, and I have a working graphics card. Thanks all for the advice. There are a couple of issues: (1) Even though the resolution is set to 1920 x 1080, it appears to be scaled so that it doesn't fill the entire screen. It is scaled to about 90% for some reason. (2) Compositing is not supported as it stands. I may need to switch that on in xorg.conf. Does anyone know how to fix the scaling issue or whether it is advisable should turn on compositing in xorg.conf? Jeff In case anyone is suffering the same problem. I fixed the display scaling issue. The ATI Catalyst control center in KDE allows you to change the scaling options. My display was set to about 7% underscaling in the display manager DTV1 menu, on the adjustments tab. All I needed to do was move the scaling slider all the way to the right, and the display scaled perfectly. Now, if only I could get compositing working :-/ Jeff
Re: [gentoo-user] Re: X programs as root
Apparently, though unproven, at 15:03 on Sunday 17 October 2010, Nikos Chantziaras did opine thusly: On 10/17/2010 04:00 PM, Nikos Chantziaras wrote: On 09/22/2010 09:48 PM, Andrey Vul wrote: When I launch X programs via sudo, I get the following: $sudo gui-admin No protocol specified gui-admin: cannot connect to X server :0 ( Assume gui-admin is an X program ) But (gk|kde)su(do)? works. This is somewhat confusing. I just discovered something. Keeping HOME is not really recommended, because the programs that run as root will then use your user's configuration files and sometimes will set 'root' as their owner. As you can imagine, this is not a good thing. It seems what X programs really need is the .Xauthority file of the current X session. All you have to do is add this line to your ~/.bashrc: export XAUTHORITY=$HOME/.Xauthority Then you don't have to configure sudoers to keep the HOME env var. (I have the tendency to press the Send button too soon...) Setting XAUTHORITY in the user's .bashrc also means that you don't have to modify /etc/sudoers *in any way*, not even DISPLAY needs to be kept. Setting XAUTHORITY is *all* what is needed. I owe you a beer :-) One little export and this annoying thingy has now gone away: $ sudo vi /etc/fstab Password: No protocol specified You have NO IDEA how long that has annoyed me and how long I've been searching for a solution. Make that two beers! -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: X programs as root
On Sun, Oct 17, 2010 at 8:37 AM, Alan McKinnon alan.mckin...@gmail.comwrote: Apparently, though unproven, at 15:03 on Sunday 17 October 2010, Nikos Chantziaras did opine thusly: On 10/17/2010 04:00 PM, Nikos Chantziaras wrote: On 09/22/2010 09:48 PM, Andrey Vul wrote: When I launch X programs via sudo, I get the following: $sudo gui-admin No protocol specified gui-admin: cannot connect to X server :0 ( Assume gui-admin is an X program ) But (gk|kde)su(do)? works. This is somewhat confusing. I just discovered something. Keeping HOME is not really recommended, because the programs that run as root will then use your user's configuration files and sometimes will set 'root' as their owner. As you can imagine, this is not a good thing. It seems what X programs really need is the .Xauthority file of the current X session. All you have to do is add this line to your ~/.bashrc: export XAUTHORITY=$HOME/.Xauthority Then you don't have to configure sudoers to keep the HOME env var. (I have the tendency to press the Send button too soon...) Setting XAUTHORITY in the user's .bashrc also means that you don't have to modify /etc/sudoers *in any way*, not even DISPLAY needs to be kept. Setting XAUTHORITY is *all* what is needed. I owe you a beer :-) One little export and this annoying thingy has now gone away: $ sudo vi /etc/fstab Password: No protocol specified You have NO IDEA how long that has annoyed me and how long I've been searching for a solution. Make that two beers! I'm a bit surprised, but this fix actually does work, even without any special arrangement to env_keep XAUTHORITY. But I still don't like it any better than my own solution echo -n .mybashrc: xhost +r...@localhost which I place in my .mybashrc, where I keep all of my .bashrc customizations. My way, it can remind me what's going on, and seems more direct. It also works if I su to root. As an old-timer on Unix, I often forget sudo. I don't like it much anyway because it won't get me into root if something goes wrong in bootup: with this in mind, I need a root PW anyway, until that bottleneck gets fixed. The above form is actually only used in a debugging mode I've defined, and is silent otherwise. ++ kevin -- Kevin O'Gorman, PhD
