Re: [systemd-devel] OnCalendar every X minutes

[Mirco Tischler]

2015-03-29 23:48 GMT+02:00 Max :
> 29.03.2015 21:28, T.C. Hollingsworth пишет:
>>
>> On Mar 29, 2015 9:52 AM, "Max" > > wrote:
>> >
>> > Hi.
>> >
>> > Is there a way to make timer unit which will execute things every X 
>> > minutes where X
>> > is not divisor for 60?
>> > In case of divisor it's obvious:
>> >
>> > [Timer]
>> > OnCalendar=*:00/10
>> >
>> > Will run every 10 minutes which nicely fit into 60 minutes hour. What if I 
>> > would like
>> > to run things every 11 minutes: 0, 11, 22, 33, 44, 55, 66, 77...
>> >
>> > If I interpret 
>> > http://www.freedesktop.org/software/systemd/man/systemd.time.html
>> > correctly than
>> > OnCalendar=*:00/11 will run on 0, 11...44,55,0,11... resulting in 
>> > unevenness at the
>> > end of an hour.
>> >
>> > Am I missing something?
>>
>> Yes. :-)  See OnActiveSec and related options, listed right above OnCalendar 
>> in the
>> documentation you linked to.
>>
>
> You probably mean 
> http://www.freedesktop.org/software/systemd/man/systemd.timer.html
> which is indeed easy to confuse with what I've linked too :)
>
> Unfortunately it doesn't have any examples :(
>
> [Timer]
> OnActiveSec=11min
>
> Will this fire up once after the timer activation? How do I combine it with 
> other
> directives to make it fire _every_ 11 minutes?
>
> cheers,
> Max.
>
What you want is OnUnitActiveSec=11min. This will cause the service
(or type of unit) associated with the timer unit to start every 11
minutes. But only if the service isn't still activated as I
understand.
OnActiveSec=11min will start the service once 11 minutes after the
timer unit itself is started.
There's also OnUnitInactiveSec where the service is started 11 minutes
after it has stopped. This may be useful if your service may need more
than 11 minutes until it exits.

In the man page it is recommended to combine OnUnitActiveSec with
onBootSec to start the service once after boot and in regular
intervals from then on.

However there's one difference between these relative triggers and
OnCalendar: you can only use Persistent= in combination with
OnCalendar. This means that if your timer elapses in 5 minutes and you
suspend your machine for an hour or so, after resume it still elapses
in 5 minutes.

Mirco
___
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

[Mirco Tischler]

2015-03-05 1:22 GMT+01:00 Mirco Tischler :
> 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

Re: [systemd-devel] autoconf cache collision in check for gnuefi

[Mirco Tischler]

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

[Mirco Tischler]

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

[systemd-devel] autoconf cache collision in check for gnuefi

[Mirco Tischler]

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

[Mirco Tischler]

Am 13.02.2014 00:14 schrieb "Kai Krakow" :
>
> Mirco Tischler  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 " 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

[Mirco Tischler]

Am 12.02.2014 01:31 schrieb "Kai Krakow" :
>
> 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 " 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

[Mirco Tischler]

Am 16.01.2014 22:15 schrieb "Chris Murphy" :
>
>
> On Jan 16, 2014, at 1:58 PM, Kai Krakow  wrote:
>
> > Chris Murphy  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/.
> >
> > 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

[Mirco Tischler]

2013/5/3 Chinmay Mahata 

> 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

[Mirco Tischler]

2013/5/2 Chinmay Mahata 

> 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

[Mirco Tischler]

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

[Mirco Tischler]

2013/4/13 Zbigniew Jędrzejewski-Szmek 
>
> On Sat, Apr 13, 2013 at 01:00:02AM +0200, Mirco Tischler wrote:
> > 2013/4/12 Steven Hiscocks 
> >
> > > 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**fc2ad9026d<http://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

[systemd-devel] [PATCH] journal: fix broken tags _SOURCE_REALTIME_TIMESTAMP and _MACHINE_ID

[Mirco Tischler]

---
 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

[Mirco Tischler]

2013/4/12 Steven Hiscocks 

> 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**fc2ad9026d
>
> 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

Re: [systemd-devel] Python wrappers for the DBus API

[Mirco Tischler]

2013/3/5 Holger Winkelmann 

