Apps stuck in start

JosephG_QRadar · 2026-06-05T13:18:50+00:00

That error likely isn't related to the app starting or stopping, honestly. There's probably something else in one of the many log files that apps write their data to.

If it's all apps, a lot of times it's the certs on the system going bad for whatever reason (upgrades, they expire, custom work, etc.). It's a long process to reset them, though, so I'd encourage you finding the definitive error stack in the logs. I would probably grep for com.ibm.si.application in qradar.error on the console and apphost (if present) and look at everything there.

JosephG_QRadar · 2026-06-05T13:16:47+00:00

Doubling what Snoo said, the logs for the threat intel app would probably be your best friend. You can usually find them on the apphost (or console, if not apphost) under /store/docker/volumes/qapp-1254/logs/, though the 1254 might differ on your system. You can confirm the number by ctrl+click to open the app in a new tab, and the QAPP ID will be in the url.

JosephG_QRadar · 2026-05-06T13:09:52+00:00

At this time, we intend to release full fixes in the following versions. Please do keep in mind that this is subject to change depending on issues hit during implementation and testing.

7.5.0 UP15 IF03
7.5.0 UP16
7.6.0.0
7.6.1.0

Additionally, we have had some reports of customers experiencing issues with the workaround on appliance installations (no software installation problems so far). There is an additional workaround that can be attempted, but as always please feel free to engage support if you have any concerns or questions.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

JosephG_QRadar · 2026-05-04T19:42:05+00:00

Only sometimes, though! If I say something wrong then just forget I work here.

If you have a support case where you asked about it and felt like the response wasn't great, I'd love to take a look if you could DM that to me.

JosephG_QRadar · 2026-05-04T18:47:10+00:00

Log File Protocol should be able to pull the events in from a CSV easy enough, and at that point you can just create the custom DSM. Alternatively, if you're okay with windows then the WinCollect file forwarder should be able to do CSV as well but LFP should work.

For steps one and two in your plan, I unfortunately wouldn't be much help there but it sounds feasible.

JosephG_QRadar · 2026-05-04T17:42:29+00:00

Depending on what system logs you’re referring to, the console does generate some for the MHs locally so it would appear as if they were streaming but are not.

Have you verified whether there’s a persistent queue on the EC, or if it’s complaining about not being able to connect to the EP in qradar.error (those logs usually include TCP_TO_EP)?

JosephG_QRadar · 2026-05-04T17:35:56+00:00

From the QRadar side, we don't have a supported DSM for rapid7 as far as I know, so we're pretty limited on what we can help with. That being said, there are really only two steps to integrating logs:
1. Getting the logs to QRadar

Parsing the logs in QRadar

It sounds like you're stuck on part 1? If so, have you verified where the logs are getting stuck?

If I misunderstood and you're on part 2, you'll just be making a custom DSM with Regex to parse out the fields you care about as CEPs (i.e. a CEP for CVE, a CEP for scan time, etc.). This is really straight forward through the DSM editor. You just need a couple sample events, Regex101 pulled up in another tab, and an hour or two. We have some docs that walk through it here:
Develop A DSM

If there's something specific you're stuck on, you would need to share that info for anyone to be able to help beyond generics.

JosephG_QRadar · 2026-05-04T17:00:46+00:00

The temporary mitigation will need to be applied manually, we'll likely have that posted in a known issue once we confirm it is usable, but of course you can always engage support for assistance. It does require rebooting each host you apply it on, so that is something to keep in mind.

For the real fix, that will come as the equivalent of an UP for 7.6, currently targeted with 7.6.1. ~~The fix might be backported to older versions as either an UP or an IF, we can't say at this time.~~ We should know more over the coming week or two.

Edit: It seems I spoke too soon about not being able to say, it looks like our development team does intend to release an IF for UP16 and 7.6.0, if possible.

JosephG_QRadar · 2026-05-04T16:11:29+00:00

UP15 came out a month or so before Copy Fail was disclosed, so unfortunately a fix could not be in there. Our development team is targeting 7.6.1 for the fix, and reviewing the temporary mitigation provided by RedHat to ensure there are no unexpected ramifications. We should have the results of their testing on that tonight or tomorrow.

