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
--