>
> On Mar 5, 2013, at 10:21 PM, Mirco Tischler  wrote:
>
> 2013/3/5 Holger Winkelmann 
>
>> Hi David,
>>
>> On Mar 5, 2013, at 9:52 PM, David Strauss  wrote:
>>
>> > On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann 
>> 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

Re: [systemd-devel] Python wrappers for the DBus API

[Mirco Tischler]

2013/3/5 Holger Winkelmann 

> Hi David,
>
> On Mar 5, 2013, at 9:52 PM, David Strauss  wrote:
>
> > On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann 
> 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] systemd kiosk volatile $HOME

[Mirco Tischler]

2013/3/5 

> Thank you Lennart. I wonder how your tip compares to our result? Our
> method employs getty.target and local-fs.target. It works but we prefer
> the Right Thing (tm). Would systemd-user-sessions.service be better for
> any reason? Here's our unit as it sits. Thanks for your input.
>
> # /etc/systemd/system/ramhome-setup.service
>
> [Unit]
> Description=Populate RAM user files from persistent store
> After=local-fs.target
>
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/rsync --archive /home/ramhome/ /ramhome
> RemainAfterExit=no
>
> [Install]
> RequiredBy=getty.target
>
> After=local-fs.target is not needed, as this is implied in the default
dependencies.

Ordering against getty.target seems wrong, because it would theoretically
be possible to start a graphical or ssh session before your service
finishes. systemd-user-sessions.service ensures no user can log in until
then (It deletes the file /run/nologin, which is created very early).

Also, RemainAfterExit=no is the default, no need to include it

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

[Mirco Tischler]

---
 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] [PATCH 3/3] coredump: make use of the cleanup macros

[Mirco Tischler]

2013/2/4 Zbigniew Jędrzejewski-Szmek 

> 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 2/3] logs-show: show messages for all unit types in systemctl status

[Mirco Tischler]

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

[systemd-devel] [PATCH 3/3] coredump: make use of the cleanup macros

[Mirco Tischler]

---
 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 1/3] journal: log user units for coredumps and show them in systemctl status

[Mirco Tischler]

---
 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

Re: [systemd-devel] journalctl to csv

[Mirco Tischler]

2013/1/29 Kai Hendry 

> On 29 January 2013 15:33, Zbigniew Jędrzejewski-Szmek 
> 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

[Mirco Tischler]

2013/1/18 Zbigniew Jędrzejewski-Szmek 

> 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 0/5] support for logging the unit of user session units

[Mirco Tischler]

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

[systemd-devel] [PATCH 3/5] logs-show: add show_journal_by_user_unit

[Mirco Tischler]

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

[systemd-devel] [PATCH 1/5] journal: log _SYSTEMD_USER_UNIT for user session units

[Mirco Tischler]

---
 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) {
+   

[systemd-devel] [PATCH 5/5] man: document the _SYSTEMD_USER_UNIT journal field

[Mirco Tischler]

---
 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 @@
 
_SYSTEMD_CGROUP=
 
_SYSTEMD_SESSION=
 _SYSTEMD_UNIT=
+
_SYSTEMD_USER_UNIT=
 
_SYSTEMD_OWNER_UID=
 
 
 The 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 4/5] systemctl: print the user session journal for user session units.

[Mirco Tischler]

---
 src/systemctl/systemctl.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index a2ad0de..d196f15 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2466,13 +2466,23 @@ static void print_status_info(UnitStatusInfo *i) {
 
 if (i->id && arg_transport != TRANSPORT_SSH) {
 printf("\n");
-show_journal_by_unit(stdout,
- i->id,
- arg_output,
- 0,
- i->inactive_exit_timestamp_monotonic,
- arg_lines,
- flags);
+if(arg_scope == UNIT_FILE_SYSTEM)
+show_journal_by_unit(stdout,
+ i->id,
+ arg_output,
+ 0,
+ 
i->inactive_exit_timestamp_monotonic,
+ arg_lines,
+ flags);
+else
+show_journal_by_user_unit(stdout,
+  i->id,
+  arg_output,
+  0,
+  
i->inactive_exit_timestamp_monotonic,
+  arg_lines,
+  getuid(),
+  flags);
 }
 
 if (i->need_daemon_reload)
-- 
1.8.1.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 2/5] core: log USER_UNIT instead of UNIT if in user session

[Mirco Tischler]

---
 src/core/execute.c | 12 ++--
 src/core/job.c | 16 
 src/core/mount.c   |  4 ++--
 src/core/service.c |  4 ++--
 src/core/unit.c|  8 
 src/core/unit.h|  5 -
 6 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/src/core/execute.c b/src/core/execute.c
