[ABRT PATCH] change /var/spool/abrt/ to /var/tmp/abrt rhbz#912750

Jiri Moskovcak jmoskovc at redhat.com
Thu Jul 18 11:11:10 UTC 2013


- note: /var/spool/abrt-upload is still ok, the data is moved
  to /var/tmp/abrt/ after it's processed

Signed-off-by: Jiri Moskovcak <jmoskovc at redhat.com>
---
 doc/abrt.conf.txt                                  |  2 +-
 .../en-US/Automatic_Bug_Reporting_Tool_ABRT.xml    | 26 +++++++++++-----------
 doc/design                                         | 24 ++++++++++----------
 doc/implementation                                 |  6 ++---
 doc/interpreted-languages                          |  8 +++----
 src/cli/list.c                                     |  2 +-
 src/daemon/abrt.conf                               |  4 ++--
 src/daemon/abrtd.c                                 |  2 +-
 src/hooks/abrt-harvest-vmcore.conf                 |  2 +-
 src/hooks/abrt-harvest-vmcore.in                   |  2 +-
 src/hooks/abrt-hook-ccpp.c                         |  4 ++--
 11 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/doc/abrt.conf.txt b/doc/abrt.conf.txt
index 6626596..d782e3d 100644
--- a/doc/abrt.conf.txt
+++ b/doc/abrt.conf.txt
@@ -16,7 +16,7 @@ A description of each item follows:
 
 DumpLocation = 'directory'::
    The directory where should 'abrt' store coredumps and all files which are
-   needed for reporting. The default is /var/spool/abrt.
+   needed for reporting. The default is /var/tmp/abrt.
 
 MaxCrashReportsSize = 'number'::
    The maximum disk space (specified in megabytes) that 'abrt'
diff --git a/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml b/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
index c05dd4a..e11307a 100644
--- a/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
+++ b/doc/deployment/en-US/Automatic_Bug_Reporting_Tool_ABRT.xml
@@ -15,7 +15,7 @@
       </para>
       <!-- msvoboda: Differencies between ABRT 1-series and ABRT 2-series cannot be added to Release Notes because the amount of changes is too large
       <para>For more information on the major differences between the <application>ABRT</application> 1-series and <application>ABRT</application> 2-series, refer to the <citetitle>Red Hat Enterprise Linux 6.2 Release Notes</citetitle>.</para>-->
-      <!--msvoboda: The ABRT Migration section will be added on RHEL 6.2 GA 
+      <!--msvoboda: The ABRT Migration section will be added on RHEL 6.2 GA
       <para>For more information on the major differences between the <application>ABRT</application> 1-series and <application>ABRT</application> 2-series, as well as easy migration instructions, refer to <xref linkend="sect-migration_to_abrt2"/>
       </para>-->
     </important>
@@ -222,7 +222,7 @@ Starting abrt daemon:                                      [  OK  ]</screen>
   <section id="sect-abrt-gui">
     <title>Using the Graphical User Interface</title>
     <para>
-      The <application>ABRT</application> daemon sends a broadcast D-Bus message whenever a problem report is created. If the <application>ABRT</application> notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the <application>ABRT GUI</application> application using this icon. As an alternative, you can display the <application>ABRT</application> GUI by selecting the 
+      The <application>ABRT</application> daemon sends a broadcast D-Bus message whenever a problem report is created. If the <application>ABRT</application> notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the <application>ABRT GUI</application> application using this icon. As an alternative, you can display the <application>ABRT</application> GUI by selecting the
       <menuchoice>
         <guimenu>Application</guimenu>
         <guisubmenu>System Tools</guisubmenu>
@@ -449,14 +449,14 @@ Starting abrt daemon:                                      [  OK  ]</screen>
         To view detected problems, enter the <command>abrt-cli list</command> command:
       </para>
       <screen>~]#&#160;<command>abrt-cli list</command>
-Directory:      /var/spool/abrt/ccpp-2011-09-13-10:18:14-2895
+Directory:      /var/tmp/abrt/ccpp-2011-09-13-10:18:14-2895
 count:          2
 executable:     /usr/bin/gdb
 package:        gdb-7.2-48.el6
 time:           Tue 13 Sep 2011 10:18:14 AM CEST
 uid:            500
 
-Directory:      /var/spool/abrt/ccpp-2011-09-21-18:18:07-2841
+Directory:      /var/tmp/abrt/ccpp-2011-09-21-18:18:07-2841
 count:          1
 executable:     /bin/bash
 package:        bash-4.1.2-8.el6
