[SOLVED]Where is gnupg/[SOLVED] bt-adapter core dump

I was just trying to setup the keyserver and auto retrieving keys in gpg.conf and dirmngr.conf then I realised gnupg isn’t in my home directory like it normally is after a fresh Arch install. I tried to install gnupg and I got the message saying reinstalling so, lol it is somewhere. I checked /etc couldn’t find it.

I had a little glance in the forum search but couldn’t find anyone asking this basic question. I’m sure I’m missing something that always seems to be the case.

I think it’s a hidden folder in home?

It should be in ~/.gnupg. Depending on how you are looking for it make sure that you are viewing hidden directories.

I checked with ls -la, before I posted. it isn’t there

after .gnome is .gtkrc then .icons

If it isn’t there, just run the command gpg and it will be created.

and then cancel with ctrl c?

Yes.

yep got it thanks.

After I posted this whilst I was waiting I ran the journalctl -p err -e and I’ve got loads of core dumps.

very little experience but from what I’ve read a core dump is when something crashes and a file gets sent to record it or something. but there’s no information just loads of numbers and stuff. When I tried to google it I can’t find anything. okay well no info that I understand

Yeah, it is when something crashes. journalctl should tell you what is crashing.

It is a binary file. You can’t easily read it.

What does the full error in journalctl say?

oh snap I was looking to try to see what had crashed but I didn’t notice systemd. lol doesn’t sound good to me.

sudo journalctl -p err -e


[muj@Blackstone ~]$ sudo journalctl -p err -e
[sudo] password for muj: 
                                                   #1  0x00007f7abb7a8659 n/a (libgobject-2.0.so.0 + 0x13659)
                                                   #2  0x00007f7abb7b613c n/a (libgobject-2.0.so.0 + 0x2113c)
                                                   #3  0x00007f7abb7b713d g_object_new_with_properties (libgobject-2.0.so.0 + 0x2213d)
                                                   #4  0x00007f7abb7b7c42 g_object_new (libgobject-2.0.so.0 + 0x22c42)
                                                   #5  0x00007f7abb88c007 g_task_new (libgio-2.0.so.0 + 0x9f007)
                                                   #6  0x00007f7abb8f7d44 n/a (libgio-2.0.so.0 + 0x10ad44)
                                                   #7  0x00007f7abb8f8016 n/a (libgio-2.0.so.0 + 0x10b016)
                                                   #8  0x00007f7abb8f8563 n/a (libgio-2.0.so.0 + 0x10b563)
                                                   #9  0x00007f7abb88e0f4 n/a (libgio-2.0.so.0 + 0xa10f4)
                                                   #10 0x00007f7abb88e129 n/a (libgio-2.0.so.0 + 0xa1129)
                                                   #11 0x00007f7abb9fb914 g_main_context_dispatch (libglib-2.0.so.0 + 0x52914)
                                                   #12 0x00007f7abba4f7d1 n/a (libglib-2.0.so.0 + 0xa67d1)
                                                   #13 0x00007f7abb9fae63 g_main_loop_run (libglib-2.0.so.0 + 0x51e63)
                                                   #14 0x00007f7abb8eefe8 n/a (libgio-2.0.so.0 + 0x101fe8)
                                                   #15 0x00007f7abba28ce1 n/a (libglib-2.0.so.0 + 0x7fce1)
                                                   #16 0x00007f7abb5413e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #17 0x00007f7abb6cc293 __clone (libc.so.6 + 0x100293)
                                                   
                                                   Stack trace of thread 3081:
                                                   #0  0x00007f7abb6c146f __poll (libc.so.6 + 0xf546f)
                                                   #1  0x00007f7abba4f75f n/a (libglib-2.0.so.0 + 0xa675f)
                                                   #2  0x00007f7abb9fa121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
                                                   #3  0x00007f7abb9fa172 n/a (libglib-2.0.so.0 + 0x51172)
                                                   #4  0x00007f7abba28ce1 n/a (libglib-2.0.so.0 + 0x7fce1)
                                                   #5  0x00007f7abb5413e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #6  0x00007f7abb6cc293 __clone (libc.so.6 + 0x100293)
Nov 03 18:57:14 Blackstone systemd-coredump[3091]: Process 3087 (bt-adapter) of user 1000 dumped core.
                                                   
                                                   Stack trace of thread 3087:
                                                   #0  0x00007fc757f50615 raise (libc.so.6 + 0x3d615)
                                                   #1  0x00007fc757f39862 abort (libc.so.6 + 0x26862)
                                                   #2  0x00007fc75830c084 n/a (libglib-2.0.so.0 + 0x1c084)
                                                   #3  0x00007fc7583668cd g_assertion_message_expr (libglib-2.0.so.0 + 0x768cd)
                                                   #4  0x000055f90e6156ca n/a (bt-adapter + 0x66ca)
                                                   #5  0x000055f90e613173 n/a (bt-adapter + 0x4173)
                                                   #6  0x00007fc757f3b152 __libc_start_main (libc.so.6 + 0x28152)
                                                   #7  0x000055f90e613c3e n/a (bt-adapter + 0x4c3e)
                                                   
                                                   Stack trace of thread 3089:
                                                   #0  0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
                                                   #1  0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
                                                   #2  0x00007fc758341e63 g_main_loop_run (libglib-2.0.so.0 + 0x51e63)
                                                   #3  0x00007fc758235fe8 n/a (libgio-2.0.so.0 + 0x101fe8)
                                                   #4  0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
                                                   #5  0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #6  0x00007fc758013293 __clone (libc.so.6 + 0x100293)
                                                   
                                                   Stack trace of thread 3088:
                                                   #0  0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
                                                   #1  0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
                                                   #2  0x00007fc758341121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
                                                   #3  0x00007fc758341172 n/a (libglib-2.0.so.0 + 0x51172)
                                                   #4  0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
                                                   #5  0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #6  0x00007fc758013293 __clone (libc.so.6 + 0x100293)