index 9718e43..65a10af 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1024,8 +1024,8 @@ int exec_spawn(ExecCommand *command,
 
 r = exec_context_load_environment(context, &files_env);
 if (r < 0) {
-log_struct(LOG_ERR,
-   "UNIT=%s", unit_id,
+log_struct_unit(LOG_ERR,
+   unit_id,
"MESSAGE=Failed to load environment files: %s", 
strerror(-r),
"ERRNO=%d", -r,
NULL);
@@ -1039,8 +1039,8 @@ int exec_spawn(ExecCommand *command,
 if (!line)
 return log_oom();
 
-log_struct(LOG_DEBUG,
-   "UNIT=%s", unit_id,
+log_struct_unit(LOG_DEBUG,
+   unit_id,
"MESSAGE=About to execute %s", line,
NULL);
 free(line);
@@ -1512,8 +1512,8 @@ int exec_spawn(ExecCommand *command,
 _exit(r);
 }
 
-log_struct(LOG_DEBUG,
-   "UNIT=%s", unit_id,
+log_struct_unit(LOG_DEBUG,
+   unit_id,
"MESSAGE=Forked %s as %lu",
   command->path, (unsigned long) pid,
NULL);
diff --git a/src/core/job.c b/src/core/job.c
index 31ab118..e381ea2 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -713,25 +713,25 @@ static void job_log_status_message(Unit *u, JobType t, 
JobResult result) {
 sd_id128_t mid;
 
 mid = result == JOB_DONE ? SD_MESSAGE_UNIT_STARTED : 
SD_MESSAGE_UNIT_FAILED;
-log_struct(result == JOB_DONE ? LOG_INFO : LOG_ERR,
+log_struct_unit(result == JOB_DONE ? LOG_INFO : LOG_ERR,
+   u->id,
MESSAGE_ID(mid),
-   "UNIT=%s", u->id,
"RESULT=%s", job_result_to_string(result),
"MESSAGE=%s", buf,
NULL);
 
 } else if (t == JOB_STOP)
-log_struct(result == JOB_DONE ? LOG_INFO : LOG_ERR,
+log_struct_unit(result == JOB_DONE ? LOG_INFO : LOG_ERR,
+   u->id,
MESSAGE_ID(SD_MESSAGE_UNIT_STOPPED),
-   "UNIT=%s", u->id,
"RESULT=%s", job_result_to_string(result),
"MESSAGE=%s", buf,
NULL);
 
 else if (t == JOB_RELOAD)
-log_struct(result == JOB_DONE ? LOG_INFO : LOG_ERR,
+log_struct_unit(result == JOB_DONE ? LOG_INFO : LOG_ERR,
+   u->id,
MESSAGE_ID(SD_MESSAGE_UNIT_RELOADED),
-   "UNIT=%s", u->id,
"RESULT=%s", job_result_to_string(result),
"MESSAGE=%s", buf,
NULL);
@@ -818,8 +818,8 @@ int job_finish_and_invalidate(Job *j, JobResult result, 
bool recursive) {
  * this context. And JOB_FAILURE is already handled by the
  * unit itself. */
 if (result == JOB_TIMEOUT || result == JOB_DEPENDENCY) {
-log_struct(LOG_NOTICE,
-   "UNIT=%s", u->id,
+log_struct_unit(LOG_NOTICE,
+   u->id,
"JOB_TYPE=%s", job_type_to_string(t),
"JOB_RESULT=%s", job_result_to_string(result),
"Job %s/%s failed with result '%s'.",
diff --git a/src/core/mount.c b/src/core/mount.c
index 25bc7e1..18ce73b 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -955,11 +955,11 @@ fail:
 void warn_if_dir_nonempty(const char *unit, const char* where) {
 if (dir_is_empty(where) > 0)
 return;
-log_struct(LOG_NOTICE,
+log_struct_unit(LOG_NOTICE,
+   unit,
"MESSAGE=%s: Directory %s to mount over is not empty, 
mounting anyway.",
unit, where,
"WHERE=%s", where,
-   "_SYSTEMD_UNIT=%s", unit,
MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
NULL);
 }
diff --git a/src/core/service.c b/src/core/service.c
index 9e46dba..bc41617 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -2939,13 +2939,13 @@ static void service_sigchld_event(Unit *u, pid_t pid, 
int code, int status) {
 f = SERVICE_SUCCESS;
 }
 
-log_struct(f == SERVICE_SUCCESS 

Re: [systemd-devel] simultaneous udp listeners for ipv4+6 caused systemd to go into a loop

[Mirco Tischler]

2012/12/5 Thomas H.P. Andersen 

> 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

[Mirco Tischler]

2012/11/18 Warpme 

> 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= 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.

[Mirco Tischler]

2012/11/15 Zbigniew Jędrzejewski-Szmek 

> 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.

[Mirco Tischler]

This allows the journal code to set the _SYSTEMD_UNIT tag for messages generated
by systemd --user session units.
---
 src/shared/cgroup-util.c | 79 +++-
 1 file changed, 51 insertions(+), 28 deletions(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index b0d378d..6e13aae 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,43 +1250,30 @@ 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;
-}
+p = strrchr(cgroup, '/') + 1;
+k = strlen(p);
 
-j = strcspn(p+k+1, "/");
-
-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);
 
 if (!b)
 return -ENOMEM;
 
-*unit = b;
+r = unit_name_is_valid(b, true);
+if (!r){
+free(b);
+return -ENOENT;
+}
+
+   *unit = b;
+
 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.

[Mirco Tischler]

2012/11/6 Mirco Tischler :
> 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

[systemd-devel] [PATCH] cgroup: look up user session units from cgroups as well.

[Mirco Tischler]

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] no log for user sessions in systemctl?

[Mirco Tischler]

2012/11/5 Thomas Meyer :
> Hi,
>
> why is no log shown for user session?
>
> like this:
>
> $ systemctl --user status smServer.service
> smServer.service - ShortMessage Server
>   Loaded: loaded (/usr/lib/systemd/user/smServer.service; enabled)
>   Active: active (running) since Mon, 05 Nov 2012 23:12:18 +0100; 
> 42min ago
> Main PID: 20651 (java)
>   CGroup: name=systemd:/user/thomas/5/systemd-20649/smServer.service
>   └ 20651 /usr/bin/java smServer.Controller
>
> -> no log
>
> but:
>
> journalctl -f
>
> Nov 05 23:53:07 localhost.localdomain java[20651]: Nov 05, 2012 11:53:07 PM 
> smServer.InnoApi send0
> [...]
> Nov 05 23:53:08 localhost.localdomain java[20651]: Nov 05, 2012 11:53:08 PM 
> smServer.InnoApi send0
> Nov 05 23:53:08 localhost.localdomain java[20651]: INFO: SMS send. Return 
> code 100
>
This isn't currently possible. However I had a patch pending that
implements this which I totally forgot about and have now send to the
list. So thanks for the reminder :-)

Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] live remote logging?

[Mirco Tischler]

2012/10/31 Cliff Brake :
> On Wed, Oct 31, 2012 at 10:36 AM, Mirco Tischler  wrote:
>>
>> 2012/10/31 Cliff Brake :
>>
>> 6) nfs mount either the server's /var/log/journal over the clients
>> /var/log/journal, or all of the
>> clients /var/log/journal/s 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] live remote logging?

[Mirco Tischler]

2012/10/31 Mirco Tischler :
> 2012/10/31 Cliff Brake :
>> 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?

[Mirco Tischler]

2012/10/31 Cliff Brake :
> 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/s 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] Race condition for service dependent on mount

[Mirco Tischler]

2012/10/18 David Strauss :
> 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

[Mirco Tischler]

2012/10/17 Reindl Harald :
> 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?

[Mirco Tischler]

2012/10/4 Ingo Molnar :
> 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

[Mirco Tischler]

2012/10/2 "Jóhann B. Guðmundsson" :
> 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

[Mirco Tischler]

2012/10/2 Kok, Auke-jan H :
> On Mon, Oct 1, 2012 at 4:58 AM, Matthew Booth  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

[Mirco Tischler]

2012/9/26 Lennart Poettering 
>
> 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

[Mirco Tischler]

2012/9/27 Henrik /KaarPoSoft :
> On 09/27/12 00:05, Tom Gundersen wrote:
>>
>> On Thu, Sep 27, 2012 at 12:02 AM, Henrik /KaarPoSoft
>>  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 2/2] journalctl: print correct timespan in verify

[Mirco Tischler]

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

[systemd-devel] [PATCH 1/2] journal: set seal even for readonly journalfiles

[Mirco Tischler]

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

Re: [systemd-devel] Question about After/Before of services

[Mirco Tischler]

2012/8/9 "Jóhann B. Guðmundsson" :
> 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

[Mirco Tischler]

2012/7/4 Kok, Auke-jan H :
> On Tue, Jul 3, 2012 at 4:49 PM, Rob Spanton  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] `systemd-analyze blame`indicates GDM3 takes longer to start with service file than with init.d script

[Mirco Tischler]

2012/6/25 Paul Menzel :
> Dear systemd folks,
>
>
> after a system start I save the output of `systemd-anlyze blame`.
>
> With Debian Sid/unstable, GDM 3.4.1 and the shipped init.d script on
> average it took about 120 ms. For example:
>
>    124ms gdm3.service
>
> Adding the following service file
>
>        $ more /lib/systemd/system/gdm3.service[Unit]
>        Description=GNOME Display Manager
>        After=systemd-user-sessions.service
>
>        [Service]
>        ExecStart=/usr/sbin/gdm3 --nodaemon
>        Type=dbus
>        BusName=org.gnome.DisplayManager
>
>        [Install]
>        WantedBy=graphical.target
>
> I now get 190 ms on average, for example:
>
>    188ms gdm3.service
>
> Can you think of a reason for that? It should at least not take more
> time, should not it?
>
>
> Thanks,
>
> Paul
>
from systemd.service, section Type=dbus:
"systemd will proceed starting follow-up units after the D-Bus bus
name has been acquired."

Seems like systemd waits until the busname has been acquired before it
recognizes the start as finished.
If gdm is started via initscript, the type is set to forking and
systemd probably simply thinks the startup has finished a little
earlier.

Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] MemoryLimit and MemorySoftLimit

[Mirco Tischler]

Am 26. März 2012 16:46 schrieb Lennart Poettering :
> 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

[Mirco Tischler]

Am 22. März 2012 01:38 schrieb Marti Raudsepp :
> On Thu, Mar 22, 2012 at 02:16, Mirco Tischler  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] Right way to do kexec

[Mirco Tischler]

Am 22. März 2012 00:33 schrieb Lennart Poettering :
> 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] systemd kernel syscall interface requirements

[Mirco Tischler]

2012/1/15 Ilyes Gouta :
> 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

[Mirco Tischler]

2011/11/15 Manuel Amador (Rudd-O) :
> 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@:port-: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

[Mirco Tischler]

2011/11/9 Michael D. Berger :
> 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

[Mirco Tischler]

2011/11/6 Michael D. Berger :
> 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

[Mirco Tischler]

2011/11/4 Manuel Amador :
> 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

[Mirco Tischler]

2011/11/3 tsuraan :
>> 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] Systemd flapping detection

[Mirco Tischler]

2011/11/2 tsuraan :
> 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] starting/stopping network interfaces with systemd

[Mirco Tischler]

2011/10/9 Cliff Brake :
> On Sat, Oct 8, 2011 at 11:09 AM, Cliff Brake  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

[Mirco Tischler]

2011/10/7 Cliff Brake :
> 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

[Mirco Tischler]

2011/9/15 Stefan G. Weichinger :
>
> 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] converting a xinetd-service to systemd