@@ -631,7 +631,7 @@ uid:            500</screen>
       <para>...where <replaceable>directory</replaceable> stands for the <emphasis
           role="bold">problem data directory</emphasis> of the problem that is being reported. For example:
       </para>
-      <screen>~]$&#160;<command>abrt-cli report</command>&#160;<filename>/var/spool/abrt/ccpp-2011-09-13-10:18:14-2895</filename>
+      <screen>~]$&#160;<command>abrt-cli report</command>&#160;<filename>/var/tmp/abrt/ccpp-2011-09-13-10:18:14-2895</filename>
 How you would like to analyze the problem?
 1) Collect .xsession-errors
 2) Local GNU Debugger
@@ -710,8 +710,8 @@ Select reporter(s): _</screen>
       <para>
         ...where <replaceable>directory</replaceable> stands for the problem data directory of the problem being deleted. For example:
       </para>
-      <screen>~]$ <command>abrt-cli rm</command> <filename>/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413</filename>
-rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
+      <screen>~]$ <command>abrt-cli rm</command> <filename>/var/tmp/abrt/ccpp-2011-09-12-18:37:24-4413</filename>
+rm '/var/tmp/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
       <note>
         <title>Deletion of a problem can lead to frequent ABRT notification</title>
         <para>
@@ -1234,11 +1234,11 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
         </varlistentry>
         <varlistentry>
           <term>
-            DumpLocation = /var/spool/abrt
+            DumpLocation = /var/tmp/abrt/
           </term>
           <listitem>
             <para>
-              This directive is commented out by default. It specifies the location where problem data directories are created and in which problem core dumps and all other problem data are stored. The default location is set to the <filename>/var/spool/abrt</filename> directory. Whichever directory you specify in this directive, you must ensure that it exists and it is writable for <systemitem class="daemon">abrtd</systemitem>. If you change the default value of this option, be aware that in order to ensure proper functionality of <application>ABRT</application>, this directory <emphasis role="bold">must not</emphasis> be the same as the directory specified for the <option>WatchCrashdumpArchiveDir</option> option.
+              This directive is commented out by default. It specifies the location where problem data directories are created and in which problem core dumps and all other problem data are stored. The default location is set to the <filename>/var/tmp/abrt/</filename> directory. Whichever directory you specify in this directive, you must ensure that it exists and it is writable for <systemitem class="daemon">abrtd</systemitem>. If you change the default value of this option, be aware that in order to ensure proper functionality of <application>ABRT</application>, this directory <emphasis role="bold">must not</emphasis> be the same as the directory specified for the <option>WatchCrashdumpArchiveDir</option> option.
             </para>
             <warning>
               <title>Do not modify this option in SELinux</title>
@@ -1330,7 +1330,7 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
     <section id="sect-abrt-configuration-kernel_panic_detection">
       <title>Configuring ABRT to Detect a Kernel Panic</title>
       <para>
-        With Red Hat Enterprise Linux 6.3, <application>ABRT</application> can detect a kernel panic using the <systemitem class="service">abrt-vmcore</systemitem> service, which is provided by the <package>abrt-addon-vmcore</package> package. The service starts automatically on system boot and searches for a core dump file in the <filename>/var/crash/</filename> directory. If a core dump file is found, <systemitem class="service">abrt-vmcore</systemitem> creates the <systemitem>problem data directory</systemitem> in the <filename>/var/spool/abrt/</filename> directory and moves the core dump file to the newly created problem data directory. After the <filename>/var/crash/</filename> directory is searched through, the service is stopped until the next system boot.
+        With Red Hat Enterprise Linux 6.3, <application>ABRT</application> can detect a kernel panic using the <systemitem class="service">abrt-vmcore</systemitem> service, which is provided by the <package>abrt-addon-vmcore</package> package. The service starts automatically on system boot and searches for a core dump file in the <filename>/var/crash/</filename> directory. If a core dump file is found, <systemitem class="service">abrt-vmcore</systemitem> creates the <systemitem>problem data directory</systemitem> in the <filename>/var/tmp/abrt/</filename> directory and moves the core dump file to the newly created problem data directory. After the <filename>/var/crash/</filename> directory is searched through, the service is stopped until the next system boot.
       </para>
       <para>
         To configure <application>ABRT</application> to detect a kernel panic, perform the following steps:
@@ -1357,7 +1357,7 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
         </listitem>
       </orderedlist>
       <para>
