配置?

配置文件?

安裝后，ABRT和libreport將各自的配置文件放在系統上的幾個目錄中：

/etc/libreport/

包含 report_event.conf 主配置文件。有關此配置文件的詳細信息，請參閱 事件配置 .

/etc/libreport/events/

保存指定預定義事件的默認設置的文件。

/etc/libreport/events.d/

保留定義事件的配置文件。

/etc/libreport/plugins/

包含參與事件的程序的配置文件。

/etc/abrt/

保存用于修改ABRT服務和程序行為的ABRT特定配置文件。有關某些特定配置文件的詳細信息，請參閱 ABRT特定配置 .

/etc/abrt/plugins/

保留用于覆蓋ABRT服務和程序的默認設置的配置文件。有關某些特定配置文件的更多信息，請參閱 ABRT特定配置 .

配置文件需要用等號分隔的鍵值對。不支持引用值。

ABRT特定配置?

標準ABRT安裝目前提供以下特定于ABRT的配置文件：

/etc/abrt/abrt.conf

允許您修改abrtd服務的行為。

/etc/abrt/abrt-action-save-package-data.conf

允許您修改abrt action save package data程序的行為。

/etc/abrt/plugins/CCpp.conf

允許您修改ABRT的核心鉤子的行為。

中支持以下配置指令 /etc/abrt/abrt.conf 文件：

  • WatchCrashdumpArchiveDir = /var/spool/abrt-upload

如果需要，請啟用此指令 abrtd 自動解包crashdump tarball檔案 (.tar.gz )位于指定目錄中的。在上面的例子中，它是 /var/spool/abrt-upload/ 目錄。無論您在這個指令中指定哪個目錄，您都必須確保它存在并且對于abrtd是可寫的。ABRT守護進程不會自動創建它。如果更改此選項的默認值，請注意，為了確保ABRT的正確功能，此目錄 不能 與為指定的目錄相同 DumpLocation 選擇權。

小心

使用SELinux時不要修改此選項

更改crashdump存檔的位置將導致SELinux拒絕，除非您首先在相應的SELinux規則中反映更改?？吹搅藛?abrt_selinux(8) 有關在SELinux中運行ABRT的更多信息，請參閱手冊頁。

請記住，如果在使用SELinux時啟用此選項，則需要執行以下命令以設置適當的SELinux布爾值，從而允許ABRT寫入 public_content_rw_t 域：：

setsebool -P abrt_anon_write 1

  • MaxCrashReportsSize = size_in_mebibytes

此選項設置ABRT用于存儲所有用戶的所有問題信息的存儲空間量（以兆字節為單位）。默認設置為5000 MiB。一旦達到此處指定的配額，ABRT將繼續捕獲問題，并且為了為新的崩潰轉儲騰出空間，它將刪除最舊和最大的崩潰轉儲。

  • DumpLocation = /var/spool/abrt

此指令指定創建問題數據目錄的位置，以及存儲問題核心轉儲和所有其他問題數據的位置。默認位置設置為 /var/spool/abrt 目錄。無論您在這個指令中指定哪個目錄，您都必須確保它存在并且可以為其寫入 abrtd . 如果更改此選項的默認值，請注意，為了確保ABRT的正確功能，此目錄 不能 與為指定的目錄相同 WatchCrashdumpArchiveDir 選擇權。

小心

使用SELinux時不要修改此選項

更改轉儲位置將導致SELinux拒絕，除非您首先在相應的SELinux規則中反映更改?？吹搅藛?abrt_selinux(8) 有關在SELinux中運行ABRT的更多信息，請參閱手冊頁。

請記住，如果在使用SELinux時啟用此選項，則需要執行以下命令以設置適當的SELinux布爾值，從而允許ABRT寫入 public_content_rw_t 域：：

setsebool -P abrt_anon_write 1

中支持以下配置指令 /etc/abrt/abrt-action-save-package-data.conf 文件：

  • OpenGPGCheck = yes/no

將OpenGPGCheck指令設置為yes（默認設置）將告訴ABRT僅分析和處理由GPG密鑰簽名的包提供的應用程序中的崩潰，GPG密鑰的位置列在/etc/ABRT/GPGu keys文件中。將OpenGPGCheck設置為no將告訴ABRT捕獲所有程序中的崩潰。

  • BlackList = nspluginwrapper, valgrind, strace, [more_packages ]