[Mirco Tischler]

2011/9/14 Stefan G. Weichinger :
> 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

[Mirco Tischler]

2011/9/14 Stefan G. Weichinger :
> 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

[Mirco Tischler]

Here it is
2011/9/10 Mirco Tischler :
> 2011/9/8 Stefan G. Weichinger :
>>
>> 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@:10080-:.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

[Mirco Tischler]

2011/9/14 Stefan G. Weichinger :
> Am 2011-09-08 22:39, schrieb Stefan G. Weichinger:
>>
>> 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.
>
>
> Is my question too stupid to deserve an answer or a pointer?
>
> Stefan
Hm. Didn't you get my reply or was it not extensive enough?

Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question

[Mirco Tischler]

2011/9/13 Sérgio Basto :
> On Mon, 2011-09-12 at 20:21 +0200, Tomasz Torcz wrote:
>> On Mon, Sep 12, 2011 at 05:49:21PM +0100, Sérgio Basto wrote:
>> > On Mon, 2011-09-12 at 15:47 +0200, Tomasz Torcz wrote:
>> > > On Mon, Sep 12, 2011 at 03:34:48PM +0200, Reindl Harald wrote:
>> > > >
>> > Man , what version do we need ?
>>
>>   'list-unit-files' was added in 729e3769c32242bbba26ea96900be005d52ce438 in 
>> July.
>> It should be in v31.
>>
>> > I got systemd-26-9.fc15.x86_64
>>
>>   Latest packaged for Fedora is systemd-35-1.fc16.  As I said, version 
>> maintained
>> in F15 is not recent enough.
>
> thanks for this information , could I update systemd to systemd-35 in
> Fedora 15 with rebuilding the src.rpm , I don't get in trouble ? or we
> have some restrictions ?
> I we don't have restriction why systemd Fedora packager don't update
> them on Fedora 15 ?
>
>
> Thanks,
>
I used the systemd packages from f16 on a f15 system and they worked
just fine for me. You can download them here:
http://koji.fedoraproject.org/koji/packageinfo?packageID=10477

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

