dvdhrm / kmscon

Linux KMS/DRM based virtual Console Emulator
http://www.freedesktop.org/wiki/Software/kmscon
Other
432 stars 79 forks source link

Weird journalctl exit #62

Closed swiftgeek closed 11 years ago

swiftgeek commented 11 years ago

In bare kmscon (without tmux) journalctrl -b ends gracefully after pressing q journalctl after pressing q acts for a longer moment like cat > /dev/null and takes 100% of CPU. Then it exits without any error

$PAGER / $SYSTEMD_PAGER are empty systemd version - 196

Happy bug-hunting season!

dvdhrm commented 11 years ago

I can reproduce this bug with kmscon and xterm so I don't think this is kmscon specific. In fact, I think this is the expected behavior. Let me explain what I think is going on:

journalctl -b generates a short amount of data that is read in some milliseconds from disk. journalctl on the other hand generates a fair amount of data that takes minutes to read from disk and decode. You can see this with: time journalctl | wc -l (takes several minutes on my machine) time journalctl -b | wc -l (takes about 400ms here) Now if you pipe this through less (which is think is the default), the '-b' data is read in 400ms by 'less' so pressing 'q' will quit less and wait until journalctl is done (which is unnoticeable fast). However, without '-b' less will quit on 'q' but not notify journalctl to quit. So journalctl will continue to read that data until it is done (which can take quite long and consumes CPU power).

I think journalctl needs to be fixed to stop if its pager quits. I am not sure whether this means handling HUP on stdout or handling SIGCHLD or SIGPIPE or whatever. I will have a look at this but I recommend reporting this to systemd guys as this isn't kmscon specific.

Thanks David

dvdhrm commented 11 years ago

This fixed it for me: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/8033

Can you give it a try? Otherwise wait for systemd-198 which should contain this fix.

swiftgeek commented 11 years ago

but for some reason everything is fine in tmux / vte / urxvt

So if this is triggered in plain xterm then i guess this should be fixed in both places. :] There is no hdd/cpu activity before i press q

Also i "invented" simple test for it PAGER=true journalctl. Please compare it on different terminal emulators For me it just quits on urxvt/tmux/vte

dvdhrm commented 11 years ago

The problem is that journalctl depends on SIGPIPE being sent if stdout is closed, but it does not set SIGPIPE to SIG_DFL. Instead it relies on it being set to SIG_DFL by the parent. In my opinion this is a bug in journalctl (so I sent a patch to systemd-devel).

Anyway, it seems only logical to reset all signal-handlers to SIG_DFL before spawning a child in kmscon (like tmux, vte, urxvt do). So that's what I did. See df2d153e3991b7191aa54e90eb99e19eb6958e6b

Thanks a lot! David

swiftgeek commented 11 years ago

Tested and it's indeed fixed ;) Thanks