在黑名單指令之后列出的包和二進制文件中的崩潰將不會由ABRT處理。如果您希望ABRT忽略其他包和二進制文件，請在此處列出它們，并用逗號分隔。

  • ProcessUnpackaged = yes/no

這個指令告訴ABRT是否處理不屬于任何包的可執行文件中的崩潰。默認設置為 no .

  • BlackListedPaths = /usr/share/doc/*, */example*

ABRT將忽略這些路徑中可執行文件的崩潰。

中支持以下配置指令 /etc/abrt/plugins/CCpp.conf 文件：

  • MakeCompatCore = yes/no

這個指令指定ABRT的core-catching鉤子是否應該創建一個core文件，如果ABRT不被安裝的話也可以這樣做。核心文件通常在崩潰程序的當前目錄中創建，但前提是 ulimit -c 設置允許。指令設置為 yes 默認情況下。

  • SaveBinaryImage = yes/no

此指令指定ABRT的core catching hook是否應將二進制圖像保存到core轉儲。它在調試已刪除的二進制文件中發生的崩潰時非常有用。默認設置為 no .

配置ABRT以檢測內核死機?

ABRT可以使用 abrt-vmcore 服務，由 abrt-addon-vmcore 包裹。該服務在系統引導時自動啟動，并在中搜索核心轉儲文件 /var/crash/ 目錄。如果找到核心轉儲文件， abrt-vmcore 在中創建問題數據目錄 /var/spool/abrt/ 目錄并將核心轉儲文件復制到新創建的問題數據目錄。之后 /var/crash/ 目錄，服務將停止，直到下一次系統啟動。

要配置ABRT以檢測內核死機，請執行以下步驟：

  1. 確保 kdump 系統上已啟用服務。特別是，為 kdump 內核必須正確設置。您可以使用 system-config-kdump 圖形化工具，或通過指定 crashkernel 中的內核選項列表中的參數 /etc/grub2.conf 配置文件。

  2. 安裝并啟用 abrt-addon-vmcore 使用yum的包：

    yum install abrt-addon-vmcore
systemctl enable abrt-vmcore

    這將安裝 abrt-vmcore 提供相應的支持和配置文件。

  3. 重新啟動系統以使更改生效。

除非ABRT的配置不同，否則任何檢測到的內核死機的問題數據現在都存儲在 /var/spool/abrt/ ABRT可以像其他檢測到的內核oop一樣進一步處理。

桌面會話自動報告?

已啟用自動報告行為?

啟用桌面會話自動報告后，ABRT會自動上傳 μ報告 一旦發現用戶的問題。如果abrt服務器 (faf )知道報告的問題，服務器提供有關問題的附加信息，ABRT通過通知氣泡通知用戶檢測到的問題是已知的。通知氣泡提供了顯示問題的網頁、在ABRT GUI中打開問題或忽略問題的功能。如果問題未知，ABRT會顯示一個通知氣泡，用戶可以像往常一樣開始報告過程，也可以忽略問題。

已禁用自動報告行為?

禁用自動報告后，ABRT上傳 μ報告 對于單擊后檢測到的問題 “報告”按鈕 在通知氣泡中。如果abrt服務器不知道檢測到的問題，abrt將繼續執行報告向導。

事件雖然ABRT通知其他用戶的問題，但它從不自動上傳這些問題的uReports。另一個用戶的問題總是以處理禁用自動報告的問題的方式來處理，這在第2段中描述。

如果網絡不可用，ABRT將推遲通知檢測到的問題，直到網絡再次可用。推遲的問題列表將僅為單用戶桌面會話保留。如果在桌面會話的生存期內網絡不可用，則延遲的問題可能根本不會得到通知。

上傳uReports需要一個可寫的問題目錄，為了使報告更加自動化，減少混亂，ABRT可能會將問題目錄從系統轉儲位置（通常是 /var/spool/abrt/ 目錄）到 $HOME/.cache/abrt/spool/ 目錄，而不請求用戶這樣做的權限。但是，只有當用戶沒有寫入系統轉儲位置的權限時，ABRT才會移動目錄。

啟用桌面會話自動報告?

