The following configuration applies: In systemsettings I have : - a script that calls firefox and thunderbird, and starts 4 rsync commands - 4 text files that are opened with Kwrite When i do a fresh boot (logging in with kdm), about 50% of the times, the following occurs: firefox and thunderbird start, the rsync commands seem to run, but only the second text file (and always only that one) is shown. When that happens, I cannot close KDE otherwise than with Ctrl-Alt-Backspace. When I do that, and immediately login as the same user, then all autostart runs completely, and I can shutdown KDE in the normal ways. Reproducible: Sometimes the script in autostart: #! /bin/bash if [ "$DISPLAY" = ":0" ] then nohup firefox & nohup thunderbird & rsync -lvrup --exclude "tmp/" --exclude "videos/" --exclude "Pictures" --exclude ".wine" --exclude "HV/fotos" --exclude ".mozilla/firefox/pewhctu3.default/Cache" --exclude ".cache" /home/herman/ /backups/mach1/home/herman/ > /home/herman/tmp/back.txt 2>&1 rsync -lvrup /home/herman/HV/fotos /beelden/ > /home/herman/tmp/back2.txt 2>&1 rsync -lvrup /home/herman/Pictures /beelden/ > /home/herman/tmp/back3.txt 2>&1 rsync -lvrup --exclude "lost+found/" /video/* /video2/ > /home/herman/tmp/back4.txt 2>&1 clear fi
scripts arent't supposed to be run from the autostart dirs anyway, see http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html Also I'd say the blocking rsync commands prevent the login finishing, but again: scripts aren't supposed to be executed, that they're apparently not forked is a secondary issue. @Jeremy, I recall your review request. Do you know whether this is still an issue in KDE 5?
If scripts are not supposed to be run from autostart , could you then explain why, in Systemsettings - Startup and Shutdown - Autostart, there is an option to specify script files? And I find also https://docs.kde.org/stable/en/kde-workspace/kcontrol/autostart/
Bug, I guess? ~/.kde/env and ~/.kde/shutdown run scripts, the autostart dir is (by the fdo spec) /only/ supposed for desktop services. Please notice that I only saw this bug because you originally assigned it to kwin, I've no expertise in this context, but happen to know the fdo spec and recall that i once had a "runvariousscripts" desktop service in the autostart dir to run scripts after the session start.
Yes, the spec only says .desktop files should be used in that folder. That SystemSettings (or the kautostart kcm) exposes a way to add scripts in there is a problem.
*** This bug has been marked as a duplicate of bug 343513 ***
The documentation I referred to in Comment 2 is thus wrong as well????
On 5/5/2015 I made a .desktop file for my script and removed the script from Systemsettings, and I had no problems anymore till this morning. Exactly the same problem crops up: the script is only partly run and - more important - KDE cannot be closed by any of its own normal provisions, but using Ctr-Alt-Backspace. As far as bug 343513 is concerned, the posters doe not mention the fact that KDE cannot be closed, so to me it does not seem to be exactly the same issue.
> As far as bug 343513 is concerned, the posters doe not mention the fact that > KDE cannot be closed, so to me it does not seem to be exactly the same issue. Because you now describe a fundamentally different situation/problem than in your original report? > the script is only partly run That's not a KDE issue at all - you'll simply have a blocking call in there which never exits. (in 9999999 of 10000000 of cases where you think it's a bash bug, it's your bug) > KDE cannot be closed by any of its own normal provisions, but using > Ctr-Alt-Backspace. How long did you wait? I assume that at some point your script will be treated w/ a SIGKILL, but I also assume there'll be a fairly long timeout (no idea how much, but 5 minutes seem reasonable enough before pot. invalidating some data) *** This bug has been marked as a duplicate of bug 343513 ***
I have to rephrase and explain what is really there: in Sytemsettings I have first four calls on Kwrite to open (existing!) files, and then the script is called. At least if the sequence shown in Systemsetings is the sequence that is followed when executing. When things go wrong, the first, third and fourth call on Kwrite and not run , at least the Kwrite window does not appear. So, only the second file is shown; always only the second. And the script always completes. I can check that, nothing hangs. As far as how long I did wait: on two occasions I left the PC there for a bit more than two hours. Is that enough? Can I send you the files where the Systemsetings Starup are shown?
(In reply to Herman Viaene from comment #9) > in Sytemsettings I have first four calls on Kwrite to open (existing!) files How? Through desktop services? > at least the Kwrite window does not appear. Checked the process table? > As far as how long I did wait: on two occasions I left the PC there for a > bit more than two hours. Is that enough? Obviously. It sounds as if what happens is that KWrite instances start, but don't show up on your desktop. On shutdown, they'd inhibit the logout process to ask stuff (eg. like "file has changed on disk, what to do?" or something) but do still not appear. I'd assume they end up on other activities? If you can see the kwrite processes but have trouble managing your activities and/or finding them there, you may try https://github.com/luebking/KLItools/blob/master/activities run "activities rescue force"
Dolphin shows desktop type files in the Autostart folder. But as I remember, these must be the result of the migration kde3 - kde4 (and some tinkering) - I had this working before and after the migration, and the problem showed up some six months ago. Anyway, I decided not to trust this setup anymore, so I deleted these four items, made for them fresh application items, and used these to redefine the Startup options in Systemsettings yesterday. This morning a normal startup, all went well, so waiting for the next startups in the following days.
Alas, problem again. And the result is te same: the second file is displayed, not file1 or 3 ot 4, and the script which follows the file commands has been run. And KDE does not close. Following your suggestion, I closed the Kwrite window of the second file and then at the CLI: [herman@xxxxx ~]$ ps -aux | grep herman Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html herman 10096 0.0 0.0 35560 2196 ? Ss 21:47 0:00 /usr/lib/systemd/systemd --user herman 10097 0.0 0.0 65324 2636 ? S 21:47 0:00 (sd-pam) herman 10098 0.0 0.0 14576 1500 ? Ss 21:47 0:00 /bin/sh /usr/bin/startkde herman 10134 0.0 0.0 16664 664 ? Ss 21:47 0:00 gpg-agent --keep-display --daemon --write-env-file /home/herman/.gnupg/gpg-agent-info herman 10171 0.0 0.0 15952 640 ? S 21:47 0:00 /usr/bin/dbus-launch --exit-with-session --sh-syntax herman 10172 0.0 0.0 15652 1364 ? Ss 21:47 0:00 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session herman 10216 0.0 0.1 171660 11012 ? Ss 21:47 0:00 s2u --daemon=yes herman 10260 0.0 0.0 4116 84 ? S 21:47 0:00 /usr/lib64/kde4/libexec/start_kdeinit +kcminit_startup herman 10261 0.1 0.5 410184 43956 ? Ss 21:47 0:00 kdeinit4: kdeinit4 Running... herman 10264 0.3 0.5 1265148 45232 ? Sl 21:47 0:00 kdeinit4: kded4 [kdeinit] herman 10266 0.0 0.0 14152 1336 ? S 21:47 0:00 /usr/libexec/gam_server herman 10269 0.1 0.3 500024 30164 ? S 21:47 0:00 kdeinit4: kglobalaccel [kdeinit] herman 10279 0.1 0.2 913392 22452 ? Sl 21:47 0:00 /usr/bin/kactivitymanagerd herman 10293 0.0 0.0 4252 348 ? S 21:47 0:00 kwrapper4 ksmserver herman 10294 0.1 0.3 586656 31748 ? Sl 21:47 0:00 kdeinit4: ksmserver [kdeinit] herman 10302 0.5 0.7 631208 64760 ? S 21:47 0:01 kwin -session 101e11872171b4000142994619400000124860000_1432050830_838575 herman 10307 0.8 1.1 3117188 94996 ? Sl 21:47 0:02 kdeinit4: plasma-desktop [kdeinit] herman 10311 0.0 0.2 285204 18704 ? S 21:47 0:00 /usr/bin/kuiserver herman 10314 0.0 0.0 265396 4004 ? Sl 21:47 0:00 /usr/libexec/mission-control-5 herman 10333 0.4 0.6 761556 49092 ? Sl 21:47 0:01 kdeinit4: krunner [kdeinit] herman 10338 0.1 0.0 579792 6628 ? S<l 21:47 0:00 /usr/bin/pulseaudio --start --log-target=syslog herman 10340 0.1 0.4 737748 37464 ? Sl 21:47 0:00 kdeinit4: kmix [kdeinit] -session 101e11872171b400014299462030 herman 10350 0.0 0.0 80496 2544 ? S 21:47 0:00 /usr/libexec/pulse/gconf-helper herman 10352 0.0 0.0 44944 2644 ? S 21:47 0:00 /usr/libexec/gconfd-2 herman 11140 0.1 0.2 546204 23596 ? Sl 21:48 0:00 /usr/bin/knotify4 herman 11143 0.0 0.0 173600 6788 ? Ss 21:48 0:00 kdeinit4: kdeinit4 Runnin e herman 11145 0.0 0.1 203720 10532 ? S 21:48 0:00 kdeinit4: klauncher [kdei e herman 11591 0.0 0.0 118188 1984 ? S 21:48 0:00 /usr/lib64/kde4/libexec/kdesud herman 14519 1.8 0.3 439412 27956 ? Sl 21:50 0:00 kdeinit4: konsole [kdeini e herman 14521 0.1 0.0 18148 3236 pts/1 Ss 21:50 0:00 /bin/bash herman 15066 0.0 0.0 12044 1104 pts/1 R+ 21:51 0:00 ps -aux herman 15067 0.0 0.0 14268 960 pts/1 S+ 21:51 0:00 grep --color herman I cann't see any unusual process there, but you might know better
Changed the whole setup, so only desktop files are used in Autostart, but the problem keeps cropping up. What can I show to convince you that my setup is now according the rules??? What is my biggest frustration is, that once I have forced KDE to abort to kdm, and then login again, the problem NEVER appears anymore., NEVER.
(In reply to Herman Viaene from comment #13) > What is my biggest frustration is, that once I have forced KDE to abort to > kdm, and then login again, the problem NEVER appears anymore., NEVER. Does the rsync trigger some automount(s)?
(In reply to Thomas Lübking from comment #14) > (In reply to Herman Viaene from comment #13) > > What is my biggest frustration is, that once I have forced KDE to abort to > > kdm, and then login again, the problem NEVER appears anymore., NEVER. > Does the rsync trigger some automount(s)? No, all disks are mounted in fstab
You could try to --exclude ".kde" --exclude ".kde4", respectively delay that rsync (put it on the end, maybe sleep some seconds) I would assume that some concurrent file access causes this - but that's just poking around in the dark.
(In reply to Thomas Lübking from comment #16) > You could try to --exclude ".kde" --exclude ".kde4", respectively delay that > rsync (put it on the end, maybe sleep some seconds) > > I would assume that some concurrent file access causes this - but that's > just poking around in the dark. I'll exclude those completely for a while, just to make sure this could be the reason. Tx.
After 10 days, (10 cold boots), the problem crops up again. Is there any log that I coud check when the problem occurs?
~/.xsession-errors Next best guess would be to redirect nohup to /dev/null.
from the description, seems this is more likely a dup of bug #328571 , with similar title "autostart never finishes..."
Created attachment 93359 [details] xsession-errors when autostart failed
Created attachment 93360 [details] following KDE start is Autostart OK I exited the first failing KDE session by Ctrl-Alt-Backspace (there is no other way) and the subsequent login (same user) works OK
(In reply to Herman Viaene from comment #22) > I exited the first failing KDE session by Ctrl-Alt-Backspace (there is no > other way) If this happens the next time, please instead try qdbus org.kde.ksmserver /KSMServer logout 0 0 2 Might provide interesting input (dbus error; maybe just plasma-desktop is buggy, or whatever) Additionally: Using network-manager? Is the content of /etc/hostname "localhost"? Magic numbers to dbus method: --------------------------- First parameter: confirm Obey the user's confirmation setting: -1 Don't confirm, shutdown without asking: 0 Always confirm, ask even if the user turned it off: 1 Second parameter: type Select previous action or the default if it's the first time: -1 Only log out: 0 Log out and reboot the machine: 1 Log out and halt the machine: 2 Third parameter: mode Select previous mode or the default if it's the first time: -1 Schedule a shutdown (halt or reboot) for the time all active sessions have exited: 0 Shut down, if no sessions are active. Otherwise do nothing: 1 Force shutdown. Kill any possibly active sessions: 2 Pop up a dialog asking the user what to do if sessions are still active: 3
Copied "qdbus org.kde.ksmserver /KSMServer logout 0 0 2" to CLI, this returns just a blank line and does not logout. /etc/hostname contains a full name, not localhost. And I think I did not use Network manager to setup the ethernet connection (no WiFi involved on this PC).
I installed Mageia 5 three weeks ago (KDE 4.14.5) and I did not see the problem anymore for two weeks. Since then, it happens consistently every time I reboot the PC and use my own userid to login. The symptoms are also consistent: slower start of KDE, startup desktop file only executed very partially, and only way to leave KDE is via Ctrl-Alt-Backspace to kdm. Second login with same userid works then perfectly (quick start, startup desktop file executed completely, all KDE functions OK.
Did you see bug #328571 ? => put an *executable* script into ~/.kde/env/glib-sucks.sh -------- snip -------- #!/bin/sh export QT_NO_GLIB=1 -------- /snip --------
I have been running with this script since then (Comment 26), with at least one reboot every day, and the problem hasn't come back yet. I guess I 'd better leave this in place until a new version of glib comes around, and then try to run without the script? The script is in my home now, and thus it could exist there for ever.
The glibc event dispatcher is, frankly, broken by design. I don't think libc updates will ever fix it, but it's been "fixed" in newer kinit by avoiding this clumsy thing. It's also really only ever required when somehow dealing with gobjects in Qt applications, ie. notably when gstreamer comes to play - the default Qt event dispatcher is much more straight forward and deterministic. *** This bug has been marked as a duplicate of bug 328571 ***
I deleted the workaround of Comment 26, as it had a side effect: in Mageia5 it stopped drakconf (Mageia Control Center) from asking the root password. The only way I could run drakconf properly is then by calling "kdesu drakconf".
~/bin/drakconf #!/bin/sh unset QT_NO_GLIB /usr/bin/drakconf ---- though it's highly suspicious that a conf tool requires a certain event dispatcher.
Replaced menu item command by /home/herman/bin/drakconf as per comment 30, but that hangs as well, both from the menu as calling ./bin/drakconf (as user herman) at the CLI.
drakconf seems to be a perl program, so it shouldn't use any QApplication event dispatchers anyway. It might try to talk to another process (daemon) and that doesn't respond because of the missing glib dispatcher. As the actual bug seems to be in kdeinit, you could shadow /usr/bin/kdeinit* in the opposite way (ie. disable the glib event dispatcher only for those)