log: fix lxc_unix_epoch_to_utc() The conversion algorithm used uses a clever trick by letting a year start at 1 March. So we need to add 1 for January and February. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

tree-wide: Sic semper assertis! Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Fix log.c for stable-2.0 logging style Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>

log: make sure that date is correctly formatted - single digit months, days, hours, minutes, and seconds should always be preceded by a 0. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

tree-wide: random macro cleanups Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: annotate lxc_unix_epoch_to_utc() Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: use lxc_unix_epoch_to_utc() This allows us to generate nice timestamps in a thread-safe manner without relying on locale touching functions from any libc. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: add lxc_unix_epoch_to_utc() Converts a unix time Epoch given by a struct timespec to a UTC string useable in our logging functions. Maybe expanded to allow for more generic formatting. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: drop all timezone conversion functions Our log functions need to make extra sure that they are thread-safe. We had some problems with that before. This especially involves time-conversion functions. I don't want to find any localtime() or gmtime() functions or relatives in here. Not even localtime_r() or gmtime_r() or relatives. They all fiddle with global variables and locking in various libcs. They cause deadlocks when liblxc is used multi-threaded and no matter how smart you think you are, you __will__ cause trouble using them. (As a short example how this can cause trouble: LXD uses forkstart to fork off a new process that runs the container. At the same time the go runtime LXD relies on does its own multi-threading thing which we can't control. The fork()ing + threading then seems to mess with the locking states in these time functions causing deadlocks.) The current solution is to be good old unix people and use the Epoch as our reference point and simply use the seconds and nanoseconds that have past since then. This relies on clock_gettime() which is explicitly marked MT-Safe with no restrictions! This way, anyone who is really strongly invested in getting the actual time the log entry was created, can just convert it for themselves. Our logging is mostly done for debugging purposes so don't try to make it pretty. Pretty might cost you thread-safety. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: use N/A if getpid() != gettid() when threaded Sample log output: lxc 20161125201943.819 INFO lxc_start - start.c:lxc_check_inherited:243 - Closed inherited fd: 54. --> lxc N/A INFO lxc_monitor - monitor.c:lxc_monitor_sock_name:178 - using monitor sock name lxc/ad055575fe28ddd5//var/lib/lxc lxc 20161125201943.958 DEBUG lxc_commands - commands.c:lxc_cmd_handler:893 - peer has disconnected --> lxc N/A DEBUG lxc_commands - commands.c:lxc_cmd_get_state:579 - 'lxc-test-concurrent-0' is in 'RUNNING' state lxc 20161125201943.960 DEBUG lxc_commands - commands.c:lxc_cmd_handler:893 - peer has disconnected lxc 20161125201944.009 INFO lxc_start - start.c:lxc_check_inherited:243 - Closed inherited fd: 3. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: fix race localtime_r() can lead to deadlocks because it calls __tzset() and __tzconvert() internally. The deadlock stems from an interaction between these functions and the functions in monitor.c and commands.{c,h}. The latter functions will write to the log independent of the container thread that is currently running. Since the monitor fork()ed it seems to duplicate the mutex states of the time functions mentioned above causing the deadlock. As a short termm fix, I suggest to simply disable receiving the time when monitor.c or command.{c,h} functions are called. This should be ok, since the [lxc monitor] will only emit a few messages and thread-safety is currently more important than beautiful logs. The rest of the log stays the same as it was before. Here is an example output from logs where I printed the pid and tid of the process that is currently writing to the log: lxc 20161125170200.619 INFO lxc_start: 18695-18695: - start.c:lxc_check_inherited:243 - Closed inherited fd: 23. lxc 20161125170200.640 DEBUG lxc_start: 18677-18677: - start.c:__lxc_start:1334 - Not dropping CAP_SYS_BOOT or watching utmp. lxc 20161125170200.640 INFO lxc_cgroup: 18677-18677: - cgroups/cgroup.c:cgroup_init:68 - cgroup driver cgroupfs-ng initing for lxc-test-concurrent-0 ----------> lxc 20150427012246.000 INFO lxc_monitor: 13017-18622: - monitor.c:lxc_monitor_sock_name:178 - using monitor sock name lxc/ad055575fe28ddd5//var/lib/lxc lxc 20161125170200.662 DEBUG lxc_cgfsng: 18677-18677: - cgroups/cgfsng.c:filter_and_set_cpus:478 - No isolated cpus detected. lxc 20161125170200.662 DEBUG lxc_cgfsng: 18677-18677: - cgroups/cgfsng.c:handle_cpuset_hierarchy:648 - "cgroup.clone_children" was already set to "1". Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