[Mirco Tischler]

2011/9/8 Stefan G. Weichinger :
>
> 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@:10080-:.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] systemd automounts

[Mirco Tischler]

2011/8/2 Steve Dickson :
>
>
> On 08/02/2011 04:35 AM, Mirco Tischler wrote:
>> 2011/8/2 Steve Dickson :
>>>
>>>
>>> On 08/01/2011 09:10 PM, Mirco Tischler wrote:
>>>> Hi
>>>> 2011/8/2 Steve Dickson :
>>>>>>
>>>>>> 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.
> Thanks for this tip... but things are still no quite right...
>
> the "Starting RPC Pipe File System" (i.e. the mount of  
> /var/lib/nfs/rpc_pipefs)
> was happening later than the "Starting Name to UID/GID mapping for NFSv4"
> (i.e. the nfs-idmap.service) so I added back the 
> After=var-lib-nfs-rpc_pipefs.automount
> line nfs-idmap.service which didn't seem to work... Looking at the booting 
> messages,
> the nfs-idmap.service is still being started before the automount.
>
> How I do I guarantee the automount happens and finish before nfs-idmap.service
> is started?
This is not how automount works. The real fs is only mounted when the
first acces is done which is of cause
after the service begins to start. The access is then blocked until
the fs is mounted.
However I'm starting to think automount isn't what you want at all.
Your nfs-idmap.service is started on boot and needs the rpc fs during
service startup so it doesn't make a lot of sense to delay the start
of the service with an automount point. Automount is more useful IMO
when the fs isn't usually used during boot.
Why don't you discard the automount unit and instead reference the
actual mount unit in your service file with After= and Wants= lines.
Does that make sense to you?
>
> Also now when I reboot the system hangs for a bit due to the following
> problem:
>
> [  272.510946] systemd[1]: var-lib-nfs-rpc_pipefs.mount mounting timed out. 
> Killing.
> [  362.511271] systemd[1]: var-lib-nfs-rpc_pipefs.mount mount process still 
> around after SIGKILL. Ignoring.
> [  362.609307] systemd[1]: Unit var-lib-nfs-rpc_pipefs.mount entered failed 
> state.
>
> So it appears the ordering of the shutdown is not quite right either...
I'm not sure if this is the problem but you have
DefaultDependencies=no in your unit files. Do you really need this? If
yes you might need to add Conflicts=shutdown.target to make this work
>
> steved.

Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd automounts