lines 85-139/139 (END)

I have to get used to seeing and reading this type of content

In this case, it is the process bt-adapter which is the issue.

Potentially a misbehaving bt device.

That doesn’t mean systemd is crashing.

is that bluetooth or bt internet, sorry what is bt

bluetooth

how’d you know its not libglib-2.0.so.0 + 0x1c084 for example

in the future do I try to individually google those lines?

That is a stacktrace. It applies to the thing above it.

This is the line that tells you what is crashing:

The stacktrace is the calls that application was making when it crashed.

deep breath. Just so much info when I have none. So the thing which is crashing will have some sort of recognisable name (if I look very closely)

You want to find the lines that says

Process xxxx (process-name) of user yyyy dumped core.

In this case, the things between the parens is the name of the process.

The indented part is the stack trace.

1 min.

okay so when there’s a core dump, something has crashed so I need to find out what crashed. The process is the thing that crashed. so I’ll find the line and google that process right?

I don’t even have bluetooth running. I turned it off. the service is disabled

what is systemctl poweroff from terminal I normally do just poweroff


[muj@Blackstone ~]$ sudo journalctl -p err -e
[sudo] password for muj: 
                                                   #0  0x00007fc757f50615 raise (libc.so.6 + 0x3d615)
                                                   #1  0x00007fc757f39862 abort (libc.so.6 + 0x26862)
                                                   #2  0x00007fc75830c084 n/a (libglib-2.0.so.0 + 0x1c084)
                                                   #3  0x00007fc7583668cd g_assertion_message_expr (libglib-2.0.so.0 + 0x768cd)
                                                   #4  0x000055f90e6156ca n/a (bt-adapter + 0x66ca)
                                                   #5  0x000055f90e613173 n/a (bt-adapter + 0x4173)
                                                   #6  0x00007fc757f3b152 __libc_start_main (libc.so.6 + 0x28152)
                                                   #7  0x000055f90e613c3e n/a (bt-adapter + 0x4c3e)
                                                   
                                                   Stack trace of thread 3089:
                                                   #0  0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
                                                   #1  0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
                                                   #2  0x00007fc758341e63 g_main_loop_run (libglib-2.0.so.0 + 0x51e63)
                                                   #3  0x00007fc758235fe8 n/a (libgio-2.0.so.0 + 0x101fe8)
                                                   #4  0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
                                                   #5  0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #6  0x00007fc758013293 __clone (libc.so.6 + 0x100293)
                                                   
                                                   Stack trace of thread 3088:
                                                   #0  0x00007fc75800846f __poll (libc.so.6 + 0xf546f)
                                                   #1  0x00007fc75839675f n/a (libglib-2.0.so.0 + 0xa675f)
                                                   #2  0x00007fc758341121 g_main_context_iteration (libglib-2.0.so.0 + 0x51121)
                                                   #3  0x00007fc758341172 n/a (libglib-2.0.so.0 + 0x51172)
                                                   #4  0x00007fc75836fce1 n/a (libglib-2.0.so.0 + 0x7fce1)
                                                   #5  0x00007fc757e883e9 start_thread (libpthread.so.0 + 0x93e9)
                                                   #6  0x00007fc758013293 __clone (libc.so.6 + 0x100293)
-- Reboot --
Nov 03 19:55:03 Blackstone kernel: i801_smbus 0000:00:1f.4: Transaction timeout
Nov 03 19:55:03 Blackstone kernel: i801_smbus 0000:00:1f.4: Failed terminating the transaction
Nov 03 19:55:03 Blackstone kernel: i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
Nov 03 19:55:08 Blackstone kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x0033903c
Nov 03 19:55:13 Blackstone pulseaudio[1220]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit: Unit dbus-org.bluez.service not found.

that means the issue is still there and not sorted right? or is the bt-adapter lines from before the reboot I just did.

Sure. That seems reasonable.

If you have bluetooth disabled but bt-adapter is still running, that is probably why it is crashing :slight_smile:

The long answer:
systemctl is a command line interface to systemd. In this case, systemctl poweroff tells systemd to poweroff the system.

The command poweroff is part of the package systemd-compat which provides backwards compatible commands for systemd. This is to keep compatibility with existing scripts and support people who don’t want to learn new commands.

If you look, poweroff is probably a symbolic link to systemctl

The short answer:
They are the same.

It is from before the reboot.

journalctl -b -p err will only show errors since the last reboot.