configure: check whether gettid() is declared Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: use thread-safe localtime_r() This fixes a race in liblxc logging which can lead to deadlocks. The reproducer for this issue before this is to simply compile with --enable-tests and then run: lxc-test-concurrent -j 20 -m create,start,stop,destroy -D which should deadlock. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

log: sanity check the returned value from snprintf() The returned value from snprintf() should be checked carefully. This bug can be leveraged to execute arbitrary code through carefully constructing the payload, e.g, lxc-freeze -n `python -c "print 'AAAAAAAA' + 'B'*959"` -P PADPAD -o /tmp/log This command running on Ubuntu 14.04 (x86-64) can cause a segment fault. Signed-off-by: Lans Zhang <jia.zhang@windriver.com>

log: remove duplicate definitons and bump buffer size When writing out the CRIU exec command, we're bumping up against the buffer size limit. Let's increase it so we can avoid: lxc 20160509213229.921 WARN lxc_log - log.c:log_append_logfile:111 - truncated next event from 523 to 512 bytes Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>

log.c:__lxc_log_set_file: completely close log file when overriding Otherwise after a shortcut on error we could end up trying to write to the closed log fd. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

log.c:__lxc_log_set_file: fname cannot be null fname cannot be passed in as NULL by any of its current callers. If it could, then build_dir() would crash as it doesn't check for it. So make sure we are warned if in the future we pass in NULL. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

log: use the right size for timestamp formatting v2: get rid of extra debug crap Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

Only use LOGPATH if lxcpath is unset or default Signed-off-by: Michał Grzędzicki <lazy404@gmail.com>

Easy to read tiemstamp in log Signed-off-by: Gyeongmin Kim <gyeongmintwo@gmail.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