-        Unless <application>ABRT</application> is configured differently, problem data for any detected kernel panic is now stored in the <filename>/var/spool/abrt/</filename> directory and can be further processed by <application>ABRT</application> just as any other detected kernel oops.
+        Unless <application>ABRT</application> is configured differently, problem data for any detected kernel panic is now stored in the <filename>/var/tmp/abrt/</filename> directory and can be further processed by <application>ABRT</application> just as any other detected kernel oops.
       </para>
     </section>
     <section id="sect-abrt-configuration-debuginfo">
@@ -1447,7 +1447,7 @@ rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen>
           <note>
             <title>The abrt user and group</title>
             <para>
-              When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem class="username">abrt</systemitem>. This user is used by the <systemitem class="daemon">abrtd</systemitem> daemon, for example, as the owner:group of <filename>/var/spool/abrt/*</filename> directories.
+              When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem class="username">abrt</systemitem>. This user is used by the <systemitem class="daemon">abrtd</systemitem> daemon, for example, as the owner:group of <filename>/var/tmp/abrt/*</filename> directories.
             </para>
           </note>
         </listitem>
@@ -1612,7 +1612,7 @@ ftp> <command>quit</command></screen>
 [1] 2823
 ~]$ <command>kill -s SEGV 2823</command></screen>
       <para>
-        <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli list --full</command> command, or by examining the crash dump created in the <filename>/var/spool/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system.
+        <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli list --full</command> command, or by examining the crash dump created in the <filename>/var/tmp/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system.
       </para>
     </section>
   </section>
diff --git a/doc/design b/doc/design
index 9044529..a9ce040 100644
--- a/doc/design
+++ b/doc/design
@@ -43,23 +43,23 @@ of the above usage scenarios.
 Since currently we do not know how to dump oops on demand,
 we can only poll for it. There is a small daemon, abrt-dump-oops,
 which polls syslog file and saves oopses when it sees them.
-The oops dump is written into /var/spool/abrt/DIR.
-[TODO? abrt-dump-oops spawns "abrt-handle-crashdump -d /var/spool/abrt/DIR"
+The oops dump is written into /var/tmp/abrt/DIR.
+[TODO? abrt-dump-oops spawns "abrt-handle-crashdump -d /var/tmp/abrt/DIR"
 which processes it according to configuration in /etc/abrt/*.conf]
 
 In order to catch binary crashes, we install a handler for it
 in /proc/sys/kernel/core_pattern (by setting it to
-"|/usr/libexec/abrt-hook-ccpp /var/spool/abrt ....").
-When process dumps core, the dump is written into /var/spool/abrt/DIR.
+"|/usr/libexec/abrt-hook-ccpp /var/tmp/abrt ....").
+When process dumps core, the dump is written into /var/tmp/abrt/DIR.
 [TODO? after this, abrt-hook-ccpp spawns "abrt-handle-crashdump
--d /var/spool/abrt/DIR"]
+-d /var/tmp/abrt/DIR"]
 Then abrt-hook-ccpp terminates.
 
 When python program crashes, it invokes internal python subroutine
 which connects to abrtd via /var/run/abrt/abrt.socket and sends
-crash data to abrtd. abrtd creates dump dir /var/spool/abrt/DIR.
+crash data to abrtd. abrtd creates dump dir /var/tmp/abrt/DIR.
 
-abrtd daemon watches /var/spool/abrt for new directories.
+abrtd daemon watches /var/tmp/abrt/ for new directories.
 When new directory is noticed, abrtd runs "post-create" event
 on it, and emits a dbus signal. This dbus signal is used
 to inform online users about the new crash: if abrt-applet
@@ -89,22 +89,22 @@ The key dbus calls served by abrtd are:
 - GetCrashInfos(): returns a vector_map_crash_data_t (vector_map_vector_string_t)
      of crashes for given uid
      v[N]["executable"/"uid"/"kernel"/"backtrace"][N] = "contents"
-- CreateReport(/var/spool/abrt/DIR): starts creating a report.
+- CreateReport(/var/tmp/abrt/DIR): starts creating a report.
      Returns job id (uint64).
      Then abrtd run "analyze" event on the DIR.
      After it completes, when report creation thread has finished,
-     JobDone(client_dbus_ID,/var/spool/abrt/DIR) dbus signal is emitted.
+     JobDone(client_dbus_ID,/var/tmp/abrt/DIR) dbus signal is emitted.
   [Problem: how to do privilegged plugin specific actions?]
     Solution: if plugin needs an access to some root only accessible dir then
     abrt should be run by root anyway
     - debuginfo gets installed using pk-debuginfo-install, which cares about
     privileges itself, so no problem here
-- GetJobResult(/var/spool/abrt/DIR): returns map_crash_data_t (map_vector_string_t)
+- GetJobResult(/var/tmp/abrt/DIR): returns map_crash_data_t (map_vector_string_t)
 - Report(map_crash_data_t (map_vector_string_t)):
-     "Please report this crash": 
+     "Please report this crash":
      abrtd run "report[_FOO]" event(s) on the DIR.
      Returns report_status_t (map_vector_string_t) - the status of each event
-- DeleteDebugDump(/var/spool/abrt/DIR): delete /var/spool/abrt/DIR. Returns bool
+- DeleteDebugDump(/var/tmp/abrt/DIR): delete /var/tmp/abrt/DIR. Returns bool
 
 [Note: we are in the process of reducing/eliminating
 dbus communication between abrt-gui/abrt-cli and abrtd.
diff --git a/doc/implementation b/doc/implementation
index e749a47..0ec9831 100644
--- a/doc/implementation
+++ b/doc/implementation
@@ -8,7 +8,7 @@ the coredump of crashing app:
 * helper source code: http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=src/Hooks/abrt-hook-python.cpp
 the code responsible for this:
 
-    #define CORE_PATTERN            "|/usr/libexec/abrt-hook-ccpp" "/var/spool/abrt" %p %s %u"
+    #define CORE_PATTERN            "|/usr/libexec/abrt-hook-ccpp" "/var/tmp/abrt" %p %s %u"
     ofstream fOutCorePattern;
     fOutCorePattern.open(CORE_PATTERN_IFACE);
     if (fOutCorePattern.is_open())
@@ -33,7 +33,7 @@ cmdline:
     char path[sizeof("/proc/%u/cmdline") + sizeof(int)*3];
     sprintf(path, "/proc/%u/cmdline", (int)pid);
 
-both is saved to file in /var/spool/abrt/ccpp-<time>-<pid> readable
+both is saved to file in /var/tmp/abrt/ccpp-<time>-<pid> readable
 only by owner the crashed process:
     int fd = open(pPath, O_WRONLY | O_TRUNC | O_CREAT, 0666);
     if(fd){
@@ -82,7 +82,7 @@ abrt-action-install-debuginfo is a shell script using elfutils to get build-ids
     - gdb is run with the same privileges as the crashed app (setregid, setreuid)
     d) BT is saved to same directory where the coredump is
 
-Once the backtrace is processed all data from the /var/spool/abrt/ccpp-<time>-<pid> is sent
+Once the backtrace is processed all data from the /var/tmp/abrt/ccpp-<time>-<pid> is sent
 over dbus to the client and then user can edit the backtrace. When user is happy about
 the report and command the client (gui, tui) to send the it, the client sends the data back
 to the daemon calling the Report(data) method over the dbus. The actual reporting is done by
diff --git a/doc/interpreted-languages b/doc/interpreted-languages
index 6609cd9..713bc59 100644
--- a/doc/interpreted-languages
+++ b/doc/interpreted-languages
@@ -32,12 +32,12 @@ be interpreted by the interpreter in the same way as the applications
 When some event which should be caught by ABRT occurs and is detected
 by the hook, the hook reports it to ABRT using ABRT daemon's socket
 file.  ABRT then creates a new directory describing the crash in
-/var/spool/abrt.
+/var/tmp/abrt.
 
 The ABRT's CCpp plugin does not use the socket file, but it creates
-crash data directory in /var/spool/abrt directly. Interpreted hooks
+crash data directory in /var/tmp/abrt directly. Interpreted hooks
 must not report crashes this way, because SELinux blocks interpreter
-access to /var/spool/abrt and this access can not be granted due to
+access to /var/tmp/abrt and this access can not be granted due to
 security issues.
 
 ABRT socket file resides in /var/run/abrt.socket. Hooks should open
@@ -76,7 +76,7 @@ for the crash dump. Sensible names are "python", "perl", "java" etc.
 
 BASENAME
 Short string indicating the origin of the event. It is used as a part
-of directory name: /var/spool/abrt/BASENAME-suffix. Use "python" for
+of directory name: /var/tmp/abrt/BASENAME-suffix. Use "python" for
 Python exceptions, "ruby" for ruby interpreter, "java" for JRE.
 
 REASON
diff --git a/src/cli/list.c b/src/cli/list.c
index 67ee00e..c29eba5 100644
--- a/src/cli/list.c
+++ b/src/cli/list.c
@@ -27,7 +27,7 @@
  *     add  wildcard e.g. *-2011-04-01-10-* (list all problems in specific day)
  *
  * TODO?: remove base dir from list of crashes? is there a way that same crash can be in
- *       ~/.abrt/spool and /var/spool/abrt? needs more _meditation_.
+ *       ~/.abrt/spool and /var/tmp/abrt? needs more _meditation_.
  */
 
 /** Prints basic information about a crash to stdout. */
