are you sure ?

the titanic did sink 'cuz of the captains, and companies, pride
but the engineers made it possible by not sealing the parts over the compartments

Daily Mail is not exactly the official newspaper of the Royal Academy. Let's say, its competence in archeology is questionable.

Also, there is no archaeological evidence to prove a past global Flood, i.e. sea level rise to approximately one to four kilometer(s) up.

And about the Titanic's captain, he knew there are icebergs and decided to continue on, instead of making a detour. Titanic was designed to withstand a major disaster, but sadly the impact was more powerful than it could bear. In few words, no ship will resist to an impact with a iceberg.

In other words, the passengers paid practically with their lives, the captain's pride of having the shortest transatlantic journey.

1 members found this post helpful.

tbh i don't blame the captain, he made a decision and went down with the ship
shows he thought it is the right decision at the time but accepted that it was not

(all hail offto... err i mean sry for offtopic, feel free to delete)

No, and you just showed why.

systemd doesn't know if the process is ready. It ASSUMES it is ready when 1 is started. It doesn't KNOW it is ready for 2 to depend on 1. That is why NetworkManager had to be modified to tell systemd the network is ready (for the "NetworkManager-wait-online.service"). Unfortunately, NetworkManager doesn't know if the network is actually ready... most of the time it is, except when it isn't.

The administrator is NOT in control.

That is the illusion of control.

Get rid of all the services that are started "-nodaemon", and you will get closer. Get rid of all the services that start trees of service - and you get closer yet. But by then you have a nearly useless system.

Alternatively, bloat each service with hooks to tell systemd that it is ready...

The fancier the plumbing, the easier it is to get the toilets stopped up

And the more fancier it gets the harder it is to fix things.

I'm sorry but Slackware is not just some Pet Project by Patrick. If it was, then obviously how the hell did it last this long? That's a very condescending remark towards one of the longest maintained GNU/Linux distributions available that has various levels of support from community to enterprise level support vectors, most of which come from private enterprises specializing in enterprise UNIX systems and solutions.

Titanic was a disaster waiting to happen with a flawed design that was meant to intercept only one kind of disaster... a torpedo. It was not designed to prevent catastrophic hull failure. Each hull compartment only protected the ship from directed sideways impacts, not multiple compartment failures and long area damages. It was a clear design that was built on ego and saying it was unsinkable. Well guess what happened? The damn thing sunk.

Since that time, no ocean liner in the world can be built of that size, tons of safety regulations were enacted, and various protocols involving ocean travel route allowances have been put into place... and all to make sure an accident like Titanic NEVER happens again.

The phrase "bigger is better" is outdated, overzealous, and egotistical at best. It's basically putting the cart before the horse. A horse was bred to pull things, not push things. The same aspect should be used with Linux.

At least with sysvinit there is only one critical failure point. Sysvinit itself. With systemd you have multiple fail points.

As far as the big brand Linux being on any level better than other distributions... then by all means if you feel so strongly about them, go use them. If you have the money to pay for and subscribe to their services for help, updates, support, etc. by all means, please exercise your choice.

Not to be obtuse with this next statement... I only mean it in humor... But I'd rather have a Linux distribution ran by a bunch of red necks, hillbillies, Okies, hippies, and beatniks of the GNU community that make a distribution that feels more like home than some corporate generated city slicker swill job.

5 members found this post helpful.

Agree. There is no archaeological evidence attesting the Great Flood.

But there is geological evidence that certifies an very similar event, which produced a global mega-tsunami with a height of 5km. It took 66 million years ago, when it produced the extinction of the dinosaurs and 99% of species of animals and plants.

The problem is that us the human species, Homo Sapiens Sapiens, we have no more than 250 000 years. However, most people on Earth have in the oral history the concept of the Great Flood, which caused a massive extinction of life on Earth. How is possible for them to known an event from 66 million years ago? No one known.

I do not see any problem as a Pet Project to be also a excellent and long-lasting operating system. When the writer is a genius, both are possible. Why not? Try not to put it all to heart.

In other hand, I have a question about systemd. How can I start Apache and MySQL? I mean, I need some help to configure these services.

Because them not start after I installed the systemd's packages.

There is possible evidence of a rather large flood when the Black sea was flooded from the Mediterranean.

Most of the "Western" oral history is carried from the middle east - and there were floods that occurred locally - causing local disasters, such as Santorini. A rather large disaster of "global" proportions, at least as far as the people were concerned. Oral history spreads as the survivors spread, thus becoming "global".

Also, remember that ships at sea are relatively immune to tsunamis, so a cargo ship far enough away from the Santorini explosion would survive (if they were outside most of the ash fall), but arrive at a port that was wiped out. It is even possible for ships relatively close to shore to be placed far inland - and occupants could even survive, even if unlikely.

Very likely, it is being started before the network is ready. This was VERY common with systemd before the changes to NetworkManager were made to try to work around the assumption that something is ready just because a service was started. That was why the "NetworkManager-wait-online.service" was created - it forces systemd to wait until NetworkManager thinks the network is ready. It usually is, but I'm not sure if the firewall is actually ready before NetworkManager sends the message. But it should be close as loading firewall configurations is usually quite fast.

Another possible problem is that Apache may be being started before MySQL is ready. But that evidence would be implied if MySQL got started, but Apache did not (it is weak evidence, as both could be being started simultaneously - at which point it is nearly random as to the order of startup). I believe the mysqld service got modified as well... (see mariadb-wait-ready.service - another tentacle).

This is one of the reasons systemd has so many tentacles. Each service has to phone home to systemd to say it is ready... and more dependencies on dbus.

