Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #16517 > unrolled thread

Faking a TTY on a pipe/socketpair

Back to article view | Back to comp.unix.programmer

Contents

  Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-11-16 11:26 +0000
    Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-11-16 20:51 +0000
      Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-17 08:41 +0000
        Re: Faking a TTY on a pipe/socketpair Wolfgang Agnes <wagnes@example.com> - 2024-11-17 11:38 -0300
        Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-11-17 18:25 +0000
          Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-17 18:41 +0000
    Re: Faking a TTY on a pipe/socketpair Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-17 17:48 +0000
      Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-17 18:39 +0000
      Re: Faking a TTY on a pipe/socketpair Eric Pozharski <apple.universe@posteo.net> - 2024-11-18 07:54 +0000
        Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-11-18 14:02 +0000
        Re: Faking a TTY on a pipe/socketpair Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-18 20:43 +0000
          Re: Faking a TTY on a pipe/socketpair Eric Pozharski <apple.universe@posteo.net> - 2024-11-19 10:07 +0000
    Re: Faking a TTY on a pipe/socketpair Janis Papanagnou <janis_papanagnou@hotmail.com> - 2024-11-18 03:38 +0100
      Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-18 08:26 +0000
      Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-11-18 09:51 +0000
        Re: Faking a TTY on a pipe/socketpair Muttley@DastartdlyHQ.org - 2024-11-18 09:57 +0000
    Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-03 05:29 +0000
      Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-03 08:20 +0000
        Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-03 20:21 +0000
          Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-04 08:34 +0000
            Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 02:11 +0000
              Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-05 06:44 +0000
                Re: Faking a TTY on a pipe/socketpair cross@spitfire.i.gajendra.net (Dan Cross) - 2024-12-05 13:15 +0000
                  Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-05 13:57 +0000
                    Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-05 15:06 +0000
              Re: Faking a TTY on a pipe/socketpair Nicolas George <nicolas$george@salle-s.org> - 2024-12-05 08:01 +0000
              Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-05 08:19 +0000
                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 20:45 +0000
                  Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-05 21:06 +0000
                  Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-06 10:28 +0000
                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-06 20:00 +0000
                      Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-06 12:37 -0800
                        Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-06 22:15 +0000
                      Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-07 10:04 +0000
                        Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-07 15:00 +0000
                          Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) Muttley@dastardlyhq.com - 2024-12-07 16:05 +0000
                            Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 09:09 +0000
                              AIX (was Re: Windows-think and systemd) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-14 12:24 +0100
                          Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 03:51 +0000
                          Re: Windows-think and systemd (Was: Something completely unrelated to what we're yapping about now) Jim Jackson <jj@franjam.org.uk> - 2024-12-09 20:38 +0000
                        Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-09 16:24 +0000
                        Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 09:06 +0000
                  Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-06 17:01 +0000
                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-09 20:28 +0000
                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-10 01:27 +0000
                      Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-10 21:01 +0000
                    Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-12-10 08:50 +0000
                      Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-10 09:23 +0000
                        Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-10 12:26 +0000
                        Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-10 20:55 +0000
                          Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-10 22:02 +0000
                          Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-11 08:33 +0000
                            Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-11 22:26 +0000
                              Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-11 22:40 +0000
                                Re: Faking a TTY on a pipe/socketpair Nicolas George <nicolas$george@salle-s.org> - 2024-12-11 23:34 +0000
                                  Re: Faking a TTY on a pipe/socketpair Alexis <flexibeast@gmail.com> - 2024-12-12 19:15 +1100
                                    Re: Faking a TTY on a pipe/socketpair Nicolas George <nicolas$george@salle-s.org> - 2024-12-12 11:46 +0000
                                  Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 08:27 +0000
                                    Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-12 09:38 +0000
                                      Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 22:24 +0000
                                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-13 20:07 +0000
                                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-13 22:05 +0000
                                      Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-14 15:20 +0000
                                        Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 22:26 +0000
                                          Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-16 23:03 +0000
                                            Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 02:39 +0000
                                              Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-18 21:19 +0000
                                                Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-18 22:16 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-18 22:25 +0000
                              Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-12 08:39 +0000
                                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-12 22:31 +0000
                                  Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-13 10:38 +0000
                                    Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-13 07:42 -0800
                                      Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 01:35 +0000
                                        Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-14 20:16 +0000
                                          Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-15 12:43 +0000
                                            Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-15 21:25 +0000
                                              Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-16 08:16 +0000
                                                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 19:51 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-17 08:34 +0000
                                                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 19:44 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-17 17:27 +0000
                                        Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-16 07:55 -0800
                                          Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 20:15 +0000
                                            Re: Faking a TTY on a pipe/socketpair John Ames <commodorejohn@gmail.com> - 2024-12-16 12:44 -0800
                                            Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-16 23:07 +0000
                                              Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 02:37 +0000
                                                Re: Faking a TTY on a pipe/socketpair Muttley@DastardlyHQ.org - 2024-12-17 08:35 +0000
                                                  Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 19:45 +0000
                                              Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-12-17 19:48 +0000
                                                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 20:45 +0000
                                                  Re: Faking a TTY on a pipe/socketpair gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-17 22:00 +0000
                                                Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-17 20:54 +0000
                                            Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-17 17:28 +0000
                                      Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-14 10:05 +0000
                                  Re: Faking a TTY on a pipe/socketpair Rainer Weikusat <rweikusat@talktalk.net> - 2024-12-13 11:42 +0000
                                  Re: Faking a TTY on a pipe/socketpair Jim Jackson <jj@franjam.org.uk> - 2024-12-13 20:15 +0000
                  Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 08:52 +0000
                    Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-14 10:09 +0000
                    Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-14 22:28 +0000
                Re: Faking a TTY on a pipe/socketpair Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-05 20:46 +0000
          Re: Faking a TTY on a pipe/socketpair rlhamil@smart.net (Richard L. Hamilton) - 2024-12-14 08:48 +0000
            Re: Faking a TTY on a pipe/socketpair Muttley@dastardlyhq.com - 2024-12-14 10:06 +0000
            macOS and UNIX conformance (was: Faking a TTY on a pipe/socketpair) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2024-12-16 14:05 +0000
      Re: Faking a TTY on a pipe/socketpair Richard Kettlewell <invalid@invalid.invalid> - 2024-12-03 08:38 +0000
      Re: Faking a TTY on a pipe/socketpair scott@slp53.sl.home (Scott Lurndal) - 2024-12-03 14:22 +0000

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#16682

Muttley@dastardlyhq.com writes:
> On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
>>
>>> On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>> What “single task” did init do?
>>> 
>>> Boot the system to usable state.
>>
>>What would you say systemd does that is not related to that?
>
> Networking, including DNS
> Graphics
> Logging
> systemd-boot 
>
> Basically init should start the system, maintain some the running of
> some essential daemons and then leave well alone.

There's no particular reason why init should implement process
management. That init is the one program which cannot easily be replaced on
a running system, is actually a good reason why it shouldn't.

At least on Linux, arbitrary processes can become so-called subreapers
for their descendant processes (prctl(2), PR_SET_CHILD_SUBREAPER). This
means not only the already specious reason¹ that only init can wait for
processes trying to "break out of process management" by double-forking
isn't really valid anymore.

¹ Well-behaved server programs shouldn't background themselves as whether or not a
particular instance should run in the background depends on the reason
why it was started. Ie, that's a system- and situation-specific policy
decision. Backgrounding can easily be provided by a special tool for
that.

[toc] | [prev] | [next] | [standalone]

#16742

In article <vj16j0$30r12$1@dont-email.me>,
	Muttley@dastardlyhq.com writes:
> On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
>>
>>> On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>> What “single task” did init do?
>>> 
>>> Boot the system to usable state.
>>
>>What would you say systemd does that is not related to that?
> 
> Networking, including DNS
> Graphics
> Logging
> systemd-boot 
> 
> Basically init should start the system, maintain some the running of
> some essential daemons and then leave well alone.
> 

On Solaris 10 and later, svc.startd does most spawning and respawning
and such, and uses a "contract" mechanism to be able to keep track of
and if needed kill off otherwise daemonized processes (sshd needs a
compile time option so it only kills the listening sshd and not the
children handling processes - which need to explicitly break their
"contract", otherwise an admin restarting sshd over ssh will kick
themselves out; but for the vast majority of other code, the contract
mechanism does what one might hope with no modification needed to the
code of what it controls)).