桌面自動報告可以通過多種方式啟用。最簡單的方法就是回答 Yes 在對話中要求 啟用自動提交的崩潰報告 點擊后出現 “報告”按鈕 在通知氣泡中。第二種方法是打開 Automatic Bug Reporting Tool 應用程序，打開應用程序菜單并單擊以下選項：

ABRT Configuration

并啟用選項：

Automatically send uReport

最后但最不方便的方法是手動編輯文件：

$HOME/.config/abrt/settings/abrt-applet.conf

并添加以下行：

AutoreportingEnabled = yes

系統自動報告?

ABRT可以配置為提交 μ報告 對于abrt服務器的每個檢測到的問題 (faf )一旦他們被發現。服務器提供有關提交的問題的以下信息：

  • 現有錯誤報告的URL（如果有）（Bugzilla錯誤）

  • 簡短描述文本

可以通過發出以下命令來啟用系統自動報告：

abrt-auto-reporting enabled

或通過 Augeas:

augtool set /files/etc/abrt/abrt.conf/AutoreportingEnabled yes

或者在 /etc/abrt/abrt.conf 配置文件：

AutoreportingEnabled yes

啟用系統自動報告時，也會啟用桌面會話自動報告。

縮短的報告?

在自動報告事件完成后報告中斷的情況下啟用縮短的GUI報告。這意味著報告是在用戶單擊時完成的 “報告”按鈕 在通知氣泡上。在那之后，ABRT上傳了一個 uReport 描述已處理的問題，顯示一個通知氣泡，說明問題已報告并完成。

縮短的報告對從GUI開始的報告過程沒有影響，因為我們希望高級用戶能夠輕松地將完整的bug報告提交到Bugzilla中。我們相信所有關心檢測到的崩潰和打開的用戶 自動錯誤報告工具 應用程序可以看到他們是高級用戶。

Default value: Yes but only if application is running in GNOME desktop

要打開縮短的報告：

Automatic Bug Reporting Tool

轉到應用程序菜單并單擊：

ABRT Configuration

并啟用選項：

Shortened Reporting

或手動編輯文件：

$HOME/.config/abrt/settings/abrt-applet.conf

再加上一行：

ShortenedReporting = yes

自動敏感數據過濾?

ABRT保存著 敏感詞 在里面 /etc/libreport/forbidden_words.conf 因此，為了更改所有用戶的列表，系統管理員必須編輯此文件。中還有每個用戶的列表 $HOME/.config/abrt/settings/forbidden_words.conf （默認情況下不存在，因此用戶必須創建它）。文件的格式是每行一個字。通配符是 NOT 支持。

禁詞有時是其他詞的一部分，通常不被視為敏感信息。提供此類假陽性敏感詞供用戶審核，使得從報表中刪除敏感數據的過程變得困難，可能會遺漏真正的敏感數據。因此，ABRT有另一個從未被視為敏感信息的單詞列表。該列表包含以下常用詞 敏感詞 . 全球 忽略的詞 保存在文件中：

/etc/libreport/ignored_words.conf

以及每個用戶列表：

$HOME/.config/abrt/settings/ignored_words.conf

事件配置?

每個事件由相應配置文件中的一個規則結構定義。配置文件通常存儲在 /etc/libreport/events.d/ 目錄。這些配置文件由主配置文件加載， /etc/libreport/report_event.conf .

這個 /etc/libreport/report_event.conf 文件由include指令和規則組成。規則通常存儲在 /etc/libreport/events.d/ 目錄。

