Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
|
06-21-2014, 07:52 PM
|
#256
|
Moderator
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,301
|
Quote:
Originally Posted by skarnet
Define "normal".
A change in state in the system is normal to me. Is it abnormal that you install new binaries ? Remove old ones ? chown and chmod ?
|
Assuming that we are still in the context of an init system, a game of musical binaries and permissions is not really "normal".
Quote:
Originally Posted by skarnet
Poor users who will get an obnoxious error message for no reason at all when they try to run something at the same time the package manager is updating it. Please, this is the Microsoft way, not the Unix way.
|
Throw more dust into the air, I think I can still see the point that was being made... (and it is not I who is posting from a Microsoft system!).
Who is talking about sending obnoxious messages to a user anyway? That is quite a leap from the context under discussion.
Quote:
Originally Posted by skarnet
It's not error trapping. It's error checking, and it's a much better programming method than gratuitously introducing race conditions and useless checks. System calls return an error code for a reason, and it's a "normal" case, not an "exceptional" case, whatever that means.
|
With whatever respect due for your work on the S6 system, I suggest that you rethink use of this as a programming axiom.
It is NOT gratuitous introduction of a race condition, and it is NOT a useless test! It IS a decision point, a control flow inflection point, a boolean test, a conditional statement to determine the course of one or more subsequent operations. Once the decision test has been made there is no race. If subsequent operations fail for any reason, including change of permissions or files, it is an error within the context of THAT decision.
It is the difference between control and simple reaction.
Quote:
Originally Posted by skarnet
I will probably not be able to convince you, so this will be my last post on the subject.
|
No need to run and hide. And please, chill a little!
There was nothing confrontational intended in my post, just a perspective that I thought important to mention.
Quote:
Originally Posted by skarnet
Upstream is reachable. Talk to me.
People haven't heard of s6 for the simple reason that I'm a busy man and my free time is better spent designing and coding software than advertising it. Time spent bullying distributions into adopting a piece of software is time not spent making said software better. But I'm realizing more and more that distributions are obviously more sensitive to public relations than to technical merit, so I'll definitely do some more PR in the future.
|
I was trying to talk to you... but I definitely feel alienated at the moment.
Technical merit is in the eye of the beholder, I suppose. One big complaint about systemd is that upstream turns a deaf ear, that is the Poettering method! We don't need another one like it!
|
|
1 members found this post helpful.
|
06-21-2014, 09:36 PM
|
#257
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
Skarnet and Pape both have been reachable which is a vast turn for the better. At least they have been willing to discuss things, and regardless of point of view over methodology, discussion right now is the most important factor here.
|
|
|
06-21-2014, 09:38 PM
|
#258
|
Member
Registered: Nov 2013
Posts: 744
Rep:
|
there is no need to check if a program is there, executable, if you have permissions etc.
the kernel does all that
the filesystem is for permissions and ID's, not the init system
at least if you ask me
Last edited by genss; 06-21-2014 at 09:52 PM.
|
|
2 members found this post helpful.
|
06-21-2014, 10:05 PM
|
#259
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
I'm glad we have LFS as a distribution to work with outside of Slackware because it allows clean room implementations we can port back to Slackware. I'm excited and nervous to build up another init from scratch again.
Maybe soon we can translate our Runit work to Slackware.
|
|
3 members found this post helpful.
|
06-21-2014, 10:10 PM
|
#260
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
Quote:
Originally Posted by skarnet
Just a technical detail here. I don't know what Slackware and LFS do exactly, but there is a very common mistake that's being made often, and even in the glibc internals: checking that a command is present and executable, then executing it. It is wrong because:
- there is a race condition. The state of the command might change between the state and the actual execution.
- it is redundant. The kernel will refuse to execute a program if it's absent (duh) or the user doesn't have permission to.
The right way to run a command if present and executable is to actually execve() it. If the execve() fails, errno will tell why, and the program can react accordingly.
|
Not a race condition.
Think about WHEN the script is run during boot - no logins are active, nor can they be. Thus nothing is there to interfere.
The purpose of checking for the existence and modes is not for the purpose of executing it - it is for the purpose of diagnostics. If something is wrong, it gets reported with decent errors.
Depending on an execv doesn't identify WHICH error it is. That still requires checking.
Depending on the execv doesn't make any difference.
Now checking AFTER an execve fails is reasonable, but not due to race conditions (the execve is going to be used anyway).
Checking after the fact allows the procedure to be a bit more efficient though when there are no errors (if there are no errors, the checks are not done).
Last edited by jpollard; 06-21-2014 at 10:12 PM.
|
|
1 members found this post helpful.
|
06-21-2014, 10:32 PM
|
#261
|
Member
Registered: Nov 2013
Posts: 744
Rep:
|
"Depending on an execv doesn't identify WHICH error it is. That still requires checking"
yes it does...
even errors that can't be found by looking at a file, like EIO
if the error is a generic one, like EACCES, details can be checked after the fact
|
|
|
06-21-2014, 10:32 PM
|
#262
|
Moderator
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,301
|
Quote:
Originally Posted by genss
there is no need to check if a program is there, executable, if you have permissions etc.
the kernel does all that
the filesystem is for permissions and ID's, not the init system
at least if you ask me
|
That is true, as long as the entirety of the execution context is limited exactly to executing the given target. Obviously, if it is either not present, or not executable, it will fail to execute.
But it is incorrect to say that it is a mistake or error to do it otherwise, as with permission and existence tests - the coder may have had other "needs" in mind.
Within the context of an init system, and particularly some specific implementations (I have Slackware in mind), it can lead to logical and even runtime inconsistencies.
For example, in the Slackware init method, and others, setting the executable permission of a script is the very method of configuring what starts at boot time.
So, if we have set a script to NOT be executable, the init scripts test this and SILENTLY ignore those at boot.
Without the test, it would attempt to run the script and the kernel would generate a "Not found" or "Permission denied" message, which might go to /dev/null, or to the dmesg buffer or an error log (maybe other places). But within this context, the script has been configured not to run so the message is redundant at best. When configured NOT to run, there should be no attempt to run it!
My point as before is this: There are many contexts within which scripts can be executed, the one under discussion is init context generally. And within the init context, specifically in the example of Slackware, there is a difference, however trivial it may be considered, in the result.
Also, "absolute efficiency of execution" is not the be-all and end-all criteria. As jpollard noted, generation of meaningful diagnostic messages may be a good reason for testing before execution, and there are others - different constraints, different objectives, different contexts. One size does not fit all - that is the Unix way.
The point is, neither way is a "mistake", the "best" or most appropriate depends on the complete execution context.
Last edited by astrogeek; 06-22-2014 at 01:37 AM.
Reason: Forgot to include a few thoughts, typos, etc...
|
|
1 members found this post helpful.
|
06-21-2014, 10:58 PM
|
#263
|
Member
Registered: Nov 2013
Posts: 744
Rep:
|
Quote:
Originally Posted by astrogeek
For example, in the Slackware init method, and others, setting the executable permission of a script is the very method of configuring what starts at boot time.
So, if we have set a script to NOT be executable, the init scripts test this and SILENTLY ignore those at boot.
|
"
EACCES
Execute permission is denied for the file or a script or ELF interpreter.
"
it does not go anywhere else
EACCES can actually mean 3 other things
Search permission is denied on a component of the path prefix of filename or the name of a script interpreter. (See also path_resolution(7).)
The file or a script interpreter is not a regular file.
The file system is mounted noexec.
first one is our/admins fault (i think)
second is, well, self explanatory and should be checked
third is... it's easy to check but an init system should know that already (unless the "mount" binary is used to mount)
so only conclusion left is it's either not executable or not a valid executable
hmmm
validating that... possible but...
tomorow as i turned off my computer and this craptop can't handle 3 pages open
|
|
2 members found this post helpful.
|
06-22-2014, 07:48 AM
|
#264
|
Member
Registered: Nov 2013
Posts: 744
Rep:
|
Quote:
Originally Posted by genss
so only conclusion left is it's either not executable or not a valid executable
|
correction
execve returns ENOEXEC if the file is not a valid executable, and EACCES if it the executable bit is not set
also checked if it's how bash does things, and yes it does try execve then stat() when that fails
so it's already default on all stock slackware systems
|
|
1 members found this post helpful.
|
06-23-2014, 02:26 AM
|
#265
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
Yes and that scripting style used by Slackware does allow for execution of instance rather than just execution by scripting. Using "if" commented instance scripts allows a far reaching level of flexibility for daemon loading and execution, but it's useful only in the one shot instance of execution phase of stage 1 system core daemon loading. At stage 2 you don't need it and can manage daemons by allowing for symlink existences in the /service execution directory.
Right now the work we've done with Runit exposes this level of flexibility, and I'm hopeful we can utilize this same level of flexibility in s6. The best thing we can do right now is assist in getting projects off the ground, do research, and get alternatives available to the general public.
|
|
1 members found this post helpful.
|
09-22-2014, 05:02 PM
|
#266
|
Senior Member
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982
|
Quote:
Originally Posted by ReaperX7
I trust you've watched this video:
http://www.youtube.com/watch?v=_2aa34Uzr3c
While I don't see it consuming glibc, gcc, or some of the various libraries and some utilities like gawk and others (how the hell could systemd even have it's own libc and compiler is actually intangible), systemd, however, is aiming to be the Core OS of the system or more or less a shell-less sealed off hypervisor running a Linux kernel to which all programs and applications run in their own userspace using cgroups as execution containers with limited permissions across the system using virtual filesystems per application installation.
We even have an OS distribution based on that concept called Core OS.
https://coreos.com/
And another called Android OS.
While for the moment all aspects of systemd are able to be optional, what would happen if that right to opting out of a service vanished? We used to be able to extract udev, now we can't hardly do that because of all the mess of software it creates, and if we want separated udev we have to use eudev. We can't opt out of journald, so what makes you think eventually we won't be able to opt out of networkd, or logind, or whatever else? And yes, Tobi it is a conglomerate project, but the goal of that project is not the goal of the sum of it's parts.
|
This is one of the most informative posts on systemd that I have read. This sums up systemd, what it is, what it stands for, and what is planned for the future.
In one phrase it is the Androidization of Linux, a power grab by Pottering and the corporations that inserted him in his current place for this sole purpose. I'm just taken aback by how quickly systemd was adopted without question and without a fight, not even from my personal hero Linus Torvalds. Well, he did put up some fight, but not enough.
For a while I thought that it would be possible to use other init systems, but udev is under systemd now, and eudev would be the only alternative. With only 3 distros left that haven't adopted systemd, the outlook is grim. Resistance is futile ...
I won't give up the fight tho, or I'll run to BSD if I have to. This whole thing sticks to high heaven. Everything about it is wrong and suspicious. Nothing anyone has said that might be a positive for systemd would make me want to touch it with a barge pole.
I'm still hoping that it all goes horribly wrong for systemd and they toss it out of the kernel like the drunken scoundrel that it is. I'm hoping even more that Linux survives as something that resembles its former self and not Android. If not, RIP Linux, hello BSD.
|
|
6 members found this post helpful.
|
09-22-2014, 05:50 PM
|
#268
|
Member
Registered: Jan 2013
Location: France
Distribution: Slackware 14.1 32 bits
Posts: 211
Rep:
|
Quote:
In one phrase it is the Androidization of Linux, a power grab by Pottering and the corporations that inserted him in his current place for this sole purpose.
|
You are close to the conclusion of many people who remains silent on that very subject.
I don't know if the link below will be a repost, but I highly suggest that you read this article (It's long, but worth it, IMHO) :
http://igurublog.wordpress.com/2014/...ainst-systemd/
It might help you to understand how the Linux kernel and its ecosystem was never really driven by people like you and me,but rather by the folks from RedHat.
Hence why PulseAudio, and systemd are a thing.
---
Quote:
Well, [Linus] did put up some fight, but not enough.
|
You're a bit confused on that one.
Linus has nothing against systemd itself. He just can't stand Lennart's behavior.
|
|
3 members found this post helpful.
|
09-22-2014, 06:41 PM
|
#269
|
Senior Member
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982
|
Quote:
Originally Posted by Nh3xus
You're a bit confused on that one.
Linus has nothing against systemd itself. He just can't stand Lennart's behavior.
|
Yeah, I read his recent comments and he is not against systemd, but he was against Pottering and Sievers and their arrogance and refusal to fix bugs. Either way, I am disappointed.
That is a great article you linked to BTW. The links for there are good too.
This is the article with Linus' POV:
https://www.linuxquestions.org/quest...md-4175518759/
http://www.itwire.com/business-it-ne...ons-on-systemd
I think Linus may be underestimating the situation.
Last edited by metaschima; 09-22-2014 at 06:48 PM.
|
|
1 members found this post helpful.
|
09-22-2014, 08:39 PM
|
#270
|
Member
Registered: May 2008
Location: Republic of Texas
Posts: 393
Rep:
|
In one of LP's musings/ramblings (and sorry, I can't remember the url nor did I bookmark it), he said (quote and unquote):
Code:
We are trying to make an OS here.
So there you are guys - straight from the horse's mouth!!
|
|
|
All times are GMT -5. The time now is 02:35 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|