But it still has init, although init does little more than start or
control svc.startd (but you could configure it to start something
outside of the control of svc.startd if you really wanted to).

What's the point of svc.startd there? It with the relevant service
configuration files can handle dependencies among services (processes
or other actions) to be started, starting in parallel any whose
dependencies are satisfied; with sufficient hardware threads, that can
provide faster startup.  And it can use the aforementioned contract
mechanism to stay more in control, and will fix simple things by
restarting, albeit not if they keep faulting too rapidly. It interacts
with fault management (which also deals with hardware issues) to
provide a consolidated handing of both daemon and hardware issues, for
greater fault tolerance.

For Solaris systems isolated enough that they didn't need regular security
updates, I've seen uptimes in years, so they're probably doing something
right (that they mostly have ECC RAM helps a lot, too). @home, I seldom
get those uptimes, in part because I don't have UPS for everything. :-)

[toc] | [prev] | [next] | [standalone]

#16649

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which “unix philosophy” would that be?
>> 
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
> What “single task” did init do?
>
> * Mount filesystems
> * Spawn syslog, cron
> * Spawn terminal login processes (getty)
> * Respawn terminated getty processes
> * Monitor other special stuff in inittab
> * Spawn random other services, without monitoring their state
> * Act as a general catch-all for orphaned processes when they terminate
>
> This was all before systemd came on the scene.