diff --git a/src/daemon/abrt.conf b/src/daemon/abrt.conf
index d00e84b..59d1831 100644
--- a/src/daemon/abrt.conf
+++ b/src/daemon/abrt.conf
@@ -10,11 +10,11 @@
 MaxCrashReportsSize = 1000
 
 # Specify where you want to store coredumps and all files which are needed for
-# reporting. (default:/var/spool/abrt)
+# reporting. (default:/var/tmp/abrt)
 #
 # Changing dump location could cause problems with SELinux. See man abrt_selinux(8).
 #
-#DumpLocation = /var/spool/abrt
+#DumpLocation = /var/tmp/abrt
 
 # If you want to automatically clean the upload directory you have to tweak the
 # selinux policy.
diff --git a/src/daemon/abrtd.c b/src/daemon/abrtd.c
index 1418aab..573ec28 100644
--- a/src/daemon/abrtd.c
+++ b/src/daemon/abrtd.c
@@ -45,7 +45,7 @@
 
 /* Daemon initializes, then sits in glib main loop, waiting for events.
  * Events can be:
- * - inotify: something new appeared under /var/spool/abrt or /var/spool/abrt-upload
+ * - inotify: something new appeared under /var/tmp/abrt or /var/spool/abrt-upload
  * - signal: we got SIGTERM, SIGINT, SIGALRM or SIGCHLD
  * - new socket connection
  */
