Before 'systemD' how was it hostorically done to keep serivces/daemons kerenel running through failures

I would love an implementation of SMF in FreeBSD. It's really smart software. I believe it has some configuration management functionality built-in too.
Anyone curses SystemD but praises SMF is a hypocrite. They are basically the same thing. You could say SystemD stole SMF's idea but if having to choose between them, I would choose SystemD. At least SystemD doesn't use XML. The service files are just plain text. I know the guy invented XML is on the Solaris crew but abusing XML everywhere everytime like they did in Solaris is unacceptable. SMF is also very slow, remember parsing manifests at startup? SystemD is much faster than SMF.

Feel free to hate me but if you ask me again I will say this again.
 
I strongly disagree with Unix purists here about a service should be allowed to fail to be able to be debugged. Call me as bad coder (I'm really bad and is an amateur) but who care about code correctness nowadays? If it's not fatal error then just restart it, done, the sky is not falling. Sometime it's just out of memory, just kill it and restart it right away and keep the downtime minimal.

Think about it. If Ultron on Avengers was designed around your Unix purism idea he would just failed to functional if hit by an exception. What allowed him to say: "System back online" right away after he was failed is something like SystemD. Or maybe he's just rebooted. But the main idea remains the same: just restart it, and we are done!
 
Your Unix purists just make the system more fragile (easy to fail), what we need is a durable system, not a correctness system. Hope it helps.
 
I agree about SMF being a bad idea as well. But not at all on the rest. "Just restart" is recipe for desaster.
 
Anyone curses SystemD but praises SMF is a hypocrite.

systemd's criticisms are completely warranted. It was a project that went way out of scope of it's original purpose.

They are basically the same thing.

No, they are not. systemd actually borrowed more from launchd than SMF because it was the desktop that fueled systemd's constraint for socket activation. Just because they both have the capability of restarting daemons on demand does not make them the same implementation.
 
I highly object.
The devices in my surrounding that are by far the most annoying, mainly due to (extremely) poor software quality and hence often bad stability and annoying bugs, are android devices, despite the fact that I still keep their numbers at a bare minimum. I can't remember how often I had to unplug my FireTV stick because it lags horribly or is completely unresponsive (I mean, really? that thing has a quad core CPU FFS!!). Same on the android phone in my car which also acts up every few days and essentially only has to stream some music, which was possible without any hazzle 15 years ago with the computing equivalent of a todays refrigerator. My impression of android is: code quality throughout the whole stack decreases rapidly, so they throw more and more abstraction layers and frameworks to it "because this makes it easier to write working code", which leads to an overall even more bloated and bug-ridden system.
The last OS I'd rely on for something that just absolutely has to work would be android (I'm not counting that mouse-only OS here). Yes, it boots on everything, but the ecosystem is a dumpster fire.
Thats why my main phone is still a Blackberry Classic with BBOS (QNIX), just because it still 'just works'™


It might be because I mostly worked as a one-man show in small/mid-sized companies, but my attitude to this is just: If my boss doubts my expertise if I tell him X is best suited for that task, he can start searching for a new sysadmin. But I can imagine how it works in bigger companies, so I'd suggest starting with low-hanging fruit and e.g. promote OpenBSD for security-critical stuff and/or networking. Word about OpenBSDs security should be known even to the most ignorant levels of management and as soon as "BSD" is somewhat familiar for them it might be easier to slip a few more servers in here and there, even running FreeBSD.
Hmmm... I see what you are saying about the Android and abstraction layer to safeguard crap code. I always wanted a QNIX OS blackberry phone; however, I was not able to get one before they discontinued them from normal suppliers, and now my service provider has disconnected service for 3G. I do not own a smart phone; however, I will be looking for one since my 3G will stop soon.

To be honest, I had no clue Android was buggy, and I do not have a modern car that has something of the sort. I still drive a 1995 jetta for the simple fact that I can still repair everything on it myself (just replaced the fuel pump last weekend).
 
I was an electronic engineer and designed a medical computer for eye surgery. If you ever had eye surgery, there's a 50/50 chance the surgeon used my machine, before 2000, and current machines by the same company still use my basic design.

