How best to deal with conf and log files in a uciForum: Window Mangers Topic: How best to deal with conf and log files in a uci started by: Juanito Posted by Juanito on June 12 2007,16:19
This my first attempt at a uci - for xorg-7.2 in this case.After building the uci, the first thing I discovered is that xorg will not run because it needs to write a log file to /opt/xorg72/var/log and read a configuration file from /opt/xorg72/etc/X11 and the uci is read-only. I was thinking that I could perhaps use symlinks as follows: /opt/xorg72/var/log/Xorg.0.log --> /var/log/Xorg.0.log /opt/xorg72/var/log/Xorg.0.log.old --> /var/log/Xorg.0.log.old /opt/xorg72/etc/X11/xorg.conf --> /etc/X11/xorg.conf Is this an "approved" way to work with uci extensions in DSL? Posted by ^thehatsrule^ on June 12 2007,18:35
For the xlogs, you probably could leave the symlinks if they work. It seems the -log option only works for real-uid root. The other alternative would be to recompile using a different default path just for the xlogs./opt/xorg72/etc/X11 is fine because it will be read-only. Maybe leaving a default "vesa" config there would be good for default behaviour (which I personally do). Why is it fine still if you want to change your xconfig? Because it looks like the search path uses /etc/X11 first... (i.e. see `man xorg.conf` ) p.s. X isn't a wm.. maybe system would be better? Posted by mikshaw on June 12 2007,19:59
In most cases, the symlink should work fine. In the case of Xorg, though, you *might* run into some trouble as it attempts to shuffle logs. Once the log gets to a certain size, a new one is created, so it might choke trying to create a new file on a read-only filesystem. I might be wrong about this, of course. I know that XFree86 creates multiple log files, but I don't know if Xorg might just stick with those two.Personally i'd still look into the suggestion of using a different default path. Posted by ^thehatsrule^ on June 12 2007,23:08
Good point mikshaw. If you run the defaults it will only use Xorg.0.log and Xorg.0.log.old - but afaik the # corresponds to the xserver # currently running ( $DISPLAY by default is :0.0 )Perhaps using /opt/xorg72/var/log/ --> /var/log/ will be easier? Posted by mikshaw on June 13 2007,01:55
That's an even better idea.
Posted by Juanito on June 13 2007,10:43
I made a few tests and using the following symlinks in the uci works:/opt/xorg72/var/log/ --> /var/log/ /opt/xorg72/etc/X11/xorg.conf --> /etc/xorg.conf As said, xorg looks for xorg.conf in /etc/X11 first - I know this because it tried to use my XF86Config-4 file and complained about a missing synaptics driver... Although xorg finds the libs it needs when starting using startx, once started mini-apps like xclock complain about missing libs so I guess I will need to change the symlink X --> xorg to something like this:
Posted by ^thehatsrule^ on June 13 2007,16:26
I have a feeling that you wouldn't need the wrapper if it was the original symlink to hd for some reason...Some notes: Isn't xorg, Xorg? (caps) Though I'm sure PATH will be set almost all the time, LD_LIBRARY_PATH usually is not, and although having a trailing : may work, perhaps checking if it's empty first or not will be better (and then setting the appropriate string). Posted by mikshaw on June 13 2007,17:58
It seems to me that the wrapper is needed for the x apps that require libraries installed into /opt/xorg72/lib. Also, if i'm understanding what you said, LD_LIBRARY_PATH *might* be set by the user prior to running Xorg, so I think it's best to include a possible existing $LD_LIBRARY_PATH when it is set rather than risk accidentally breaking other apps. A check for an existing non-zero value (test -n or test -z, for example) will work as well, but a trailing colon will do no harm.
Posted by Juanito on June 14 2007,03:48
If I check the contents of the library path after running xorg, but before running xclock, I get this:
Where the space is deliberate - i.e. the library path is either empty or contains <space> and/or <cr>. If I check the contents of the path, I don't remember exactly what it shows, but I remember end of the entry is ".../opt/bin:." where there is a full stop after the semi-colon - I don't know if this is significant or not. Posted by mikshaw on June 14 2007,05:03
The space is deliberate only because the echo command automatically adds a space to its output. If you were to use echo's "-n" parameter (echo -n $LD_LIBRARY_PATH), or used some other method of grabbing the variable, you would not see that space.Your personal LD_LIBRARY_PATH variable, as well as that of any other DSL user who hasn't changed it, is empty (or possibly unset, although the difference between empty and unset is not important in this case). My earlier point about appending rather than replacing the variable, even if it is usually empty, is important because even though your variable is empty, someone else's may not be. If you're creating something that will be distributed to other users you shouldn't make assumptions about things like this, particularly when avoiding a potential problem is a simple task. The dot at the end of PATH is not a full stop. It's a dot, which represents the present directory. What it means is that no matter what directory you are in, that directory becomes part of PATH so you can run commands in that directory without preceding the command with "./" (while you're in that directory). I'm not really sure why this was done, especially considering many people claim this is a potential security issue. But at least the dot is at the end of PATH, so commands in ./ do not override system commands. Also, I see you ran the echo command as root. Each user has a unique environment, so root's LD_LIBRARY_PATH is not going to be the same as dsl's LD_LIBRARY_PATH. If the application is run by dsl, root's environment has no influence over it. |