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. 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 -- "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> So so is good, very good, very excellent good: and yet it is not; it is but so so. -- William Shakespeare, "As You Like It" 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
