Make systemd units/targets as runlevels for init# command? [SOLVED]

jackie · 2021-09-02 18:19:12

im aware runlevels are a bit antiquated but id like to be able to create/alter them for use with the init# command.

so i know targets are the analogous contemporary equivalent, yes? but can i have my personalized targets correspond to runlevels for use with that command? how would i go about that?

its my understanding there is backwards compatibility with runlevels?

Last edited by jackie (2021-09-03 00:29:10)

Slithery · 2021-09-02 18:53:21

Just make the required services depend on the relevant systemd target, this is all covered in the documentation...
https://www.freedesktop.org/software/sy … level.html

jackie · 2021-09-02 19:16:58

Slithery wrote:

Just make the required services depend on the relevant systemd target, this is all covered in the documentation...
https://www.freedesktop.org/software/sy … level.html

appreciate the answer friend. apologies im aware this question has answers elsewhere,
but was unable to get an answer sufficiently clear to give me confidence in doing so. i suppose i just wanted to knowboth:

- whether i could and should create/alter custom runlevels with personalized units
-if running init(#), potentially at a custom runlevel# entirely, would mean fucking up my systemd configuration.

appreciate the link

but if i could further inquire:
i rmember when i configured my debian server, i read in a book that each unit has a link with a file setting parameters for the unit like wants and needs. which is what i used to configure bootup.

but upon googling im confused if there is a systemd directory containing a symbolic link to that file in each service's installation dir or vice versa?

And im trying to understand how the systemd subdir which is implicated in the links or files is referenced? What references it during initialization?
I looked this up on google but maybe im not wording it properly enough to yield the results i want, but i want to know
Will systemctl overwrite my personalized file, will it recognize it as enabled manually?
orwill it overwrite any personalized edits upon initialization, like how NetworkManager does? like if i were to create the links/files in the systemd dir without using systemctl "enable" (or alter them after using it )?
again sorry for the stupid questions. seriously appreicate the reply. really want to be sure

edited a ton to really clarify what im asking. apologies for my lack of vocabulary on the subject to articulate my questions meaningfully /

Last edited by jackie (2021-09-02 22:15:29)

loqs · 2021-09-02 19:41:35

jackie wrote:

Will systemctl overwrite my personalized file or will it recognize it as enabled manually?

Have you read systemctl daemon-reload?

jackie wrote:

or if i use systemctl enable , will it overwrite my personalized edits upon initialization? like if i were to create the links in the systemd dir/service dir?

See systemctl enable

jackie · 2021-09-02 20:07:33

loqs wrote:

jackie wrote:
Will systemctl overwrite my personalized file or will it recognize it as enabled manually?
Have you read systemctl daemon-reload?
jackie wrote:
or if i use systemctl enable , will it overwrite my personalized edits upon initialization? like if i were to create the links in the systemd dir/service dir?
See systemctl enable

Hey, the daemon man page you linked contains much of what im looking for. I had gotten an idea from the systemd man page, i tried to look for daemon but maybe i put systemctl daemon. Sockets was the word that was on the tip of my tongue. I knew id know it. I actually looked at sockets in systemd earler idk why thought i was wrong

but that contains plainly stated that the daemon is regulated by *sockets* which set parameters for units. Including the active vs. static enabled status which is what i was concerned with. Thank you so much friend

Am i correct in my understanding of the chronology of reference during initialization?

systemd --> initalizes targets --> which initialize specific units --> which are regulated by sockets (as both individuals/targets, yes?)--> which ultimately determine the chain of process execution by defining conditional factors and executing wants/needs ?
(I think something struggle with is Idont have confidence in my judgement.)

Last edited by jackie (2021-09-02 21:21:56)

Slithery · 2021-09-02 20:43:25

An enabled socket means that the relevant service won't start until a request to it is made.
An enabled service will start at the relevant runlevel.

Not all services have or require a socket.

jackie · 2021-09-02 20:52:31

Slithery wrote:

An enabled socket means that the relevant service won't start until a request to it is made.
An enabled service will start at the relevant runlevel.
Not all services have or require a socket.

Oh okay! so this is where I was getting confused !

rThank you so much this is what I needed. I would mark the thread solved if i knew how because that gives me the info i needed. ill put it in the title idk if im supossed to flag it any other way

I was so confused looking for the files that regulate the processes in systemctl list-units. And I actually briefly looked at the socket files in the /etc/systemd directory the other day and was able to add a couple manual configurations. But quickly concluded i must be mistaken in thinking these are the files i was after. because many units i want to edit are listed in systemctl list-units but didnt have a socket file.

Just to be sure, so if i make a socket file for any unit which doesnt have one, that means there are no pre-defined conditional factors to that unit in initialization that I could upset? like beyond being envoked elsewhere (by a target,need, etc.)

Last edited by jackie (2021-09-03 00:29:59)

Slithery · 2021-09-02 21:31:35

jackie wrote:

Thank you so much this is what I needed. I would mark the thread solved if i knew how because that gives me the info i needed

RTFW....
https://wiki.archlinux.org/title/General_guidelines

jackie · 2021-09-02 21:43:03

Slithery wrote:

jackie wrote:
Thank you so much this is what I needed. I would mark the thread solved if i knew how because that gives me the info i needed
RTFW....
https://wiki.archlinux.org/title/General_guidelines

lmao I read the man pages but couldnt find an answer that stated plainly and succinctly

I think my problem is that I dont trust my own judgement enough. I actually was able to gather from what I read in wiki/man pages that sockets were what I was after.

But I was, stupidly, confident that sockets must not be what im after. I was so certain that I had read in The Linux Bible by Christopher Negus that these files were universal for units, could be grouped, and were responsible for assigning parent/child status (i assumed via wants/needs), for every step of initialization. I actually reread a few chapters yesterday and still had that impression. But I mightve been thinking of master/slave in network interface bonding, which I was also doing and reading about yesterday.

regardless, i appreciate the help and the clarification.

Last edited by jackie (2021-09-02 22:21:17)

Arch Linux

#1 2021-09-02 18:19:12

Make systemd units/targets as runlevels for init# command? [SOLVED]

#2 2021-09-02 18:53:21

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#3 2021-09-02 19:16:58

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#4 2021-09-02 19:41:35

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#5 2021-09-02 20:07:33

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#6 2021-09-02 20:43:25

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#7 2021-09-02 20:52:31

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#8 2021-09-02 21:31:35

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

#9 2021-09-02 21:43:03

Re: Make systemd units/targets as runlevels for init# command? [SOLVED]

Board footer