I think the developers had so much trouble with it, that to force systemd to work at all, they dumped the sysVinit process entirely. Systemd just isn't compatible.

Originally, they planned to release systemd as an option for Fedora 14. Use either one... But it didn't work, so they delayed until Fedora 15. With Fedora 15 they gave no choice. If you DID try to use the previous init system (upstart), very little would actually work. So it was a complete drop of the sysVinit/upstart (and that "compatibility" is not really compatible - it is in name only. Yes, it runs the scripts... but you don't have much control over WHEN the scripts run, and you have little control over any other dependencies (other than internal ones).

BTW, if you are missing log entries of the errors - that is also a problem with systemd. They have attempted (I haven't satisfied myself they "fixed" the problem yet) to work around THAT problem too. Due to the thundering herd scheduling of startup, it is possible that a burst of messages overflows the message queue. That was part of the purpose of journald (and another dependency) and routing error messages through systemd. Errors no longer go to the console device log. Stderr/stdout is routed to systemd instead, which then passes it to journald... (another tentacle).

I was just browsing the mysqld.service file- if you modify the file limits, they warn that you ALSO have to modify systemd file limits as well... this looks like a bit of a kludge, as I suspect it is because myslqd would inherit some limits from systemd, where mysqld used to be independent of the particular init system... They also assume nothing will depend on it (WantedBy=multi-user.target) It also means that other processes started by systemd will get that limit too...

Guys, you all have been warned several times now. Do I really have to be the bad moderator and give you people a break from posting on LQ? Is systemd really that much a pain for you that it is impossible for you to keep this thread on topic? It seems to me that you all are grown up and reasonable persons, why is it so hard not to fall back in your general discussions about Red Hat/systemd/whatever if those discussions clearly are not the topic and there were already several warnings from different moderators?

yes. It is a pain.

And since you ask, that is why it is causing so much trouble getting it to work.

The problems being seen are the same ones that happened with Fedora. And each time the fix has been to put yet another feedback point between the FORMERLY independent service and systemd.

I think we need to look into creating an entire batch of service start scripts to ensure proper start ups are made. Maybe even some custom scripts as well if systemd will allow it. Maybe we need to rethink this like Slackware scripts and not just traditional ways. That way we could maybe use if and else triggers for tighter controls.

Indeed ReaperX7, thats why I started with this.
The more we can do with services scripts for slackware, the easier it will be everyone by the time if it is needed.
If pat never includes systemd, than it is good to know what is possible and what not.
if pat includes systemd, we as community has helped alot in testing, creating scripts, documentation, etc.

1 members found this post helpful.

+1

... or, the *less* that's done, the easier. Ideally, IMO, systemd would just hand off to the existing unchanged /etc/rc.d/rc.{0,4,6,K,M,S} scripts, and then get on with being pid 1, sexting kdbus etc etc.

Anyone looked at systemd-shim?

Thats the problem. for some things (like MySQL) you can't. There is no way for systemd to know if the service is ready for dependencies.

Now scripts will work in some cases. Especially those where there are no dependencies. These are very simple. The really simple ones don't even need a script though - systemd itself can start these (that is where the "-nodaemon" option occurs).

The others are not. They require the service itself to be modified.

Part of the problem is caused by the "monitoring" of processes that systemd does. If the service is required, then systemd has to know when it terminates. Normal process cleanup is still done, but a script starts other processes... thus systemd cannot know what those other processes are. So that requires the script to not exit unless its child process exits (or to do an exec of that process, which works too).

The next part of the problem is more severe. Systemd has to know when it is possible to start any dependent services. The only way for that to happen is to modify the actual service to send back the right message... This requires each such service to be modified.

That is why it is so intrusive.

The dependency graph analysis causes a number of problems. The process gets started, but it takes time to initialize. In the default case (no notification), systemd assumes the service is ready as soon as it starts it, and that permits any depending process to be started... even though the process may take a good bit of time before it can work. In the case of MySQL, it has to process the configuration files, validate the database is usable, open network sockets, and THEN be ready to respond to connections. If the dependent service is started too soon, it gets a "cannot connect" in the case of MySQL and aborts. Another issue is that if the process fails after a time (after processing the configuration files and finds an error)... The dependent service also gets a "cannot connect". And the two errors do not have to come out in order - the depending service error can occur, with its error message BEFORE, the original process has determined its failure... thus causing confusion as to which error is caused by what failure.

Usually this can be figured out when there is a tight dependency like that between a database server and its clients... But it gets tricky when it is between something more generic, like a network initialization... Or more complex as in starting VMs...

This is also the symptom where processes are explicitly waiting for the network, and don't start... because the network took too long to initialize. Works fine when started AFTER logging in. No issues at all. It would also likely work if you just added a 10 second delay before starting the process during boot - which is why a number of people resorted to putting "systemctl start ...." sequences in rc.local. It made it easy to put a sleep at the beginning, then put the startup explicitly in order. And if things still didn't work, sticking sleeps after each startup. Of course, that is also completely bypassing what systemd is supposed to do.

Passing stuff back to the BSD scripts might be a solution if we can minimize how many scripts systemd uses on it's own before the hand off...

rc.local!!!! Why didn't I see it earlier... Think about it. Instead of mitigating everything to systemd service handlers that can be started by systemd, leave only the bare minimum for systemd and symlink a modified rc.M to the systemd friendly rc.local with everything else to be loaded traditionally. Of course you'd have to remake the local script to wait until rc.M is finished, but if it could be done, it'd solve the whole of the problem.

2 members found this post helpful.

Only briefly... It looks like it is the code needed to be added to some services to interact with systemd. (from https://github.com/desrt/systemd-shim)

But it doesn't seem very complete, nor up to date.