I used a real-time operating system that was not Unix or BSD or Linux anything else. There was no disk drive--it booted out of EPROM--but it did save data in nonvolatile memory. It had a real time clock and watchdog timer as described above. I guess sitting in an operating room with probes inflating someone's eye is as mission critical as you can get.
That sounds really neat!!! Thank you for posting. That is what always amazed me of the Commodore, it just booted from an os on EPROM and directly into a coding environment/os. ++laugh++ c64/c128 were ahead of the times, since it had instant boot into os/coding environment - now days we have SSD and OS. ++laugh++
 
This papering over serious problems reminds me of Windows reboot syndrome.
In Windows you can set a service to take action on:
* First failure
* Second failure
* Subsequent failure

Possible actions:
* Take No Action (default)
* Restart the Service
* Run a Program
* Restart the Computer

There's also a class of Windows services viz. "Critical System Services" e.g. lsass.exe, smss.exe, etc.
If you change their in-use resources, you have to restart the system.
How to idendify them: enum RM_APP_TYPE is set to RmCriticial in RM_PROCESS_INFO structure.

Of course they're different from Windows Critical Error i.e. BSOD. Reaction to BSOD is modifiable through registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

If you look at Android and Cell phones - they are operating without issues, and car companies are leaving QNX for Android.
"without issues" is another name for "lost advanced civilisations". it doesn't exist.
The story of Patriot Missile Failure, arithmetic errors and 24 bit fixed point register:
http://www-users.math.umn.edu/~arnold//disasters/patriot.html | UMN.edu

I wanted to talk to folks that did embedded systems for projects like NASA and other mission critical aspects that might be beyond the scope of Linux and FreeBSD.
When it comes to "Embedded System", electronics is the most important topic.
IMO. Frankly, 'FreeBSD vs Linux' and/or (systemd)?"bad":"good"; etc is rather off-topic.
I'm not talking about raspbian-enabled Pi, sitting on the table, running ^C/^V-ed code.

Final words:
IMO, electronics 101 is essential to embedded systems. Here's two paper-books (my favourite!).
First item has a new edition, I don't have it, but I think 2nd edition is good enough!

1. The Art of Electronics 2nd Edition (Horowitz, 1989)
2. Digital Logic and Computer Design (Mano, 1979)
 
I'm using daemon(8) to deamonize various jobs/services/scripts and use its -r option for stuff that I specifically want to keep running (e.g. the fancontrol scirpt on my homeserver). I often wish '-r' would take another argument to specify how often daemon should try to restart the service.
8BitGlitch, this is also an answer to your initial question. In ancient days, the X11 display manager xdm(8) was started this way; it was only restarted in case it failed. Unlike nowadays, it was common to not restart the Xserver(1) after each user session. sko, try this: in ttys(5) (traditionally called inittab(5) on other systems), add
Code:
arg_to_fancontrol "/usr/local/bin/fancontrol -min 0 -max 4000"    unknown   on window="/usr/local/bin/before -this -is -optional"
If your service fails too quickly, init(8) will pause for 30 seconds before restarting it again. The older ones will remember a message like this from init(8):/usr/X11/bin/xdm respawning too fast, spleeping for 30 seconds...
 
No, they are not. systemd actually borrowed more from launchd than SMF because it was the desktop that fueled systemd's constraint for socket activation. Just because they both have the capability of restarting daemons on demand does not make them the same implementation.
OK, so systemd and launchd are basically the same thing. IMHO, cursing systemd but on the other hand trying to port launchd to FreeBSD is ridiculous. How double standard! Accept it. You people want launchd. You hate systemd as simply you hate anything Linux originated!
 
This is just nonsense. What "we" want (well, most of us I assume) AND get is a well-designed system that's robust, simple and efficient to operate. What some want is service supervision (for clearly defined usecases), which always existed and can be provided without integrating it into init. What some others want is a "faster" bootup with something that seems "simpler" than shellscripts, but for most, this isn't interesting. After all, FreeBSD's init/rc has always been simpler and more reliable than SysV. Dependencies are handled well, and init-scripts are typically short and simple thanks to a well thought-of framework.

Systemd is not Linux. The fact that it's written FOR Linux and used by many Linux distributions has nothing to do with the actual problem: it's a huge overcomplicated mess. The few Linux distributions avoiding it don't do that because they "hate Linux".
 
This is just nonsense. What "we" want (well, most of us I assume) AND get is a well-designed system that's robust, simple and efficient to operate. What some want is service supervision (for clearly defined usecases), which always existed and can be provided without integrating it into init. What some others want is a "faster" bootup with something that seems "simpler" than shellscripts, but for most, this isn't interesting. After all, FreeBSD's init/rc has always been simpler and more reliable than SysV. Dependencies are handled well, and init-scripts are typically short and simple thanks to a well thought-of framework.