Originally, mainly two things: Execute a script to kick off userspace
boot. Call wait in a loop in order to reap zombies.

System V init is somewhat more complicated than that. It has a concept
of numbered run levels and will run a configurable command in response
to runlevel change request. On linux, that's usually the script
/etc/init.d/rc. It also has some process monitoring capabilities: It can
start programs depending on the current runlevel and restart them when
they terminate. This is typically used to run getty processes for real
or virtual terminals and serial lines connected to modems.

Minus some handling of special situations (power failure, ctrl-alt-del
on PCs), that's it. Anything beyond that is done by the rc script.

One could argue that this is already a case of creature feep as process
monitoring and restarting of terminated processes and many other
process invocation management tasks can as well be provided
by dedicated programs. There's no reason to hack all of this (or rather,
some random subset of what could be provided here) into a single
codebase save developer inertia: It's less work to add code to a file
that's already compiled by some build system or to add a new file to a
code base which already has a build system than to create lots of
different, specialized tools.

[toc] | [prev] | [next] | [standalone]

#16688

On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which ???unix philosophy??? would that be?
>> 
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
> What ???single task??? did init do?
>
> * Mount filesystems
> * Spawn syslog, cron
> * Spawn terminal login processes (getty)
> * Respawn terminated getty processes
> * Monitor other special stuff in inittab
> * Spawn random other services, without monitoring their state
> * Act as a general catch-all for orphaned processes when they terminate
>
> This was all before systemd came on the scene.

Actually traditional Unix "init" didn't do ALL those things. Most tended 
to have the inittab config file. Even busybox's init has.

I can't think of a pre-systemd init that mounted filesystems, or spawned 
things like syslog/cron. It ran other programs/systems that did most of 
system-bring-up and the process control stuff one of which was SysV 
initialise setup. Which, surprize though this might sound to some 
people, was, at the time, an improvement on the startup setups that had 
been common previously.




 

[toc] | [prev] | [next] | [standalone]

#16690

On Mon, 9 Dec 2024 20:28:31 -0000 (UTC), Jim Jackson wrote:

> Actually traditional Unix "init" didn't do ALL those things.

sysvinit certainly did. That is the usual standard of comparison, is it 
not?

[toc] | [prev] | [next] | [standalone]

#16695

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 9 Dec 2024 20:28:31 -0000 (UTC), Jim Jackson wrote:
>
>> Actually traditional Unix "init" didn't do ALL those things.
>
> sysvinit certainly did. That is the usual standard of comparison, is it 
> not?

It certainly didn't. sysvinit is a program. There source code is, for example, online
here

https://github.com/slicer69/sysvinit/blob/main/src/init.c

and all this does is execute configurable other programs in a couple of
different ways (mostly respawn, exec once and exec once and wait for it)
in response to runlevel changes.

[toc] | [prev] | [next] | [standalone]

#16692

Jim Jackson <jj@franjam.org.uk> writes:
> On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> What ???single task??? did init do?
>>
>> * Mount filesystems
>> * Spawn syslog, cron
>> * Spawn terminal login processes (getty)
>> * Respawn terminated getty processes
>> * Monitor other special stuff in inittab
>> * Spawn random other services, without monitoring their state
>> * Act as a general catch-all for orphaned processes when they terminate
>>
>> This was all before systemd came on the scene.
>
> Actually traditional Unix "init" didn't do ALL those things. Most
> tended to have the inittab config file. Even busybox's init has.

Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree
terms.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#16693

