Darrell,
I have a note to commit 77aed4a4. I'm afraid that used grep is dangerous. For example, my colleague has a login name 's' (yes, only one letter). Such grep would return unwanted results. I propose a change roughly as follows. This will make it possible to omit some grep and also condition.
ps -u $USER -o pid= -o comm= | grep -w kdesktop_lock | awk '{print $1}' | xargs -r kill -9
The second note is that this killing can be dangerous. If the machine is configured for multi-user login (multi-seat, xdmcp), the user could have multiple active sessions. Alternatively, user could have running some applications remotely - dcopserver would be active for remote session.
On Mon February 24 2014 3:42:56 pm Slávek Banko wrote:
Darrell,
I have a note to commit 77aed4a4. I'm afraid that used grep is dangerous. For example, my colleague has a login name 's' (yes, only one letter). Such grep would return unwanted results. I propose a change roughly as follows. This will make it possible to omit some grep and also condition.
ps -u $USER -o pid= -o comm= | grep -w kdesktop_lock | awk '{print $1}' | xargs -r kill -9
The second note is that this killing can be dangerous. If the machine is configured for multi-user login (multi-seat, xdmcp), the user could have multiple active sessions. Alternatively, user could have running some applications remotely - dcopserver would be active for remote session.
I am open to whatever works best. I developed those snippets because I do a lot of testing for the project. During testing I do things that many people are unlikely to do, but that is exactly what testing includes.
For example, in my testing I routinely use Ctrl+Alt+Backspace. When I do that some Trinity processes are not terminated gracefully. The snippets I added are intended to ensure those abandoned processes do not impede the next startup of Trinity.
Yet even when I am using my main office system, sometimes Trinity breaks when logging out. As you know, we have been trying to resolve those problems for a very long time. We have yet to find the runaway process, memory leak, or race condition that causes this breakage. So even on a production box sometimes I resort to using Ctrl+Alt+Backspace. If this happens to me then I presume other users are affected too.
Similarly, at the end of starttde where I explicitly kill gamin, I have seen gamin hang a reboot or halt. Often when I logout of Trinity I then reboot or halt the system. Once in a while the system hangs until I open a console and kill gamin. I have that in my various system shutdown scripts but since Trinity uses gamin indirectly, there is no harm in killing a gamin process spawned by that user. Even with multiple logins by the same person, gamin just creates a new process. The kill command won't kill gamin processes owned by other users and I did not expect any problems.
That is the background of the new snippets. Please modify the snippets to make them more robust and reduce errors or conflicts.
By the way, my apologies for 6a571749. I should have caught that and would have done so this morning when I rebuilt tdebase with some test patches. Had I built tdebase yesterday I would have had my Homer Simpson moment sooner (Doh!).
On Monday 24 of February 2014 23:10:39 Darrell wrote:
On Mon February 24 2014 3:42:56 pm Slávek Banko wrote:
Darrell,
I have a note to commit 77aed4a4. I'm afraid that used grep is dangerous. For example, my colleague has a login name 's' (yes, only one letter). Such grep would return unwanted results. I propose a change roughly as follows. This will make it possible to omit some grep and also condition.
ps -u $USER -o pid= -o comm= | grep -w kdesktop_lock | awk '{print $1}' | xargs -r kill -9
The second note is that this killing can be dangerous. If the machine is configured for multi-user login (multi-seat, xdmcp), the user could have multiple active sessions. Alternatively, user could have running some applications remotely - dcopserver would be active for remote session.
I am open to whatever works best. I developed those snippets because I do a lot of testing for the project. During testing I do things that many people are unlikely to do, but that is exactly what testing includes.
For example, in my testing I routinely use Ctrl+Alt+Backspace. When I do that some Trinity processes are not terminated gracefully. The snippets I added are intended to ensure those abandoned processes do not impede the next startup of Trinity.
Yet even when I am using my main office system, sometimes Trinity breaks when logging out. As you know, we have been trying to resolve those problems for a very long time. We have yet to find the runaway process, memory leak, or race condition that causes this breakage. So even on a production box sometimes I resort to using Ctrl+Alt+Backspace. If this happens to me then I presume other users are affected too.
Similarly, at the end of starttde where I explicitly kill gamin, I have seen gamin hang a reboot or halt. Often when I logout of Trinity I then reboot or halt the system. Once in a while the system hangs until I open a console and kill gamin. I have that in my various system shutdown scripts but since Trinity uses gamin indirectly, there is no harm in killing a gamin process spawned by that user. Even with multiple logins by the same person, gamin just creates a new process. The kill command won't kill gamin processes owned by other users and I did not expect any problems.
That is the background of the new snippets. Please modify the snippets to make them more robust and reduce errors or conflicts.
By the way, my apologies for 6a571749. I should have caught that and would have done so this morning when I rebuilt tdebase with some test patches. Had I built tdebase yesterday I would have had my Homer Simpson moment sooner (Doh!).
I have no objections to killing gamin_server. However, killing kdesktop_lock for active session causes the user logs off - it's not very good. What is the effect of kills dcopserver for active applications I have not tested it.
Regarding commit 6a571749 / 44b8d19c, I rather surprised that this had an influence. I assumed that the updates is applied only on the earlier version of the configuration, and it will not affect the fresh configuration.
Slavek --
I have no objections to killing gamin_server. However, killing kdesktop_lock for active session causes the user logs off - it's not very good. What is the effect of kills dcopserver for active applications I have not tested it.
I am not following your thinking. The new snippet only ensures kdesktop_lock for $USER is not running. Nobody else is affected.
In the case of multiple logins by the same user, I will run some tests.
Regarding commit 6a571749 / 44b8d19c, I rather surprised that this had an influence. I assumed that the updates is applied only on the earlier version of the configuration, and it will not affect the fresh configuration.
This was strange to me too. The script was supposed to run only against existing profiles and not against new/fresh profiles. For many years going way back to KDE 3.5.0 I have been confused by this behavior. The script was always flawed and always conflicted with the defaults. Now I know why. Oh well, problem solved --- almost 10 years later.
-
Darrell -
Slávek Banko