logs: introduce a thread-local 'current' lxc_config (v2) The logging code uses a global log_fd and log_level to direct logging (ERROR(), etc). While the container configuration file allows for lxc.loglevel and lxc.logfile, those are only used at configuration file read time to set the global variables. This works ok in the lxc front-end programs, but becomes a problem with threaded API users. The simplest solution would be to not allow per-container configuration files, but it'd be nice to avoid that. Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible", but would be a huge complication as there are many functions, including struct member functions and callbacks, which don't have that info and would need to get it from somewhere. So the approach I'm taking here is to say that all real container work is done inside api calls, and therefore the API calls themselves can set a thread-local variable indicating which log info to use. If unset, then use the global values. The lxc-* programs, when called with a '-o logfile' argument, set a global variable to indicate that the user-specified value should be used. In this patch: If the lxc container configuration specifies a loglevel/logfile, only set the lxc_config's logfd and loglevel according to those, not the global values. Each API call is wrapped to set/unset the current_config. (The few exceptions are calls which do not result in any log actions) Update logfile appender to use the logfile specified in lxc_conf if (a) current_config is set and (b) the lxc-* command did not override it. Changelog (2015-04-21): . always re-set current_config to NULL at end of an API call, rather than storing the previous value. We don't nest API calls. . remove the log_lock stuff which wasn't used . lxc_conf_free: if the config is current_config, set current_config to NULL. (It can't be another thread's current_config, or we wouldn't be freeing it) . lxc_check_inherited: don't close fd if it is the current_config->logfd. Note this is only called when starting a container, so we have no other threads at this point. Changelog (2015-04-22) . Unset the per-container logfd on destroy . . Do so before we rm the containerdir. Otherwise if the logfile is set . to $lxcpath/$name/log, the containerdir won't be fully deleted. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

Revert (by hand) "logs: introduce a thread-local 'current' lxc_config" This is hopefully temporary - it works great for lxc itself, but seems to be upsetting golang. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Tested-by: Tycho Andersen <tycho.andersen@canonical.com>

logs: introduce a thread-local 'current' lxc_config The logging code uses a global log_fd and log_level to direct logging (ERROR(), etc). While the container configuration file allows for lxc.loglevel and lxc.logfile, those are only used at configuration file read time to set the global variables. This works ok in the lxc front-end programs, but becomes a problem with threaded API users. The simplest solution would be to not allow per-container configuration files, but it'd be nice to avoid that. Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible", but would be a huge complication as there are many functions, including struct member functions and callbacks, which don't have that info and would need to get it from somewhere. So the approach I'm taking here is to say that all real container work is done inside api calls, and therefore the API calls themselves can set a thread-local variable indicating which log info to use. If unset, then use the global values. The lxc-* programs, when called with a '-o logfile' argument, set a global variable to indicate that the user-specified value should be used. In this patch: If the lxc container configuration specifies a loglevel/logfile, only set the lxc_config's logfd and loglevel according to those, not the global values. Each API call is wrapped to set/unset the current_config. (The few exceptions are calls which do not result in any log actions) Update logfile appender to use the logfile specified in lxc_conf if (a) current_config is set and (b) the lxc-* command did not override it. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

typofixes - https://github.com/vlajos/misspell_fixer Signed-off-by: Veres Lajos <vlajos@gmail.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

rmdir and lxc_unpriv returns non-negative error codes Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

add file/func/line to debug info Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

log: fix quiet mode quiet mode was overriden by the double call of lxc_log_init see lxc_container_new use lxc_log_options_no_override in order to fix this Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by: William Dauchy <william@gandi.net>

use lxcpath as unprivileged containers log directory Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

fix fd leak in test-concurrent Opening a debug log for every thread at every iteration of test-concurrent causes it to quickly run out of fd's because this fd is leaked. Fix this by adding a new api: lxc_log_close(). As Caglar noted, the log handling is in general a bit "interesting" because a logfile can be opened through the per-container api c->set_config_item("lxc.logfile") but lxc_log_fd is now per-thread data. It just so happens in test-concurrent that there is a 1:1 mapping of threads to logfiles. Split out getting debug logs from quiet since I think they are useful separately. If debug is specified, get a log of any mode, not just during start. Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

add shared lxc_log_fd into TLS Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

put shared variables into thread-local storage This doesn't solve the general design problem of the log.c (eg; some log lines got lost or scattered into multiple files) but at least prevent multithreaded code from crashing. Before this change something like following; sudo src/tests/lxc-test-concurrent -i 10 -j 20 was crashing nearly all the time due to 3afbcc4600a as we started to set lxc.loglevel and lxc.logfile with that commit. Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

coverity: Drop dead code Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

log: Don't crash when name is NULL This fixes a crash in lxc-autostart following the addition of lxc_log_init as lxc-autostart doesn't use the name property. Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

logging: Add lxc_log_options_no_override function In current LXC, loglevel and logfile are write-once functions. That behaviour was appropriate when those two were first introduced (pre-API) but with current API, one would expect to be able to set_config_item those multiple times. So instead, introduce lxc_log_options_no_override which when called turns those two config keys read-only and have all existing binaries which use log_init call that function once they're done setting the value requested by the user. Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

Disable logpath for unprivileged containers Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

Re-organize API for global lxc.conf config Instead of having one function for each possible key in lxc.conf which doesn't really scale and requires an API update for every new key, switch to a generic lxc_get_global_config_item() function which takes a key name as argument. Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

Remove process_lock() except where actually needed Functions like open(), close(), socket(), socketpair(), pipe() and mkdir() are generally thin wrappers around kernel-provided system calls. It's the kernel not libc, who ensures race-free handling of file descriptors. Thus locking around these functions is unnecessary even on somewhat buggy libcs. fopen(), fclose() and other stdio functions may maintain internal lists of open file handles and thus can be prone to race-conditions. Hopefully, most libcs utilize proper locking or other ways to ensure thread-safety of these functions. Bionic used to have non-thread-safe stdio [2] but that must be fixed since android 4.3 [3, 4]. S.Çağlar Onur showed [1] that openpty() (because of nsswitch) is not thread-safe though. So we workaround it by protecting openpty() calls with process_lock()/process_unlock(). Because of the need to guard openpty() with process_lock()/process_unlock(), process_unlock() is still used after fork(). This commit reverts most of 025ed0f3911836b71f498d8368725c77a7e1932a. [1] https://github.com/lxc/lxc/pull/106#issuecomment-31077269 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=687367 [3] https://android.googlesource.com/platform/bionic/+/f582340a6a48588aa50da17e1620e8f91b146941 [4] https://android.googlesource.com/platform/bionic/+/6b3f49a5374305ce9690c3c5ca2aadc90f54c521 Signed-off-by: Andrey Mazo <mazo@telum.ru> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

allow setting/getting lxc.loglevel and lxc.logfile via set_config_item/get_config_item API calls Signed-off-by: S.Çağlar Onur <caglar@10ur.org> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

Fix build failure on sparc Signed-off-by: Thomas Nemeth <thomas.nemeth@laposte.net> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

make heavier use of process_lock (v2) pthread_mutex_lock() will only return an error if it was set to PTHREAD_MUTEX_ERRORCHECK and we are recursively calling it (and would otherwise have deadlocked). If that's the case then log a message for future debugging and exit. Trying to "recover" is nonsense at that point. process_lock() was held over too long a time in lxcapi_start() in the daemonize case. (note the non-daemonized case still needs a check to enforce that it must NOT be called while threaded). Add process_lock() at least across all open/close/socket() calls. Anything done after a fork() doesn't need the locks as it is no longer threaded - so some open/close/dups()s are not locked for that reason. However, some common functions are called from both threaded and non-threaded contexts. So after doing a fork(), do a possibly-extraneous process_unlock() to make sure that, if we were forked while pthread mutex was held, we aren't deadlocked by nobody. Tested that lp:~serge-hallyn/+junk/lxc-test still works with this patch. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Tested-by: S.Çağlar Onur <caglar@10ur.org> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

licensing: Add missing headers and FSF address Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>

lxc-execute: allow lxc-init to log only when we have a valid log level Right now if we use lxc-execute without log level set, we get error: lxc: invalid log priority NOTSET. Because we set log level manually in execute_start(), but didn't check if we have a valid log level or not, so fix it. Signed-off-by: Qiang Huang <h.huangqiang@huawei.com> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

allow lxc-init to log when rootfs not given On Mon, 29 Apr 2013 14:44:47 -0500 Serge Hallyn <serge.hallyn@ubuntu.com> wrote: > Quoting Dwight Engen (dwight.engen@oracle.com): > > So I did this, only to realize that lxc-init is passing "none" for > > the file anyway, so it currently doesn't intend to log. This makes > > me think that passing NULL for lxcpath is the right thing to do in > > this patch. If you want me to make it so lxc-init can log, I can do > > that but I think it should be in a different change :) > > That actually would be very useful, but as you say that's a different > feature - thanks. ... and here is said change. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

log.c: always use dir when lxcpath is not default Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

Create log file in lxcpath for non-system containers On Fri, 26 Apr 2013 10:18:12 -0500 Serge Hallyn <serge.hallyn@ubuntu.com> wrote: > Quoting Dwight Engen (dwight.engen@oracle.com): > > On Fri, 26 Apr 2013 09:37:49 -0500 > > Serge Hallyn <serge.hallyn@ubuntu.com> wrote: > > > > > Quoting Dwight Engen (dwight.engen@oracle.com): > > > > Using lxc configured with --enable-configpath-log, and > > > > specifying a path to the lxc commands with -P, the log file > > > > path is generated with a basename of LOGPATH instead of the > > > > lxcpath. This means for example if you do > > > > > > > > lxc-start -P /tmp/containers -n test01 -l INFO > > > > > > > > your log file will be > > > > > > > > /var/lib/lxc/test01/test01.log > > > > > > > > I was expecting the log to be /tmp/containers/test01/test01.log. > > > > This is particularly confusing if you also have test01 on the > > > > regular lxcpath. The patch below changes the log file path to be > > > > based on lxcpath rather than LOGPATH when lxc is configured with > > > > --enable-configpath-log. > > > > > > > > I think that even in the normal non --enable-configpath-log case > > > > we should consider using lxcpath as the base and not having > > > > LOGPATH at all, as attempting to create the log files > > > > in /var/log is not going to work for regular users on their own > > > > lxcpath. If we want that, I'll update the patch to do that as > > > > well. > > > > > > > > > Perhaps we should do: > > > > > > 1. If lxcpath == default_lxc_path(), then first choice is > > > LOGPATH, second is lxcpath/container.log > > > 2. when opening, if first choice fails, use second choice > > > if there is any. > > > > > > That way 'system' containers will go to /var/log/lxc, as I think > > > they should. Custom-lxcpath containers should never go > > > to /var/log/lxc, since their names could be dups of containers in > > > default_lxc_path(). And if the system is a weird one where > > > default_lxc_path is set up so that an unprivileged user can use > > > it, then we should log into $lxcpath. > > > > That sounds good to me. So these rules would apply in both the > > regular and --enable-configpath-log cases. I updated the patch to try to open the log file according to the choices given above. Along the way I cleaned up log.c a bit, making some things static, grouping external interfaces together, etc... Hopefully that doesn't add too much noise. > > > (Note this patch will trivially conflict with my new lxc_clone.c > > > causing it to fail to build - unfortunate result of timing) > > > > Yeah unfortunately this touches every lxc_log_init() caller. I can > > work on the above logic and re-submit after your new lxc_clone > > stuff goes in. > > No no, I'll just need to remember to update mine. Don't hold up on > mine, this is just the nature of such collaboration :) > > > Did you have any thoughts on the XXX what to pass in for lxcpath in > > lxc_init? Right now it just falls back to LOGPATH. > > No - that's a weird one, since lxc_init runs in the container. If > there were only system containers I'd say always use LOGPATH. > However there are people (apparently :) who use container sharing the > host's rootfs... > > lxc-execute does know the lxcpath. Perhaps we can simply have > src/lxc/execute.c:execute_start() look at handler->conf to see if a > rootfs is set. If rootfs is NOT set, then pass lxcpath along to > lxc-init. Then lxc-init can mostly do the same as the others? (It > doesn't use src/lxc/arguments.c, so you'd have to add lxcpath to > options[] in lxc-init.c) So I did this, only to realize that lxc-init is passing "none" for the file anyway, so it currently doesn't intend to log. This makes me think that passing NULL for lxcpath is the right thing to do in this patch. If you want me to make it so lxc-init can log, I can do that but I think it should be in a different change :) -- Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

