Artix Linux Forum

Quote from: Dastard – on 09 July 2025, 16:55:04

It's called a session because it runs from login to logout, I think it's a pretty apt name for it. And although wayland can spawn programs in x11 for compatibility purposes, this refers to x11 alone.

People can make things up but this is technology where words have specific and exact meanings.  Linux does not have "session"s.  It has processes - heavy or light, which can be child processes or not.  It uses fork() and clone() and you can see the processes with the ps command or the pstree command.  Processes are sent to the scheduler to receive their share of time and share a memory stack which can be segregated and which is processed by a CPU which is a Newman machine.

None of which has the word "session".  So when the word session is used, I am confused to what you mean. 

I run several X server processes at the same time on different ttys, btw, for different work.

You are saying a session is a program that runs with login and ends with logout?  That doesn't even describe that X or Wayland does.  XDM or whatever greeting application you are running, is ran from the system as a service from the init.  A service is a process started by the init system which runs as a dameon.  So with a conventional graphics login, X or Wayland is running before you login and still runs upon exit.  If that is not correct, I am happen to be corrected.

https://tldp.org/LDP/tlk/kernel/processes.html

Then you have a waking session in which you started a system power on session which booted into a linux kernel session that let you start a x11 session that let you have a browser session during which you made this post. Noone argued that "session" was an x-related term, and I would advise against using a tech forum as a replacement for social interaction.

You are either heavily on the spectrum, or peaking in dunning-kruger. While session may not a rigorously defined term, everyone understand what it means in the context it is used in. Whether you are trying to flex your knowledge or are genuinely confused, you can only resolve that with introspection, derailing threads won't get you anywhere.

Plasma has pretty much adopted wayland as the main display server in the past year or so, and besides if you're using something as "bloated" as plasma, I don't understand why you'd worry about the couple MB of disk space removing wayland would give you. As for me personally I've had 0 hickups with wayland, and the only reason I would use x11 is for DWM.

Since you are an expert, you explain what a session is.

Don't be a PRICK and one of the two of us in the conversation actually has a medical license and that would not be you. [...] Since you are an expert, you explain what a session is.

Nobody is flaunting their "expert" status except you

and one of the two of us in the conversation actually has a medical license

Quote

and one of the two of us in the conversation actually has a medical license

Anti Nowhere League say it better than I could (original better than the Metallica cover)
Give it a rest for the love of Linus

Of course, you can use DWL if you want to stay on Wayland... DWL has a way to go to be on-par with DWM (IMHO, of course).
I managed to get it up and running but there are not enough patches (well, the ones I use anyways) and really don't want to invest time trying to convert/hack/whatever to get things working in Wayland with the patches I do use or created. Not even touching the apps I use.

According to google (now our AI overlord) linux processes appear to have something called sessions.

The setsid command can be used to start a new 'session'.

I'm not sure exactly what defines a 'session', but it seems to be describable by an integer equivalent in size to the PID_t and can be used in pkill commands to remove all 'session' members.

I know from messing with slim/openbox that the slim 'session' propagates to  openbox and its children. If any of the autostart kids becomes detached (so its parent is pid 1) the 'session' id remains that of slim.

I suspect session and process group are more or less the same.

      The autogroup feature
       Since Linux 2.6.38, the kernel provides a feature known as
       autogrouping to improve interactive desktop performance in the
       face of multiprocess, CPU-intensive workloads such as building the
       Linux kernel with large numbers of parallel build processes (i.e.,
       the make(1) -j flag).

       This feature operates in conjunction with the CFS scheduler and
       requires a kernel that is configured with CONFIG_SCHED_AUTOGROUP.
       On a running system, this feature is enabled or disabled via the
       file /proc/sys/kernel/sched_autogroup_enabled; a value of 0
       disables the feature, while a value of 1 enables it.  The default
       value in this file is 1, unless the kernel was booted with the
       noautogroup parameter.

       A new autogroup is created when a new session is created via
       setsid(2); this happens, for example, when a new terminal window
       is started.  A new process created by fork(2) inherits its
       parent's autogroup membership.  Thus, all of the processes in a
       session are members of the same autogroup.  An autogroup is
       automatically destroyed when the last process in the group
       terminates.

       When autogrouping is enabled, all of the members of an autogroup
       are placed in the same kernel scheduler "task group".  The CFS
       scheduler employs an algorithm that equalizes the distribution of
       CPU cycles across task groups.  The benefits of this for
       interactive desktop performance can be described via the following
       example.

       Suppose that there are two autogroups competing for the same CPU
       (i.e., presume either a single CPU system or the use of taskset(1)
       to confine all the processes to the same CPU on an SMP system).
       The first group contains ten CPU-bound processes from a kernel
       build started with make -j10.  The other contains a single CPU-
       bound process: a video player.  The effect of autogrouping is that
       the two groups will each receive half of the CPU cycles.  That is,
       the video player will receive 50% of the CPU cycles, rather than
       just 9% of the cycles, which would likely lead to degraded video
       playback.  The situation on an SMP system is more complex, but the
       general effect is the same: the scheduler distributes CPU cycles
       across task groups such that an autogroup that contains a large
       number of CPU-bound processes does not end up hogging CPU cycles
       at the expense of the other jobs on the system.

It is amazing what can be learned when people aren't being hostile and the smoke clears.

Quote from: mrbrklyn – on 10 July 2025, 13:14:49

It is amazing what can be learned when people aren't being hostile and the smoke clears.

Please consider hide your offtopic posts in other people's topics in spoiler tag or, even better, do not post it there at all. If your goal on this forum is not to provoke flood and if you have some extraneous questions and misunderstandings then start new topic. Thank you.

According to google (now our AI overlord) linux processes appear to have something called sessions.
The setsid command can be used to start a new 'session'.
I'm not sure exactly what defines a 'session', but it seems to be describable by an integer equivalent in size to the PID_t and can be used in pkill commands to remove all 'session' members.
I know from messing with slim/openbox that the slim 'session' propagates to  openbox and its children. If any of the autostart kids becomes detached (so its parent is pid 1) the 'session' id remains that of slim.
I suspect session and process group are more or less the same.

Guys you are waaay overcomplicating this... "Session" as a concept indicates user's timed (logged)