To shell or not to shell everything ?

chomwitt · 2025-06-30 22:14:12

Why a shell (by interpreting a sysadm's script) couldnt do what a service manager does ?

ralph.ronnquist · 2025-06-30 22:29:22

It could.

chomwitt · 2025-06-30 23:01:39

So.. if it could .. wouldnt a shell by being more flexible and powerfull be more good at it ?

ralph.ronnquist · 2025-07-01 01:10:38

I think service supervision should be repeatable and robust while flexible. Therefore it's an advantage to use shell scripts. Which is how sysvinit was designed.

Of course, a system that is open and flexible entices and empowers a large number of people to have a go at adjusting scripts and making new ones, and slowly the aggregate system will start to lose it's coherence as well as any original overarching design ideas. And with less and less coherence, newcomers more and more easily get confused and misdirected, so they more or less inadvertently continue exploiting the inherent openness and flexibility to make the aggregate system even less coherent.

To adopt and pursue an original intent would take "unproductive" effort to find such original intent purposefully documented and to digest and assimilate it. This often demands additional layers of learning that typically are well to the side of the immediate objective which most often merely is "to have something working for me right now".

greenjeans · 2025-07-01 01:49:33

^^^Great post, you're a pretty erudite dude RRQ.

chomwitt · 2025-07-01 14:47:13

ralph.ronnquist i should study more sysvinit and runit i guess. My idea was that by using a scripted service-system supervisor you make the system less complex (in comparison to having a another -hardcoded- supervisor). But you argue that shell-scripted control leads to less coherence due to more offered flexibility. So as a metaphore ,the system's services supervisor should be a brick to hold the userspace and not a quicksand ?

chomwitt · 2025-07-01 19:51:32

Interestingly reading about the various service depedency models and what is supported by each system it reminds me of similar discussions regarding apt dependencies. A package A depends on B. So B is installed with A. Now A is gone, what apt should do with B ?
I guess the answer could be fuzzy and elusive.

Which makes me think. Is APT scripted or not? And maybe then my initial question could be better rephrased as : Should a service manager be implemented in a certain programming language or in a scripted (interpreted) language? And a similar question : Is BASH (a shell) a specialized interpreter suited for that kind of job (service-system supervisor) or another interpreter could be better suited ?

EDX-0 · 2025-07-01 20:57:27

writing an init (or parts of an init), service supervision suite/system, or even an init-like daemon with it's client sounds like a good idea, shell even allows you to do some of the needed tasks trivially like gathering the pid of a process started with &, however once you face some of the less trivial and more complex tasks you start to stumble upon walls that you could not have seen purely from having a naive initial design/architecture for the driving daemon and then enter the refactoring purgatory where you can't just simply start refactoring code and changing program architecture but have to plan out every refactor and change so that later down the line when it is finally time to implement the feature no new roadblock will appear from thin air...

https://github.com/eylles/shed

ralph.ronnquist · 2025-07-01 21:00:54

No, service management should not be a brick because it needs openness and flexibility. In my mind, my words were rather an attempt to explain why one might raise the questions you raised; my view is that a service management system needs to be open and flexible in order to be useful in a multitude of circumstances.

Are you seeking answers really, or are you seeking questions? Don't you wish to come to conclusions about those questions you ask, or do you prefer to side step and ask similar or new questions about other sub systems? Why don't you focus on individual functions. such as partitioning or file manager or keyboard mapping?

chomwitt · Yesterday 16:02:43

EDX-0 'shed' you mention used the scripted way. But i dont understand the problems that you refer to and why they would be related intrinsically to an interpreted service manager .

Also i find it interesting that you refer (in the shed project site) to efforts of other projects to make programs demonized. It seems that the different service managers are creating pressure for user apps to have various perhaps incompatible 'APIs' to be 'manageable' by the various service managers.

Last edited by chomwitt (Yesterday 16:17:32)

chomwitt · Yesterday 16:17:04

ralph.ronnquist my questions initially began regarding emacs as a service (dng list).

Then the idea of 'user' services stack in my mind.

Can we consider emacs a 'user' service even if it's a non-automated service? Or we could imagine emacs performing automated text processing from text streams generated somewhere. Or emacs poses as a 'deamon' (a longlasting , always needed service) to project it's ambitions ?

Anyway in that case should we have a service manager per user ? That seems logical if similar needs arise. But in that point i thought.. isnt the shell the main way that a user 'composes' & sets up her/his work ? So could we say that already a user has it's service manager ? (but possibly lacking user gui daemons? Like a maestro lacking an orchestra?) . And how does a user program like emacs , gimp etc become managable by a service manager ? I guess by offering automation of tasks in a permanent way . So my inquiry looks at two sides. A service manager manages programs that 'grow' facilities that beg to be managed by a service manager

So its not just a question of daemonizing wrappers . What would be a related API , needed to be implemented by a process, in order for that process to be admissible to the "orchestra" of a computer system playing the symphony of a service manager?

If broadly speaking a sysadm is a kind of a user why his/her service manager should be fundamentally different ? Adm creates the ground of the userspace. But likewise a 'user' could create the ground for higher lever users.

Interestingly 'shed' user service manager mentioned by EDX-0 seem a sysvinit for each user.

Last edited by chomwitt (Yesterday 18:37:27)

EDX-0 · Yesterday 23:29:53

yes, shed is pretty much a "per user session" sysvinit-like program, that is what i took as a base when i wrote it or well rather my understanding of how sysvinit works is what served as the base for shed tho that is the long term goal for now it is gearing more towards being a generic session process that can provide the debian x-session-manager spec, that is why i wrote about the problems with a fully shell script written service manager as with shed i am stuck in the refactoring purgatory planning multiple refactorings of various functions, a pair of interfaces, shared code and even the build system just so that the features from the todo list are painless to implement once i eventually get there...

The officially official Devuan Forum!

#1 2025-06-30 22:14:12

To shell or not to shell everything ?

#2 2025-06-30 22:29:22

Re: To shell or not to shell everything ?

#3 2025-06-30 23:01:39

Re: To shell or not to shell everything ?

#4 2025-07-01 01:10:38

Re: To shell or not to shell everything ?

#5 2025-07-01 01:49:33

Re: To shell or not to shell everything ?

#6 2025-07-01 14:47:13

Re: To shell or not to shell everything ?

#7 2025-07-01 19:51:32

Re: To shell or not to shell everything ?

#8 2025-07-01 20:57:27

Re: To shell or not to shell everything ?

#9 2025-07-01 21:00:54

Re: To shell or not to shell everything ?

#10 Yesterday 16:02:43

Re: To shell or not to shell everything ?

#11 Yesterday 16:17:04

Re: To shell or not to shell everything ?

#12 Yesterday 23:29:53

Re: To shell or not to shell everything ?

Board footer