SlackwareThis 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.
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.
and this is why the systemd contribution list grow and grow, but who cares about facts and details
btw, there are astonishing names to find ...
in comparison with others systemd provides a lot of documentation an information, but again, you have your opinion and are imune against facts, I know
you guys that think this is a Red Hat thing and they want to take over and make it only for them understandable and make Linux proprietary are not very sane. look at you mobile phones and complain about the right stuff.
Unfortunately, Man pages do not equal API documentation. API documents tell how the API itself works, what it works with, other APIs it interacts with, and what it can be used for. Man pages only describe usage vectors of interfaces with the system wether they are files, binaries, scripts, etc, but they don't explain the API.
API documentation is often but not always built from documentation in the code itself that explains functionality providing usage examples for developers and project leaders. Usually this documentation is excessively thorough and meticulous in detail.
Unfortunately, Man pages do not equal API documentation. API documents tell how the API itself works, what it works with, other APIs it interacts with, and what it can be used for. Man pages only describe usage vectors of interfaces with the system wether they are files, binaries, scripts, etc, but they don't explain the API.
API documentation is often but not always built from documentation in the code itself that explains functionality providing usage examples for developers and project leaders. Usually this documentation is excessively thorough and meticulous in detail.
do you want a java like documentation or do you just don't know what you are talking about.
oh, I understand, you have heard that argument some where, it sounds good, and now you repeat it
I've read the documentation they've "conveniently" provided, but the underlying libsystemd0 API still is not complete in documentation because parts of the API are still not properly documented to understand how they function, or explain what exactly the function is doing. Is this not spoken clearly enough for you to understand?
Repeating the argument? That damn bloody argument is well known yet conveniently avoided because nobody wants to admit it!
Do you know how the libsystemd0 API works? If so, please, by all means enlighten us!
I've read the documentation they've "conveniently" provided, but the underlying libsystemd0 API still is not complete in documentation because parts of the API are still not properly documented to understand how they function, or explain what exactly the function is doing. Is this not spoken clearly enough for you to understand?
Repeating the argument? That damn bloody argument is well known yet conveniently avoided because nobody wants to admit it!
Do you know how the libsystemd0 API works? If so, please, by all means enlighten us!
do you mean that things like
Code:
int sd_journal_previous(sd_journal *j);
int sd_journal_next(sd_journal *j);
are not expressive enough ?
to enlighten you, and prove one more time that you have no idea what you are talking about and therefore just spread worthless and wrong rumours and show what it is worth if a 'damn bloody argument is well known' by you
I quote here as example one file from the systemd public interface and then you tell me how much API doc you want and what you miss
Code:
/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
#ifndef foosddaemonhfoo
#define foosddaemonhfoo
/***
This file is part of systemd.
Copyright 2013 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.
systemd is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see <http://www.gnu.org/licenses/>.
***/
#include <sys/types.h>
#include <inttypes.h>
#include "_sd-common.h"
_SD_BEGIN_DECLARATIONS;
/*
The following functionality is provided:
- Support for logging with log levels on stderr
- File descriptor passing for socket-based activation
- Daemon startup and status notification
- Detection of systemd boots
See sd-daemon(3) for more information.
*/
/*
Log levels for usage on stderr:
fprintf(stderr, SD_NOTICE "Hello World!\n");
This is similar to printk() usage in the kernel.
*/
#define SD_EMERG "<0>" /* system is unusable */
#define SD_ALERT "<1>" /* action must be taken immediately */
#define SD_CRIT "<2>" /* critical conditions */
#define SD_ERR "<3>" /* error conditions */
#define SD_WARNING "<4>" /* warning conditions */
#define SD_NOTICE "<5>" /* normal but significant condition */
#define SD_INFO "<6>" /* informational */
#define SD_DEBUG "<7>" /* debug-level messages */
/* The first passed file descriptor is fd 3 */
#define SD_LISTEN_FDS_START 3
/*
Returns how many file descriptors have been passed, or a negative
errno code on failure. Optionally, removes the $LISTEN_FDS and
$LISTEN_PID file descriptors from the environment (recommended, but
problematic in threaded environments). If r is the return value of
this function you'll find the file descriptors passed as fds
SD_LISTEN_FDS_START to SD_LISTEN_FDS_START+r-1. Returns a negative
errno style error code on failure. This function call ensures that
the FD_CLOEXEC flag is set for the passed file descriptors, to make
sure they are not passed on to child processes. If FD_CLOEXEC shall
not be set, the caller needs to unset it after this call for all file
descriptors that are used.
See sd_listen_fds(3) for more information.
*/
int sd_listen_fds(int unset_environment);
/*
Helper call for identifying a passed file descriptor. Returns 1 if
the file descriptor is a FIFO in the file system stored under the
specified path, 0 otherwise. If path is NULL a path name check will
not be done and the call only verifies if the file descriptor
refers to a FIFO. Returns a negative errno style error code on
failure.
See sd_is_fifo(3) for more information.
*/
int sd_is_fifo(int fd, const char *path);
/*
Helper call for identifying a passed file descriptor. Returns 1 if
the file descriptor is a special character device on the file
system stored under the specified path, 0 otherwise.
If path is NULL a path name check will not be done and the call
only verifies if the file descriptor refers to a special character.
Returns a negative errno style error code on failure.
See sd_is_special(3) for more information.
*/
int sd_is_special(int fd, const char *path);
/*
Helper call for identifying a passed file descriptor. Returns 1 if
the file descriptor is a socket of the specified family (AF_INET,
...) and type (SOCK_DGRAM, SOCK_STREAM, ...), 0 otherwise. If
family is 0 a socket family check will not be done. If type is 0 a
socket type check will not be done and the call only verifies if
the file descriptor refers to a socket. If listening is > 0 it is
verified that the socket is in listening mode. (i.e. listen() has
been called) If listening is == 0 it is verified that the socket is
not in listening mode. If listening is < 0 no listening mode check
is done. Returns a negative errno style error code on failure.
See sd_is_socket(3) for more information.
*/
int sd_is_socket(int fd, int family, int type, int listening);
/*
Helper call for identifying a passed file descriptor. Returns 1 if
the file descriptor is an Internet socket, of the specified family
(either AF_INET or AF_INET6) and the specified type (SOCK_DGRAM,
SOCK_STREAM, ...), 0 otherwise. If version is 0 a protocol version
check is not done. If type is 0 a socket type check will not be
done. If port is 0 a socket port check will not be done. The
listening flag is used the same way as in sd_is_socket(). Returns a
negative errno style error code on failure.
See sd_is_socket_inet(3) for more information.
*/
int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port);
/*
Helper call for identifying a passed file descriptor. Returns 1 if
the file descriptor is an AF_UNIX socket of the specified type
(SOCK_DGRAM, SOCK_STREAM, ...) and path, 0 otherwise. If type is 0
a socket type check will not be done. If path is NULL a socket path
check will not be done. For normal AF_UNIX sockets set length to
0. For abstract namespace sockets set length to the length of the
socket name (including the initial 0 byte), and pass the full
socket path in path (including the initial 0 byte). The listening
flag is used the same way as in sd_is_socket(). Returns a negative
errno style error code on failure.
See sd_is_socket_unix(3) for more information.
*/
int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t length);
/*
Helper call for identifying a passed file descriptor. Returns 1 if
the file descriptor is a POSIX Message Queue of the specified name,
0 otherwise. If path is NULL a message queue name check is not
done. Returns a negative errno style error code on failure.
See sd_is_mq(3) for more information.
*/
int sd_is_mq(int fd, const char *path);
/*
Informs systemd about changed daemon state. This takes a number of
newline separated environment-style variable assignments in a
string. The following variables are known:
READY=1 Tells systemd that daemon startup is finished (only
relevant for services of Type=notify). The passed
argument is a boolean "1" or "0". Since there is
little value in signaling non-readiness the only
value daemons should send is "READY=1".
STATUS=... Passes a single-line status string back to systemd
that describes the daemon state. This is free-from
and can be used for various purposes: general state
feedback, fsck-like programs could pass completion
percentages and failing programs could pass a human
readable error message. Example: "STATUS=Completed
66% of file system check..."
ERRNO=... If a daemon fails, the errno-style error code,
formatted as string. Example: "ERRNO=2" for ENOENT.
BUSERROR=... If a daemon fails, the D-Bus error-style error
code. Example: "BUSERROR=org.freedesktop.DBus.Error.TimedOut"
MAINPID=... The main pid of a daemon, in case systemd did not
fork off the process itself. Example: "MAINPID=4711"
WATCHDOG=1 Tells systemd to update the watchdog timestamp.
Services using this feature should do this in
regular intervals. A watchdog framework can use the
timestamps to detect failed services. Also see
sd_watchdog_enabled() below.
Daemons can choose to send additional variables. However, it is
recommended to prefix variable names not listed above with X_.
Returns a negative errno-style error code on failure. Returns > 0
if systemd could be notified, 0 if it couldn't possibly because
systemd is not running.
Example: When a daemon finished starting up, it could issue this
call to notify systemd about it:
sd_notify(0, "READY=1");
See sd_notifyf() for more complete examples.
See sd_notify(3) for more information.
*/
int sd_notify(int unset_environment, const char *state);
/*
Similar to sd_notify() but takes a format string.
Example 1: A daemon could send the following after initialization:
sd_notifyf(0, "READY=1\n"
"STATUS=Processing requests...\n"
"MAINPID=%lu",
(unsigned long) getpid());
Example 2: A daemon could send the following shortly before
exiting, on failure:
sd_notifyf(0, "STATUS=Failed to start up: %s\n"
"ERRNO=%i",
strerror(errno),
errno);
See sd_notifyf(3) for more information.
*/
int sd_notifyf(int unset_environment, const char *format, ...) _sd_printf_(2,3);
/*
Similar to sd_notify(), but send the message on behalf of another
process, if the appropriate permissions are available.
*/
int sd_pid_notify(pid_t pid, int unset_environment, const char *state);
/*
Similar to sd_notifyf(), but send the message on behalf of another
process, if the appropriate permissions are available.
*/
int sd_pid_notifyf(pid_t pid, int unset_environment, const char *format, ...) _sd_printf_(3,4);
/*
Returns > 0 if the system was booted with systemd. Returns < 0 on
error. Returns 0 if the system was not booted with systemd. Note
that all of the functions above handle non-systemd boots just
fine. You should NOT protect them with a call to this function. Also
note that this function checks whether the system, not the user
session is controlled by systemd. However the functions above work
for both user and system services.
See sd_booted(3) for more information.
*/
int sd_booted(void);
/*
Returns > 0 if the service manager expects watchdog keep-alive
events to be sent regularly via sd_notify(0, "WATCHDOG=1"). Returns
0 if it does not expect this. If the usec argument is non-NULL
returns the watchdog timeout in µs after which the service manager
will act on a process that has not sent a watchdog keep alive
message. This function is useful to implement services that
recognize automatically if they are being run under supervision of
systemd with WatchdogSec= set. It is recommended for clients to
generate keep-alive pings via sd_notify(0, "WATCHDOG=1") every half
of the returned time.
See sd_watchdog_enabled(3) for more information.
*/
int sd_watchdog_enabled(int unset_environment, uint64_t *usec);
_SD_END_DECLARATIONS;
#endif
The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:
Undocumented switches to systemd, systemctl and otherwise
The internal protocols used on the various sockets such as the sockets /run/systemd/shutdown, /run/systemd/private.
What does this mean for you? When developing with systemd, don't use any of the latter interfaces, or we will tell your mom, and she won't love you anymore.
This is supposed to be GPLv2.1 licensed software under the Free Open Source banner, yet they still refuse to document parts of systemd considered to be private? Last I heard, and knew, nothing under the GPL banner was proprietary, private, or closed off by any means, including documentation.
This is supposed to be GPLv2.1 licensed software under the Free Open Source banner, yet they still refuse to document parts of systemd considered to be private? Last I heard, and knew, nothing under the GPL banner was proprietary, private, or closed off by any means, including documentation.
They don't refuse to documents these parts, they just don't promise that these interfaces will stay stable as says the last sentence of the last paragraph, that you unfortunately omitted to quote (emphasize added):
Quote:
You are welcome to use the other interfaces listed here, but if you use any of the second kind (i.e. those where we don't yet make a stability promise), then make sure to subscribe to our mailing list, where we will announce API changes, and be prepared to update your program eventually.
Anyway these API are of no use to yourself, so maybe you could consider letting the developers speak for themselves.
The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:
Undocumented switches to systemd, systemctl and otherwise
The internal protocols used on the various sockets such as the sockets /run/systemd/shutdown, /run/systemd/private.
What does this mean for you? When developing with systemd, don't use any of the latter interfaces, or we will tell your mom, and she won't love you anymore.
This is supposed to be GPLv2.1 licensed software under the Free Open Source banner, yet they still refuse to document parts of systemd considered to be private? Last I heard, and knew, nothing under the GPL banner was proprietary, private, or closed off by any means, including documentation.
this is something very normal. there is a public, stable interface and the private internal one with implementation.
every library component and even the kernel has this.
you criticise things you do not understand with strong arguments and so you expose more and more of your lack of knowledge.
you guys that think this is a Red Hat thing and they want to take over and make it only for them understandable and make Linux proprietary are not very sane.
I certainly don't think this is just a Red Hat thing. Ubuntu makes a lot of brain-dead decisions as well. If some new fad arrives tomorrow you can be sure Ubuntu will have their agents publishing stories about how Ubuntu will have this new fad in their repos before the week is out. New phone? No problem. We'll have it before the month is out. New tablet? No problem; we'll have that for you yesterday. Let's go with upstart. No, forget that, we'll go with systemd instead. Why don't we create Mir to replace x11? No forget that, we'll use Weston instead. Gnome have made spectacularly stupid decisions as well. Who knows who they were really working for, eh? openSuse made a spectacularly stupid decision some years ago that they've never recovered from. Enterprise Linux? Don't make me laugh. I work with several companies and they would laugh in your face if you suggested they should go with invasive, untested, broken technology like systemd.
You seem to think just because virtually every distro out there has chosen to adopt systemd that this is a vindication of systemd. It's not; it just shows that the Linux lemmings will jump off any cliff as long as they're told to. Docker is another example; it was barely out a few months yet Red Hat decided it was stable enough to include in their "enterprise" offerings. Is it any wonder our "enterprises" are collapsing all around us, when we have decisions like this made?
Anything I have suggested in this post should not be construed as an attack on your employer, whoever that is.
Take a break from this thread by the way; you're getting far too hysterical over choices other people are making for themselves.
Last edited by Gerard Lally; 02-17-2015 at 03:17 AM.
systemd is Linux in a mall.
All those distros gathered in a loose marketplace, with multiple entry and exit points. Far better to throw a wall, with a single doorway, round the lot of them. That way, shoppers can go where they please, in the mall, but you can monitor who goes in and out, through the single doorway. Red Hat is the wall and systemd is the doorway.
Everything about the implementation of systemd rings alarm bells. It stinks of hidden agendas, perception management, debate shaping and the intentionally hurtful dismissal of dissent. This is how policies that are known to be unfair or disadvantageous are rammed through. I spend long periods of time debating in political forums. What I see with systemd is exactly the same as I saw when it was time to pretend Russia was and had always been 'the eternal enemy', or that Corporate tax evasion is a good thing, or that the answer to an out of control class of ultra-wealthy individuals having screwed the global economy was to punish the poor. Suddenly there's a new idea in town. Anyone who questions it is likened to holocaust deniers or supporters of terrorism; their posts described as "whining" or "crying". The proponents of this 'new idea' are rude, arrogant, nasty, dishonest, pedantic with others yet liberal with themselves, etc. They achieve their goals by bullying everyone into accepting their idea as "the only idea worth having" and by ridiculing opponents. If they get a Moderator onside (and no, that's not an accusation) then so much the better because they then begin to silence dissent officially.
The whole exercise is about creating the perception that the new idea is the only idea with any value; the new idea is so self evident that dissenters merely show their feebleminded stupidity when they disagree; the new idea is so good that every idea that went before it was trying to be what the new idea embodies; that the originators of the new idea are so far above everyone else that they have no need of manners, mercy, respect, debating skills or any of the other restrictions you and I have to abide by; and that anyone who does not wish to follow the new idea is so backward and old fashioned that it's a wonder they've got as far as clothing.
I'd almost go as far as saying that as soon as you see that sort of behaviour, you know the idea being mooted is a rubbish one as good ideas don't need to bully their way to being accepted. I see this behaviour everywhere, from the British Parliament to the way charities deal with staff who take the Mission too seriously. It's a management technique and it's a very effective one, but if you're on the wrong end of it you can end up questioning your own sanity.
systemd is Linux in a mall.
All those distros gathered in a loose marketplace, with multiple entry and exit points. Far better to throw a wall, with a single doorway, round the lot of them. That way, shoppers can go where they please, in the mall, but you can monitor who goes in and out, through the single doorway. Red Hat is the wall and systemd is the doorway.
Everything about the implementation of systemd rings alarm bells. It stinks of hidden agendas, perception management, debate shaping and the intentionally hurtful dismissal of dissent. This is how policies that are known to be unfair or disadvantageous are rammed through. I spend long periods of time debating in political forums. What I see with systemd is exactly the same as I saw when it was time to pretend Russia was and had always been 'the eternal enemy', or that Corporate tax evasion is a good thing, or that the answer to an out of control class of ultra-wealthy individuals having screwed the global economy was to punish the poor. Suddenly there's a new idea in town. Anyone who questions it is likened to holocaust deniers or supporters of terrorism; their posts described as "whining" or "crying". The proponents of this 'new idea' are rude, arrogant, nasty, dishonest, pedantic with others yet liberal with themselves, etc. They achieve their goals by bullying everyone into accepting their idea as "the only idea worth having" and by ridiculing opponents. If they get a Moderator onside (and no, that's not an accusation) then so much the better because they then begin to silence dissent officially.
The whole exercise is about creating the perception that the new idea is the only idea with any value; the new idea is so self evident that dissenters merely show their feebleminded stupidity when they disagree; the new idea is so good that every idea that went before it was trying to be what the new idea embodies; that the originators of the new idea are so far above everyone else that they have no need of manners, mercy, respect, debating skills or any of the other restrictions you and I have to abide by; and that anyone who does not wish to follow the new idea is so backward and old fashioned that it's a wonder they've got as far as clothing.
I'd almost go as far as saying that as soon as you see that sort of behaviour, you know the idea being mooted is a rubbish one as good ideas don't need to bully their way to being accepted. I see this behaviour everywhere, from the British Parliament to the way charities deal with staff who take the Mission too seriously. It's a management technique and it's a very effective one, but if you're on the wrong end of it you can end up questioning your own sanity.
A really excellent analysis. The Russia example has been on my mind for days. A revolution is stitched up in Ukraine and the country is reduced to rubble, but it's the innocent party that gets blamed for it? Are we living in the same world we were living in just 20 years ago, when at least some sanity still prevailed? The lunatics have definitely taken over the asylum, and as you say it's a common trend extending well beyond just Linux and systemd. Thank you for expressing this idea so well and in such a civil yet devastating way. The immature should reflect long and hard on this post.
And the GNU/Linux conservatives are considered backwards "grey beards of UNIX" who are anti-progress, fearing change, and against the status-quo hurting GNU/Linux's chance at gaining it's lionshare of the marketplace against Apple, Microsoft, and Google.
It must be quaint and exciting throwing away quality for quantity and wiping your ass with tradition and stable foundations.
This is a good and honest answer. I think that many of the most vocal systemd opponents, whatever their apparent rationalizations, do feel that way. I have the same knee-jerk reaction about systemd, when it comes to _my_ machines - the ones I manage, use and want to control and understand. And I also had the same reaction about udev, HAL, dbus, all the *kit, and more generally all the Desktop Environment things.
Now, when it comes to providing a comfortable environment to regular end-users, especially in a corporate environment, it is another story. Most end-users do want a desktop environment, with all the bells and whistles. It obviously can be done without systemd, but my understanding is that systemd is becoming a better, more consistent platform to build a robust desktop (see the KDE developer blog post cited above).
Whatever we may think of the big DE (KDE, Gnome) developers and of the large distros technical leaders, these guys are smart and knowledgeable, and have spend lots of time and effort understanding systemd before adopting it.
We may just not be the right target for their stuff.
I agree, but as far as I am concerned KDE and Gnome have had their chance. 20 years is long enough to get a desktop as good as any of the Windows desktops, yet for all the manpower at their disposal they have failed to come up with something people will use without even noticing. I have not managed to convert one single customer to long-term Linux use over the past 9 years. Some bug will invariably come back to bite me, and I have always ended up having to reinstall Windows. Yet the major desktops are telling us another decade of instability is what is needed?
Sorry, had your chance. Failed. Goodbye. I use Linux and BSD without a desktop for servers and firewalls, Windows for desktops.
I certainly don't think this is just a Red Hat thing. Ubuntu makes a lot of brain-dead decisions as well. If some new fad arrives tomorrow you can be sure Ubuntu will have their agents publishing stories about how Ubuntu will have this new fad in their repos before the week is out. New phone? No problem. We'll have it before the month is out. New tablet? No problem; we'll have that for you yesterday. Let's go with upstart. No, forget that, we'll go with systemd instead. Why don't we create Mir to replace x11? No forget that, we'll use Weston instead. Gnome have made spectacularly stupid decisions as well. Who knows who they were really working for, eh? openSuse made a spectacularly stupid decision some years ago that they've never recovered from. Enterprise Linux? Don't make me laugh. I work with several companies and they would laugh in your face if you suggested they should go with invasive, untested, broken technology like systemd.
You seem to think just because virtually every distro out there has chosen to adopt systemd that this is a vindication of systemd. It's not; it just shows that the Linux lemmings will jump off any cliff as long as they're told to. Docker is another example; it was barely out a few months yet Red Hat decided it was stable enough to include in their "enterprise" offerings. Is it any wonder our "enterprises" are collapsing all around us, when we have decisions like this made?
Anything I have suggested in this post should not be construed as an attack on your employer, whoever that is.
Take a break from this thread by the way; you're getting far too hysterical over choices other people are making for themselves.
no facts, opinions, parts of paranoia and posing that you are more clever than all the 'Linux lemmings'.a nd than you say I should take a break
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
