Description of problem: Running Mga3 with XFCE and all updates. Since the updates about Dec 17, when I stop xscreensaver and bring back my desktop, the executable for the hack continues in background, using 10-15% CPU. It won't respond to a kill command. I have to use "kill -9" At the moment, ps shows: doug 11273 10.4 1.6 80908 68496 ? RN 03:06 1:07 glslideshow -root Version-Release number of selected component (if applicable): 5.21-1. How reproducible: Every time the screensaver is stopped to bring the desktop back, whether after normal scredensaving or using startsaver to start it manually. Lock screen is off. Steps to Reproduce: As Above. 1. 2. 3. Reproducible: Steps to Reproduce:
After shutting down overnight, this bug appears to have vanished. I will watch it for a few days. Last night, at one point, there were two hacks running in the background.
a different topic. The yes command is giving yes: standard output: Broken pipe yes: write error but the command following is still executed. Probably should be a separate bug, but somebody in programming will no doubt come up against it.
In what context does the yes command give an error? Just running it in a terminal works fine. As for xscreensaver, if the problem does come back, it'd be interesting to know if 5.26 fixes it. You could try rebuilding it from the source RPM with 5.26 and installing an updated RPM. If it does fix an issue for you, we could backport it as an update. I'm going to close this as INVALID for now, but feel free to post any additional comments or reopen it if there's a reproducible issue.
Status: NEW => RESOLVEDCC: (none) => luigiwalserResolution: (none) => FIXED
Whoops, INVALID not FIXED.
Resolution: FIXED => INVALID
INVALID is fine by me. It hasn't come back. Both these problems arose after the latest round of updates. There is another post on alt.os.linux.mageia about a problem with kaffeine disappearing after a cold start. Just running yes in a terminal works fine for me too. I run bashpodder. I added a line to copy my playlist to a backup as follows: yes | cp 2012-10-20/podnew.m3u ./podnew.bak That now gives me the quoted error message. The command that follows, still runs to completion. Instances I found on the Web are identical in this regard, but are in foreign contexts: BSD, a specific program. Last night I saw it in the output of something else. It sounds like it's just me and a nuisance thing anyway.
Ahh, you get that output because cp stops reading from standard input after reading the first 'y' and then the yes process gets killed. Doesn't look like there's a way to tell yes how many iterations to run. I'd think it'd make more sense to just use cp -f, then you wouldn't need yes.
Thanks for the tip. That cured it.
The xscreensaver problem is back. I had to reinstall Cauldron again because I couldn't get beyond a "dropping to maintenance" prompt. Also back is Bug 11666, which vanished in the same way. I probably should be running the official release (or another distro.)
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
Sorry, this is using the 5.26 package David recommended. Should I rebuild it?
If you're using Cauldron, you shouldn't need to rebuild anything. What exactly is the issue now?
It is exactly as in the Description. There is no problem until a hack starts, either because the screensaver is activated, or because I select "Preview" in its config dialog. The hack should exit when the desktop comes back up, but it keeps running in the background. I run gkrellm, which shows Boinc as No.1 and the hack as No.2. It doesn't seem to depend on which hack is involved, but I have not been able to check whether it is only on OpenGL ones. I have looked at Bug 12230, which seems vaguely similar, but wasn't helpful.
I ran xscreensaver-demo, it asked to start xscreensaver since it wasn't running (I was in IceWM), I chose GLSlideShow, hit Preview, saw the screensaver, clicked to make it go away, then closed xscreensaver-demo. glslideshow did not persist in the process list. I cannot reproduce.
So it looks as though it is only me. It hasn't happened before the current Cauldron. I didn't mention that this time, I deleted ~/.xscreensaver and re-created it, but I expect that it is happening elsewhere. I am not sure that it ever really went away. It no longer seems to take up as much CPU as before. There is something strange about this and Bug 11666 appearing together and going away together. Perhaps a hardware problem? I have another user (boinc.) I will see what happens there. If that fixes it, I have a corrupted file somewhere.
Running it under boinc, the problem still occurs, but xscreensaver is as buggy as anything. It may have been that I was in KDE, but it sounds as though I need to delete everything and do a first-time install, including my $HOME directory.
Cauldron just became unusable for the 500th time. Aftert a reinstall, this problem seems to have gone away, but the GLX bug is back, so I can run only the "Themed" hack.
OK, I'll close this bug. If you're having video driver issues, please file a new bug.
Status: REOPENED => RESOLVEDResolution: (none) => INVALID
Fair enough David. I think that the gremlins have taken over. I want to stay away from Bugzilla as much as possible. After updating, I couldn't get a desktop. I installed Mga3 on another partition, changed the Cauldron runlevel to 3 then rebooted into Cauldron with rebootin. I finished up in a graphical desktop as normal, i.e. runlevel 5, back before Bug 12416 was fixed. A fix for the GLX came through about then. I must have got the runlevel targets confused. I have had enough of tearing my hair out over Cauldron.
I hope Mageia 4 works out better for you. Other than bugzilla, you may find other forms of support helpful too, such as the forums, the discuss mailing list, or IRC if you're so inclined. Good luck.
I have joined Bug 12108.