On Tuesday 26 February 2013 11:42:52 Gene Heskett did opine: > On Tuesday 26 February 2013 11:27:12 Sebastian Kuzminsky did opine: > > On 2/26/13 08:54 , Arvid Brodin wrote: > > > On 2013-02-26 16:23, Sebastian Kuzminsky wrote: > > >> On 02/26/2013 01:38 AM, Michael Haberler wrote: > > >>> sim build: > > >>> - there is no /proc/rtapi/debug since sim builds dont sport kernel > > >>> modules and hence no procfs/sysfs entries - the program which runs > > >>> 'sim RT modules', rtapi_app, currently has no way of setting the > > >>> RTAPI message level for the simulated RT components. - hence, with > > >>> userland setting the message level in a usermode component does > > >>> not apply to any 'simulated RT components' either - if you want > > >>> more detailed (level<RTAPI_MSG_ERR) RTAPI error messages from an > > >>> RT component with the userland thread styles, the current method > > >>> is to add a 'rtapi_set_msg_level()' to rtapi_app_main of the > > >>> component in question, and recompile (I would love to be > > >>> corrected on this wart.) - this 'sim build' situation applies to > > >>> all userland thread styles (xenomai, RT-PREEMPT, Posix). RT > > >>> components happily print to the 'console' (wherever that output > > >>> goes), since it's all usermode now. > > >> > > >> Standard out and standard error of all linuxcnc processes is > > >> captured by the linuxcnc starter script and written to a log file > > >> in tmp. The logfile is given a random name, and removed when > > >> linuxcnc exits, both these behaviors make it harder than it should > > >> be to inspect them. > > > > > > Perhaps doing what the X server does is a considerable (and easy) > > > improvement: place the log file (with a fixed name) in /var/log/ and > > > rewrite it on each startup. > > > > That would sure be a big improvement over what we have now. But there > > are difficulties: LinuxCNC runs as a regular user (at least in > > run-in-place mode, and i think also in when installed via the .debs), > > and users don't have permission to write directly to /var/log. So > > we'd need to think about maybe a setuid log helper. > > > > Also, in addition to stdout/stderr mentioned above, there are other > > log mechanisms that write directly to files or to the kernel log. > > Some way to unify all that would still be needed if we want > > everything in one place. > > That seems like it is a no brainer guys. Right? > > The install made the linuxcnc directory as the head directory for most > of the install, located in the users $HOME right? Copy/paste the code > that does that and have it generate a linuxcnc/log directory also owned > by the user. Then log to ~/linuxcnc/log/linuxcnc.log, without any > append (>>) syntax.
I should clarify that, to use the > to make or 'rewind' the file ala xorg, but use the >> syntax for all error messages. > Problem solved. The user has all rights to read > it, or rename it in the event he wants to rerun it for a comparison > copy. > > Whats not to like? > > The only truly user friendly way IMO. > > Cheers, Gene Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> Life is like a sewer. What you get out of it depends on what you put into it. -- Tom Lehrer I was taught to respect my elders, but its getting harder and harder to find any... ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
