You are not logged in.
Pages: 1
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
Doesn't RHEL7 come with sysVinit as optional/alternative to systemd? If so, there's your answer Alternatively, building OpenRC might be an option if you deploy the OS on multiple instances of said (embedded) system.
Online
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
This is a question to be asked on Red Hat or Fedora forum. And best to do research before asking/answering.
Online
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
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
Offline
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
RHEL7 ... an embedded system
Sounds like "Certified LED blinker based on Arduino with blinking shield".
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
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
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
Pages: 1