Add tool to display emergency log message full-sceen on boot failure. - #28077

I want to start with a function that fetches the oldest message in the journal and displays it to the console.
Currently I set PRIORITY to 5(notice) to see if I'll get any messages. I'm currently not getting any.

@bluca
Following Poettering's guidance, I created this bsod tool.
Currently it just tries to fetch the oldest message from the current boot with a log level of "emergency", and prints it to a console.

Subsequently, I have to modify it to take over the entire screen, turn it blue, and display the QR code.

Howevever, I am currently not getting an output at all, even when i change the PRIORITY to numbers other than 0.
What am I doing wrong sir?

Thank you.

I read that the APIs return errno-style errors on failure. Kindly review my choice of error types sir.

I made some of the requested changes.

I still have the SD_ID128_FORMAT_STR() and SD_ID128_FORMAT_VAL() outstanding. Still need to study them more.
And of course VT.

But I don't want to miss the chance of getting a review in case you view the PR, so I decided to push some first.

I looked up the format string and format value macros sir, and I've now used them in the patch.

So it's VT I need to look up now.

perhaps I have too many log messages?

Now, we need to register this service as a varlink API client that subscribes to journald to get notified when messages with log_level "emerg" are processed, so it can fetch the message and display it.

I've been stuck on implementing this subscribe feature in journald. Please could I get some high level guidance - not so high level, or some resources or docs recommendations? Thank you sirs.

@bluca, Have you been in touch with Poettering though? I looked the the PRs -open and closed ones, It looks like he hasn't been with us for over a week. Did he go on vacation without inviting us or at least share photos?

I'm sort of bothered I've been on just one of the 4 points from his last guidance for over 2 weeks.
If I'm unbale to complete them by Aug 25, would you guys still spare some more time to guide beyond Aug 25?

Thank you.

there's a merge conflict, needs a rebase

okay sir.
I'll be home in 30minutes

Looks like I'm hearing you say "tty1's fd should be closed before we assign fd to hold the descriptor of another tty" doesn't _cleanup_close_ handle such scenarios?

doesn't _cleanup_close_ handle such scenarios

The _cleanup_* macros (aka __attribute__((__cleanup__(*)))) only activate when the variable goes out of scope. In other words, when the block that the variable is declared in ends.

{
    _cleanup_close_ void* int fd = -EBADF;
    fd = open(...); /* fd = 4 */
    fd = open(...); /* fd = 5 */
    /* we're about to leave the block... compiler adds: */ close(fd)
}

Notice that in the above code, close(fd) is called when fd=5, but fd 4 never gets closed. Thus, a leak.

What you want to do is something like this:

{
    _cleanup_close_ void* int fd = -EBADF;
    fd = open(...); /* fd = 4 */
    close(fd) /* we close fd 4, since we're about to replace it with fd 5, which will get auto-closed when we leave the block */
    fd = open(...); /* fd = 5 */
    /* we're about to leave the block... compiler adds: */ close(fd)
}

That is what close_and_replace does

Wow... awesome.
Thanks @AdrianVovk,
You explain like you're a college professor.
Are you?

Thanks again.

Let me fix.

hey @AdrianVovk, I found you do actually have some business in college, although not actually as a professor.
I'd like to stay in touch if your schedule permits. I found a twitter profile which you don't seem to have used in a while. I followed you anyways.

Please let me know if your schedule has room for some sort of extra friend.
Thank you.

Thank you @yuwata for the detailed review.
I'm very grateful!

@yuwata, I have made all the requested changes.

Thank you so much @yuwata for the very detailed review.
Let me fix.

@yuwata, I made all the requested changes.
Sorry I took long.

needs a rebase on main due to conflicts

needs a rebase on main due to conflicts

Okay sir.
I'll fix in about an hour.

When you rebase and push, please also amend the commit message, as this is not about PID1, it's a different tool

When you rebase and push, please also amend the commit message, as this is not about PID1, it's a different tool

Certainly sir.

LGTM. Let's go in this form at least now. Future tasks are

• merge two qrcode logic more,
• add tests for bsod.service.

Alright sir.
I hope "future" turns out to be next week or next month.