diff --git a/src/hooks/abrt-harvest-vmcore.conf b/src/hooks/abrt-harvest-vmcore.conf
index d2d5413..ed7556f 100644
--- a/src/hooks/abrt-harvest-vmcore.conf
+++ b/src/hooks/abrt-harvest-vmcore.conf
@@ -1,4 +1,4 @@
-# Do you want vmcore to be copied, or moved from /var/crash to /var/spool/abrt?
+# Do you want vmcore to be copied, or moved from /var/crash to /var/tmp/abrt?
 # (default is to copy, but it may duplicate way too much data)
 CopyVMcore = yes
 
diff --git a/src/hooks/abrt-harvest-vmcore.in b/src/hooks/abrt-harvest-vmcore.in
index 99022d9..a9ed1a2 100644
--- a/src/hooks/abrt-harvest-vmcore.in
+++ b/src/hooks/abrt-harvest-vmcore.in
@@ -48,7 +48,7 @@ for d in *; do
 	# to process partially-copied directory.
 	#
 	# This is the efficient way:
-	#mv -- "$d" "/var/spool/abrt/vmcore-$d.new" || continue
+	#mv -- "$d" "/var/tmp/abrt/vmcore-$d.new" || continue
 	# ...and this is what selinux forces me to do
 	# (otherwise files have wrong context and abrtd can't access them):
 	cp -r --no-preserve=all -- "$d" "$dst.new" || {
diff --git a/src/hooks/abrt-hook-ccpp.c b/src/hooks/abrt-hook-ccpp.c
index 2fd6d6d..99ce5d5 100644
--- a/src/hooks/abrt-hook-ccpp.c
+++ b/src/hooks/abrt-hook-ccpp.c
@@ -626,7 +626,7 @@ int main(int argc, char** argv)
         check_free_space(maxsize, g_settings_dump_location);
     }
 
-    /* Check /var/spool/abrt/last-ccpp marker, do not dump repeated crashes
+    /* Check /var/tmp/abrt/last-ccpp marker, do not dump repeated crashes
      * if they happen too often. Else, write new marker value.
      */
     snprintf(path, sizeof(path), "%s/last-ccpp", g_settings_dump_location);
@@ -666,7 +666,7 @@ int main(int argc, char** argv)
     }
 
     /* use fsuid instead of uid, so we don't expose any sensitive
-     * information of suided app in /var/spool/abrt
+     * information of suided app in /var/tmp/abrt
      */
     dd = dd_create(path, fsuid, DEFAULT_DUMP_DIR_MODE);
     if (dd)
-- 
1.8.3.1



More information about the Crash-catcher mailing list