Comment # 5
on bug 1121076
from Oliver Kurz
(In reply to Christian Dywan from comment #4)
> ^^ That would be me :-)
>
> From the log I can see that you're basically doing "midori -e fullscreen
> https://openqa.opensuse.org?group=openSUSE Tumbleweed" although the command
> line is unfortunately incomplete.
The complete command line would be
```
midori -e Fullscreen -e Navigationbar -e ZoomIn -e ZoomIn -a
https://openqa.opensuse.org?group=openSUSE Tumbleweed$|openSUSE Leap
[0-9]{2}.?[0-9]*$|openSUSE Leap.*JeOS$|openSUSE Krypton|openQA|GNOME
Next&limit_builds=2&time_limit_days=14&&show_tags=1&fullscreen=1#build-results
```
The process is started from ~/.xinitrc of an unpriviledged user within an LXDE
session . .xinitrc calls a script that starts the above command line in the
background so that the browser shows up on the screen in full screen acting as
a non-interactive "dashboard". Over a cron job every 3 minutes the following
two commands are called:
```
DISPLAY=:0 xdotool search --onlyvisible --any --classname midori windowactivate
DISPLAY=:0 xdotool key F5
```
to reload the current page. Previous versions of midori promised to have an
option that internally reloads in an interval but it seems more recent versions
of midori do not tell about that option anymore, e.g. when calling `midori
--help`.
> Can you clarify how the crash occurs?
We can see from coredumpctl how often the crashes occur:
```
Thu 2019-01-03 13:52:39 CET 2220 1001 100 11 missing /usr/bin/midori
Sat 2019-01-05 09:58:23 CET 2218 1001 100 11 missing /usr/bin/midori
Tue 2019-01-08 09:52:33 CET 2219 1001 100 11 missing /usr/bin/midori
Wed 2019-01-09 14:31:31 CET 1750 1001 100 11 missing /usr/bin/midori
Fri 2019-01-11 09:34:58 CET 2282 1001 100 11 missing /usr/bin/midori
Sat 2019-01-12 10:16:15 CET 2224 1001 100 11 missing /usr/bin/midori
Thu 2019-01-17 08:52:26 CET 1778 1001 100 11 missing /usr/bin/midori
Fri 2019-01-18 09:46:22 CET 2267 1001 100 11 missing /usr/bin/midori
Sat 2019-01-19 10:31:26 CET 2271 1001 100 11 missing /usr/bin/midori
Tue 2019-01-29 09:55:49 CET 1741 1001 100 11 present /usr/bin/midori
Wed 2019-01-30 11:28:24 CET 1744 1001 100 11 present /usr/bin/midori
Fri 2019-02-01 09:34:19 CET 1772 1001 100 11 present /usr/bin/midori
```
I did restart the computer normally after every crash when I was actually in
the office. In the week from 2019-01-21 I was not in the office for a week and
no one restarted the computer. What we can see is that there is no crash
reported between 2019-01-19 and 2019-01-29, probably because I restarted the
computer on Monday, 2019-01-28.
> Are there any particular settings
> you're using?
Nothing in particular has been configured in midori itself. However as this is
an older installation of openSUSE Tumbleweed and I have not deleted
~/.config/midori/ some data there might impact how it is running.
> Is it just running all day and crashing eventually?
Yes.
Additionally I realize now something else is off in the way I start the
process.
My start script says:
```
(midori --version | grep -q 'midori 7\.' && midori -e fullscreen "$url" ||
midori -e Fullscreen -e Navigationbar -e ZoomIn -e ZoomIn -a "$url")&
```
meaning that the browser should start with `midori -e fullscreen���` as visible
above it's started with the old syntax which should only happen when `midori
--version | grep -q 'midori 7\.'` fails.
~/.xsession-errors reports:
```
$ grep 'midori.*20093' .xsession-errors
** (midori:20093): WARNING **: 09:33:56.039: app.vala:472: Unexpected action
'navigationbar'.
** (midori:20093): WARNING **: 09:33:56.381: app.vala:472: Unexpected action
'zoomin'.
** (midori:20093): WARNING **: 09:33:56.382: app.vala:472: Unexpected action
'zoomin'.
```
which was just before the latest crash. I guess this could cause this? The
browser should not segfault but I will still try to investigate this.