Start in daemon mode

[Linuus]

Hi!

Is there a way to start qutebrowser as a daemon (in background)? Currently, when I just run qutebrowser from the terminal it locks up that terminal window and outputs the logs. Or are you supposed to start it in some other way?

[professorjamesmoriarty]

A few things here, What desktop manager are you using. If it's gnome and other similar managers you may have a "run" dialog type tool built in. Try this by pressing alt+f2 and typing qutebrowser. Also fairly sure this isnt the type of app that would run as a daemon. You might also be able to make a link or short cut depending on your window manager. But if you want to fork or sepperate the process from a terminal you can do one of two things I'm aware of. You can add a & to the end of the command. Or "nohup qutebrowser" And you should then be able to close your terminal just fine. But i suggest some type of menu or launcher app.

[Linuus]

Sorry, I forgot to mention that I'm on OS X. I will try your suggestions.

All I want is to be able to close/restart my terminal without killing my browser:)

[ff2000]

I still think this could be handy. Having an instance running in the background
would greatly improve startup time. I think firefox has a "background" mode,
libreoffice should have one, too. Of course this requires qutebrowser to be sort
of a "single application". (Did not check now if it actually already is one...)

Linus Pettersson wrote:

Sorry, I forgot to mention that I'm on OS X. I will try your suggestions.

All I want is to be able to close/restart my terminal without killing my browser:)

---

Reply to this email directly or view it on GitHub:
#631 (comment)

[Linuus]

It would be cool to be able to handle it like a regular OS X app as well. So you can start it with Alfred, have a nice icon in the dock and so on :)

[The-Compiler]

I think we're talking about two different things right now 😉

I plan to look into building and distributing an .app for OS X - see #384. It's just that it isn't exactly a priority for me right now... But if you want to, you can try launching python3 scripts/freeze.py bdist_dmg and (hopefully) get a working .dmg with everything needed bundled in the dist/ subfolder. If you do, can you please tell me if it worked?

I still think this could be handy. Having an instance running in the background
would greatly improve startup time. I think firefox has a "background" mode,
libreoffice should have one, too. Of course this requires qutebrowser to be sort
of a "single application". (Did not check now if it actually already is one...)

It already is one. I think you could (auto-)start qutebrowser with --nowindow and then it's essentially that, except on :quit that instance will quit as well. Though to be honest I'd rather look into making the startup faster than doing such a daemon-thingy...

[ff2000]

Florian Bruhin wrote:

I think we're talking about two different things right now 😉
Yeah, sorry xD
The intetion was hidden: Usually when you have a background instance running starting a new (visible) instance comes back to the console. That's what you also see with qutebrowser :)

except on :quit that instance will quit as well.
That's not so great ;) So not a replacement for background instance (and breaks my hidden intention...)

Though to be honest I'd rather look into making the startup faster than doing such a daemon-thingy...
Startup time is really good! Compared to other browsers...
When you start after a fresh boot (and are not in a DE depending on Qt5...) most of the time is spent in loading the libs (+Py bindings) (~20 secs here - no optimization possible). For the next startups it's esentially firing up the python Interpreter/VM (is it a VM?) and initialize the browser (<1sec here, IMHO no optmization needed).

[spiderbit]

hmm have problems with qutebrowser, if I start it with --nowindow parameter and I close the last window with the ":close" command it quits the windowless window.

That I guess this is a bug. I use the version from nixos, v 0.7.0.

[The-Compiler]

@spiderbit Right now --nowindow is mainly used for testing, but I guess that should work as well. However it's not really something high-priority for me right now.

[spiderbit]

it really hurts me... I am switching from conkeror, I dont use tabs, whenever I want a new site open I open a new window with a shortcut... in conkeror that takes under 1 sek. I have no deamon there too, but because the start is under 1 second it does not matter.

While the very slow python aparently needs 4 to 5 seconds to start, btw even if a instance is open already.

I seen a workaround for that, but it depends on a instance already running.

So I would have to build a script like (if instalnce running) do that, (if not) do that. and bind that to my shortcut.

So this really hurts the usability for me.

[spiderbit]

I mean I understand taht this is maybe no high priority for you, but its at least a bug.

it does not make any sense to start a instance with no window and then when you close a window the instance exits, for what is then the quit button, if close does the same thing.

I just also think that would be a much easier workaround than trying to make the starttime 5 times faster or at least 3 times faster, or do you think that would be easy to do?

[The-Compiler]

If you say it takes 4-5 seconds on your system even with an instance running, how does this change anything?

