On Fri, 16 Dec 2011 02:41:22 -0900
Greg Madden <gomadtroll@...> wrote:

> 
> 
> On Friday 16 December 2011 1:41 am David Hare wrote:
> > On 15/12/11 23:12, Greg Madden wrote:
> > > TDE 3.5.13 Debian Squeeze
> > >
> > > I was trying to run   'kcron' as root, from a root prompt in konsole.
> > > 'kcron' is not found, I have to use full path '/opt/trinity/bin/kcron'.
> > > This brings up kcron but trying to add a cron job causes a crash, the
> > > crash handler pops up.
> > >
> > > I get this info from the terminal:
> > >
> > > "In file /build/buildd/kdeadmin-trinity-3.5.13/./kcron/ktview.cpp, line
> > > 372: Out of memory
> > > KCrash: crashing... crashRecursionCounter = 2
> > > KCrash: Application Name = kcron path =<unknown>  pid = 4347
> > > kdeinit: Got EXEC_NEW 'drkonqi' from socket.
> > > Could not load library! Trying exec....
> > > kdeinit: PID 4413 terminated."
> > >
> > > I noticed that using the 'export' command, there is no reference to
> > > KDEDIR(S) or PATH to the Trinity stuff.
> > >
> > >   I installed the metapackage  'kdebase-trinity', 'kdepim-trinity' and a
> > > few apps, not the full DE.
> > >
> > > It seems like kcron can't find a library.  what sets up the TDE
> > > environment for root ?
> >
> > You should probably be using <kdesu kcron> Kdesu is the wrapper to
> > transfer X credentials. Bug 394 is marked fixed (but see 703) and kdesu
> > mostly works here.
> >
> > I too use a selective TDE install on Squeeze and don't use sudo
> >
> > I can use kcron that way here. It will however crash like you say if I
> > don't first highlight the "tasks" box for the user I want to set a new
> > task for (usually root)
> >
> > If I do highlight the "tasks" box it works and the task shows up in
> > /var/spool/cron/crontabs/root
> >
> > Let us know, if that works for you.
> 
> Thanks, kdesu works, cool :-)
> 
> Previous installs (TDE 3.5.12), it seems, root could run a command from the cli, 
> ie the environment must? have been setup pointing to the TDE stuff. Anyway kdesu 
> works fine my my purposes, probably a better method, I don't have to use xhost to 
> allow root access to the display.

If you still want to get the cli working, check root's PATH and LD_LIBRARY_PATH 
using set.  The former needs to include "/opt/trinity/bin" for the application to be found
without the full path, and the latter needs to include "/opt/trinity/lib" for it to find its 
libraries.

(Been there, done that . . . except the problem was with my main user, not with root,
so nothing would work until I fixed it.)