Systemd is not Linux. The fact that it's written FOR Linux and used by many Linux distributions has nothing to do with the actual problem: it's a huge overcomplicated mess. The few Linux distributions avoiding it don't do that because they "hate Linux".
If SystemD is cross platform and BSD licensed, will FreeBSD adopt it?

And what do you think about using Python instead of shell for init/rc? I don't like shell, at all.
 
Too many people think we should have systemd because....because...uh, er....cause EVERYBODY HAS IT!!! and no other reason.
This is not me. I have never said anything like that. BTW, I know I'm off topic. I'm out. Sorry everyone.
 
OK, so systemd and launchd are basically the same thing. IMHO, cursing systemd but on the other hand trying to port launchd to FreeBSD is ridiculous. How double standard! Accept it. You people want launchd. You hate systemd as simply you hate anything Linux originated!
We don't want launchd. You are a little out of touch with the direction of FreeBSD.

There is like 1 guy working on it: https://github.com/mheily/jobd

And even then it supports Linux too.
 
If SystemD is cross platform and BSD licensed, will FreeBSD adopt it?

And what do you think about using Python instead of shell for init/rc? I don't like shell, at all.
Python over shell!!! Good god no to Python. Before long you will have a 200MB dependency library. I would take POSIX shell over Python any day if you are just slinging together commands to do something; however, I would take Perl over both, yet it is helpful to have the Shell support Arrays, but that is already an add on option and available in FreeBSD.

But you are getting really off topic, and trying to high jack this great community thread with hostile intent from 3.000,00m high.

++trolling time, get your nets out++
Coming from the network side of the industry, live in Tcl and Lua. However before that, I used Perl since the mid 90s and it served us 90s folks great. I know some could argue that Python is better then Perl, and that is ok; however, SnakeOil does nothing more, nothing less then Perl did since 1995 with Cpan. Only thing Python has/had, which Perl never had was a major company, with dogmatic followers that poached the designer of Python. ++laugh++ OOP who that? You talking crazy now.... Id didn't need no stinking OOP to make some of the greatest games of the 90s.

++First catch of the day, time to go back to Dutch Harbor (Blasting in background - wagner flying dutchman overture)++
 
8BitGlitch, this is also an answer to your initial question. In ancient days, the X11 display manager xdm(8) was started this way; it was only restarted in case it failed. Unlike nowadays, it was common to not restart the Xserver(1) after each user session. sko, try this: in ttys(5) (traditionally called inittab(5) on other systems), add
Code:
arg_to_fancontrol "/usr/local/bin/fancontrol -min 0 -max 4000"    unknown   on window="/usr/local/bin/before -this -is -optional"
If your service fails too quickly, init(8) will pause for 30 seconds before restarting it again. The older ones will remember a message like this from init(8):/usr/X11/bin/xdm respawning too fast, spleeping for 30 seconds...
Thank you!!! This helps to understand the history and life cycle of the OS. Much appreciated.
 
Python over shell!!! Good god no to Python. Before long you will have a 200MB dependency library. I would take POSIX shell over Python any day if you are just slinging together commands to do something; however, I would take Perl over both, yet it is helpful to have the Shell support Arrays, but that is already an add on option and available in FreeBSD.
What I mean is not really our normal Python but Bython:


A 200MB dependency will never happen with Bython, since we control it tightly. We have no control over Python, so they are not the same.
 
What I mean is not really our normal Python but Bython:


A 200MB dependency will never happen with Bython, since we control it tightly. We have no control over Python, so they are not the same.
I woudn't say never, and I am not sure if a language that has objects or structure like calls belongs in a POSIX glue language as you say. Why write something like python "xyz.zyx.x" when something like "dh -h" is so much easier? And (echo "Embraer EMB 314 Super Tucano" >> foo.txt) is so much easier then "write.object".

Plus do not have to reinvent the wheel. Lua with add ons so we can get all those embedded folks helping the FreeBSD ecosystem or promote Perl, but again - does it make sense as a glue language.

This is a great discussion but getting way off topic!!!
 
There was a need/want for a more modern init system. Some may it's a natural successor to init/rcNG. The potato got too hot though.
 
Back
Top