Logs: liberachat/#xmonad
| 2025-10-02 14:44:11 | <geekosaur> | right, that;'s the other side of it: processes are killed not when xmonad exits but when a new xmonad is spawned (usually what you get woth mod-q) |
| 2025-10-02 14:44:16 | <geekosaur> | welp |
| 2025-10-02 14:44:36 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 2025-10-02 14:44:37 | <liskin> | But the X server going away will be noticed by xmobar and it will exit on its own |
| 2025-10-02 14:45:20 | <Enrico63> | Sorry, I dropped a sec. Anyway, log out= io exitSuccess |
| 2025-10-02 14:45:24 | <liskin> | What happens to processes spawned by it? Similar. If there's a pipe they'll notice and should exit themselves. If there's not a pipe then probably nothing |
| 2025-10-02 14:46:13 | <liskin> | Enrico63: that might or might not mean the X server terminates (I run xmonad in a loop so even if it crashes the X stays alive, for example ) |
| 2025-10-02 14:46:58 | <Enrico63> | With that command, I'm back to the VT, so X is gone |
| 2025-10-02 14:47:50 | <geekosaur> | then any processes that weren't terminated will see EOF on their X server sockets and will exit |
| 2025-10-02 14:48:09 | <geekosaur> | (XNextEvent() will fail) |
| 2025-10-02 14:48:34 | <Enrico63> | geekosaur, I could use that killAllStatusBars to see if I can reproduce the behavior I see without exiting XMobar and X. |
| 2025-10-02 14:50:04 | <Enrico63> | Ok, let me give more context. I have xmobar run as I explained above. Then I have a plugin in xmobar that registers a notification server (that I've written). When I exit xmonad as explained, and then log back in, I can register the notificatin server again because the name is still busy, revealing something was left running. |
| 2025-10-02 14:51:52 | <Enrico63> | If take xmobar out of the equation and run the notificationi server in a terminal, I can reproduce this zombie behavior by running `kill -KILL $(pidof the-notif-server-running-in-the-other-terminal)`. I'll basically see that the notification server keeps printing notifications in the terminal, even if I killed it. If I try to register a new one, it |
| 2025-10-02 14:51:52 | <Enrico63> | fails because the name is busy, just like in the case described above. Luckily, in this case, closing the terminal cleans things up. |
| 2025-10-02 14:52:27 | <Enrico63> | I CAN'T register, I meant. |
| 2025-10-02 14:53:01 | <Enrico63> | (sorry for caps) |
| 2025-10-02 14:58:50 | <Enrico63> | Killing xmobar via killAllStatusBars still leaves things in a good state, in the sense that the notification server is unregistered (if I'm using the right terminology) |
| 2025-10-02 15:18:39 | × | mc47 quits (~yecinem@xmonad/TheMC47) (Ping timeout: 250 seconds) |
| 2025-10-02 15:19:34 | <geekosaur> | that makes me think however your xmobar plugin is managing the notification server is wrong, since xmobar should be exiting and hopefully running some plugin deinit first (it may not exit until xmonad starts up again, because we can't kill things at exit so we save them and kill at next startup, but this is guaranteed to happen before starting new bars). if it's not, the notification server may keep running |
| 2025-10-02 15:26:09 | <Enrico63> | Mmm. But regarding the fact that I can reproduce the "zombi" scenario by killing the notification server (when I run it as standalone from a terminal) via `kill -KILL`... that's not a proof on its own that there's a bug, right? I mean -KILL means that no chance is given to the process to clean up anything, am I correct? |
| 2025-10-02 15:26:35 | <geekosaur> | correct |
| 2025-10-02 15:27:09 | <geekosaur> | but it's rare for anything to use -KILL directly; the convention is -TERM, wait 5-10 seconds, -KILL if the process hasn't exited on its own |
| 2025-10-02 15:27:45 | <geekosaur> | to keep stuck processes from blocking an entire "stack" from shutting down |
| 2025-10-02 15:27:58 | <Enrico63> | I see |
| 2025-10-02 15:32:58 | <liskin> | Is this notification server a separate process? |
| 2025-10-02 15:34:38 | <liskin> | If yes and it expects to be terminated by a signal, then that's fraught with disappointment. Nothing, apart from xmonad's dynamicSBs, sends signals. Even dynamicSBs doesn't send them on exit, only on rescreen. |
| 2025-10-02 15:35:15 | <liskin> | You'll need to find another way. And you'll need to learn a bit about signals and pipes and processes and such. |
| 2025-10-02 15:35:37 | <liskin> | Or you can do what I do and just let systemd manage everything. :-) |
| 2025-10-02 15:35:58 | <Enrico63> | Ok, that assumes my understanding of how xmobar spawns the `IO` actions provided by the plugins. Let me check |
| 2025-10-02 15:36:24 | <liskin> | I just run xmobar "plug-ins" as completely separate systemd services that write into X props and xmobar reads from them. Works like a charm. |
| 2025-10-02 15:37:11 | <liskin> | (but getting that to work with multiple X sessions means straying so far from the beaten path it's not even fun) |
| 2025-10-02 15:37:46 | <Enrico63> | Well, at the moment I'm more curious about understanding what's going on with my setting. I mean, the bug can easily be in my notification server. |
| 2025-10-02 15:38:11 | <geekosaur> | or in xmobar or your plugin, as I said |
| 2025-10-02 15:39:03 | <geekosaur> | lots of moving parts here, and it's sufficiently distant from xmonad that that's unlikely to be involved if xmobar is getting killed/restarted correctly; that fingers the plugin or thenotification server |
| 2025-10-02 15:42:13 | <Enrico63> | The IO action I use the start the server is here https://codeberg.org/Aster89/xnobar/src/commit/7a445e8302db800b214dcc7f11562cc06f854dd3/lib/Server/XNobar/Server.hs#L78-L102. |
| 2025-10-02 15:42:13 | <Enrico63> | The `reply == NamePrimaryOwner` means that the registration happened successfully, in which case I pass `Right (notifications, revoke)` down the following computation, but `revoke` is an IO action that undos what I've done in the linked code. And at |
| 2025-10-02 15:42:14 | <Enrico63> | https://codeberg.org/Aster89/xnobar/src/commit/7a445e8302db800b214dcc7f11562cc06f854dd3/lib/XNobar/XNobar.hs#L60-L62 I try to be careful to run that `finally`. |
| 2025-10-02 15:42:47 | <Enrico63> | With that, I think I'm ensuring that things are clean up correctly, at least if I don't kill with -KILL. |
| 2025-10-02 15:43:25 | <Enrico63> | Does it sound sensible, or am I saying crap? :/ |
| 2025-10-02 15:45:31 | <liskin> | That assumes xmobar terminates its threads cleanly and waits for them |
| 2025-10-02 15:45:36 | <liskin> | I wouldn't bet it does |
| 2025-10-02 15:45:45 | <geekosaur> | there's one key piece missing: how, if at all, does xmobar tell your plugin to deinitialize? |
| 2025-10-02 15:45:52 | <Enrico63> | The fact that, when I run the notif server in a terminal, killing it with -KILL leaves it running like a zombi and when i kill it without KILL it is shut down and I can restart it, leads me to think that my notif server is behaving well |
| 2025-10-02 15:46:16 | <liskin> | Wait what |
| 2025-10-02 15:46:29 | <liskin> | If you KILL then it's running? Wtf |
| 2025-10-02 15:46:30 | <geekosaur> | it's entirely possible that it assumes plugins don't do anything persisten |
| 2025-10-02 15:46:33 | <geekosaur> | t |
| 2025-10-02 15:46:45 | <Enrico63> | liskin gimme a moment to re-read my msg |
| 2025-10-02 15:46:51 | <geekosaur> | liskin, -KILL prevents cleanup, so the server isn't reaped |
| 2025-10-02 15:47:21 | <liskin> | geekosaur: they didn't say killing xmobar, they said killing notif server |
| 2025-10-02 15:47:37 | <Enrico63> | Oh, yeah, liskin, if I kill -KILL the notification server, I see it keeps running. even if the PID is gone |
| 2025-10-02 15:47:40 | <geekosaur> | also, wrt the server itself, -KILL means not being able to tell dbus to deregster the name |
| 2025-10-02 15:47:57 | <Enrico63> | Yes, @geee |
| 2025-10-02 15:48:06 | <geekosaur> | so registering it again will fail without a flag to reuse the name |
| 2025-10-02 15:48:10 | <Enrico63> | yes, geekosaur, that's why I think it's normal that it keeps running in that case |
| 2025-10-02 15:48:11 | <liskin> | But yeah if C-Cing xmobar evals the finally, that's a hint maybe it does actually wait for the threads |
| 2025-10-02 15:49:21 | <geekosaur> | also, if the pid is gone, the server is gone. but its registration with dbus may still be there |
| 2025-10-02 15:50:01 | <Enrico63> | liskin, eh... but I actually added that finally just an attempt to fix this issue. I had forgotten to do any deristration before, and it would stil bheave the same (i.e. react well when I, say, kill xmobar, or restart xmonad in place, and it would leave the name busy when logging out of xmonad) |
| 2025-10-02 15:50:05 | <geekosaur> | sometimes this is just something you must deal with. https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L448-L450 |
| 2025-10-02 15:51:11 | <Enrico63> | > also, if the pid is gone, the server is gone. but its registration with dbus may still be there |
| 2025-10-02 15:51:11 | <Enrico63> | yea, geekosaur, I think that is what happens when I exit xmonad. And I tend to think that it's because xmobar kills me too harshly, like with KILL. |
| 2025-10-02 15:51:12 | <lambdabot> | <hint>:1:5: error: parse error on input ‘,’ |
| 2025-10-02 15:51:43 | <liskin> | So did we at least establish whether the process is still running? |
| 2025-10-02 15:51:56 | <liskin> | If not and dbus refuses then what geekosaur says |
| 2025-10-02 15:52:00 | <geekosaur> | quote with something other than "> ", lambdabot takes that as code to run |
| 2025-10-02 15:52:17 | <geekosaur> | they said the pid is gone, so it's not running |
| 2025-10-02 15:52:19 | <Enrico63> | Sorry, I didn't know that :( |
| 2025-10-02 15:52:21 | <liskin> | If yes then it's an issue of process lifetimes and signalling |
| 2025-10-02 15:52:38 | <Enrico63> | If you give me a moment I can record a GIF |
| 2025-10-02 15:52:46 | <Enrico63> | well, more than a moment |
| 2025-10-02 15:52:52 | <liskin> | (afk now, sry) |
| 2025-10-02 16:01:13 | <Enrico63> | Here's the GIF showing my repro https://codeberg.org/Aster89/xnobar/attachments/03972518-6532-4594-b632-62bf39030453 |
| 2025-10-02 16:20:24 | <geekosaur> | okay, that proves killing xmobar doesn't do anything. I think liskin was asking about your notification server itself |
| 2025-10-02 16:20:28 | <Enrico63> | The IO action I defined in my plugin is run here: https://codeberg.org/xmobar/xmobar/src/commit/4e8ec5a4c86873018f3ba33669fb9affff280d6e/src/Xmobar/Run/Loop.hs#L104 via `async` |
| 2025-10-02 16:21:29 | <Enrico63> | geekosaur, I might have misunderstood what I was asked. What about the notification server? |
| 2025-10-02 16:24:08 | <geekosaur> | you said its pid had gonee away but it was still running. by "its pid had gone away" did you mean xmobar, or the notification server itself? |
| 2025-10-02 16:30:00 | <Enrico63> | When I said that I was talking of the scenario I've shown in the GIF, that is when take xmobar out of the equation and run the notification server manually in a terminal. |
| 2025-10-02 16:30:30 | <Enrico63> | In that case, the PID is the PID of the `cabal run` that I enter in the terminal to run the notification server. |
| 2025-10-02 16:34:04 | <Enrico63> | So I'm just making the hypothesis that when I exit xmonad, xmobar (at some point) is shutting down my notification sever in a way similar to what I can do via kill -KILL when I run my notification sever standalone, i.e. in a way that doesn't give it a chance to unregister from dbus. |
| 2025-10-02 16:35:10 | <Enrico63> | But I don't know how to see if that's the case. I think the clean up of xmobar's plugins happens via this function: https://codeberg.org/xmobar/xmobar/src/commit/4e8ec5a4c86873018f3ba33669fb9affff280d6e/src/Xmobar/Run/Loop.hs#L73-L76 |
| 2025-10-02 16:36:33 | <Enrico63> | But `cancel` seem to do the right thing, according to the doc: https://hackage.haskell.org/package/async-2.2.5/docs/Control-Concurrent-Async-Internal.html#v:cancel |
| 2025-10-02 16:39:04 | <liskin> | What do you mean by you don't know how to see? Just login as root from vt1 and do ps axf after you've shut down X? |
| 2025-10-02 16:39:41 | <liskin> | (or even perhaps login as your user if you don't use user systemd to manage the X session) |
| 2025-10-02 16:39:42 | <Enrico63> | To see what? If xmobar is running or not? |
| 2025-10-02 16:40:04 | <liskin> | Probably a good idea to not limit yourself to xmobar. |
| 2025-10-02 16:40:16 | <liskin> | To see everything. What's still running and what's not. |
| 2025-10-02 16:40:49 | <Enrico63> | Ok, but I have to know what to look for, no? |
| 2025-10-02 16:41:01 | <Enrico63> | Just saying I don't know what else to look for. |
| 2025-10-02 16:41:23 | <Enrico63> | Except I'd wander about my notification server, but is that a _process_? |
| 2025-10-02 16:41:47 | <Enrico63> | As in, if the IO action is run via async... then it won't have a PID associated, or would it? |
| 2025-10-02 16:42:53 | <liskin> | If it's not a separate process then yeah xmobar |
| 2025-10-02 16:44:09 | <Enrico63> | On this line here https://codeberg.org/xmobar/xmobar/src/commit/4e8ec5a4c86873018f3ba33669fb9affff280d6e/src/Xmobar/Run/Loop.hs#L104 `start` is the thing I define in my plugin. It is run via `async`. So the conclusion is that it's not a separate process, right? Is just a separate thread |
| 2025-10-02 16:48:16 | <liskin> | Yeah |
| 2025-10-02 16:48:47 | <geekosaur> | your plugin, yes. but if you spawn something, that will be a separate process. (it's also playing with fire, as mixing threads and processes is unsafe in any language. fork+immediate exec is usually safe, but still has potential for crashes) |
| 2025-10-02 16:52:20 | <Enrico63> | "but if you spawn something" -> does registering with dbus count? |
| 2025-10-02 16:52:49 | <geekosaur> | no |
| 2025-10-02 16:53:02 | <geekosaur> | you are running a notification server which is a separate process |
| 2025-10-02 16:54:24 | <Enrico63> | Yeah, but I'm not spawning anything, as far as I know. I'm just using DBus API |
| 2025-10-02 16:55:21 | <geekosaur> | wait, this is all running inside of xmobar, then? |
| 2025-10-02 16:57:12 | <geekosaur> | okay, I see, it's just a library. so if xmobar exits the thread shouldn't exist any more (when the main thread of a process exits, all other threads are hard-killed) |
All times are in UTC.