fortify: minor cleanups for unused variables, stricter types Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

Fix typos identified by lintian Lintian spotted those two typos. Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

use a default per-container logfile Until now, if a lxc-* (i.e. lxc-start) command did not specify a logfile (with -o logfile), the default was effectively 'none'. With this patch, the default becomes a per-container log file. If a container config file specifies 'lxc.logfile', that will override the default. If a '-o logfile' argument is specifed at lxc-start, then that will override both the default and the configuration file entry. Finally, '-o none' can be used to avoid having a logfile at all (in other words, the previous default), and that will override a lxc.logfile entry in the container configuration file. If the user does not have rights to open the default, then 'none' will be used. However, in that case an error will show up on console. (We can work on removing that if it annoys people, but I think it is helpful, at least while we're still ironing this set out) If the user or container configuration file specified a logfile, and the user does not have rights to open the default, then the action will fail. One slight "mis-behavior" which I have not fixed (and may not fix) is that if a lxc.logfile is specified, the default logfile will still get created before we read the configuration file to find out there is a lxc.logfile entry. changelog: Jan 24: add --enable-configpath-log configure option When we log to /var/lib/lxc/$container/$container.log, several things need to be done differently than when we log into /var/log/lxc (for instance). So give it a configure option so we know what to do When the user specifies a logfile, we bail if we can't open it. But when opening the default logfile, the user may not have rights to open it, so in that case ignore it and continue as if using 'none'. When using /var/lib/lxc/$c/$c.log, we use $LOGPATH/$name/$name.log. Otherwise, we use $LOGPATH/$name.log. When using /var/lib/lxc/$c/$c.log, don't try to create the log path /var/lib/lxc/$c. It can only not exist if the container doesn't exist. We don't want to create the directory in that case. When using /var/log/lxc, then we do want to create the path if it does not exist. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

Revert "use a default per-container logfile" The logfile changes broke lxc-info and possibly more command line tools. Revert for now until we get those issues addressed. This reverts commit 74476cf144523530022d76cef3a558b0662b592f.

Revert "use a default per-container logfile" The logfile changes broke lxc-info and possibly more command line tools. Revert for now until we get those issues addressed. This reverts commit b8e0503a1d1dbf3a508bf6f34521606ba231b1fe.

use a default per-container logfile log_open: make sure the parent directory for logfiles Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

use a default per-container logfile [ Thanks to Stéphane and Dwight for the feedback on the previous patch ] Until now, if a lxc-* (i.e. lxc-start) command did not specify a logfile (with -o logfile), the default was effectively 'none'. With this patch, the default becomes $LOGPATH/<container>/<container>.log. LOGPATH is specified at configure time with '--with-log-path='. If unspecified, it is $LXCPATH, so that logs for container r2 will show up at /var/lib/lxc/r2/r2/log. LOGPATH must exist, while lxc will make sure to create $LOGPATH/<name>. As another example, Ubuntu will likely specify --with-log-path=/var/log/lxc (and place /var/log/lxc into debian/lxc.dirs), placing r2's logs in /var/log/lxc/r2/r2.log. If a container config file specifies 'lxc.logfile', that will override the default. If a '-o logfile' argument is specifed at lxc-start, then that will override both the default and the configuration file entry. Finally, '-o none' can be used to avoid having a logfile at all (in other words, the previous default), and that will override a lxc.logfile entry in the container configuration file. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

remove logfile and loglevel from struct lxc_conf The options are still supported in the lxc configuration file. However they are stored only in local variables in src/lxc/log.c, which can be read using two new functions: int lxc_log_get_level(void); const char *lxc_log_get_file(void); Changelog: jan 14: have lxc_log_init use lxc_log_set_file(), have lxc_log_set_file() take a const char *, and have it keep its own strdup'd copy of the filename. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>

lxc_conf logfile and loglevel support Add 'lxc.logfile' and 'lxc.loglevel' config items. Values provided on the command line override the config items. Have lxccontainer not set a default loglevel and logfile. Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>

Fix fd leak in lxc log lxc_log_init will leak an fd when it is called by a long running program that may call lxc_container_new multiple times. Fix by only opening the log if it is not already open. Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>

lxc: default log appender on stderr The default appender for logs is currently the file one: this make macros from log.h unusable as long as lxc_log_init() hasn't been called. This prevents errors from even being printed on stderr in lxc_caps_init() for example. Let's make stderr the default appender. Signed-off-by: Greg Kurz <gkurz@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

fix log appending to any file With the capabilities, the open of the log file can be done on any file, making possible to modifify the content of the file. Let's drop the privilege when opening the file, so we ensure that is no longer possible. Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

add quiet option This added quiet option allow to disable the reporting via stderr of the lxc error messages. Note that the usage function is still printing in case of error, but will be removed by later patches Signed-off-by: Michel Normand <normand@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

add a default stderror log appender This is adding a stderror log appender that is used as default one. Signed-off-by: Michel Normand <normand@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

properly handle va_list in log_append functions the support of multiple appenders need to associate one va_list per appender. This is the purpose of this patch to copy the va_list before to call the appender. Signed-off-by: Michel Normand <normand@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

add support of a lxc log file to cli this is adding -o and -l options to all cli of lxc Signed-off-by: Michel Normand <normand@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Revert "make the log fd thread safe" This reverts commit 2c9bd0073f29573181dc16a840c674dacc8a33fd. Pointless and useless right now and certainly wrong as several threads in the library may want to log to the same, to be defined later.

add the missing header in the log file License header is missing in the log files. Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

locally define O_CLOEXEC this is a required patch to be able to compile lxc on a RedHat 5 update 1 which has such define. This is also required for the F_DUPFD_CLOEXEC define Signed-off-by: Michel Normand <normand@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

make the log fd thread safe Add the tls attribute for the global static variables in the logs. Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

lxc: cleanup log some headers and macros are now redundant Signed-off-by: Cedric Le Goater <legoater@free.fr> Acked-by: Daniel Lezcano <dlezcano@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

lxc: introduce log4c style logging lxc_log_init() should be called in each main() of a command to define the default log priority and log file. Signed-off-by: Cedric Le Goater <legoater@free.fr> Acked-by: Daniel Lezcano <dlezcano@fr.ibm.com> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

cleanup log.h Rename lxc_log.h to log.h Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>