[Mirco Tischler]

2011/8/2 Steve Dickson :
>
>
> On 08/01/2011 09:10 PM, Mirco Tischler wrote:
>> Hi
>> 2011/8/2 Steve Dickson :
>>>>
>>>> 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] sub-processes handling question

[Mirco Tischler]

2011/7/25 Honza Horak :
> Hi,
>
> I'm wondering how good systemd is in killing all sub-processes when a
> service fails/ends (un)expectedly. Let's say a service forks several times
> during its execution and the forked processes do some nasty work to detach
> from parent process. Can we be sure that all processes will be
> interrupted/killed after main service process ends/fails?
>
> Thanks for any reply
>
> Cheers,
>
> Honza
Basically yes. It's one of the features of systemd that no other init
system provides:)

Systemd uses cgroups to track childprocesses. A process can call
fork() as much as it wants, all the childprocesses will still be in
the same cgroup as their parent. On service stop systemdthen sends
TERM and later KILL signals to all the processes left in that
service's cgroup.
The only way to escape would be by the process removing itself from
the cgroup, which seems malicious to me and should never be done by
any sane service.

Mirco
___
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?

[Mirco Tischler]

Hi
2011/4/23 Baldur :
> 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

[Mirco Tischler]

2011/4/19 Michael Olbrich :
> 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

