-5

Regarding what process is a daemon, https://unix.stackexchange.com/a/175396/674 says

The big problem here comes when your system runs a graphical environment. Since GUI programs (i.e. Chromium) are not attached to a terminal, they also appear in the output.

... Basically, we would like to display all programs without a controlling terminal, but not GUI programs. Luckily for us, there is a program to list GUI processes : xlsclients

Can a X client without a controlling terminal be a daemon?

Can a process running a GUI program without a controlling terminal be a daemon?

The link seems to say no to both questions. What aspect of a daemon makes a X client (or a process running a GUI program) without a controlling terminal not a daemon? That boils down to what the definition of a daemon is.

Note that:

  • Are X clients and GUI programs the same concept? The link seems to say yes. But note that a X client doesn't necessarily have a window, while the name seems to me that a GUI program process must have at least one window. In particular, can a X client without any window run as a daemon?

  • Any process (X client, GUI program, and any others) can be in a process session with or without a controlling terminal (e.g. when starting an X client or GUI program from a shell with a controlling terminal, and when starting it from the menu of desktop environment). A daemon's process session can't have a controlling terminal, so I am considering the case without a controlling terminal.

Thanks.

Community
  • 1
Tim
  • 101,790
  • 1
    What's the point? What do you want to achieve? It's a bad idea to start from solutions instead of questions. – Ho1 Dec 27 '18 at 22:10
  • I am not sure your comment makes any sense... – Tim Dec 27 '18 at 22:14
  • And yet I think it would be very helpful if you could understand it. – Stephen Kitt Dec 27 '18 at 22:17
  • 1
    Also, define “daemon”. – Stephen Kitt Dec 27 '18 at 22:17
  • @StephenKitt "what is a daemon" is underlying and part of my question. Yes, I understand that the comment doesn't have a point. If you insist, I can pretend to applaud it. – Tim Dec 27 '18 at 23:00
  • 5
    Tell you what, if you’re going to pretend (and miss the point entirely), I’ll join you — I’ll just pretend to answer (which will save me an awful lot of time). – Stephen Kitt Dec 27 '18 at 23:11
  • 1
    You are trying to create hard strict definitions where none exist. The lines are blurred and something may be considered a daemon if started one way, but a foreground process if started another. The lines get especially blurred when considering X clients (e.g. xbuffy may be a daemon if started from fvwmrc, but isn't if started from a terminal; the running process may not even be on the same machine as the display!). – Stephen Harris Dec 28 '18 at 00:23
  • Do not post the same question for more than one time. – 炸鱼薯条德里克 Dec 28 '18 at 02:20

1 Answers1

4

I would say this is mostly a matter of definition. The canonical (no-controlling-terminal) definition predates X (or W for that matter) – by a couple of years at least – as far as I can tell. So the definitions do not necessarily have to be compatible with the extended environment.

If your definition of a daemon is "doesn't have a controlling terminal", then that's what it is, regardless of whether it is an X client or not – and regardless of whether it has an active visible window (think an audio volume manager listening for hotkeys).

If you decide to go with a broader definition (e.g. from the summary of the Wikipedia entry):

a computer program that runs as a background process, rather than being under the direct control of an interactive user,

then it depends on what such a program actually does - a system monitor (like Conky) would be a good candidate for a daemon with a read-only GUI. From my point of view, having a controlling terminal doesn't necessarily interfere with such a broad definition (although I don't think it would be a Good IdeaTM).

As a side note, even a desktop environment may end up having a controlling terminal (or an X session) - last time I checked startx was still available, so you can perfectly well log into a system, start a X11 DE from shell and at least parts of it may have a controlling terminal (the one that the session was started from), depending on the actual implementation.

peterph
  • 30,838
  • And with X, the client process talking to the server may even be on a different machine, which complicates things even more (DISPLAY=remotemachine:0 xsnow ... assuming permissions have been granted!). – Stephen Harris Dec 27 '18 at 23:50
  • @peterph Thanks. Note that some X clients don't have any window. That's why I was asking if X clients and GUI programs are the same concept and if a GUI program must have at least one window. Can a X client without any window run as a daemon? – Tim Dec 28 '18 at 00:29
  • By "From my point of view, having a controlling terminal doesn't necessarily interfere with such a broad definition", do you mean " From my point of view, having a window doesn't necessarily interfere with such a broad definition" instead? – Tim Dec 30 '18 at 04:15
  • No, I meant is as written. That an application has an open controlling terminal doesn't necessarily mean it is using it as a mean of communication with the user (although it is possible). If the program is not really taking any inputs from the terminal, the only thing the terminal is good for (apart from displaying possible output) is transferring signals, most likely SIGINT (alias Ctrl-C) or SIGHUP (closing the terminal) - but these signals may as well be sent in a different way (with kill()), so functionally-wise there's not much of a difference. – peterph Jan 07 '19 at 10:38