如果您想修改這個文件，請注意它尊重shell元字符 (* ， $ ， ? ，并解釋相對于其位置的相對路徑。

每個規則都以一行非空格的前導字符開頭，所有以空格字符或制表符開頭的后續行都被視為該規則的一部分。每個規則由兩部分組成，一個條件部分和一個程序部分。條件部分包含以下形式之一的條件：

VAR=VAL,

VAR!=VAL

VAL~=REGEX

在哪里？

  • VAR 要么是 EVENT 問題數據目錄元素的關鍵字或名稱，例如 executable ， package ， hostname ，..?？匆?ABRT收集的元素 想要更多。

  • VAL 是事件或問題數據元素的名稱，以及

  • REGEX 是正則表達式。

程序部分由程序名和shell可解釋代碼組成。如果條件部分中的所有條件都有效，則程序部分將在shell中運行。下面是一個事件示例：

EVENT=post-create date > /tmp/dt
        echo $HOSTNAME `uname -r`

此事件將覆蓋 /tmp/dt 文件，并在標準輸出上打印機器的主機名及其內核版本。

下面是一個更復雜事件的示例，它實際上是預定義事件之一。它保存來自 ~/.xsession-errors 向問題報告提交 abrt-ccpp 服務已用于處理該問題，崩潰的應用程序已加載任何 X11 崩潰時的庫：

EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
        test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
        test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
        executable=`cat executable` &&
        base_executable=${executable##*/} &&
        grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
        echo "Element 'xsession_errors' saved"

可能發生的事件并不是固定的。系統管理員可以根據需要添加事件。目前，標準ABRT和libreport安裝提供了以下事件名稱：

post-create

此事件由自動運行 abrtd 在新創建的問題數據目錄上。當 post-create 事件已運行， abrtd 檢查 UUID 新問題數據的標識符與 UUID 任何已經存在的問題目錄。如果存在這樣的問題目錄，則刪除新的問題數據?？吹搅藛?重復數據消除 有關重復處理的詳細信息。

analyze_name_suffix

在哪里？ name_suffix 是事件名稱的可調整部分。此事件用于處理收集的數據。例如 analyze_LocalGDB 運行GNU調試器 (GDB )應用程序的核心轉儲上的實用程序，并生成崩潰的回溯。

collect_name_suffix

其中nameu后綴是事件名稱的可調整部分。此事件用于收集有關問題的其他信息。

report_name_suffix

其中nameu后綴是事件名稱的可調整部分。此事件用于報告問題。

有關事件的附加信息（如事件的描述、名稱和可以作為環境變量傳遞給它們的參數類型以及其他屬性）存儲在 /etc/libreport/events/event_name.xml 文件夾。GUI和CLI都使用這些文件，以使用戶界面更友好。除非要修改標準安裝，否則不要編輯這些文件。

標準ABRT安裝支持的事件?

標準ABRT安裝目前提供了許多默認的分析、收集和報告事件。其中一些事件可以使用 gnome-abrt GUI應用程序。以下是ABRT標準安裝提供的默認分析、收集和報告事件列表：

analyze_VMcore -分析VM核心

跑 GDB （GNU調試器）處理應用程序的問題數據，并生成內核的回溯。定義見 /etc/libreport/events.d/vmcore_event.conf 配置文件。

analyze_LocalGDB -本地GNU調試器

跑 GDB （GNU調試器）并生成崩潰的回溯。定義見 /etc/libreport/events.d/ccpp_event.conf 配置文件。

analyze_RetraceServer -遠程生成回溯

上載核心轉儲到 回溯服務器 用于遠程回溯生成。定義見 /etc/libreport/events.d/ccpp_retrace_event.conf 配置文件。

analyze_xsession_errors -Collect.xsession錯誤

從中保存相關行 ~/.xsession-errors 提交到問題報告。定義見 /etc/libreport/events.d/ccpp_event.conf 配置文件。

report_Logger -記錄器

創建問題報告并將其保存到指定的本地文件。定義見 /etc/libreport/events.d/print_event.conf 配置文件。

report_Mailx -郵件

通過發送問題報告 mailx 指定電子郵件地址的實用程序。i它在 /etc/libreport/events.d/mailx_event.conf 配置文件。

report_Uploader -報表上載程序

上傳一個tarball (.tar.gz )使用FTP或SCP協議將有問題的數據存檔到選定的目標。定義見 /etc/libreport/events.d/uploader_event.conf 配置文件。

report_uReport - μ報告 上傳器

上載 μ報告 到 faf 服務器。

report_EmergencyAnalysis — Upload problem directory to faf

將tarball上傳到 faf 服務器進行進一步分析。用于標準報告方法失敗時報告失敗的情況。定義見 /etc/libreport/events.d/emergencyanalysis_event.conf 配置文件。

工作流配置?

report gtk和report cli是報告應用程序崩潰和abrtd守護程序捕獲的其他問題的工具，或者由使用libreport的其他程序創建的工具。為此，他們調用所謂的 EVENTs . 有兩種方法可以指定要執行的事件?？梢詫⑵渲付槊钚袇担ㄟx項 -e EVENT )要報告gtk/report cli，也可以在 工作流文件 位于 /usr/share/libreport/workflows/ . 中定義了將使用哪些工作流文件 工作流配置文件 在里面 /etc/libreport/workflows.d/ .

工作流中使用的每個事件都必須有相應的XML描述文件 /usr/share/libreport/events/ . 這些文件的格式在 report_event.conf(5) 人頁。

工作流文件?

中的每個XML文件 /usr/share/libreport/workflows/ 必須符合以下DTD：

<!ELEMENT workflow    (name+,description+,priority?,events*)>
<!ELEMENT name        (#PCDATA)>
<!ATTLIST name         xml:lang CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!ATTLIST description  xml:lang CDATA #IMPLIED>
<!ELEMENT priority =  (#PCDATA)>
<!ELEMENT events =    (event)+>
<!ELEMENT event =     (#PCDATA)>
name

工作流的面向用戶的名稱。

description

工作流的面向用戶的描述。

priority

工作流的優先級。數字越大，用戶界面中的位置越明顯。如果沒有提供，則使用0。該值是有符號整數。

events

工作流中執行的事件列表。

event

要執行的事件的名稱。也可以使用通配符 (* )在名稱的末尾選擇多個具有公共前綴的事件。如果某個事件不適用于問題數據或未定義，則流程將繼續處理下一個同級事件。

工作流配置文件?

配置文件包含在給定條件下執行哪些工作流的規則。每一條規則都以一行非空格的前導字符開始。每個規則由兩部分組成：工作流名稱和以下格式的可選條件：

EVENT=<WORKFLOW_NAME> [CONDITION]

后一部分由以下形式之一的條件的空格分隔列表組成：

VAR=VAL,

VAR!=VAL, or

VAL~=REGEX

在哪里？

  • VAR 是有問題的數據目錄元素（例如 executable ， package ， hostname 等等——見 ABRT收集的元素 更多信息），

  • VAL 是有問題的數據元素，并且

  • REGEX 是正則表達式。

裝載程序?

report gtk或report cli查看 /etc/libreport/workflows.d/ 目錄并遍歷每個配置文件中的所有規則，檢查是否滿足每個規則的指定條件。

如果只有一個工作流的條件得到滿足，則從中加載其規范 /usr/share/libreport/workflows/<WORKFLOW_NAME>.xml 它的每一個事件都被執行。如果有多個工作流符合這些條件，則用戶可以選擇執行哪一個工作流。

工作流示例?

為了說明這個過程，我們提供了一個為mailx創建工作流的示例，即POSIX郵件實用程序。第一步是在中創建工作流配置文件 /etc/libreport/workflows.d/ 內容如下：

EVENT=workflow_mailx analyzer=CCpp

這指示記者尋找一個 workflow_mailx.xml 文件在 /usr/share/libreport/workflow/ 每當分析器是CCpp（崩潰分析器為C和C++）。

在第二步中，我們創建所需的工作流文件， workflow_mailx.xml ，內容如下：

<?xml version="1.0" encoding="UTF-8"?>
<workflow>
    <name>Send the problem data via mailx</name>
    <description>Analyze the problem locally and send information via mailx</description>
    <priority>-99</priority>

    <events>
        <event>report_Mailx</event>
    </events>
</workflow>

它指示報告程序（report gtk或report cli）運行事件 report_Mailx 作為此工作流的唯一步驟。

第三步是創建事件配置文件 report_Mailx.xml 對應于 report_Mailx 來自 workflow_mailx.xml 上述配置文件。該文件的內容如下：

<?xml version="1.0" encoding="UTF-8" ?>
<event>
    <name>Mailx</name>
    <description>Send via email</description>

    <requires-items></requires-items>
    <exclude-items-by-default>count,event_log,reported_to,coredump,vmcore</exclude-items-by-default>
    <exclude-items-always></exclude-items-always>
    <exclude-binary-items>no</exclude-binary-items>
    <include-items-by-default></include-items-by-default>
    <minimal-rating>0</minimal-rating>
    <gui-review-elements>yes</gui-review-elements>

    <options>
        <option type="text" name="Mailx_Subject">
            <label>Subject</label>
            <allow-empty>no</allow-empty>
            <description>Message subject</description>
            <default-value>[abrt] detected a crash</default-value>
        </option>
        <option type="text" name="Mailx_EmailFrom">
            <label>Sender</label>
            <allow-empty>no</allow-empty>
            <description>Sender's email</description>
        </option>
        <option type="text" name="Mailx_EmailTo">
            <label>Recipient</label>
            <allow-empty>no</allow-empty>
            <description>Recipient's email</description>
        </option>
        <option type="bool" name="Mailx_SendBinaryData">
            <label>Send Binary Data</label>
            <description>Send binary files like coredump</description>
            <default-value>no</default-value>
        </option>
    </options>
</event>

調整插件配置?

ABRT向不同的目的地報告問題。幾乎每個報告目的地都需要一些配置。例如，Bugzilla需要登錄名、密碼和指向Bugzilla服務實例的URL。一些配置細節可以有默認值（例如Bugzilla的URL），但其他配置細節沒有合理的默認值（例如login）。

ABRT允許用戶通過文本配置文件提供配置，例如 /etc/libreport/events/report_Bugzilla.conf . 所有文本配置文件都由鍵/值對組成。

事件文本配置可以存儲在以下文件之一中：

  • /etc/libreport/events/somename.conf -對于系統范圍配置

  • $XDG_CACHE_HOME/abrt/events/somename.conf -用于用戶范圍配置 [XDG]

這些文件是在問題目錄上運行事件所必需的最少文件。ABRT GUI和CLI工具將從這些文件中讀取配置數據，并將其傳遞給它們運行的事件。

但是，為了使GUI界面更加用戶友好，可以在同一目錄中的XML文件中提供附加信息，例如 report_Bugzilla.xml . 這些文件可以包含以下信息：

  • 用戶友好的事件名稱和描述( 布奇拉 ， 向Bugzilla bug tracker報告 ）

  • 問題目錄中事件成功所需的項的列表。

  • 默認和強制選擇要發送或不發送的項目。

  • GUI是否應提示進行數據審查。

  • 存在哪些配置選項、它們的類型（字符串、布爾值等）、默認值、提示字符串等。這使GUI能夠構建適當的配置對話框。

ABRT的GUI將配置選項保存在 gnome-keyring 或 ksecrets 并將它們傳遞給事件，覆蓋文本配置文件中的數據。

通過執行以下命令，可以獲取特定事件的一組密鑰：

xmllint --xpath "/event/options/option/@name" $EVENT_XML_FILE | sed 's/name="\([^ ]*\)"/\1\n/g'

事件XML定義文件和事件配置文件之間的映射：

事件名稱

定義文件

配置文件

布奇拉

report_Bugzilla.xml

report_Bugzilla.conf

記錄器

report_Logger.xml

report_Logger.conf

C/C++碰撞分析

analyze_CCpp.xml

analyze_CCpp.conf

本地GNU調試器

analyze_LocalGDB.xml

analyze_LocalGDB.conf

回溯服務器

analyze_RetraceServer.xml

analyze_RetraceServer.conf

分析VM核心

analyze_VMcore.xml

analyze_VMcore.conf

收集GConf配置

collect_GConf.xml

collect_GConf.conf

收集系統范圍的vim配置文件

collect_vimrc_system.xml

collect_vimrc_system.conf

收集vim配置文件

collect_vimrc_user.xml

collect_vimrc_user.conf

Collect.xsession錯誤

collect_xsession_errors.xml

collect_xsession_errors.conf

事后報告

post_report.xml

post_report.conf

Kerneloops.org

report_Kerneloops.xml

report_Kerneloops.conf

郵件

report_Mailx.xml

report_Mailx.conf

報表上載程序

report_Uploader.xml

report_Uploader.conf

uReport公司

report_uReport.xml

report_uReport.conf

默認情況下，如果沒有配置任何強制選項，ABRT會抱怨缺少配置。強制選項是未標記為“允許空”的選項。運行以下命令以獲取強制選項列表：

xmllint --xpath "/event/options/option[allow-empty!='yes']/@name" $EVENT_XML_FILE \
        | sed 's/name="\([^ ]*\)"/\1\n/g'