[Mirco Tischler]

Hi
2011/4/17 Michael Olbrich :
> 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?

[Mirco Tischler]

2011/4/9 Michał Piotrowski 

> >>  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] PgSQL, MySQL systemd services - how to rewrite complex init scripts?

[Mirco Tischler]

Hi
2011/4/9 Michał Piotrowski 

> 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] systemd and sshd.socket/sshd@.service

[Mirco Tischler]

Am 17.03.2011 02:32, schrieb Lennart Poettering:
> On Thu, 17.03.11 02:21, Mirco Tischler (mircotisch...@gmx.net) wrote:
>>> Your sshd seems to return exit with a non-zero exit code just indicating
>>> a failure of some kind. use "ExecStart=-/foo/bar" instead of
>>> "ExecStart=/foo/bar" to spawn a process and ignore if it fails.
>>>
>>> Lennart
>>>
>> The most likely failure here is an authentication failure. sshd exits
>> with exit code 254(afair) in that case if in inet mode. This caused the
>> very same problem (sshd.socket shutting down) for me on a machine that
>> was accessable from the internet where I get a few hundred failed login
>> attempts per day.
> I think it is probably wise to use ExecStart=- on all instantiated
> socket services. Since failed services are not GC'ed you might otherwise
> end up collecting up quite a number of failed sshd@ instances until the
> limit is reached and further clients will be refused.
>
> Lennart
>
Yup, I agree on that. Just wanted to make a suggestion were all those
failed instances may come from :)

Thanks
Mirco



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd and sshd.socket/sshd@.service

[Mirco Tischler]

Am 17.03.2011 01:13, schrieb Lennart Poettering:
> On Sat, 19.02.11 00:15, Vasiliy G Tolstov (v.tols...@selfip.ru) wrote:
>
> Hmm, can you try to reproduce this when booting with
> systemd.log_level=debug and systemd.log_target=kmsg on the kernel
> cmdline? Then, kmsg should definitely include a message on what is going
> on. (and when we found it we probably should bump up the error level of
> that msg)
>
> Lennart
>
>> Ok. I'm add corresponding params to kernel cmdline. After sometime i
>> get on screen messages like in attached image
> Your sshd seems to return exit with a non-zero exit code just indicating
> a failure of some kind. use "ExecStart=-/foo/bar" instead of
> "ExecStart=/foo/bar" to spawn a process and ignore if it fails.
>
> Lennart
>
The most likely failure here is an authentication failure. sshd exits
with exit code 254(afair) in that case if in inet mode. This caused the
very same problem (sshd.socket shutting down) for me on a machine that
was accessable from the internet where I get a few hundred failed login
attempts per day.

Mirco



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] ExecConfigTest first try

[Mirco Tischler]

Am 11.01.2011 17:40, schrieb Alexander E. Patrakov:
> 11.01.2011 21:11, Mirco Tischler wrote:
>
> 
>
> 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

[systemd-devel] [PATCH] ExecConfigTest first try

[Mirco Tischler]

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 {
 

[systemd-devel] [PATCH] service: ExecConfigTest command to test config before startup/restart/reloading of service.

[Mirco Tischler]

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));
+  

Re: [systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID

[Mirco Tischler]

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: Allow mainpid to restart in other than SERVICE_EXEC_START.

[Mirco Tischler]

This patch should fix it. Can you test it? The problem was that after a
the mainpid exits,
and because there are commands left to execute systemd assumes it
executes an ExecStart
line from a type=oneshot service file. But in this case it executes an
ExecReload line.
This patch simply removes the assumptions. AFAICT this should work.

Mirco
---
 src/service.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/src/service.c b/src/service.c
index a28eb8a..4ff9f5d 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2181,9 +2181,6 @@ static void service_run_next_main(Service *s, bool
success) {
 if (!success)
 s->failure = true;
 
-assert(s->control_command_id == SERVICE_EXEC_START);
-assert(s->type == SERVICE_ONESHOT);
-
 s->control_command = s->control_command->command_next;
 service_unwatch_main_pid(s);
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 'tasks' as first-order objects?

[Mirco Tischler]

 Am 13.08.2010 12:49, schrieb Claes H:
> On Thu, Aug 12, 2010 at 9:21 PM, Lennart Poettering
>  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