[systemd-devel] Regarding the
Hi All, I am new to Systemd, Need help about understanding some of features of the systemd. I am interested in knowing the failure of a service and the exact cause of it. Inside the systemd unit file there are options like SuccessExitStatus and On-failure. In SuccessExitStatus we can specify the signals which when received will be considered as the the successful exit. my question is 1. Any other signal than the ones mentioned in SuccessExitStatus would be considered as the failure(on-failure)? 2. How can we get the exact signal from on-failure? 2. Rather than Restart = on-failure, can we use something like on-failure = xyz.service 3. Is there any Dbus interface exposed by systemd which can be used to get the information like service with unusual exit and the corresponding signal? Thanks in advance. Kindly forgive me if the questions are already answered. Thanks Abhishek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util.c: ignore pollfd.revent for loop_read/loop_write
On Sun, Sep 22, 2013 at 09:10:47PM +0800, cee1 wrote:
Let read()/write() report any error/EOF.
This look OK, but can you provide a bit of motivation?
Zbyszek
---
src/shared/util.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 2009553..3c08650 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -2186,8 +2186,10 @@ ssize_t loop_read(int fd, void *buf, size_t
nbytes, bool do_poll) {
return n 0 ? n : -errno;
}
-if (pollfd.revents != POLLIN)
-return n 0 ? n : -EIO;
+/* We knowingly ignore the revents value
here,
+ * and expect that any error/EOF is reported
+ * via read()/write()
+ */
continue;
}
@@ -2234,8 +2236,10 @@ ssize_t loop_write(int fd, const void *buf,
size_t nbytes, bool do_poll) {
return n 0 ? n : -errno;
}
-if (pollfd.revents != POLLOUT)
-return n 0 ? n : -EIO;
+/* We knowingly ignore the revents value
here,
+ * and expect that any error/EOF is reported
+ * via read()/write()
+ */
continue;
}
--
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Accept EPOLLERR from /dev/kmsg
On Thu, Sep 19, 2013 at 05:03:33PM -0500, Zbigniew Jędrzejewski-Szmek wrote: Also print out unexpected epoll events explictly. --- Hi, could you try with the following patch? Seeing no objections, I pushed the patch :). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journald stops logging when lots of output
On Wed, Sep 11, 2013 at 08:35:49PM +0200, Lennart Poettering wrote: (Of course, journald should not exit under any such circumstances, but to find that we first need to track down why it does that currently). Though it might hide problems, shouldn't journald be configured to automatically be restarted by systemd? -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] License of systemd API
At Hackers News, someone (seemingly involved with OpenRC) claims that the systemd API is somehow licensed under the LGPL. Thus making it impossible for OpenRC to implement the same API. See https://news.ycombinator.com/item?id=6446700 for the entire comments and https://news.ycombinator.com/item?id=6448366 for the specific claim made by the user synchronise. As far as I understood, an API cannot be under any license/copyright. Just the method/code implementing it is. Anyway, to avoid any misunderstandings, could a main developer clarify if the systemd API is or is not under a copyright / license and if it is, which? Thanks. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] License of systemd API
On Thu, Sep 26, 2013 at 03:52:09PM +0200, Olav Vitters wrote: At Hackers News, someone (seemingly involved with OpenRC) claims that the systemd API is somehow licensed under the LGPL. Thus making it impossible for OpenRC to implement the same API. See https://news.ycombinator.com/item?id=6446700 for the entire comments and https://news.ycombinator.com/item?id=6448366 for the specific claim made by the user synchronise. As far as I understood, an API cannot be under any license/copyright. Just the method/code implementing it is. Anyway, to avoid any misunderstandings, could a main developer clarify if the systemd API is or is not under a copyright / license and if it is, which? If you have legal questions, please contact a lawyer, not a programmer. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] main: Set umask before creating any files
This avoids a problem when we inherit a non-zero umask from the
initramfs. This would cause /run/systemd to be created with the wrong
mode.
---
src/core/main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 72bd542..f532dca 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1276,6 +1276,9 @@ int main(int argc, char *argv[]) {
if (in_initrd())
initrd_timestamp = userspace_timestamp;
+/* Set umask before creating any files. */
+umask(0);
+
if (!skip_setup) {
mount_setup_early();
if (selinux_setup(loaded_policy) 0)
@@ -1339,6 +1342,9 @@ int main(int argc, char *argv[]) {
kernel_timestamp.monotonic = 0ULL;
kernel_timestamp.realtime = 0ULL;
+/* Set umask before creating any files. */
+umask(0);
+
} else {
/* Running as user instance */
arg_running_as = SYSTEMD_USER;
@@ -1441,9 +1447,6 @@ int main(int argc, char *argv[]) {
if (arg_running_as == SYSTEMD_SYSTEM) {
/* Become a session leader if we aren't one yet. */
setsid();
-
-/* Disable the umask logic */
-umask(0);
}
/* Move out of the way, so that we won't block unmounts */
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journald stops logging when lots of output
On Thu, Sep 26, 2013 at 2:46 PM, Olav Vitters o...@vitters.nl wrote: On Wed, Sep 11, 2013 at 08:35:49PM +0200, Lennart Poettering wrote: (Of course, journald should not exit under any such circumstances, but to find that we first need to track down why it does that currently). Though it might hide problems, shouldn't journald be configured to automatically be restarted by systemd? I'm not sure but I believe it crashes three times in a row, which is how far systemd will go trying to revive it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] License of systemd API
On Thu, 26.09.13 15:52, Olav Vitters (o...@vitters.nl) wrote: At Hackers News, someone (seemingly involved with OpenRC) claims that the systemd API is somehow licensed under the LGPL. Thus making it impossible for OpenRC to implement the same API. See https://news.ycombinator.com/item?id=6446700 for the entire comments and https://news.ycombinator.com/item?id=6448366 for the specific claim made by the user synchronise. As far as I understood, an API cannot be under any license/copyright. Just the method/code implementing it is. Anyway, to avoid any misunderstandings, could a main developer clarify if the systemd API is or is not under a copyright / license and if it is, which? IANAL, but I think most folks agree that APIs are not copyrightable in most counties. The header files certainly carry the LGPL headers. But that doesn't even matter as most of the APIs are actually exposed via D-Bus, where you don't have any headers... And besides that: the glibc headers carry the word for word identical copyright header (only replacing systemd by GNU C Library). So if those headers are OK for usage with OpenRC the systemd headers should be too. And really, licensing is how Canonical might deal with competition, but not us, we picked the most liberal, compatible and well-known copyleft license there is to stay away from all that mess. They can do with the headers whatever they want, I really don't care, and I pretty much wrote them all... And even if that was an issue, and LGPL would apply to the header files, what would stop the OpenRC folks to implement such a library and make it available under the same terms? That doesn't even have to touch the rest of the OpenRC code. I mean, if they want to be compatible with our library then all they need to make sure that they don't restrict their licensing more than LGPL... Anyway, to me this appears as an uneducated attempt to blame other people for their own incapability... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] License of systemd API
On 2013-09-26 17:11, Lennart Poettering wrote: And besides that: the glibc headers carry the word for word identical copyright header (only replacing systemd by GNU C Library). So if those headers are OK for usage with OpenRC the systemd headers should be too. But, if I understand correctly, OpenRC isn't going to try and re-implement any glibc functionality, but it might try to re-implement systemd functionality. (Even if they did want to re-implement libc, their question would be directed to ANSI or The Open Group(?), not GNU/FSF, because ANSI/TOG are the authors of the C standard/POSIX.) Adam ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] License of systemd API
On Thu, Sep 26, 2013 at 05:46:40PM +0100, Adam Spragg wrote: On 2013-09-26 17:11, Lennart Poettering wrote: And besides that: the glibc headers carry the word for word identical copyright header (only replacing systemd by GNU C Library). So if those headers are OK for usage with OpenRC the systemd headers should be too. But, if I understand correctly, OpenRC isn't going to try and re-implement any glibc functionality, but it might try to re-implement systemd functionality. If you worry about this type of thing, please consult a lawyer who deals with this area of the law. Don't trust random programmers to give you legal advice. Do you ask lawyers for medical advice? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journald stops logging when lots of output
On Thu, 26.09.13 15:46, Olav Vitters (o...@vitters.nl) wrote: On Wed, Sep 11, 2013 at 08:35:49PM +0200, Lennart Poettering wrote: (Of course, journald should not exit under any such circumstances, but to find that we first need to track down why it does that currently). Though it might hide problems, shouldn't journald be configured to automatically be restarted by systemd? We do that, but not indefinitely. See StartLimitInterval=/StartLimitBurst= in systemd.service(5). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] main: Set umask before creating any files
On Thu, 26.09.13 10:50, Mike Gilbert (flop...@gentoo.org) wrote:
This avoids a problem when we inherit a non-zero umask from the
initramfs. This would cause /run/systemd to be created with the wrong
mode.
Merged this, but ordered things so that umask() is only invoked at one
place.
---
src/core/main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 72bd542..f532dca 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1276,6 +1276,9 @@ int main(int argc, char *argv[]) {
if (in_initrd())
initrd_timestamp = userspace_timestamp;
+/* Set umask before creating any files. */
+umask(0);
+
if (!skip_setup) {
mount_setup_early();
if (selinux_setup(loaded_policy) 0)
@@ -1339,6 +1342,9 @@ int main(int argc, char *argv[]) {
kernel_timestamp.monotonic = 0ULL;
kernel_timestamp.realtime = 0ULL;
+/* Set umask before creating any files. */
+umask(0);
+
} else {
/* Running as user instance */
arg_running_as = SYSTEMD_USER;
@@ -1441,9 +1447,6 @@ int main(int argc, char *argv[]) {
if (arg_running_as == SYSTEMD_SYSTEM) {
/* Become a session leader if we aren't one yet. */
setsid();
-
-/* Disable the umask logic */
-umask(0);
}
/* Move out of the way, so that we won't block unmounts */
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Regarding the
On Thu, 26.09.13 18:28, abhishek sharma (abhishek.sharm...@gmail.com) wrote: Hi All, I am new to Systemd, Need help about understanding some of features of the systemd. I am interested in knowing the failure of a service and the exact cause of it. Inside the systemd unit file there are options like SuccessExitStatus and On-failure. In SuccessExitStatus we can specify the signals which when received will be considered as the the successful exit. my question is 1. Any other signal than the ones mentioned in SuccessExitStatus would be considered as the failure(on-failure)? Nope. SIGINT, SIGTERM, SIGHUP, SIGPIPE are never considerd failures, as they generally indicate clean or user triggered termination. 2. How can we get the exact signal from on-failure? Use the bus API, it's all exported. http://www.freedesktop.org/wiki/Software/systemd/dbus/ See the documentation for ExecStartPre, ExecStart, ExecStartPost, ExecReload, ExecStop, ExecStop, ExecMainCode and ExecMainStatus under Service Unit Objects. 2. Rather than Restart = on-failure, can we use something like on-failure = xyz.service There's OnFailure= for this. See systemd.unit(5). 3. Is there any Dbus interface exposed by systemd which can be used to get the information like service with unusual exit and the corresponding signal? Yes, (see above). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