On Tue, 10 Dec 2024 08:50:20 +0000
Richard Kettlewell <invalid@invalid.invalid> wibbled:
>Jim Jackson <jj@franjam.org.uk> writes:
>> On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> What ???single task??? did init do?
>>>
>>> * Mount filesystems
>>> * Spawn syslog, cron
>>> * Spawn terminal login processes (getty)
>>> * Respawn terminated getty processes
>>> * Monitor other special stuff in inittab
>>> * Spawn random other services, without monitoring their state
>>> * Act as a general catch-all for orphaned processes when they terminate
>>>
>>> This was all before systemd came on the scene.
>>
>> Actually traditional Unix "init" didn't do ALL those things. Most
>> tended to have the inittab config file. Even busybox's init has.
>
>Depends if you mean init=/sbin/init or init=the entire sysvinit system.
>If you(plural) are going talk about init systems then you need to agree
>terms.

Its probably fair to say that because the traditional init system uses 
shell scripts and hence can do anything you like they often did. But the
core part should really just be limited to starting the machine and getting
enough things running for a user to log on (or if its a black box to do its
task).

[toc] | [prev] | [next] | [standalone]

#16694

On 2024-12-10, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
> On Tue, 10 Dec 2024 08:50:20 +0000
> Richard Kettlewell <invalid@invalid.invalid> wibbled:
>>Jim Jackson <jj@franjam.org.uk> writes:
>>> On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> What ???single task??? did init do?
>>>>
>>>> * Mount filesystems
>>>> * Spawn syslog, cron
>>>> * Spawn terminal login processes (getty)
>>>> * Respawn terminated getty processes
>>>> * Monitor other special stuff in inittab
>>>> * Spawn random other services, without monitoring their state
>>>> * Act as a general catch-all for orphaned processes when they terminate
>>>>
>>>> This was all before systemd came on the scene.
>>>
>>> Actually traditional Unix "init" didn't do ALL those things. Most
>>> tended to have the inittab config file. Even busybox's init has.
>>
>>Depends if you mean init=/sbin/init or init=the entire sysvinit system.
>>If you(plural) are going talk about init systems then you need to agree
>>terms.

Yes of course. But he did mention "init" which I take to mean pid 1.

> Its probably fair to say that because the traditional init system uses 
> shell scripts and hence can do anything you like they often did. But the
> core part should really just be limited to starting the machine and getting
> enough things running for a user to log on (or if its a black box to do its
> task).

Doesn't have to be shell scripts - init just launched programs, e.g. 
getty on serial lines, etc.

I think Android init does quite a bit more.

[toc] | [prev] | [next] | [standalone]

#16696

On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:

> But the core part should really just be limited to starting the
> machine and getting enough things running for a user to log on (or
> if its a black box to do its task).

One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

[toc] | [prev] | [next] | [standalone]

#16697

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:
>
>> But the core part should really just be limited to starting the
>> machine and getting enough things running for a user to log on (or
>> if its a black box to do its task).
>
> One thing lacking from sysvinit is, while it can start a service, it
> cannot ensure the service was started properly, and it cannot perform
> reliable service shutdown. So the job of service management was really
> only half-done.

sysvinit has no concept of 'service.'

"Service started properly" is a pointless historical property because
"service was running propery 1ms" ago doesn't mean "service is still
running properly now" (that's one of the classic TOCTOU races everybody
just loves to ignore).

It's unclear what "reliable service shutdown" is supposed to mean. It's
possible to stop a somehow monitored process (not service) reliably (or
sort-of reliably) by killing it if it didn't terminate on its own
within some amount of time after a SIGTERM was sent to it. This works
perfectly with a special-purpose tool for that and doesn't need any
giant wolpertingers implemented with hundredthousands of lines of
overcomplicated C code.

[toc] | [prev] | [next] | [standalone]

#16700

On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:
>
>> But the core part should really just be limited to starting the
>> machine and getting enough things running for a user to log on (or
>> if its a black box to do its task).
>
>One thing lacking from sysvinit is, while it can start a service, it
>cannot ensure the service was started properly, and it cannot perform
>reliable service shutdown. So the job of service management was really
>only half-done.