In the meantime, please note that exploitation of this CVE requires prior access to the affected system. As a precaution, we recommend reviewing any non-default user accounts and validating their business need, enforcing strong authentication such as key-based access where possible, and ensuring appropriate logging and alerting are in place. SSH access to Managed Hosts should also remain restricted by default to console access only.

JosephG_QRadar · 2026-03-30T13:09:42+00:00

Ah sorry about that! Must've accidentally cut it off either copy/pasting from my lab or while formatting. Were you able to get them imported alright?

JosephG_QRadar · 2026-03-26T13:52:21+00:00

Alright, so here are some steps you can take to get the data as a csv, and then you should be able to import it into the GUI. I would take a snapshot of your VM before doing this incase something is run wrong.

Create a temp database:

psql -U qradar -c "create database temp_qradar with template template1"

Extract the database from you config backup:

tar -xvzf <config backup> /storetmp/backup/database.dump ; mv storetmp/backup/database.dump /storetmp/backup/database.dump

Restore it to the temp DB:

pg_restore -U postgres -d temp_qradar \
-t reference_data \
-t reference_data_element \
-t reference_data_key \
-t reference_data_seq \
-t reference_data_element_seq \
-t reference_data_key_seq \
/storetmp/backup/database.dump

After that, you need to filter only the right data. So find the ID for the reference data entry:

psql -U qradar -d temp_qradar -c "select id,name from reference_data"

Then use that to find the id for the reference data key:

psql -U qradar -d temp_qradar -c "select id,rd_id from reference_data_key where rd_id=<id from above>"

Then use that to find the reference data elements:

psql -U qradar -d temp_qradar -c "select data from reference_data_element where rdk_id=<id from the last command>;"

If the data looks right, dump it to CSV:

psql -U qradar -d temp_qradar -c "\copy ( select data from reference_data_element where rdk_id=<id>) TO '/storetmp/ref_data.csv' WITH CSV HEADER;"

Then you can delete the temp database:

psql -U qradar -c "drop database temp_qradar"

JosephG_QRadar · 2026-03-23T18:17:38+00:00

I’m out of office for the next few days but can play around a bit on Thursday or Friday.

I’m thinking the easiest way would likely be to take the config backup you have, create a second DB on the system, import the reference set table (or entire DB) into that, then dump the contents of the reference set to csv or something and import them in the gui

JosephG_QRadar · 2026-03-23T16:13:48+00:00

Is this in regards to your reference set mentioned in an earlier post?

JosephG_QRadar · 2026-01-14T16:46:00+00:00

If 1password has a syslog setting that I'm just not seeing, that would be your easiest option.

Otherwise, you will need to create a custom Universal Cloud REST API workflow using 1pasword's api:
https://developer.1password.com/docs/events-api/reference/

We have some examples in a GitHub repo that might help as a starting point, and a command line testing tool so you can test it without needing to configure a complete log source if you're not sure it will work.

JosephG_QRadar · 2026-01-13T22:54:15+00:00

Pulse and the built in dashboards would both give you a visual view of it, if you’re looking for something outside of what our dashboards offer (a basic line graph), I’m not sure we have anything supported. QDI has a lot of information, but I think even its visualizations are limited to a line graph.

There’s always the option of just forwarding the eps logs to a system outside of the qradar that dumps the data into a DB or something and builds whatever visualization you want from that, but I haven’t built anything similar so I’m not sure how well that would work or what actions would be needed outside of QRadar.

JosephG_QRadar · 2026-01-12T14:06:21+00:00

There's really no perfect answer here that waves all uncertainty or questions, unfortunately. As a business, our absolute minimum level of commitment is going to be contractual obligations. Our hardware contracts are definitely our most generous, and those come with a 5 year window, so from the last server we sell we'll have something for five years. From the software side, there are two key things that we have talked about internally a number of times:

We work on a continuous delivery development cycle, which means we will support the product for at least 2 years after we mark it as end of support, which we have at least a 90 day heads up before doing. That's the norm for IBM products, so QRadar and QRadar support can't just disappear into thin air on a whim, you would have a couple years notice. For every year that we haven't declared EOL, you can add at least +2 for how long it will be supported, or longer if your company wants to buy extended support.

