Re: [systemd-devel] autoconf cache collision in check for gnuefi
Thanks Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: fix check for efi-lds file
Using the DIR macro breaks caching and has no benefit as it only offers
performance improvements when AS_FOR is used with a single element list.
Also --with-lds-dir= was broken as we never set have_efi_lds in this case.
Fix this and check if PATH actually contains the efi-lds file.
---
configure.ac | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 419b5d4..14518bc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1182,9 +1182,10 @@ AS_IF([test x$enable_gnuefi != xno], [
have_efi_lds=no
AC_ARG_WITH(efi-ldsdir,
AS_HELP_STRING([--with-efi-ldsdir=PATH], [Path to EFI lds
directory]),
-[EFI_LDS_DIR=$withval],
+[EFI_LDS_DIR=$withval
AC_CHECK_FILE([${EFI_LDS_DIR}/elf_${EFI_ARCH}_efi.lds],
+[have_efi_lds=yes])],
[AS_FOR([DIR], [EFI_LDS_DIR], [${efiroot}/gnuefi
${efiroot}],
-[AC_CHECK_FILE([DIR/elf_${EFI_ARCH}_efi.lds],
+
[AC_CHECK_FILE([${EFI_LDS_DIR}/elf_${EFI_ARCH}_efi.lds],
[have_efi_lds=yes break])])])
AS_IF([test x$have_efi_lds = xyes],
[AC_SUBST([EFI_LDS_DIR])],
--
2.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] autoconf cache collision in check for gnuefi
2015-03-05 1:22 GMT+01:00 Mirco Tischler mt...@gmx.de: Thanks Mirco Sorry I messed up, this was supposed to be. I figured it out. Patch in seperate Mail ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] autoconf cache collision in check for gnuefi
Hi
I get the following error when doing ./configure --enable-gnuefi:
checking for /usr/lib/gnuefi/elf_x86_64_efi.lds... no
checking for /usr/lib/elf_x86_64_efi.lds... (cached) no
configure: error: *** gnuefi support requested but files not found
even though the second file exists on my system.
In the lines: configure.ac:1186
[AS_FOR([DIR], [EFI_LDS_DIR], [${efiroot}/gnuefi
${efiroot}],
[AC_CHECK_FILE([DIR/elf_${EFI_ARCH}_efi.lds],
AC_CHECK_FILE doesn't expand the DIR variable and creates the cached
variable ac_cv_file_DIR_elf_x86_64_efi_lds, which is then falsely
reused for all DIRs. I'm not sure if this is an autotools or systemd
issue.
systemd version: current git
autoconf version: 2.69
on Arch Linux
Thanks
Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to prevent sleep during running oneshot units
Am 13.02.2014 00:14 schrieb Kai Krakow hurikha...@gmail.com: Mirco Tischler mircotisch...@gmx.net schrieb: It's late here so excuse me if I'm missing something. But wouldn't a simple Before=sleep.target suffice to implement b)? I'm not sure... The unit is not enabled, only triggered by the timer - so it may work. I think I may try that as an alternative to systemd-inhibit. Systemd-inhibit just does not feel like the right tool for this. If your backup job is still running it blocks sleep.target's start until it finishes. Then, what happens if I start using my system during backup, sleep.target had been triggered but is waiting for the backup job to finish? Will it simply go to sleep then while I am using the system? OTOH, will systemd- inhibit cover that case? Yeah, the job to start sleep.target will still be active, so this should only work for overnight stuff. Twisted around: What happens if sleep is triggered by the system due to idle time while sleep is inhibited? Will it trigger as soon as the inhibit is removed again? Or will the idle timer for my system just trigger sleep again after it has passed a second time? Systemd-inhibit has the options block and delay for this. But when and if the idle time gets restarted is up to the idle timer ;-) Though for the grace period some ugly hack such as ExecStartPost=/usr/bin/sleep n would be required. My primary concern here is btrfs doing a lot of background work when handling snapshots. My backup medium is a btrfs with rsync copying the source as in-place deltas to a scratch area, then taking a snapshot of it. Later, I'd like to automatically cleanup old snapshots - but that means I should wait before going back to sleep until btrfs finished that job. A simple sleep probably won't do. I suppose it would require an option like --wait to btrfs subvolume delete, then wait another 5 minutes to give all pending write commits a chance to make it to disk. Sounds like you want systemd-inhibit for both your backup service and the btrfs subvolume delete 'service'. And the kernel will call sync() before suspending, shouldn't that suffice? -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to prevent sleep during running oneshot units
Am 12.02.2014 01:31 schrieb Kai Krakow hurikha...@gmail.com: Hey there! Hey I've got a daily backup job scheduled using a timer unit and a oneshot service file. This backup takes around 2-4 hours. It's using rsync and syncs from btrfs HDD to a snapshotted btrfs on USB with inplace deltas. I'm mentioning this because it may matter. I've also set my system to auto-sleep after 4 hours of idle time. This means, in KDE I've set the option to put the system to sleep after that time of inactivity. This usually works fine. But sometimes during backup, the system cannot sleep. I see it still powered fully on the next morning. In dmesg, a lot of btrfs and blockdev related tracebacks accumulated with notes of being unable to sleep because a processed has refused to stop. I don't know if this is btrfs-related or not - but actually I don't think it's wise to go to sleep while the backup process is still running either. There may be a bug here, because almost every time when that happened it looks like systemd has suspended my network connection but didn't bring it back online after the system refused to go to sleep. I need to restart NetworkManager then or reboot (I prefer reboot to alleviate any other side effects that may have had). But what actually results from this is the following question: How do I prevent systemd from trying to go to sleep while the backup job is running? I'd like it to either (a) do not go to sleep at all (do not even try) or (b) defer the sleeping signal until the backup job finished, with (b) preferred plus some grace time. I don't know if something like Conflicts=sleep.target would do the job, I even do not know if that would be a good idea at all. It's late here so excuse me if I'm missing something. But wouldn't a simple Before=sleep.target suffice to implement b)? If your backup job is still running it blocks sleep.target's start until it finishes. Though for the grace period some ugly hack such as ExecStartPost=/usr/bin/sleep n would be required. Ah, and then another one, more or less unrelated: Lennart one time told me that it's on the feature plan for systemd to wake the system up for selected timer units and put it back to sleep afterwards. It would be a nice-to-have. Still on the feature list? Maybe any news on that? I'd like to test it. Another one, partially unrelated: I've set up the backup mount point with automount in systemd (via fstab). Is it possible to automatically undo that automount upon finishing the backup job? If I explicitly call umount, the job could wait forever if I accidently left a shell open in that directory. This more or less concludes to the question: Could automount units also automatically unmount after some idle time (after nothing any longer accessed the volume)? -- Replies to list only preferred ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Am 16.01.2014 22:15 schrieb Chris Murphy li...@colorremedies.com: On Jan 16, 2014, at 1:58 PM, Kai Krakow hurikha...@gmail.com wrote: Chris Murphy li...@colorremedies.com schrieb: Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. I'd recommend to place /var/log/journal on a subvolume so it is not affected by snapshotting. You can do separate snapshots for it (tho I cannot imagine why you would want to do it). That way you get a snapshot protection for these files, too, and you are free to roll back the rest of the system without affecting this subvolume. Aha, good idea. So then I mount the subvol at /var/log/journal? Is there any risk of journald writing to rootfs /var/log/journal before the subvolume is mounted? Or is the flush to persistent storage sufficiently delayed as to not be a concern? Chris Murphy Afair, you don't need to mount subvolumes. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora 16 and upstart
2013/5/3 Chinmay Mahata chinmay_mah...@rediffmail.com Hi, Thanks a lot, everybody for your support, for quick and valuable comments. So it is time for me to write the systemd service scripts (and bite the bullet !!! to be frank, I am not feeling much confident). Now I have few queries (may sound like dumb questions). 1. How can I call user-defined shell(bash) functions from the service scripts in ExecStartPre and ExecStartPost sections? Like I have a shell file /home/me/my_functions_file, inside it, there is a function foo_function. I used different ways (below) in my scripts but all failed miserably. EnvironmentFile=/home/me/my_functions_file ExecStartPre=foo_function param1 -- ExecStartPre=/bin/bash /home/me/my_functions_file; foo_function param1 -- ExecStartPre=/home/me/my_functions_file ExecStartPre=foo_function param1 Nothing is working (strangely, not getting any error messages) No this won't work. Systemd is not a shell. Simply write a bash script where you do all your stuff and then put that as the ExecStart line. 2. How can I run multiple instances of an executable with different arguments? You might be able to use template units. Name your service name@.service and then you can start it as name@arg.service and reference arg via the %i and %I (large i) specifiers in the ExecStart line. http://www.freedesktop.org/software/systemd/man/systemd.unit.html has further information. 3. How can I use user-defined signals in the service scripts? Does http://www.freedesktop.org/software/systemd/man/systemd.kill.html help you? Please give me a few clues. Best regards, --Chinmay Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora 16 and upstart
2013/5/2 Chinmay Mahata chinmay_mah...@rediffmail.com Hi All, Sorry for asking such a noob question. I am migrating my system from fedora 13 (fc13) to fedora 16 64-bit (fc16 x86_64) version. In fc13 all our module service scripts are written for upstart/initctl. In fc16, there is no upstart/initctl support any more, but there is systemd as the init system. Hi You do realise that F16 is EOL and won't receive any updates (not only systemd, but in general)? I'd strongly recommend using F18 instead. So my queries are: 1. Is there any way I can reuse my upstart initctl scripts in fc16 x86_64? 2. What are items/things I need to do in fc16 so that I can reuse the old initctl scripts? Please help me out by sending me your solutions/suggestions. Upstart scripts aren't supported. You need to rewrite them as systemd unit files. If you're lucky, that isn't too much work though ;-) Thanks in advance. Best regards, --Chinmay Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: remove duplicate MESSAGE= from log message
This was needed with log_struct_unit() but log_notice_unit() adds it
anyway.
---
src/core/unit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index c0c3ce9..b624ca6 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1468,7 +1468,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
if (ns != os ns == UNIT_FAILED) {
log_notice_unit(u-id,
-MESSAGE=Unit %s entered failed
state., u-id);
+Unit %s entered failed state.,
u-id);
unit_start_on_failure(u);
}
}
--
1.8.2.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journal issues
2013/4/12 Steven Hiscocks steven-syst...@hiscocks.me.uk Hi, I'm having two issues in relation to the journal with my recent upgrade to v201. One issue, is that it appears that _MACHINE_ID field is missing the = character. I had a quick look, and I think the bug was introduced on the last part of the following commit: http://cgit.freedesktop.org/**systemd/systemd/commit/src/** journal/journald-server.c?id=**adb435bb70815461eeddf44dd5d6f1**fc2ad9026dhttp://cgit.freedesktop.org/systemd/systemd/commit/src/journal/journald-server.c?id=adb435bb70815461eeddf44dd5d6f1fc2ad9026d The second issue, is it appears that _SOURCE_MONOTONIC_TIMESTAMP is being truncated to just _SOURC. I'm not clear where this issue was introduced. Hi My guess is http://cgit.freedesktop.org/systemd/systemd/commit/src/journal/journald-server.c?id=a569398925430de1f8479262e8ab39502054f2e9 Both issues can be easily seen with journalctl output in export format. I've seen this issue on two of Arch Linux x86_64 systems. Thanks :) A patch to fix this follows up. On an unrelated note: Is DECIMAL_STR_MAX() in macro.h broken for types longer than 64 bit, or am I just too thick to understand this line: sizeof(type) = 8 ? 20 : sizeof(int[-2*(sizeof(type) 8)]))) ? Thanks Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: fix broken tags _SOURCE_REALTIME_TIMESTAMP and _MACHINE_ID
---
src/journal/journald-server.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 53e3830..be84323 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -538,7 +538,7 @@ static void dispatch_message_real(
char pid[sizeof(_PID=) + DECIMAL_STR_MAX(ucred-pid)],
uid[sizeof(_UID=) + DECIMAL_STR_MAX(ucred-uid)],
gid[sizeof(_GID=) + DECIMAL_STR_MAX(ucred-gid)],
-source_time[sizeof(_SOURCE_REALTIME_TIMESTAMP= +
DECIMAL_STR_MAX(usec_t))],
+source_time[sizeof(_SOURCE_REALTIME_TIMESTAMP=) +
DECIMAL_STR_MAX(usec_t)],
boot_id[sizeof(_BOOT_ID=) + 32] = _BOOT_ID=,
machine_id[sizeof(_MACHINE_ID=) + 32] = _MACHINE_ID=;
@@ -699,7 +699,7 @@ static void dispatch_message_real(
r = sd_id128_get_machine(id);
if (r = 0) {
-sd_id128_to_string(id, machine_id + sizeof(_MACHINE_ID) - 1);
+sd_id128_to_string(id, machine_id + sizeof(_MACHINE_ID=) -
1);
IOVEC_SET_STRING(iovec[n++], machine_id);
}
--
1.8.2.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journal issues
2013/4/13 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl On Sat, Apr 13, 2013 at 01:00:02AM +0200, Mirco Tischler wrote: 2013/4/12 Steven Hiscocks steven-syst...@hiscocks.me.uk Hi, I'm having two issues in relation to the journal with my recent upgrade to v201. One issue, is that it appears that _MACHINE_ID field is missing the = character. I had a quick look, and I think the bug was introduced on the last part of the following commit: http://cgit.freedesktop.org/**systemd/systemd/commit/src/** journal/journald-server.c?id=**adb435bb70815461eeddf44dd5d6f1**fc2ad9026dhttp://cgit.freedesktop.org/systemd/systemd/commit/src/journal/journald-server.c?id=adb435bb70815461eeddf44dd5d6f1fc2ad9026d The second issue, is it appears that _SOURCE_MONOTONIC_TIMESTAMP is being truncated to just _SOURC. I'm not clear where this issue was introduced. Hi My guess is http://cgit.freedesktop.org/systemd/systemd/commit/src/journal/journald-server.c?id=a569398925430de1f8479262e8ab39502054f2e9 Both issues can be easily seen with journalctl output in export format. I've seen this issue on two of Arch Linux x86_64 systems. Thanks :) A patch to fix this follows up. On an unrelated note: Is DECIMAL_STR_MAX() in macro.h broken for types longer than 64 bit, or am I just too thick to understand this line: sizeof(type) = 8 ? 20 : sizeof(int[-2*(sizeof(type) 8)]))) That's what's called an inline compile time check ;) Zbyszek Makes sense. Thanks :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
2013/3/5 Holger Winkelmann h...@travelping.com Hi David, On Mar 5, 2013, at 9:52 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. Thats what I expected anyway, so for our logging purposes I would like to have structured logging… So thanks for the Info, I'll wait for the Documentation of the raw format (or we check the C implementation) for the time being we use the C-Lib. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- Holger Winkelmann Managing Director Out of curiosity, what are your reasons to avoid the C library? And I personally don't ever expect the raw format to be documented - I see it as an implementation detail, not part of any kind of API Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
2013/3/5 Holger Winkelmann h...@travelping.com On Mar 5, 2013, at 10:21 PM, Mirco Tischler mt...@gmx.de wrote: 2013/3/5 Holger Winkelmann h...@travelping.com Hi David, On Mar 5, 2013, at 9:52 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. Thats what I expected anyway, so for our logging purposes I would like to have structured logging… So thanks for the Info, I'll wait for the Documentation of the raw format (or we check the C implementation) for the time being we use the C-Lib. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- Holger Winkelmann Managing Director Out of curiosity, what are your reasons to avoid the C library? And I personally don't ever expect the raw format to be documented - I see it as an implementation detail, not part of any kind of API Depends how you see an API, We have a messaging passing background (we are Erlang programmer here) and for us the message over the socket is seen as the API. and the C-lib wraps this for the C Language. To use the C-API we need to write a NIF function for Erlang where the c part needs to be cross compiled for all different architectures. Writing the format native to the socket will avoid this. Another example: Just recently we had a project partner being in Java-Land was not allowed by management to use any Native Library. Thanks, that makes more sense. I stupidly assumed you were talking about python ;-) Holger Mirco -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] journal: log user units for coredumps and show them in systemctl status
---
src/journal/coredump.c | 9 ++---
src/shared/logs-show.c | 18 +++---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index c989be9..91528d3 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -144,11 +144,14 @@ int main(int argc, char* argv[]) {
core_unit = strappend(COREDUMP_UNIT=, t);
free(t);
-
-if (core_unit)
-IOVEC_SET_STRING(iovec[j++], core_unit);
+} else if (cg_pid_get_user_unit(pid, t) = 0) {
+core_unit = strappend(COREDUMP_USER_UNIT=, t);
+free(t);
}
+if (core_unit)
+IOVEC_SET_STRING(iovec[j++], core_unit);
+
/* OK, now we know it's not the journal, hence make use of
* it */
log_set_target(LOG_TARGET_JOURNAL_OR_KMSG);
diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c
index 034fde6..7dacccf 100644
--- a/src/shared/logs-show.c
+++ b/src/shared/logs-show.c
@@ -954,7 +954,7 @@ int show_journal_by_user_unit(
uid_t uid,
OutputFlags flags) {
-_cleanup_free_ char *m1 = NULL, *m2 = NULL, *m3 = NULL;
+_cleanup_free_ char *m1 = NULL, *m2 = NULL, *m3 = NULL, *m4 = NULL;
sd_journal *j = NULL;
int r;
@@ -972,7 +972,8 @@ int show_journal_by_user_unit(
if (asprintf(m1, _SYSTEMD_USER_UNIT=%s, unit) 0 ||
asprintf(m2, USER_UNIT=%s, unit) 0 ||
-asprintf(m3, _UID=%d, uid) 0) {
+asprintf(m3, COREDUMP_USER_UNIT=%s, unit) 0 ||
+asprintf(m4, _UID=%d, uid) 0) {
r = -ENOMEM;
goto finish;
}
@@ -985,7 +986,7 @@ int show_journal_by_user_unit(
r = sd_journal_add_match(j, m1, 0);
if (r 0)
goto finish;
-r = sd_journal_add_match(j, m3, 0);
+r = sd_journal_add_match(j, m4, 0);
if (r 0)
goto finish;
@@ -996,9 +997,20 @@ int show_journal_by_user_unit(
r = sd_journal_add_match(j, m2, 0);
if (r 0)
goto finish;
+r = sd_journal_add_match(j, m4, 0);
+if (r 0)
+goto finish;
+
+/* Look for coredumps of the service */
+r = sd_journal_add_disjunction(j);
+if (r 0)
+goto finish;
r = sd_journal_add_match(j, m3, 0);
if (r 0)
goto finish;
+r = sd_journal_add_match(j, m4, 0);
+if (r 0)
+goto finish;
r = show_journal(f, j, mode, n_columns, not_before, how_many, flags);
if (r 0)
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] coredump: make use of the cleanup macros
---
src/journal/coredump.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index 91528d3..4f79c45 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -32,6 +32,7 @@
#include log.h
#include util.h
+#include macro.h
#include mkdir.h
#include special.h
#include cgroup-util.h
@@ -49,7 +50,7 @@ enum {
};
static int divert_coredump(void) {
-FILE *f;
+_cleanup_fclose_ FILE *f = NULL;
int r;
log_info(Detected coredump of the journal daemon itself, diverting
coredump to /var/lib/systemd/coredump/.);
@@ -94,21 +95,20 @@ static int divert_coredump(void) {
}
finish:
-fclose(f);
return r;
}
int main(int argc, char* argv[]) {
int r, j = 0;
-char *p = NULL;
+_cleanup_free_ char *p = NULL;
ssize_t n;
pid_t pid;
uid_t uid;
gid_t gid;
struct iovec iovec[14];
-char *core_pid = NULL, *core_uid = NULL, *core_gid = NULL,
*core_signal = NULL,
+_cleanup_free_ char *core_pid = NULL, *core_uid = NULL, *core_gid =
NULL, *core_signal = NULL,
*core_timestamp = NULL, *core_comm = NULL, *core_exe = NULL,
*core_unit = NULL,
-*core_session = NULL, *core_message = NULL, *core_cmdline =
NULL, *t;
+*core_session = NULL, *core_message = NULL, *core_cmdline =
NULL, *t = NULL;
prctl(PR_SET_DUMPABLE, 0);
@@ -143,11 +143,8 @@ int main(int argc, char* argv[]) {
}
core_unit = strappend(COREDUMP_UNIT=, t);
-free(t);
-} else if (cg_pid_get_user_unit(pid, t) = 0) {
+} else if (cg_pid_get_user_unit(pid, t) = 0)
core_unit = strappend(COREDUMP_USER_UNIT=, t);
-free(t);
-}
if (core_unit)
IOVEC_SET_STRING(iovec[j++], core_unit);
@@ -264,18 +261,5 @@ int main(int argc, char* argv[]) {
log_error(Failed to send coredump: %s, strerror(-r));
finish:
-free(p);
-free(core_pid);
-free(core_uid);
-free(core_gid);
-free(core_signal);
-free(core_timestamp);
-free(core_comm);
-free(core_exe);
-free(core_cmdline);
-free(core_unit);
-free(core_session);
-free(core_message);
-
return r 0 ? EXIT_FAILURE : EXIT_SUCCESS;
}
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] logs-show: show messages for all unit types in systemctl status
I can't find a reason why we shouldn't try to output messages for other unit types than .service, .socket, .mount and .swap as well. It's probably a leftover from before we started logging UNIT= from inside PID 1. --- src/shared/logs-show.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index 7dacccf..b909c24 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -886,12 +886,6 @@ int show_journal_by_unit( assert(mode _OUTPUT_MODE_MAX); assert(unit); -if (!endswith(unit, .service) -!endswith(unit, .socket) -!endswith(unit, .mount) -!endswith(unit, .swap)) -return 0; - if (how_many = 0) return 0; @@ -962,11 +956,6 @@ int show_journal_by_user_unit( assert(mode _OUTPUT_MODE_MAX); assert(unit); -if (!endswith(unit, .service) -!endswith(unit, .socket)) - -return 0; - if (how_many = 0) return 0; -- 1.8.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] coredump: make use of the cleanup macros
2013/2/4 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
On Mon, Feb 04, 2013 at 03:13:25PM +0100, Mirco Tischler wrote:
---
src/journal/coredump.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index 91528d3..4f79c45 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -32,6 +32,7 @@
#include log.h
#include util.h
+#include macro.h
#include mkdir.h
#include special.h
#include cgroup-util.h
@@ -49,7 +50,7 @@ enum {
};
static int divert_coredump(void) {
-FILE *f;
+_cleanup_fclose_ FILE *f = NULL;
int r;
log_info(Detected coredump of the journal daemon itself,
diverting coredump to /var/lib/systemd/coredump/.);
@@ -94,21 +95,20 @@ static int divert_coredump(void) {
}
finish:
-fclose(f);
return r;
}
Hi,
if you do that, than you can go one step further, and get rid of
finish label. We don't enforce a single point of return, and it
is easier to read 'return -errno' instead of 'r = -errno; ...; return r;'.
Zbyszek
Thanks for your comment; new patch following.
I tried the same for main() but return EXIT_FAILURE; all over the place
just looks ugly in my eyes.
Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] coredump: make use of the cleanup macros
---
src/journal/coredump.c | 41 ++---
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index 91528d3..021b4c6 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -32,6 +32,7 @@
#include log.h
#include util.h
+#include macro.h
#include mkdir.h
#include special.h
#include cgroup-util.h
@@ -49,8 +50,7 @@ enum {
};
static int divert_coredump(void) {
-FILE *f;
-int r;
+_cleanup_fclose_ FILE *f = NULL;
log_info(Detected coredump of the journal daemon itself, diverting
coredump to /var/lib/systemd/coredump/.);
@@ -70,19 +70,16 @@ static int divert_coredump(void) {
if (l = 0) {
if (ferror(f)) {
log_error(Failed to read coredump: %m);
-r = -errno;
-goto finish;
+return -errno;
}
-r = 0;
break;
}
q = fwrite(buffer, 1, l, f);
if (q != l) {
log_error(Failed to write coredump: %m);
-r = -errno;
-goto finish;
+return -errno;
}
}
@@ -90,25 +87,23 @@ static int divert_coredump(void) {
if (ferror(f)) {
log_error(Failed to write coredump: %m);
-r = -errno;
+return -errno;
}
-finish:
-fclose(f);
-return r;
+return 0;
}
int main(int argc, char* argv[]) {
int r, j = 0;
-char *p = NULL;
+_cleanup_free_ char *p = NULL;
ssize_t n;
pid_t pid;
uid_t uid;
gid_t gid;
struct iovec iovec[14];
-char *core_pid = NULL, *core_uid = NULL, *core_gid = NULL,
*core_signal = NULL,
+_cleanup_free_ char *core_pid = NULL, *core_uid = NULL, *core_gid =
NULL, *core_signal = NULL,
*core_timestamp = NULL, *core_comm = NULL, *core_exe = NULL,
*core_unit = NULL,
-*core_session = NULL, *core_message = NULL, *core_cmdline =
NULL, *t;
+*core_session = NULL, *core_message = NULL, *core_cmdline =
NULL, *t = NULL;
prctl(PR_SET_DUMPABLE, 0);
@@ -143,11 +138,8 @@ int main(int argc, char* argv[]) {
}
core_unit = strappend(COREDUMP_UNIT=, t);
-free(t);
-} else if (cg_pid_get_user_unit(pid, t) = 0) {
+} else if (cg_pid_get_user_unit(pid, t) = 0)
core_unit = strappend(COREDUMP_USER_UNIT=, t);
-free(t);
-}
if (core_unit)
IOVEC_SET_STRING(iovec[j++], core_unit);
@@ -264,18 +256,5 @@ int main(int argc, char* argv[]) {
log_error(Failed to send coredump: %s, strerror(-r));
finish:
-free(p);
-free(core_pid);
-free(core_uid);
-free(core_gid);
-free(core_signal);
-free(core_timestamp);
-free(core_comm);
-free(core_exe);
-free(core_cmdline);
-free(core_unit);
-free(core_session);
-free(core_message);
-
return r 0 ? EXIT_FAILURE : EXIT_SUCCESS;
}
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl to csv
2013/1/29 Kai Hendry hen...@iki.fi On 29 January 2013 15:33, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Try 'journalctl --lines=0 --follow' with the latest git. Ah, I see the change: http://cgit.freedesktop.org/systemd/systemd/commit/?id=67e04a486b92fcb656049cb4d6b66148c7d2e61b I'm too much of a newbie to compile systemd from git on Arch just yet. Unless git is packaged somewhere? Thank you, There's a systemd-git package in the AUR Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch 0/5] support for logging the unit of user session units
2013/1/18 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Hi, I had a look at the your patches (without actually running them :). I started with a few cleanups, I'll post them as replies to this letter. Then I had a better look at the logic of USER_UNIT and I have a few questions. Hi Thanks for having a look. -#define log_full_unit(level, unit, ...) log_meta_object(level, __FILE__, __LINE__, __func__, UNIT=, unit, __VA_ARGS__) +#define log_full_unit(level, unit, ...) log_meta_object(level, __FILE__, __LINE__, __func__, getpid() == 1 ? UNIT= : USER_UNIT=, unit, __VA_ARGS__) +#define log_struct_unit(level, unit, ...) log_struct(level, getpid() == 1 ? UNIT=%s : USER_UNIT=%s, unit, __VA_ARGS__) Are all those calls to getpid() efficient? Is the result cached or does each one generate a system call? According to man 2 getpid the result is cached, which btw Linus calls a totally useless optimization ;) http://yarchive.net/comp/linux/getpid_caching.html +if (!endswith(unit, .service) +!endswith(unit, .socket) +!endswith(unit, .mount) +!endswith(unit, .swap)) +return 0; +if (!endswith(unit, .service) +!endswith(unit, .socket)) Do those conditions make sense? Aren't the messages logged for all types of units (at least under debug or error conditions) by systemd itself? The the first four conditions already exist in the current code. I wasn't sure if they make sense either but left them in place for now or rather removed mount and swap units for the user session. Zbyszek Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/5] man: document the _SYSTEMD_USER_UNIT journal field
--- man/systemd.journal-fields.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml index 13af4fd..2e9bc5b 100644 --- a/man/systemd.journal-fields.xml +++ b/man/systemd.journal-fields.xml @@ -212,13 +212,15 @@ termvarname_SYSTEMD_CGROUP=/varname/term termvarname_SYSTEMD_SESSION=/varname/term termvarname_SYSTEMD_UNIT=/varname/term + termvarname_SYSTEMD_USER_UNIT=/varname/term termvarname_SYSTEMD_OWNER_UID=/varname/term listitem paraThe control group path in the systemd hierarchy, the systemd session ID (if any), -the systemd unit name (if any) +the systemd unit name (if any), +the systemd user session unit name (if any) and the owner UID of the systemd session (if any) of the process the journal entry -- 1.8.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/5] journal: log _SYSTEMD_USER_UNIT for user session units
---
src/journal/journald-server.c | 11 +++-
src/shared/cgroup-util.c | 122 --
src/shared/cgroup-util.h | 1 +
3 files changed, 105 insertions(+), 29 deletions(-)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index ec9be65..12a46e6 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -601,8 +601,15 @@ static void dispatch_message_real(
if (cg_pid_get_unit(ucred-pid, t) = 0) {
unit = strappend(_SYSTEMD_UNIT=, t);
free(t);
-} else if (unit_id)
-unit = strappend(_SYSTEMD_UNIT=, unit_id);
+} else if (cg_pid_get_user_unit(ucred-pid, t) = 0) {
+unit = strappend(_SYSTEMD_USER_UNIT=, t);
+free(t);
+} else if (unit_id) {
+if (session)
+unit = strappend(_SYSTEMD_USER_UNIT=,
unit_id);
+else
+unit = strappend(_SYSTEMD_UNIT=, unit_id);
+}
if (unit)
IOVEC_SET_STRING(iovec[n++], unit);
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index 9dfab2e..3d12233 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -36,6 +36,7 @@
#include util.h
#include path-util.h
#include strv.h
+#include unit-name.h
int cg_enumerate_processes(const char *controller, const char *path, FILE
**_f) {
char *fs;
@@ -1210,11 +1211,76 @@ int cg_pid_get_cgroup(pid_t pid, char **root, char
**cgroup) {
return 0;
}
-int cg_pid_get_unit(pid_t pid, char **unit) {
+static int instance_unit_from_cgroup(char **cgroup){
+char *at;
+
+assert(cgroup);
+
+at = memchr(*cgroup, '@', strlen(*cgroup));
+if (at at[1] == '.') {
+char *i, *s;
+
+/* This is a templated service */
+i = memchr(at, '/', strlen(at));
+if(!i)
+return -EIO;
+
+s = strndup(at + 1, i - at);
+if (!s)
+return -ENOMEM;
+
+i = strdup(i + 1);
+if (!i) {
+free(s);
+return -ENOMEM;
+}
+
+strcpy(at + 1, i);
+strcpy(at + strlen(i) + 1, s);
+at[strlen(at) - 1] = '\0';
+
+free(i);
+free(s);
+}
+
+return 0;
+}
+
+static int cgroup_to_unit(char *cgroup, char **unit){
int r;
-char *cgroup, *p, *at, *b;
+char *b, *p;
size_t k;
+assert(cgroup);
+assert(unit);
+
+r = instance_unit_from_cgroup(cgroup);
+if (r 0)
+return r;
+
+p = strrchr(cgroup, '/') + 1;
+k = strlen(p);
+
+b = strndup(p, k);
+
+if (!b)
+return -ENOMEM;
+
+r = unit_name_is_valid(b, true);
+if (!r) {
+free(b);
+return -ENOENT;
+}
+
+*unit = b;
+
+return 0;
+}
+
+int cg_pid_get_unit(pid_t pid, char **unit) {
+int r;
+char *cgroup;
+
assert(pid = 0);
assert(unit);
@@ -1227,38 +1293,40 @@ int cg_pid_get_unit(pid_t pid, char **unit) {
return -ENOENT;
}
-p = cgroup + 8;
-k = strcspn(p, /);
+r = cgroup_to_unit(cgroup, unit);
+if (r 0){
+free(cgroup);
+return r;
+}
-at = memchr(p, '@', k);
-if (at at[1] == '.') {
-size_t j;
+free(cgroup);
-/* This is a templated service */
-if (p[k] != '/') {
-free(cgroup);
-return -EIO;
-}
+return 0;
+}
-j = strcspn(p+k+1, /);
+int cg_pid_get_user_unit(pid_t pid, char **unit) {
+int r;
+char *cgroup;
-b = malloc(k + j + 1);
+assert(pid = 0);
+assert(unit);
-if (b) {
-memcpy(b, p, at - p + 1);
-memcpy(b + (at - p) + 1, p + k + 1, j);
-memcpy(b + (at - p) + 1 + j, at + 1, k - (at - p) - 1);
-b[k+j] = 0;
-}
-} else
- b = strndup(p, k);
+r = cg_pid_get_cgroup(pid, NULL, cgroup);
+if (r 0)
+return r;
-free(cgroup);
+if (!startswith(cgroup, /user/)) {
+free(cgroup);
+return -ENOENT;
+}
-if (!b)
-return -ENOMEM;
+r = cgroup_to_unit(cgroup, unit);
+if (r 0) {
+free(cgroup);
+
[systemd-devel] [PATCH 3/5] logs-show: add show_journal_by_user_unit
Print the journal for a user session unit. For now this filters by
_SYSTEMD_USER_UNIT and USER_UNIT and additionally _UID.
---
src/shared/logs-show.c | 205 +++--
src/shared/logs-show.h | 12 +++
2 files changed, 159 insertions(+), 58 deletions(-)
diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c
index c221af3..034fde6 100644
--- a/src/shared/logs-show.c
+++ b/src/shared/logs-show.c
@@ -774,72 +774,22 @@ int output_journal(
return ret;
}
-int show_journal_by_unit(
-FILE *f,
-const char *unit,
-OutputMode mode,
-unsigned n_columns,
-usec_t not_before,
-unsigned how_many,
-OutputFlags flags) {
+static int show_journal(FILE *f,
+sd_journal *j,
+OutputMode mode,
+unsigned n_columns,
+usec_t not_before,
+unsigned how_many,
+OutputFlags flags) {
-_cleanup_free_ char *m1 = NULL, *m2 = NULL, *m3 = NULL;
-sd_journal *j = NULL;
int r;
unsigned line = 0;
bool need_seek = false;
int warn_cutoff = flags OUTPUT_WARN_CUTOFF;
+assert(j);
assert(mode = 0);
assert(mode _OUTPUT_MODE_MAX);
-assert(unit);
-
-if (!endswith(unit, .service)
-!endswith(unit, .socket)
-!endswith(unit, .mount)
-!endswith(unit, .swap))
-return 0;
-
-if (how_many = 0)
-return 0;
-
-if (asprintf(m1, _SYSTEMD_UNIT=%s, unit) 0 ||
-asprintf(m2, COREDUMP_UNIT=%s, unit) 0 ||
-asprintf(m3, UNIT=%s, unit) 0) {
-r = -ENOMEM;
-goto finish;
-}
-
-r = sd_journal_open(j, SD_JOURNAL_LOCAL_ONLY|SD_JOURNAL_SYSTEM_ONLY);
-if (r 0)
-goto finish;
-
-/* Look for messages from the service itself */
-r = sd_journal_add_match(j, m1, 0);
-if (r 0)
-goto finish;
-
-/* Look for coredumps of the service */
-r = sd_journal_add_disjunction(j);
-if (r 0)
-goto finish;
-r = sd_journal_add_match(j,
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1, 0);
-if (r 0)
-goto finish;
-r = sd_journal_add_match(j, m2, 0);
-if (r 0)
-goto finish;
-
-/* Look for messages from PID 1 about this service */
-r = sd_journal_add_disjunction(j);
-if (r 0)
-goto finish;
-r = sd_journal_add_match(j, _PID=1, 0);
-if (r 0)
-goto finish;
-r = sd_journal_add_match(j, m3, 0);
-if (r 0)
-goto finish;
/* Seek to end */
r = sd_journal_seek_tail(j);
@@ -916,6 +866,145 @@ int show_journal_by_unit(
}
finish:
+return r;
+}
+
+int show_journal_by_unit(
+FILE *f,
+const char *unit,
+OutputMode mode,
+unsigned n_columns,
+usec_t not_before,
+unsigned how_many,
+OutputFlags flags) {
+
+_cleanup_free_ char *m1 = NULL, *m2 = NULL, *m3 = NULL;
+sd_journal *j = NULL;
+int r;
+
+assert(mode = 0);
+assert(mode _OUTPUT_MODE_MAX);
+assert(unit);
+
+if (!endswith(unit, .service)
+!endswith(unit, .socket)
+!endswith(unit, .mount)
+!endswith(unit, .swap))
+return 0;
+
+if (how_many = 0)
+return 0;
+
+if (asprintf(m1, _SYSTEMD_UNIT=%s, unit) 0 ||
+asprintf(m2, COREDUMP_UNIT=%s, unit) 0 ||
+asprintf(m3, UNIT=%s, unit) 0) {
+r = -ENOMEM;
+goto finish;
+}
+
+r = sd_journal_open(j, SD_JOURNAL_LOCAL_ONLY|SD_JOURNAL_SYSTEM_ONLY);
+if (r 0)
+goto finish;
+
+/* Look for messages from the service itself */
+r = sd_journal_add_match(j, m1, 0);
+if (r 0)
+goto finish;
+
+/* Look for coredumps of the service */
+r = sd_journal_add_disjunction(j);
+if (r 0)
+goto finish;
+r = sd_journal_add_match(j,
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1, 0);
+if (r 0)
+goto finish;
+r = sd_journal_add_match(j, m2, 0);
+if (r 0)
+goto finish;
+
+/* Look for messages from PID 1 about this service */
+r = sd_journal_add_disjunction(j);
+if (r 0)
+goto finish;
+r = sd_journal_add_match(j, _PID=1, 0);
+if (r 0)
+goto finish;
+r = sd_journal_add_match(j, m3, 0);
+if (r 0)
+
[systemd-devel] [Patch 0/5] support for logging the unit of user session units
Hi The following series of patches implements support for logging user session units to the journal. Messages by the unit itself are marked with _SYSTEMD_USER_UNIT and messages regarding the unit from the systemd instance are marked with USER_UNIT. Patch 1: log _SYSTEMD_USER_UNIT into the journal Patch 2: log USER_UNIT from systemd core and use it. Patch 3+4: use _SYSTEMD_USER_UNIT and USER_UNIT in systemctl --user status Patch 5: update the man page However, something isn't working quite right. The output of systemctl --user status sometimes shows entries that belong to different units and it doesn't always show the configured number of entries, even if there are enough available. I suspect a bug in the seek and match code that's triggered by Patches 3+4. But I don't have a very good understanding of the lower level journal code so even though I tried I couldn't locate the bug :/ Of cause the possibility remains that the patches are simply faulty, so please take a look ;) Here are some todos I didn't get to yet: - support for coredumps (COREDUMP_USER_UNIT) - (maybe) only open logfiles of one user (SD_JOURNAL_USER_ONLY) Thanks Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] simultaneous udp listeners for ipv4+6 caused systemd to go into a loop
2012/12/5 Thomas H.P. Andersen pho...@gmail.com I was looking into why the unit files for talkd/ntalkd were not working [1]. For some reason specifying these two lines in the same socket file triggers an unfortunate behavior in systemd: ListenDatagram=[::]:517 ListenDatagram=0.0.0.0:517 Systemd first of all fails to start the service. It then tries starting it again and again repeatedly. This quickly reaches the limit for failing to start a service too often. It still just continues and it spams the journal about having hit this limit. It caused a noticeable slow down of the computer and my log file began rotating. I have not looked into what is going on in systemd, or whether this is a bug or not. However it is case where I think that it could be nice to provide a clear error message. Maybe someone can spread some light about what is going on here? A socket file with just one of the two ListenDatagram-lines works just fine. [1] https://bugzilla.redhat.com/show_bug.cgi?id=737219 My guess is systemd gets confused because the two addresses overlap. By default specifying an ipv6 address will make the service available on both ipv6 and ipv4, so the second directive is redundant. This can be disabled with BindIPv6Only=ipv6-only. But systemd could indeed behave nicer in this situation :) Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting systemd service in udev rule via ENV{SYSTEMD_WANTS} - help needed
2012/11/18 Warpme war...@o2.pl
Well,
Things pretend to be simple seems to be not simple
After 2 days of fighting with issue I have to ask for help.
I want to kick systemd service when usb HDD is plugged.
As started service needs to know HDD label I wan to use templates.
Here is what it goes:
udev rule:
SUBSYSTEM==block, KERNEL==sd[c-z][0-9], GOTO=begin
GOTO=end
LABEL=begin
ACTION==add, GOTO=begin_add
ACTION==remove, GOTO=begin_remove
GOTO=end
LABEL=begin_add
SYMLINK+=usbhd-%k, GROUP=root
ENV{ID_FS_LABEL_ENC}=usbhd-%**k
IMPORT{program}=/sbin/blkid -o udev -p $tempnode
ENV{ID_FS_LABEL_ENC}==.myth.**backup,
ENV{MOUNT_DIR}=/media/$env{**ID_FS_LABEL_ENC},
RUN+=/bin/mkdir -p $env{MOUNT_DIR}, RUN+=/bin/mount -t auto -o
rw,noauto,noatime /dev/%k $env{MOUNT_DIR}
ENV{ID_FS_LABEL_ENC}==.myth.**backup, TAG+=systemd,
ENV{SYSTEMD_WANTS}=ext-usb-**backup.service
GOTO=end
service file:
[Unit]
Description=MythtTV ExtUSB Backup Helper
[Service]
ExecStart=/usr/local/bin/run-**backup.sh
Type=forking
GuessMainPID=false
RemainAfterExit=no
Issue:
it works with:
ENV{ID_FS_LABEL_ENC}==.myth.**backup, RUN+=/usr/bin/systemctl start
ext-usb-backup.service
but not works with:
ENV{ID_FS_LABEL_ENC}==.myth.**backup, TAG+=systemd,
ENV{SYSTEMD_WANTS}=ext-usb-**backup.service
(With TAG+ENV approach udev behaves like line with TAG+ENV is
non-existing: no any error nor any sign it is parsed)
Where the issue is ?
Thx in advance !
Hi
I don't really have an idea, but here are some things you could check
additionally:
Does systemd create a .device unit? And if yes is it active/plugged? And
does it have the correct Wants=ext-usb-backup.service attribute? Does
udevadm info --query=property --path=path to sysfs device show the
correct values for
SYSTEMD_WANTS and TAGS?
Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroup: look up user session units from cgroups as well.
2012/11/15 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl On Tue, Nov 06, 2012 at 01:07:26AM +0100, Mirco Tischler wrote: This allows the journal code to set the _SYSTEMD_UNIT tag for messages generated by systemd --user session units. Hi, this would open the door to spoofed messages. Previously Lennart suggested [1] using _SYSTEMD_USER_UNIT=. Zbyszek [1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006103.html Hi, thanks for your comment. My idea was to add filtering after the _SYSTEMD_SESSION field to systemctl status. The reason why I didn't implement this yet is because I wasn't sure about the best way to make known wether we are in session or system mode where we'd need it. But if _SYSTEMD_USER_UNIT is preferred, I'll try to implement a patch. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cgroup: look up user session units from cgroups as well.
This allows the journal code to set the _SYSTEMD_UNIT tag for messages generated
by systemd --user session units.
---
src/shared/cgroup-util.c | 76 +++-
1 file changed, 49 insertions(+), 27 deletions(-)
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index b0d378d..11f4f55 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -36,6 +36,7 @@
#include util.h
#include path-util.h
#include strv.h
+#include unit-name.h
int cg_enumerate_processes(const char *controller, const char *path, FILE
**_f) {
char *fs;
@@ -1202,9 +1203,44 @@ int cg_pid_get_cgroup(pid_t pid, char **root, char
**cgroup) {
return 0;
}
+static int instance_unit_from_cgroup(char **cgroup){
+char *at;
+
+assert(cgroup);
+
+at = memchr(*cgroup, '@', strlen(*cgroup));
+if (at at[1] == '.') {
+char *i, *s;
+
+/* This is a templated service */
+i = memchr(at, '/', strlen(at));
+if(!i)
+return -EIO;
+
+s = strndup(at + 1, i - at);
+if (!s)
+return -ENOMEM;
+
+i = strdup(i + 1);
+if (!i) {
+free(s);
+return -ENOMEM;
+}
+
+strcpy(at + 1, i);
+strcpy(at + strlen(i) + 1, s);
+at[strlen(at) - 1] = '\0';
+
+free(i);
+free(s);
+}
+
+return 0;
+}
+
int cg_pid_get_unit(pid_t pid, char **unit) {
int r;
-char *cgroup, *p, *at, *b;
+char *cgroup, *p, *b;
size_t k;
assert(pid = 0);
@@ -1214,36 +1250,16 @@ int cg_pid_get_unit(pid_t pid, char **unit) {
if (r 0)
return r;
-if (!startswith(cgroup, /system/)) {
+r = instance_unit_from_cgroup(cgroup);
+if(r 0){
free(cgroup);
-return -ENOENT;
+return r;
}
-p = cgroup + 8;
-k = strcspn(p, /);
-
-at = memchr(p, '@', k);
-if (at at[1] == '.') {
-size_t j;
-
-/* This is a templated service */
-if (p[k] != '/') {
-free(cgroup);
-return -EIO;
-}
-
-j = strcspn(p+k+1, /);
+p = strrchr(cgroup, '/') + 1;
+k = strlen(p);
-b = malloc(k + j + 1);
-
-if (b) {
-memcpy(b, p, at - p + 1);
-memcpy(b + (at - p) + 1, p + k + 1, j);
-memcpy(b + (at - p) + 1 + j, at + 1, k - (at - p) - 1);
-b[k+j] = 0;
-}
-} else
- b = strndup(p, k);
+b = strndup(p, k);
free(cgroup);
@@ -1251,6 +1267,12 @@ int cg_pid_get_unit(pid_t pid, char **unit) {
return -ENOMEM;
*unit = b;
+r = unit_name_is_valid(*unit, true);
+if (!r){
+free(b);
+return -ENOENT;
+}
+
return 0;
}
--
1.8.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroup: look up user session units from cgroups as well.
2012/11/6 Mirco Tischler mt...@gmx.de: This allows the journal code to set the _SYSTEMD_UNIT tag for messages generated by systemd --user session units. Sorry forgot to commit some changes. Updated version follows. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] live remote logging?
2012/10/31 Cliff Brake cliff.br...@gmail.com: Hello, I've come up with several ideas: 1) scp/rsync the journal files to the server. * how do we know when a file is ready to be scp'd? * is there any way to get reasonable update rate? It seems running rsync every 10s might get expensive. Each time an entry is added, you need to copy the whole file. This would only work for static, already rotated files. 2) use the systemd-journal-gatewayd in v195 * is there any way to stream the journal with this, or is this more of a query interface? * I assume, we then we loose the journal file format 3) write our own app that monitors the journal and copies over data * how would this operate, would we use mmap + file change notifications, or journal C api? * with mmap, would we watch all the files in the journal directory? 4) wait for the live remote logging features * any timeline for when this will be available? 5) run syslog along side journal and use the syslog network logging features * then the anti-systemd members of the team say -- why don't we just ditch systemd and go back to sysvinit and syslog ... :-) * then we lose the query benefits of the journal on the server. 6) nfs mount either the server's /var/log/journal over the clients /var/log/journal, or all of the clients /var/log/journal/machine-ids into the server's /var/log/journal. Additionally, on the server, it seems like it makes sense to use the journal files for the log storage. 1) how would log rotation be managed (discard old logs)? systemd does log rotation based on available disc space, in order to keep a maximum of log entries. It rotates logs when they grow beyond a certain limit, and when a maximum of disk space is used deletes the oldest file. The options to configure this and default values are explained in the journald.conf man page. 2) can the systemd-journal-gatewayd be used on a independent directory of log files? systemd-journal-gatewayd doesn't take any arguments, so it currently seems not possible. Appreciate any ideas. Thanks, Cliff Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] live remote logging?
2012/10/31 Mirco Tischler mt...@gmx.de: 2012/10/31 Cliff Brake cliff.br...@gmail.com: Additionally, on the server, it seems like it makes sense to use the journal files for the log storage. 1) how would log rotation be managed (discard old logs)? systemd does log rotation based on available disc space, in order to keep a maximum of log entries. It rotates logs when they grow beyond a certain limit, and when a maximum of disk space is used deletes the oldest file. The options to configure this and default values are explained in the journald.conf man page. Sorry, just now I get what you're talking about here ;-) Log rotation is done by journald and the limits are checked before each append. All other applications writing to /var/log/journal should do the same. I guess that rules out 1) and 2). Mounting the server /var/log/journal on the clients and configuring the clients to use the same limits as the server seems ok, as all writers can see the whole data and do the rotation themselves. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] live remote logging?
2012/10/31 Cliff Brake cliff.br...@gmail.com: On Wed, Oct 31, 2012 at 10:36 AM, Mirco Tischler mt...@gmx.de wrote: 2012/10/31 Cliff Brake cliff.br...@gmail.com: 6) nfs mount either the server's /var/log/journal over the clients /var/log/journal, or all of the clients /var/log/journal/machine-ids into the server's /var/log/journal. How does the process work for mounting this during bootup? How does journald transition the logging to this NFS mount? Do you delay journald starting until the mount is complete? Thanks, Cliff journald starts logging to /run/ until all filesystems are mounted. systemd-journal-flush.service then triggers the migration to persistent storage. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Race condition for service dependent on mount
2012/10/18 David Strauss da...@davidstrauss.net: If a service depends on a mount, systemd doesn't properly wait for the mount to complete before starting the service. This creates bad race conditions where the service may write to the mount directory before the mount is active, which can stop the mount from even completing successfully because the mount directory isn't empty. We might be able to stop the writes through permissions on the mount directory, but the writes would still fail. The cleanest solution to this seems to be notify integration into the mount utility so it tells systemd that the mount is complete or waiting for the mount request to complete in some other way. Part of why we use this dependency is to perform the mount before forking the file system namespace for the dependent service. This allows the dependent service file system namespace to not propagate further mounts from the main file system. Has anyone else looked into this? -- David Strauss I was under the impression that systemd waits for mount to exit before it marks the unit as started. And mount itself may either mount the fs and exit or wait for a fs specific helper to exit, which then does the actual mounting and exits only after the mount is complete. So systemd should never mark a mount unit as mounted before it actually is ready. At least that's how I think it's supposed to work. Every deviation I would count as a bug. Or is my logic flawed? Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald[257]: Allocation limit reached, rotating
2012/10/17 Reindl Harald h.rei...@thelounge.net: how large is the limit here? a machine running F17 since this night has a dedicated /var/log/ with 1 GB and after send out a small newsletter this happens 4 times in dmesg for me it seems the limits are too tight in the case of small but dedicated /var/log disks the machine itself is running rsyslog for persistent storage systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. You can configure the limits in journald.conf. The default file size is 1,25% (1/8 of 10%) of the filesystem Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unexpectedly dropping into rescue mode - how do I best debug this?
2012/10/4 Ingo Molnar mi...@kernel.org: Here are the kernel parameters: lyra:~ cat /proc/cmdline BOOT_IMAGE=/boot/bzImage root=UUID=dd8873f1-9cfd-4338-b9ec-f4902abdc486 ro single rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 You boot into single user mode, which I guess is translated into runlevel1, which is a symlink to rescue.target by default? Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
2012/10/2 Jóhann B. Guðmundsson johan...@gmail.com: On 10/01/2012 10:53 PM, Mirco Tischler wrote: Systemd isn't really the right place to do network related stuff, imo. Such things are better dealt with in the network connection manager, where the information is already available. NetworkManager has a mechanism to execute custom scripts in /etc/NetworkManager/dispatcher.d on network events. For details take a look at the man page, support for explicit actions on vpn-up/down is mentioned there. Arguably systemd is the correct place under CoreOS to unite and manage network connections JBG How do you do that? systemd doesn't have any support to manage network connections. It lacks information about the state of the network devices and cannot configure them as well. In Matthew's case creating a dispatcher script that issues a systemctl restart squid.service on vpn state changes looks like a correct solution to me. Do you have a better idea? Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Launching a unit in response to a D-Bus signal
2012/10/2 Kok, Auke-jan H auke-jan.h@intel.com: On Mon, Oct 1, 2012 at 4:58 AM, Matthew Booth mbo...@redhat.com wrote: I have a requirement to restart squid whenever the VPN goes up or down[1]. Reading around, it seems that the way to do this would be in response to the relevant D-Bus signal, which seems to be this one: signal sender=:1.6 - dest=(null destination) serial=269 path=/org/freedesktop/NetworkManager/ActiveConnection/2; interface=org.freedesktop.NetworkManager.VPN.Connection; member=VpnStateChanged I expected that systemd would allow me to do this, but as far as I can tell it doesn't (I'm using F17). I can obviously write my own daemon to do this, but it seems to me that a daemon just for this would be a waste. I think this sounds like a good fit for systemd. Is it anything anybody's looked at? The problem with listening on a specific DBus message is that it requires you to implement much more of DBus than systemd internally can. I'm not sure it's a good idea to put something that complex into systemd. Your alternatives are to write a simple DBus frontend, or perhaps a Network Manager plugin (if there is such a thing, I know connman has the concept of plugins). You can certainly socket activate a dummy service that doesn't actually listen on DBus but instead executes `systemctl restart squid.service` based on the BusName only. Systemd will likely however not appreciate the unhandled socket, but it may be worth a try. Auke Systemd isn't really the right place to do network related stuff, imo. Such things are better dealt with in the network connection manager, where the information is already available. NetworkManager has a mechanism to execute custom scripts in /etc/NetworkManager/dispatcher.d on network events. For details take a look at the man page, support for explicit actions on vpn-up/down is mentioned there. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 192
2012/9/26 Lennart Poettering lenn...@poettering.net Heya, Almost exclusively only bug fixes. You want this if you are on 190 or 191 right now. http://www.freedesktop.org/software/systemd/systemd-192.tar.xz CHANGES WITH 192: * The bash completion logic is now available for journalctl too. * We don't mount the cpuset controller anymore together with cpu and cpuacct, as cpuset groups generally cannot be started if no parameters are assigned to it. cpuset hence broke code that assumed it it could create cpu groups and just start them. * journalctl -f will now subscribe to terminal size changes, and line break accordingly. Changes from: Dave Reisner, Kay Sievers, Lennart Poettering, Lukas Nykrynm, Mirco Tischler, Václav Pavlín Lennart $systemd --version systemd 191 $git grep 191 configure.ac configure.ac:[191], $git describe v192 The version number didn't get the increment it deserves ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Keeping console messages on VT1
2012/9/27 Henrik /KaarPoSoft hen...@kaarposoft.dk: On 09/27/12 00:05, Tom Gundersen wrote: On Thu, Sep 27, 2012 at 12:02 AM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: (b) Is there a way to have logind NOT show a login prompt on VT1? It is not logind that starts login, but getty. You want to disable getty@tty1.service, and enable say getty@tty2.service instead. -t DOH! If I move /etc/systemd/system/getty.target.wants/getty@tty1.service to /etc/systemd/system/getty.target.wants/getty@tty2.service this annoyance is gone. Thank you, Tom! (but of course I still get console messages on the current VT, not VT1) /Henrik ___ I haven't tried this and maybe it won't work, but you can set TTYPath to /dev/tty1 in journald.conf. But I suppose you will still get kernel messages, as they don't go through the journal (quiet on the kernel commandline gets rid of the unimportant ones). Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] journal: set seal even for readonly journalfiles
journalctl needs to know wether the file has been sealed to
be able to do verification.
---
src/journal/journal-file.c | 3 +--
1 Datei geändert, 1 Zeile hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 6db9955..f775fec 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -260,8 +260,7 @@ static int journal_file_verify_header(JournalFile *f) {
f-compress = JOURNAL_HEADER_COMPRESSED(f-header);
-if (f-writable)
-f-seal = JOURNAL_HEADER_SEALED(f-header);
+f-seal = JOURNAL_HEADER_SEALED(f-header);
return 0;
}
--
1.7.12.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] journalctl: print correct timespan in verify
The old code used a timestamp to print a timespan for unsealed journalfiles,
incorrectly showing things like 2230 days of unsealed entries. Print the
timespan
between the first and last entry instead.
---
src/journal/journalctl.c | 2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 6b580d4..2bca53e 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -708,7 +708,7 @@ static int verify(sd_journal *j) {
format_timespan(c, sizeof(c),
total to ? total - to : 0));
} else if (total 0)
log_info(= No sealing yet, %s of
entries not sealed.,
- format_timespan(c, sizeof(c),
total));
+ format_timespan(c, sizeof(c),
total - f-header-head_entry_realtime));
else
log_info(= No sealing yet, no
entries in file.);
}
--
1.7.12.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about After/Before of services
2012/8/9 Jóhann B. Guðmundsson johan...@gmail.com: On 08/09/2012 04:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? Yes If A.service unit has Wants=B.service and After=B.service it will be start after B.service has finished starting *unless* B.service unit is Type=oneshot service then it will be started immediately after B.service is has been started not when B.service has finished starting... JBG Or unless B.service is Type=simple (the default). In this case systemd has no way to tell when B.service has finished starting and continues to start A.service right away. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service reactivation with device plugging
2012/7/4 Kok, Auke-jan H auke-jan.h@intel.com: On Tue, Jul 3, 2012 at 4:49 PM, Rob Spanton rspan...@zepler.net wrote: Hi, I wrote: I was recently working on an embedded system that had a daemon [ ...which] needed to be run when both [serial] devices were plugged in. If any of the devices was unplugged, the daemon would exit, and would need to be restarted the next time both devices were plugged in. Auke wrote: why not write a middle-man layer that uses socket activation? My understanding of socket activation is that it is for starting a service when something attempts to connect to a socket. I don't understand how this relates to my situation with two serial devices. alternatively, you could use inotify and immediately start your daemon. Presumably you mean by writing a second daemon that uses inotify? Yes, I can see that this would solve my problem, however I was wondering whether there was a simpler way of doing it just using systemd. I'm more throwing ideas out there at this point, I don't know the whole situation. First, things can be a lot easier if components use proper methods. For device nodes, udev rules should be the way to go. You can have udev do things for you if the devices appear, so that should be one line of approach: have udev start something for you. You could make a program that just exits if only one device is available, and runs if two are available. Once udev sees the second device, things will just work. Auke Seconded. For clues on how to let udev start things for you see the systemd.device man page A unit like this should work with udev activation: [Unit] Description=... BindTo=dev-serial-a.device dev-serial-b.device After=dev-serial-a.device dev-serial-b.device [Service] ExecStart=/usr/bin/my-magic-service Type=notify Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] MemoryLimit and MemorySoftLimit
Am 26. März 2012 16:46 schrieb Lennart Poettering lenn...@poettering.net: On Mon, 26.03.12 11:06, Albert Strasheim (full...@gmail.com) wrote: See http://www.kernel.org/doc/Documentation/cgroups/memory.txt for more information how MemoryLimit= and MemorySoftLimit= work. Is there a way for an application to detect when it has hit its MemorySoftLimit=? We would like to log a warning at this point. I am not aware that we had any infrastructure for notification of userspace on memory suppression situations. If I read the link you provided correctly, it is possible to use eventfd() for notification on hitting the limit. Lennart Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Right way to do kexec
Am 22. März 2012 00:33 schrieb Lennart Poettering lenn...@poettering.net: On Wed, 21.03.12 12:24, Marti Raudsepp (ma...@juffo.org) wrote: Hi, I've been trying to figure out how to use systemd's kexec functionality right. When one runs systemctl kexec, systemd simply shuts down and executes 'kexec -e'. For this to work, a kexec-able kernel has to be already loaded. Now, when do I load this kernel? Loading at startup means that I'm simply wasting the memory most of the time when I'm not rebooting. But I think this is the theory of how things are done. I remember some issues with requiring continious memory which might be hard to come by if the kernel is loaded only very late. Might be something to discuss with the kexec folks. And if I upgrade the kernel, the old kernel sticks around in memory -- but the point of rebooting is usually to load the *new* kernel? presumably yes Unless you want to use kexec on panic. In that case the kexec kernel should be loaded at boot, doesn't it? But I don't know if this is actually in use or more a debugging tool for kernel devs. Lennart Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Right way to do kexec
Am 22. März 2012 01:38 schrieb Marti Raudsepp ma...@juffo.org: On Thu, Mar 22, 2012 at 02:16, Mirco Tischler mt...@gmx.de wrote: Unless you want to use kexec on panic. In that case the kexec kernel should be loaded at boot, doesn't it? But I don't know if this is actually in use or more a debugging tool for kernel devs. Sure, the crashdump kernel is loaded with 'kexec --load-panic' and is usually a different image/initrd anyway. So systemd's usage of kexec for reboot doesn't affect that at all. Regards, Marti I wasn't aware of that. Thanks for the clarification. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd kernel syscall interface requirements
2012/1/15 Ilyes Gouta ilyes.go...@gmail.com: Hi there, I'm looking at porting (just starting) systemd to an embedded Linux distribution and would like to ask if systemd has any requirements as far as the syscall interface is concerned (then minimal kernel version)? Does the same stand for glibc (i.e. same question)? Thanks a lot, -Ilyes Hi Take a look at the README file ( http://cgit.freedesktop.org/systemd/systemd/tree/README ). The requirements are listed there. The DISTRO_PORTING file will probably give you some clues for your work as well, and there has been work done to port systemd to the embedded distribution Angstrom :-) Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] openvpn@.service
2011/11/15 Manuel Amador (Rudd-O) rud...@rudd-o.com: It's a multi-instance service. You can instance it several times based on a parameter, much like tty@.service can be instantiated to be tty@tty1.service. On Tue, 2011-11-15 at 10:06 -0500, Michael D. Berger wrote: Why does openvpn@.service have the '@'? Thanks, Mike. -- Michael D. Berger Most certainly it is a socket activated service in the inetd style, i.e. one service instance per connection. The socket file probably contains Accept=yes, meaning for every connection to that socket one instance openvpn@host-ip:port-client-ip:port.service is spawned. This way, all daemons that support inetd can be socket activated in systemd, although the preferred way is to have an openvpn.service file (without the @) which gets started on the first connection and then handles all incoming connections, without exiting after all connections are closed. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
2011/11/9 Michael D. Berger m.d.ber...@ieee.org: myDaemon must start after myBaseDaemon, and must start only if myBaseDaemon is started. Do I use: After=myBaseDaemon Requires=myBaseDaemon ;or only: Requires=myBaseDaemon ? Thanks, Mike. The first. Requires alone doesn't ensure the ordering. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] After httpd.service
2011/11/6 Michael D. Berger m.d.ber...@ieee.org: In my F15_64, in myUpperDaemon.service, I need the dependency specified by: After httpd.service but there is no httpd.service . After looking at /etc/init.d/httpd, I see no obvious reason why I shouldn't write a httpd.service . But then, why is it not provided? Would there be some problem I don't see? If so, how else could I obtain the required dependency? Thanks, Mike. Systemd is compitable to SysV, so if theres an old style httpd init script in /etc/init.d, it will create a httpd.service that calls this script. So you can do the ordering without a native httpd.service file. The reason why there isn't an httpd.service shipped with f15 was that it wasn't ported yet. In f16 there are explicit service files for httpd, so if you want to use native systemd service files I suggest you take a look at the ones shipped with f16. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about generators and adding new units in the middle of a transaction
2011/11/4 Manuel Amador rud...@rudd-o.com: I am developing systemd support for ZFS: https://github.com/zfsonlinux/zfs/pull/435/files as you can see, I create the units early on bootup using a generator (a mechanism that is entirely undocumented, tsk). Then systemd proceeds with normal system startup. The whole point is to be able to mount file systems of other types on top of ZFS file systems, and then ZFS file systems on top of that. This work lets this scenario work properly: / zfs /blah ext4 /blah/blahblah zfs But, here is a problem. This works fine and dandy when ZFS has loaded the pools at boot through dracut or something, but will most assuredly fail if ZFS is not the root file system, as nothing will load the ZFS module. We have some udev mechanisms at the moment to ensure that actually happens (loading of the zfs modules, importing of all pools). Good and dandy so far. Now, this will happen during udev settle. What I want is to generate more units when pools are discovered and their file systems require to be mounted automatically. That is, I need to re-run the generator and generate new units, and then tell systemd to daemon-reload. But systemd is in the middle of a transaction, serving the unit local- fs.target. And, as you can imagine, the file systems that were discovered late, must be linked as wants of local-fs.target. So my question is: what happens if I systemctl daemon-reload DURING the transaction that brings the system up? Will systemd pick up the new units and add them as wants of local-fs.target? ideal process: root fs is mounted starting local-fs.target starting block device discovery block dev discovered, import pool in block dev oh, we found new file systems! generate units for those daemon-reload to add the new units as wants for local-fs.target start all of these new units and then, only then, local-fs.target will reach started state. Is this even possible?? Hi I know very little about ZFS so please excuse my ignorance, but I don't understand the problem you are trying to solve. Systemd parses /etc/fstab already and creates the mount units. And the necessary modules should be loaded automatically on mount, just like with all the other filesystems. And udev works nicely with systemd to announce new block devs. What differs in ZFS that this isn't working for you? Thanks Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd flapping detection
2011/11/2 tsuraan tsur...@gmail.com: Is there a way to disable systemd's flapping detection that causes it to give up on starting services that exit too quickly? The closest thing I can find to controlling this is the Restart= option, but that doesn't seem to do what I need. My situation is that each PC is a node of a cluster. When a PC reboots, it can take a while for the cluster to recognize that it has left, and until that happens attempts to rejoin the cluster are rejected. The daemon in charge of joining the cluster dies when it cannot join, and then systemd restarts it. The problem is that systemd gets sick of restarting it after a while (5 tries?), and then the node is just broken. So, I could have the daemon loop until it can join, but since I have a handful of daemons that behave this way, and systemd is really good at cleaning up and restarting things, I'd like to let systemd do the restarting work. Is there anything I can tune to make systemd not give up, or do I just need to rewrite all the main functions of my daemons to do the looping themselves? Hi RestartSec allows you to set the time waited before restarting so that you can avoid systemd needing to restart the service too often before it starts successfully. Also, are there any docs that detail how systemd does its flapping detection? Is there some time that a service has to have been running in order for it to not be considered flapping, or an exit code that systemd looks for? Any details would be appreciated. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd flapping detection
2011/11/3 tsuraan tsur...@gmail.com: RestartSec allows you to set the time waited before restarting so that you can avoid systemd needing to restart the service too often before it starts successfully. Is there a cooldown period that I need to exceed to prevent systemd from giving up? Assuming it takes 5 failures (however that's defined) before it gives up, and I have a RestartSec of 15s, then it will be 1.5min before it would give up. Is that going to be long enough that it will keep trying a sixth time, or is it just not possible to have it keep trying forever? I'm sorry, but I don't know the internals. The only tip I have is to set RestartSec high enough that this case never happens. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] starting/stopping network interfaces with systemd
2011/10/9 Cliff Brake cliff.br...@gmail.com:
On Sat, Oct 8, 2011 at 11:09 AM, Cliff Brake cliff.br...@gmail.com wrote:
and a service file like this:
cat networl@.service:
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifup %i
ExecStop=/sbin/ifdown %i
StandardOutput=syslog+console
I'm still not successfull in getting ifup to run on boot (after the
NIC is detected) or on NIC insertion.
This is actually working for me now on bootup, or first NIC insertion.
I'm not sure what I did wrong earlier -- perhaps missed reloading the
systemd config files or something ...
Cool
However, it does not work for subsequent NIC insertions. It appears
that stop is not getting executed when the device is removed, as
network@eth0.service is always listed as active after the NIC is
installed, and then removed.
Hmm, true. I wonder if the ExecStop line is really necessary, as it
doesn't make sense to execute this after the device is plugged out. So
if you drop this, you can drop the RemainAfterExit as well and it
should work for subsequent insertions.
Another way that comes to mind might be to add
ENV{SYSTEMD_ALIAS}=/$name to the udev rule and add
BindTo=%i.device in the unit section of the service file.
Cliff
Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] starting/stopping network interfaces with systemd
2011/10/7 Cliff Brake cliff.br...@gmail.com:
Hi,
I'm trying to customize systemd to start/stop network interfaces in an
embedded system (OpenEmbedded/Angstrom). Angstrom has some support
for systemd and its working fairly well so far. Are there any
examples I can start with? Basically, when a network device is
installed (USB), I'd like to run ifup eth0, etc.
this is what I have so far:
[Unit]
Description=Start networking services
After=syslog.target
[Service]
ExecStart=/sbin/ifup eth0
Type=oneshot
ExecStop=/sbin/ifdown eth0
StandardOutput=syslog+console
[Install]
WantedBy=multi-user.target
but its not working:
systemctl start network.service
asix 1-2:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
ifup[756]: udhcpc (v1.18.5) started
ifup[756]: Sending discover...
ifup[756]: Sending select for 192.168.1.100...
ifup[756]: Lease of 192.168.1.100 obtained, lease time 3600
ifup[756]: adding dns 192.168.1.1
This all looks good, but then when I do ifconfig, the network devices
is not configured:
root@cm-x270:/lib/systemd/system# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:268 (268.0 B) TX bytes:268 (268.0 B)
running ifup eth0 manually works fine.
The problem is, as soon as ifup exits systemd thinks the service is dead and
calls the ExecStop line, which of cause brings down the interface
again instantly.
The solution should be to add RemainAfterExit=yes to your service file.
Beyond this, it would be nice to somehow trigger on when a USB NIC is
installed and automatically run ifup. Any pointers would be
appreciated.
An udev rule which starts a template unit file is probably the right
thing to do.
Something like this may do the job:
SUBSYSTEM==net, KERNEL!=lo, ENV{SYSTEMD_WANTS}=network@$name.service
and a service file like this:
cat networl@.service:
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifup %i
ExecStop=/sbin/ifdown %i
StandardOutput=syslog+console
Haven't tested this or even done something like this before, so no
guarantee it will work like this.
Thanks,
Cliff
Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] converting a xinetd-service to systemd
Here it is 2011/9/10 Mirco Tischler mt...@gmx.de: 2011/9/8 Stefan G. Weichinger li...@xunil.at: Greets, systemd-devs and -users, maybe I ask a FAQ, pls be kind ... I am rather new to systemd and figuring out how to use it w/ gentoo linux. It is available within the gentoo-portage-package-system, yes. Compiles etc. But IMO it still needs some polishing there. Aside from the distro-specific stuff I simply wonder how to convert a xinetd-service to a systemd-service. Maybe I didn't find it, pls just point me at any howto ... In specific I look for how to convert my xinetd-service for the amanda backup suite and I haven't yet found an example to copy from. Thanks for any help with this issue, Stefan Hi Stefan I didn't find anything either, So I just wrote up this little (untested) example: You need to create at least two unit files, amanda.socket and amanda@.service. The socket file tells systemd which socket to create and the service file what executable to start. Based on the xinetd configuration file that comes with Fedora's amanda rpm they should look like this or something similar: amanda.socket: [Socket] ListenStream=10080 # listen for a stream (tcp) on port 10080 both on ipv4 and ipv6 Accept=yes # spawn a new instance for each incoming connection [Install] WantedBy=sockets.target # the unit is disabled by default, but can be enabled with systemctl enable amanda.socket amanda@.service: [Service] ExecStart=/usr/sbin/amandad -auth=bsdtcp amdump # the binary to start with arguments User=amandabackup # the user Group=disk # the default group If you start amanda.socket, for each incoming connection systemd spawns a service named something like amanda@host-ip:10080-client-ip:port.service. I haven't tested this and probably missed something so no guarantee at all, but it should give you a start. For further information on what the options do take a look at the man pages. Especially systemd.socket, systemd.service, systemd.exec and maybe systemd.unit should be of interest for you. Good luck Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] converting a xinetd-service to systemd
2011/9/14 Stefan G. Weichinger li...@xunil.at: What I have now: # cat amanda.socket [Socket] ListenStream=10080 Accept=true [Install] WantedBy=sockets.target # cat amanda\@.service [Unit] Description=amandad [Service] ExecStart=-/usr/libexec/amanda/amandad -auth=bsdtcp amdump User=amanda Group=amanda [Install] WantedBy=multi-user.target This leads to a failing service after I run amcheck -c ... on the backup server (this contacts the client to check availability etc). I am unsure about User and Group within the service-file, couldn't find that within the manpage. Stefan Pretty much identical to what I wrote. You can find information about User and Group in systemd.exec. Minor detail: you don't want the Install section in the service file. systemd wouldn't know what to fill in behind the @. Can you get more information why the service fails? Maybe the amanda log or systemctl status give you a clue... Mirco P.S.: sorry for the messed up formatting in my previous answer. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] converting a xinetd-service to systemd
2011/9/14 Stefan G. Weichinger li...@xunil.at:
Am 14.09.2011 22:58, schrieb Mirco Tischler:
Pretty much identical to what I wrote. You can find information about
User and Group in systemd.exec.
Ah, yes, did now.
Minor detail: you don't want the Install section in the service file.
systemd wouldn't know what to fill in behind the @.
removed that section now, thanks.
Can you get more information why the service fails? Maybe the amanda
log or systemctl status give you a clue...
I get selfcheck request failed: recv error: Connection reset by peer
on the server which somehow points at something like:
server tries to use bsdtcp-authentication and client (= the machine with
systemd listening) doesn't answer correctly.
My working xinetd-file is:
service amanda
{
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = amanda
groups = yes
server = /usr/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump
disable = no
}
I would write the unit files exactly as you did.
The amanda.socket fails after about two times trying to contact it from
the server.
systemd[1]: amanda.socket failed to queue socket startup job: File exists
systemd[1]: Unit amanda.socket entered failed state.
Maybe the Type of the service is wrong?
Easy to check: if you execute the command in a shell does amandad
background itself? If yes type should be forking, else Type=simple
(the default) is fine.
What you can try is to remove the - in front of the ExecStart
command. systemd will then no longer ignore an exit status != 0 and
will mark the services as failed. Maybe you can get more info about
those services (exit status, listed PIDs,...)
One more thing to check: if you use a very recent version of systemd
(afair v35 and up) try adding StandardInput=socket and
StandardOutput=socket to the service file.
Stefan
Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] converting a xinetd-service to systemd
2011/9/15 Stefan G. Weichinger li...@xunil.at: additional info: # systemctl status amanda.socket amanda.socket Loaded: loaded (/etc/systemd/system/amanda.socket) Active: failed since Thu, 15 Sep 2011 00:04:17 +0200; 19min ago Accepted: 22; Connected: 0 CGroup: name=systemd:/system/amanda.socket What does that say? It accepts, but doesn't connect ... S Do you actually see any amanda service instances started in the systemctl output? Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd automounts
2011/8/2 Steve Dickson ste...@redhat.com: On 08/01/2011 09:10 PM, Mirco Tischler wrote: Hi 2011/8/2 Steve Dickson ste...@redhat.com: Yes, this looks like a good usecase. Hmm, does the automount point work after boot? It seems so, because if I restart nfs-idmap.service the service comes up. How does the output of systemctl list-units look like for the automount and mount unit? attached. steved. The attached output indicates that your automount unit isn't started, and I can't see anything causing it to start in your unit files either. You can verify this with systemctl status var-lib-nfs-rpc_pipefs.automount. It appears you are correct. systemctl status var-lib-nfs-rpc_pipefs.automount show the status not being started. Note that After= is only an ordering information and doesn't cause the unit to be started. Only if the automount is started anyway through some other path, the After= line causes the service to wait until the automount point is started.You may need to add a line Wants=var-lib-nfs-rpc_pipefs.automount to your service file. Does that help you? Adding that wants does start var-lib-nfs-rpc_pipefs.automount but now I'm getting two mounts... # mount | grep rpc systemd-1 on /var/lib/nfs/rpc_pipefs type autofs (rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) or is that normal for automounts? steved. Yup that's normal. the systemd-1 is the automount point. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service should run with a certain User?
Hi 2011/4/23 Baldur bal...@email.de: Hi, I am embarrassed to answer myself after hitting the send button. Of course i should not have put test.sh in /root , because the user has no rights to access it... It works now - but now the stopping the service seems a problem. It always goes to failed because the java vm seems to provide a status=143 Loaded: loaded (/lib/systemd/system/cruisctl.service) Active: failed Process: 4811 ExecStart=/usr/bin/java $CRUISCTLOPTIONS (code=exited, status=143) CGroup: name=systemd:/system/cruisctl.service Regards (and hoping that the solution will also come to me when i hit the send button) The cleanest solution would of cause be to make the jvm exit with 0. But if that is not possible you can prefix the ExecStart path with a minus (ExecStart=-/usr/bin/java...). This way the exit status is ignored and the service should end up with status exited. Here is the working script: # # Install # in directory /lib/systemd/system [Unit] Description=Cruise Control After=local-fs.target network.target [Service] Type=simple Note that you don't need this line as simple is the default type EnvironmentFile=/etc/sysconfig/cruisctl User=cruisctl WorkingDirectory=/var/cruisecontrol ExecStart=/usr/bin/java $CRUISCTLOPTIONS #ExecStart=/tmp/test.sh $CRUISCTLOPTIONS [Install] WantedBy=multi-user.target Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto migrate some things to systemd
2011/4/19 Michael Olbrich m.olbr...@pengutronix.de: Hi, On Tue, Apr 19, 2011 at 09:02:47AM +0200, Robert Schwebel wrote: On Mon, Apr 18, 2011 at 11:57:46PM +0200, Mirco Tischler wrote: How about pointing the default.target symlink at your custom unit that pulls in only a very basic system and executes your custom setup script. That sounds pretty good, we'll try that! Unfortunately not. This is far too late. udev is already running and sockets are up too. At that point it's rather difficult to ensure that nothing else is executed. And there is already stuff confused by the ro/rw filesystem: - systemd-user-sessions[430]: Failed to remove /etc/nologin file: Read-only file system - Regards, Michael Olbrich setup.service: DefaultDependencies=off Requires=local-fs.target After=local-fs.target With such a service file as default target you should end up with only the fs mounted and not much else. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto migrate some things to systemd
Hi 2011/4/17 Michael Olbrich m.olbr...@pengutronix.de: Hi, I'm trying to migrate some stuff to systemd, but I have some problems getting it right. The scenario: I'm cross-building root file systems. I try to do as much as possible on the host system, but there is some stuff that needs to run on the target when booting for the first time. I'm not sure how to integrate this with systemd. Some of the issues I have: - With a classic init, the init-script just touches a file to indicate the one-time stuff is complete. Is there a better way for this with systemd? How about pointing the default.target symlink at your custom unit that pulls in only a very basic system and executes your custom setup script. And when you're done link default.target back to multi-user.target or whatever unit you want to start as a default and then reboot, or if you're brave call systemctl isolate default.target. - The system usually runs with a read-only mounted rootfs. I remount it temporarily for the one-time stuff. However this confuses other services that run at the same time. I'm not sure what's the best solution for this. - One of the task is prelinking the whole system. This means all programs and libraries are modified, so nothing else should be running. And systemd must be restarted before the rootfs can be mounted read-only. Again I have no idea how to do this. Any hints on how to do this? Regards, Michael Olbrich You would end up with only a very basic system so there should be no confused services or anything that cares if you remount the rootfs rw or prelink some files. However, this just popped into my head when reading your mail and I'm probably missing something... Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PgSQL, MySQL systemd services - how to rewrite complex init scripts?
Hi 2011/4/9 Michał Piotrowski mkkp...@gmail.com Hi, ... Mysql script also has some data dir creation code - I think it can also be moved to separated script. Thoughts, recommendations, comments are welcome -- Best regards, Michal Have you considered using a file in /etc/tmpfiles.d and let systemd take care of this? Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PgSQL, MySQL systemd services - how to rewrite complex init scripts?
2011/4/9 Michał Piotrowski mkkp...@gmail.com Have you considered using a file in /etc/tmpfiles.d and let syBstemd take care of this? Mirco No, but I think that this is a good idea. Thanks! Hmmm... but what if I want to change default dir? I use /home/data/ instead of /var/lib/pgsql and /var/lib/mysql -- Best regards, Michal Does mysql really try to create the data dir on every start if it doesn't exist? This sounds flawed to me. If the data dir doesn't exist it's likely there is a bigger problem. I thought we were talking about pid or lockfiles, which might reside on a tmpfs. Thanks, Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ExecConfigTest first try
Am 11.01.2011 17:40, schrieb Alexander E. Patrakov: 11.01.2011 21:11, Mirco Tischler wrote: a patch Sorry, this doesn't work as expected. To reproduce the problem: 1) Start a service with a good config 2) Edit the config. Make a typo. 3) Attempt to reload the service. At this point, systemd will put the whole service into a failed state. 4) Fix the typo. 5) Attempt to reload the service. Expected result: service reloaded with the new config. Actual result: systemd doesn't let me reload the service. Also, when starting a service, systemd tests the config twice for some reason. And it is really strange that in the system log with systemd.log_level=debug systemd.log_target=kmsg, systemd attempts to fork the main command before the check finished and thus seems to run the main command in parallel with the check. In other words, I doubt that the correct thing is tested. I suspect that the executable is found fact is tested, not the command executed successfully. Thanks for testing it. I didn't expect it to do the right thing yet ;) All the tests I was able to run for reasons of limited time was service start, restart and reload without. Seems I need to read the sources a little more. Some of them could really use more commenting. :) A second version will follow probably next week. And sorry for the patch send twice. The first version was mangled by my mailclient so I tried git send-email on the second one. Thanks Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID
Am 11.01.2011 16:11, schrieb Alexander E. Patrakov: Also, the test config before reloading feature still doesn't work right. If I add this ExecReload line before the existing one: ExecReload=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf then systemd will kill lighttpd-angel when the configuration file is bad. It should instead complain to syslog and do nothing with the running instances of lighttpd and lighttpd-angel. The behaviour seems to be undocumented (at least i havn't found anything) if the ExecReload= command fails. But if a reload fails it makes sense to me to stop a service because this service wouldn't be in the state the caller wants it to be. In this case, it doesn't make sense, because the service is still in a known state (the old state) that is still better than the non-running state from the viewpoint of avoiding downtime. There is no way you can notify systemd that the failed reload attempt was just a test prior to executing the real reload command (e.g. there is no ExecReloadPre or the like). (If a service keeps running I won't check syslog..) When the config is bad and the additional ExecReload line is present, systemd does tell me that reload failed. So I have a good reason to check syslog, and even am suggested by systemd to do so. At last: Isn't that something lighttpd should take care off? Or the user should test before issuing a reload? Or a small script can do? Isn't one of the points of systemd to eliminate such small scripts? I just implemented an additional command: ExecConfigTest, which could solve your issues. This is just a very quick first version and I'm sure I've done something wrong or oversaw somethin although in a quick test it works. If set, the command is executed prior to those commands: ExecStart or if exists ExecStartPre, ExecReload and ExecRestart. When failing, on startup, the server isn't started. On restart and reload failure leads to the service continuing to run and systemd not executing the restart/reload command. So downtime because of configuration failures can be minimized for services which provide a config test command. The patch will be a followup to this mail. Would this be usefull? Alexander, I've also thought about your email concerning yesterdays patch and you have made some valid points. I'm not sure how to fix this right yet though. Thanks Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] service: ExecConfigTest command to test config before startup/restart/reloading of service.
The ExecConfigTest command is trigerred before each ExecStart/Pre,
ExecReload
and ExecRestart command and the execution of those commands is denied when
the ExecConfigTest fails.
---
src/load-fragment.c |1 +
src/service.c | 52
+++
src/service.h |2 +
3 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/src/load-fragment.c b/src/load-fragment.c
index 261180d..b268f81 100644
--- a/src/load-fragment.c
+++ b/src/load-fragment.c
@@ -1853,6 +1853,7 @@ static int load_from_path(Unit *u, const char *path) {
{ ExecReload,
config_parse_exec,
u-service.exec_command+SERVICE_EXEC_RELOAD, Service },
{ ExecStop,
config_parse_exec,
u-service.exec_command+SERVICE_EXEC_STOP, Service },
{ ExecStopPost,
config_parse_exec,
u-service.exec_command+SERVICE_EXEC_STOP_POST, Service },
+{ ExecConfigTest,
config_parse_exec,
u-service.exec_command+SERVICE_EXEC_CONFIG_TEST,Service },
{ RestartSec,
config_parse_usec,
u-service.restart_usec,Service },
{ TimeoutSec,
config_parse_usec,
u-service.timeout_usec,Service },
{ Type,
config_parse_service_type,
u-service.type,Service },
diff --git a/src/service.c b/src/service.c
index a28eb8a..829bd5a 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1941,6 +1941,27 @@ static void service_enter_running(Service *s,
bool success) {
service_enter_stop(s, true);
}
+static int service_enter_config_test(Service *s) {
+int r = 0;
+
+assert(s);
+
+s-control_command_id = SERVICE_EXEC_CONFIG_TEST;
+if ((s-control_command =
s-exec_command[SERVICE_EXEC_CONFIG_TEST]))
+ if((r = service_spawn(s,
+ s-control_command,
+ true,
+ false,
+ !s-permissions_start_only,
+ !s-root_directory_start_only,
+ false,
+ false,
+ s-control_pid) 0))
+ service_set_state(s, SERVICE_CONFIG_TEST);
+
+return r;
+}
+
static void service_enter_start_post(Service *s) {
int r;
assert(s);
@@ -1980,6 +2001,13 @@ static void service_enter_start(Service *s) {
assert(s-exec_command[SERVICE_EXEC_START]);
assert(!s-exec_command[SERVICE_EXEC_START]-command_next ||
s-type == SERVICE_ONESHOT);
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]
!s-exec_command[SERVICE_EXEC_START_PRE]) {
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not
starting: %s, s-meta.id, strerror(-r));
+goto fail;
+}
+ }
+
if (s-type == SERVICE_FORKING)
service_unwatch_control_pid(s);
else
@@ -2044,6 +2072,13 @@ static void service_enter_start_pre(Service *s) {
service_unwatch_control_pid(s);
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]) {
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not
reloading: %s, s-meta.id, strerror(-r));
+goto fail;
+}
+}
+
s-control_command_id = SERVICE_EXEC_START_PRE;
if ((s-control_command =
s-exec_command[SERVICE_EXEC_START_PRE])) {
if ((r = service_spawn(s,
@@ -2082,6 +2117,15 @@ static void service_enter_restart(Service *s) {
goto fail;
}
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]) {
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not
restarting: %s, s-meta.id, strerror(-r));
+service_enter_running(s, true);
+return;
+}
+}
+
+
service_enter_dead(s, true, false);
if ((r = manager_add_job(s-meta.manager, JOB_START, UNIT(s),
JOB_FAIL, false, error, NULL)) 0)
@@ -2102,6 +2146,14 @@ static void service_enter_reload(Service *s) {
assert(s);
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]){
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not
reloading: %s, s-meta.id, strerror(-r));
+service_enter_running(s, true);
+return;
+
[systemd-devel] [PATCH] ExecConfigTest first try
diff --git a/src/load-fragment.c b/src/load-fragment.c
index 261180d..b268f81 100644
--- a/src/load-fragment.c
+++ b/src/load-fragment.c
@@ -1853,6 +1853,7 @@ static int load_from_path(Unit *u, const char *path) {
{ ExecReload, config_parse_exec,
u-service.exec_command+SERVICE_EXEC_RELOAD, Service },
{ ExecStop, config_parse_exec,
u-service.exec_command+SERVICE_EXEC_STOP, Service },
{ ExecStopPost, config_parse_exec,
u-service.exec_command+SERVICE_EXEC_STOP_POST, Service },
+{ ExecConfigTest, config_parse_exec,
u-service.exec_command+SERVICE_EXEC_CONFIG_TEST,Service },
{ RestartSec, config_parse_usec,
u-service.restart_usec,Service },
{ TimeoutSec, config_parse_usec,
u-service.timeout_usec,Service },
{ Type, config_parse_service_type,
u-service.type,Service },
diff --git a/src/service.c b/src/service.c
index a28eb8a..829bd5a 100644
--- a/src/service.c
+++ b/src/service.c
@@ -1941,6 +1941,27 @@ static void service_enter_running(Service *s, bool
success) {
service_enter_stop(s, true);
}
+static int service_enter_config_test(Service *s) {
+int r = 0;
+
+assert(s);
+
+s-control_command_id = SERVICE_EXEC_CONFIG_TEST;
+if ((s-control_command = s-exec_command[SERVICE_EXEC_CONFIG_TEST]))
+ if((r = service_spawn(s,
+ s-control_command,
+ true,
+ false,
+ !s-permissions_start_only,
+ !s-root_directory_start_only,
+ false,
+ false,
+ s-control_pid) 0))
+ service_set_state(s, SERVICE_CONFIG_TEST);
+
+return r;
+}
+
static void service_enter_start_post(Service *s) {
int r;
assert(s);
@@ -1980,6 +2001,13 @@ static void service_enter_start(Service *s) {
assert(s-exec_command[SERVICE_EXEC_START]);
assert(!s-exec_command[SERVICE_EXEC_START]-command_next || s-type
== SERVICE_ONESHOT);
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]
!s-exec_command[SERVICE_EXEC_START_PRE]) {
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not
starting: %s, s-meta.id, strerror(-r));
+goto fail;
+}
+ }
+
if (s-type == SERVICE_FORKING)
service_unwatch_control_pid(s);
else
@@ -2044,6 +2072,13 @@ static void service_enter_start_pre(Service *s) {
service_unwatch_control_pid(s);
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]) {
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not reloading:
%s, s-meta.id, strerror(-r));
+goto fail;
+}
+}
+
s-control_command_id = SERVICE_EXEC_START_PRE;
if ((s-control_command = s-exec_command[SERVICE_EXEC_START_PRE])) {
if ((r = service_spawn(s,
@@ -2082,6 +2117,15 @@ static void service_enter_restart(Service *s) {
goto fail;
}
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]) {
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not
restarting: %s, s-meta.id, strerror(-r));
+service_enter_running(s, true);
+return;
+}
+}
+
+
service_enter_dead(s, true, false);
if ((r = manager_add_job(s-meta.manager, JOB_START, UNIT(s),
JOB_FAIL, false, error, NULL)) 0)
@@ -2102,6 +2146,14 @@ static void service_enter_reload(Service *s) {
assert(s);
+if(s-exec_command[SERVICE_EXEC_CONFIG_TEST]){
+if((r = service_enter_config_test(s) 0)) {
+log_warning(%s failed config test, not reloading:
%s, s-meta.id, strerror(-r));
+service_enter_running(s, true);
+return;
+}
+}
+
service_unwatch_control_pid(s);
s-control_command_id = SERVICE_EXEC_RELOAD;
diff --git a/src/service.h b/src/service.h
index 500bebf..df2a218 100644
--- a/src/service.h
+++ b/src/service.h
@@ -35,6 +35,7 @@ typedef enum ServiceState {
SERVICE_RUNNING,
SERVICE_EXITED,/* Nothing is running
Re: [systemd-devel] 'tasks' as first-order objects?
Am 13.08.2010 12:49, schrieb Claes H: On Thu, Aug 12, 2010 at 9:21 PM, Lennart Poettering lenn...@poettering.net wrote: So, maybe Type=transient is nicer? Sounds a bit scientific but this word is not unheard in the Free software world at least (i.e. X uses that iirc) and describes pretty accurately what these kind of processes are used for, i.e. transient, temporary, short-running processes? Other suggestions? Intermittent? Type=finite? describes well the difference to an infinetly available service imho. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