[spiderbit]

there is a workaround which enables you to send a new-window command or something I found somewhere here. that shoul then be faster wasnt it even in the faq, wait a second I search it.

[spiderbit]

#1098

this echo command at the bottom, dont have this socat installed, so I cant test it, but it should work I guess?

open a new window with open also is instant, so open it twice with one instance should not take longer.

[The-Compiler]

Most time is taken by PyQt imports, which are also done when opening a second instance which just communicates with the first one.

[spiderbit]

wouldnt it be possible to have either a second starter or some if/else that forgoes that, if a instance is already open, or a flag or something?

[The-Compiler]

I don't understand that question.

[spiderbit]

so you say it imports PyQt, if only creates a new window with a existing instance, it would not be needed to import that again right?

so you could have some kind of detection or start parameter that makes the starter not import that pyqt a second time. or is the starter always start a new instance?

[spiderbit]

Well no matter what the answer is to that, this echo command dont imports pyqt again, so its faster (if its still working), so if --no-window would keep open a instance I could load one instance without a window at windowmanager start, and then use this echo command to start new windows of qutebrowser.

That would fit my workflow.

[The-Compiler]

@spiderbit First of all: Every time you do a comment here, you send mail to something like 100 people. Can you please stop the rapid double-comments? 😉

Some PyQt imports are needed because qutebrowser uses Qt's QLocalSocket to communicate with the existing instance. Though imports could certainly be rearranged a bit to speed things up, that's why #1098 exists. An alternative would be to have a qutebrowser-client script which only talks to an existing instance, erroring out if none exists.

FWIW on my (5 year old) laptop it takes ~1s to spawn a new instance, and less than that to communicate with an existing one. PRs to improve this would certainly be welcome, but again, I won't get the time to work on this anytime soon.

[spiderbit]

I have here a new Acer Chromebook 11 some kind of pentium somthing dualcore with around 2ghz and I tihnk 2gb ram, and some sort of internal flash memory.

And I just again tried it, as far as good I can press the stop clock its around 4 to 5 seconds. On my core i5 thinkpad x220 its around 1 sek. so there its fast enough, with a real ssd.

But that does not help me on my chromebook :)

[jarbus]

Piggybacking off of this thread, I'm loving qutebrowser but was wondering if running qutebrowser as a daemon would enable faster start-up times for new windows compared to both having an instance already open and no instances open.

[The-Compiler]

@jarbus It'd make the initial start (with no instances open) faster. For the rest, see #4467, #1098, #153.

[ghost]

I'm now using --nowindow in a systemd user service and the open_url_in_instance.sh script and it makes a big difference in speed, even on a very modern (Ryzen 4000 8-core APU, NVMe SSD).
The only annoying thing is when I close the last qutebrowser window, the service (--nowindow) process will also exit. Is there a way to make the instance stay alive, even when the last window is closed?

[spiderbit]

one way would be to detect a "crash" in systemd and then restart the service I think? That would be at least a improvement right?

Adding
Restart=true

under [Service] should do the trick?

[ghost]

I already did that, but if I restart qutebrowser (kill and start it again) too quickly, it will start in the foreground, which is annoying. I want to be able to close all windows and open a new one very quickly, without waiting for the background process to restart. I use this quite a lot in my workflow to clean old tabs.

[The-Compiler]

The fact that --nowindow (kinda) works for this is mostly an accident - the reason that flag exists is mostly for testing. A proper solution for this would probably stay around indefinitely (and perhaps optionally even display a tray icon or so) - but as far as I'm aware, nobody is working on this at the moment.

[knatsakis]

Just in case someone may find it useful, I am using the following as my /usr/bin/qutebrowser in order to run it in daemon mode: https://gist.github.com/knatsakis/8cf329853330893cd2d7fa3dbd5692b0 (it uses --nowindow)

The script does a few extra stuff that are somewhat relevant to running in daemon mode, but possibly of no interest to others:

• Supports a few commands in order to control the daemon (:recycle, :restart, :shutdown), along with this configuration:

c.aliases.update({
    'recycle':  'quit --save _recycle',
    'restart':  'quit --save _restart',
    'shutdown': 'quit --save _shutdown',
})  

• In case of a crash, saves the sesion to /tmp
• Copies ~/.local/share/qutebrowser and ~/.config/qutebrowser to /run/user/${UID}/qutebrowser and uses that as a basedir, so that changes are not persisted.
• With --mutt, it copies the file argument before mutt has a chance to delete it