It doesn't need to , it can just spawn off a script or some other program
which does that which is entirely inline with the unix philosophy. Something
Poettering never understood.

[toc] | [prev] | [next] | [standalone]

#16707

On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:

> On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>
>> One thing lacking from sysvinit is, while it can start a service, it
>> cannot ensure the service was started properly, and it cannot perform
>> reliable service shutdown. So the job of service management was really
>> only half-done.
> 
> It doesn't need to , it can just spawn off a script or some other
> program which does that which is entirely inline with the unix
> philosophy.

Which is where the trouble starts.

> Something Poettering never understood.

Poettering understands that services don’t just to be started, they also 
need to be managed and shut down cleanly.

[toc] | [prev] | [next] | [standalone]

#16709

On 2024-12-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>
>> On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>> One thing lacking from sysvinit is, while it can start a service, it
>>> cannot ensure the service was started properly, and it cannot perform
>>> reliable service shutdown. So the job of service management was really
>>> only half-done.
>> 
>> It doesn't need to , it can just spawn off a script or some other
>> program which does that which is entirely inline with the unix
>> philosophy.
>
> Which is where the trouble starts.
>
>> Something Poettering never understood.
>
> Poettering understands that services don???t just to be started, they also 
> need to be managed and shut down cleanly.

My God, how did we all manage running services before systemd came along?

[toc] | [prev] | [next] | [standalone]

#16710

Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
 écrit :
> My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.

[toc] | [prev] | [next] | [standalone]

#16714

Nicolas George <nicolas$george@salle-s.org> writes:

> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>  écrit :
>> My God, how did we all manage running services before systemd came along?
>
> Badly, with services that have crashed and nobody noticed for weeks.
>
> Some teams have been working on better replacement for SysV init, but
> without the industrial strength of Red Hat they could only stay niche.

Jonathan de Boyne Pollard, creator of the Nosh system[a], has written an
article about "known problems with System 5 rc":

  https://jdebp.uk/FGA/system-5-rc-problems.html

i've used runit and s6+66 on Void Linux, and on Gentoo am currently
using OpenRC+s6 (the latter for providing user services, which are are
still a work in progress under OpenRC[b]):

  https://wiki.gentoo.org/wiki/User:Flexibeast/guides/OpenRC_user_services_via_s6

My own case is certainly niche, though s6 is extensively used for
containers, via the s6-overlay project, which currently has ~3.8k stars
on GitHub:

  https://github.com/just-containers/s6-overlay


Alexis.


[a] https://jdebp.uk/Softwares/nosh/

[b] https://github.com/OpenRC/openrc/pull/723

[toc] | [prev] | [next] | [standalone]

#16721

Alexis , dans le message <87bjxhnwpz.fsf@gmail.com>, a écrit :
> My own case is certainly niche, though s6 is extensively used for
> containers, via the s6-overlay project, which currently has ~3.8k stars
> on GitHub:

I am rather pleased to ear that s6 has some success, although I know all the
ill its author thinks of containers.

[toc] | [prev] | [next] | [standalone]

#16715

On 11 Dec 2024 23:34:39 GMT, Nicolas George wrote:

> Some teams have been working on better replacement for SysV init, but
> without the industrial strength of Red Hat they could only stay niche.

I wonder what you think Red Hat’s business model could be in forcing 
competitors to adopt technology they developed without paying for it.

[toc] | [prev] | [next] | [standalone]

#16718

On Thu, 12 Dec 2024 08:27:39 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On 11 Dec 2024 23:34:39 GMT, Nicolas George wrote:
>
>> Some teams have been working on better replacement for SysV init, but
>> without the industrial strength of Red Hat they could only stay niche.
>
>I wonder what you think Red Hat’s business model could be in forcing 
>competitors to adopt technology they developed without paying for it.

Dead Rat was the darling of the business community for a long time - even more
so once IBM bought it. It was effectively a replacement for Solaris, HP-UX and 
AIX. So the other distros thought they needed to follow suite in order to pick 
up some of that market. Whether that worked or not I don't know, but its left
us with this legacy of systemd infesting just about every mainstream distro.

[toc] | [prev] | [next] | [standalone]

#16725

On Thu, 12 Dec 2024 09:38:58 -0000 (UTC), Muttley wrote:

> So the other distros thought they needed to
> follow suite in order to pick up some of that market.

Something you pulled out of your fevered imagination, no doubt.

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web