If I open terminal and execute w command then it will show:

user tty7 :0 12:04 39:56 36.87s 0.06s /sbin/upstart -

Now if open terminator or xterm and execute w command then it will show it's entry in the output of w command like

user tty7 :0 12:04 39:56 36.87s 0.06s 
/sbin/upstart -
user pts/2 :0.0 12:50 1.00s 0.02s 0.00s w

but it will not show a new entry when I open gnome-terminal or xfce4-terminal.
Why it is showing new session for terminator and not for xfce4-terminal?

w displays the information stored in utmp (/var/run/utmp typically on Linux systems). This generally is only updated by “login” sessions, i.e. login (for logins on virtual consoles or serial connections), the display manager (for graphical sessions), the SSH server (for SSH connections), and some (most?) terminal emulators. In the latter case, whether or not they update utmp depends on their built-in support and configuration; for example xterm has the ut flag for this (-ut disables utmp updates, +ut enables them), and GNOME Terminal no longer updates utmp directly at all.

So you’re seeing the entries which have been added to utmp in your case: one added by your display manager (on tty7), and others added by some of the terminal emulators you’re using.

It should be possible to wrap commands to add utmp logging to anything you like, using for example libutempter, but that is apparently not as straightforward as one might hope.

w does not show terminal sessions. The login database, that the w program reports on, is not a terminal database. (Formally, it is a user accounting database, but the Single Unix Specification is incomplete on this point.)

If it were a terminal database, it would record all of the pseudo terminals that programs use, from the likes of NeoVIM, emacs, tmux, screen, ptybandage, ptyrun, and even script. But it does not, and it is not.

(One can make a similar argument, that needs a slightly greater knowledge of history, about it not recording "call out" terminal usage and the likes of BBS, FidoNet, and UUCP terminal sessions.)

As a login database, it records login sessions, both textual and graphical. The libvte people make the argument that writing to this database is within the purview of the login subsystems, graphical and textual, not within the purview of a terminal emulator that runs within login sessions. This is a fair point, bolstered by the fact that it makes a nonsense of the security of login accounting to allow programs outwith the Trusted Computing Base to write/update the login database.

As such, you shouldn't expect every terminal emulator session to show up as a login session in the login database — or indeed any terminal emulator sessions. Even terminal emulators that are invoking login shells are not doing any actual logging on to the system, and are acting entirely within an already-logged-in session. Terminal emulator writers tried to make the login database record terminal emulator sessions, but the effort has led to a number of problems, long-since recognized.

Conversely, you should expect to see a single record for your GUI login session. (Although, as explained in an article in further reading, in practice this is rather a mess.)

Further reading

• Jonathan de Boyne Pollard (2018). The Unix login database. Frequently Given Answers.


• https://unix.stackexchange.com/a/437762/5132


• 
  pututxline. Base Specifications. IEEE 1003.1:2017. The Open Group.