The officially official Devuan Forum!

You are not logged in.

#1 2019-08-26 20:41:08

pj1967
Member
Registered: 2017-06-24
Posts: 18  

Marginalizing systemd

So, a customer of ours is insisting on RHEL7 (don't know why but I suspect those that make such decisions are not very technically savvy).  So, if one wanted to reduce systemd's functionality within a system that is, for all intensive purposes, an embedded system, what might be a way(s) to accomplish this?  Are there ways to strip it down to nearly nothing, and then call my own "rc.local" scripts to start the few things that I want running?

Offline

#2 2019-08-26 20:58:15

Dutch_Master
Member
Registered: 2018-05-31
Posts: 285  

Re: Marginalizing systemd

Doesn't RHEL7 come with sysVinit as optional/alternative to systemd? If so, there's your answer wink  Alternatively, building OpenRC might be an option if you deploy the OS on multiple instances of said (embedded) system.

Offline

#3 2019-08-26 22:15:11

pj1967
Member
Registered: 2017-06-24
Posts: 18  

Re: Marginalizing systemd

Dutch_Master wrote:

Doesn't RHEL7 come with sysVinit as optional/alternative to systemd? .

Really?  I was under the impression that RHEL7 was SystemD only.  Hmm, I'll have to look into that.

Offline

#4 2019-08-26 22:21:31

golinux
Administrator
Registered: 2016-11-25
Posts: 3,316  

Re: Marginalizing systemd

This is a question to be asked on Red Hat or Fedora forum.  And best to do research before asking/answering.

Offline

#5 2019-08-27 01:10:02

pj1967
Member
Registered: 2017-06-24
Posts: 18  

Re: Marginalizing systemd

golinux wrote:

This is a question to be asked on Red Hat or Fedora forum.  And best to do research before asking/answering.

You really think I'll get a straight answer from an RH forum? :-\  I'd have better luck in a xBSD forum.  Oh, and part of researching is asking those who might know.  But, your irrelevant response is noted.

Last edited by pj1967 (2019-08-27 01:11:48)

Offline

#6 2019-08-27 14:30:33

pcalvert
Member
Registered: 2017-05-15
Posts: 215  

Re: Marginalizing systemd

pj1967 wrote:

So, a customer of ours is insisting on RHEL7 (don't know why but I suspect those that make such decisions are not very technically savvy).

I think you should ask them why they want RHEL7. And perhaps you could try to explain to them why it may not be the best choice for an embedded system.

Phil


Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Another one is called Luxxle.

Offline

#7 2019-08-27 14:56:29

pj1967
Member
Registered: 2017-06-24
Posts: 18  

Re: Marginalizing systemd

pcalvert wrote:
pj1967 wrote:

So, a customer of ours is insisting on RHEL7 (don't know why but I suspect those that make such decisions are not very technically savvy).

I think you should ask them why they want RHEL7. And perhaps you could try to explain to them why it may not be the best choice for an embedded system.

Phil

I think this is a case of the customer employing "corporate" think reinforced by a perceived prestige (undeserved, IMO) that RH has (enlarged to some degree by it's acquisition by IBM).

Since we've already experienced odd performance problems with RHEL7 (RHEL6 works fine for us now), I've already deployed a Devuan-based system for development and testing with the intent to demonstrate Devuan's superiority.  In fact, for our other product lines, I've already deemed Devuan to be the OS going forward.  However, it's likely that systemd has no bearing on our problem.  But, my original post of this thread is my searching for a worst case scenario solution should the customer stick to their demand for RHEL7 and if we are able to resolve the performance problem.

Offline

#8 2019-08-28 04:44:48

ToxicExMachina
Member
Registered: 2019-03-11
Posts: 210  

Re: Marginalizing systemd

pj1967 wrote:

RHEL7 ... an embedded system

Sounds like "Certified LED blinker based on Arduino with blinking shield".

pj1967 wrote:

So, if one wanted to reduce systemd's functionality within a system that is, for all intensive purposes, an embedded system, what might be a way(s) to accomplish this?

You can try to replace init system manually. Yes, it may break most of RHEL in case of updates. But if customer want RHEL7 you can provide the solution he want. You can also try to talk with customer about it and give some recommendations. May be one will decide to use something else instead of RHEL. May be decision will be something like "We care only about RHEL certificate. So install 1 Tb DDR4 RGB Super Gaming RAM and a couple NVMe QLC SSD in RAID 0 as swap. It will be our embedded system.". I never seen embedded linux system with systemd in production. OpenWRT, for example, has own init system.

Offline

#9 2019-09-06 18:00:26

siva
Member
Registered: 2018-01-25
Posts: 282  

Re: Marginalizing systemd

pj1967 wrote:

Are there ways to strip it down to nearly nothing, and then call my own "rc.local" scripts to start the few things that I want running?

It may be fruitful to play around with RHEL in a VM.  You can circumvent init and a service manager (or don't use a service manager at all) pretty easily.  I posted a couple things a few weeks ago that you might find useful.

I don't know your role, why your customer wants RHEL, or how it will be used.  When we want to steer a customer to a better alternative, we usually just let them tell us why they want "their" way, and explain the issues with their thinking.  Then, we suggest a better route.

Based on its stats, how likely is it that RHEL7, which we know is a farcry from RHEL6, will run well on it?  How many more hours will be charged to maintenance?  I don't need an answer, but these are issues with tangible consequences for a customer.

Offline

#10 2019-09-16 18:09:43

pj1967
Member
Registered: 2017-06-24
Posts: 18  

Re: Marginalizing systemd

siva wrote:
pj1967 wrote:

Are there ways to strip it down to nearly nothing, and then call my own "rc.local" scripts to start the few things that I want running?

It may be fruitful to play around with RHEL in a VM.  You can circumvent init and a service manager (or don't use a service manager at all) pretty easily.  I posted a couple things a few weeks ago that you might find useful.

I don't know your role, why your customer wants RHEL, or how it will be used.  When we want to steer a customer to a better alternative, we usually just let them tell us why they want "their" way, and explain the issues with their thinking.  Then, we suggest a better route.

Based on its stats, how likely is it that RHEL7, which we know is a farcry from RHEL6, will run well on it?  How many more hours will be charged to maintenance?  I don't need an answer, but these are issues with tangible consequences for a customer.

Just did exactly that...installed RHEL7 in a VM and limited it's boot to just bringing up the system with console logins.  Turned off all daemons, and use rc.local to invoke the network settings and launch the specific daemons I want running.

I do have parallel systems running Devuan which is my distro of choice, when given the choice, but does require more tinkering to get our software compiled and running (just a matter of cleaning up our software build process to know where generic libraries are located).

Offline

Board footer