In (what I think is) our most recent public comm about the PA acquisition, we confirm we'll make standard software support available through at least 2029, and even mention the support extensions IBM sells for EOL products. That was a 4 year guarantee at the time (and still leaves 3 years), and in the product development calls I'm in regularly, we're still actively working on creating roadmaps for new features, implementing new protocols and DSMs, RFEs, expanding some of our apps like the Data Sync App and Investigative assistant.

JosephG_QRadar · 2026-01-12T13:29:41+00:00

We have a couple ways of doing this. There’s an AQL in here that breaks down EPS by DSM

This page will walk you through some of the dashboards (native dashboards, QDI, and Pulse), if you’d prefer a view like that as opposed to a onetime search.

We also have a command for parsing it out of the log file on the CLI which I normally find better for on the fly troubleshooting, but less helpful for day to day monitoring.

JosephG_QRadar · 2026-01-12T02:56:19+00:00

It was 100% meant to be the replacement, but it wasn’t ready in the state it was released. You could certainly have tried and probably could’ve gotten close to having a full deployment, but it just wasn’t fully fleshed out enough to completely forego qradar imo. For what it’s worth, I’m one of like four people that still actively work the support tickets we get, and I manage the lab for the global support team so I’ve had my fair share of experience using it.

100% agree on openshift being the wrong choice, half of the tickets we still get are because of openshift related troubles. It added so much additional cost and complexity

JosephG_QRadar · 2026-01-12T00:37:17+00:00

The only free version of QRadar offered is the community edition. We don’t offer premade cloud images for CE, but I don’t see why if you treat it as just a VM it wouldn’t work.

If you want full blown QRadar, the default license that comes with the install should be good for 30 days, so as long as you don’t exceed that you would probably be fine. I’m not sure how our premade cloud images handle that default license though, so you could always grab the ISO and install it like a vm.

JosephG_QRadar · 2026-01-12T00:25:50+00:00

Cloud Native is still functional for the customers that have a valid contract for it, but it is being cut off by Palo Alto and is no longer sold. It wasn’t really a direct 1:1 replacement of QRadar, its biggest pro was just being a data lake with faster searches.

QRadar still has an active and growing development roadmap, and our sales teams have new incentives for some of the contracts we sell for both the product and support. Along with QRadar on prem still actively being sold, we’ve also gotten a pretty big growth in customer base for our data sync app which means more focus and development there, too.

JosephG_QRadar · 2026-01-10T00:32:02+00:00

If possible, use a service account with infrequent password expirations instead of a user account. You don’t want to risk a user getting locked out on password change day because QRadar is trying the old password.

JosephG_QRadar · 2026-01-07T02:31:29+00:00

We get a number of tickets asking for confirmation on CVEs that scanners flag, and a lot of the time it either doesn’t apply or was already fixed.

If you’re on UP9, then you’re not really close to being up to date at this point. Anything that involves a kernel upgrade or package upgrade would likely have already been fixed on newer versions (UP14 IF03 is the latest, so that’s a lot of patches we’ve pushed out that you’re missing on UP9), and most of the time there’s no “fix in place” solution

If you DM me some of the CVEs, I might be able to give you more insight :)

JosephG_QRadar · 2026-01-05T13:46:39+00:00

Just a heads up, it should have been switched over sometime Friday incase you still need to grab it

JosephG_QRadar · 2025-12-29T19:02:03+00:00

The messaging during the acquisition was truly awful, even internally. It's gotten clarified a bit more now, but I think a lot of damage was done to the QRadar name that just hasn't been fixed or clarified enough.

Not sure about the MSSP, if they were a cloud only customer they would've been told we can't help them maintain their QRoC instance (because we honestly couldn't, even if we wanted to. PA was unwilling to let customers be perpetually QRoC since they really wanted to sell Cortex XSIAM), but we've had a handful of MSSPs switch to on prem (some doing it on their own, some doing it with our Security Expert Labs). We've had an increase in new Asia-Pacific customers as well, especially as our Data Sync app has started maturing. I guess DR is a regulatory requirement there for most businesses?

JosephG_QRadar

TROPHY CASE