Re: [systemd-devel] [PATCH 2/3 RFC] systemd: use structured logging for unit changes

[Marius Tolzmann]

Hi..

On 10/18/12 16:12, Zbigniew Jędrzejewski-Szmek wrote:
 Information which unit a log entry pertains to enables systemctl
 status to display more log messages.
 ---
 @@ -1022,7 +1024,11 @@ int exec_spawn(ExecCommand *command,
  
  r = exec_context_load_environment(context, files_env);
  if (r  0) {
 -log_error(Failed to load environment files: %s, 
 strerror(-r));
 +log_struct(LOG_ERR,
 +   UNIT=%s, unit_id,
 +   MESSAGE=Failed to load environment files: %s, 
 strerror(-r),
 +   ERRNO=%d, errno,

shouldn't that be ERRNO=%d, (-r), ?

I did not check the rest. It just hit my eyes 8)

Bye marius..


-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] when will mount / df get fixed?

[Marius Tolzmann]

Hi..

On 10/02/12 10:11, Zbigniew Jędrzejewski-Szmek wrote:


 filesystem size mounted on
 /mnt/whatever  xxx  /wherever

 now instead displaying it as /mnt/whatever it just displays as /dev/sdb3 ..

 Which is in fact not nice, but hey, it works.
 
 This is not as nice, but actually more correct. If the original
 mountpoint is unmounted, which is certainly possible, than the old
 line with /mnt/whatever is not true anymore. The line with
 /dev/whatever is still correct.

That's true. But as long as '/' of the same device is also mounted it
may be possible to display it that way. So the mount order is not important.

 BTW Is there a way to see what olddir was bind mounted on which
 newdir with /etc/mtab being a symlink to /proc(/self)/mounts? Does
 the kernel keep track of this information at all? Should it at all
 keep track of it? And if not, why not? Is this information present
 in some kernel structure which is just not exported via procfs?
 Hey, Kernel guys, please help 8)
 $ sudo mount --bind /usr/share/info /tmp/info
 $ findmnt
 ...
 └─/tmp/info /dev/mapper/root[/usr/share/info] ext4 rw,noatime,err
 
 So, the answer is yes. The data comes from /proc/self/mountinfo.

Oh I missed that... thank you. I actually looked at /proc/self/mountinfo
but misinterpreted the output. And my findmnt seems to be out of date,
because it does not show this information. ;)

 Because it is not /dev/sda1 which is mounted as /. It is / of (the
 filesystem on) /dev/sda1 which is mounted as /. And it may be
 /tmp/abc of /dev/sda1 which is mounted as /home/abc/tmp (and not
 just /dev/sda1 mounted as /home/abc/tmp).
 The original mountpoint is irrelevant. What you say, that the / of the
 filesystem is mounted, is true. But by convention, when mounting the /
 of the filesystem, mount shows it as if the device was mounted. This
 makes sense because it is certainly the most common case.

I agree, it is irrelevant if you mount the root (/). ;)

But to focus again to the original problem, where df does not work
(because systemd is evil and broke it ;) )

I think (given your information) that it may be possible to fix the
original issue where a symlinked mtab pollutes df output just by using
the information provided by the kernel itself and not depending on some
maybe-out-of-date-/etc/mtab.

If no file name is given, the space available on all currently mounted
file systems is shown. (from df(1)). If this is intended, then it was
broken before, because it only showed filesystems recorded in /etc/mtab
and not all mounted filesystems 8).

So maybe neither (symlinked) /etc/mtab nor df needs to be fixed. There
is just a tool missing, showing only the diskusage / available space of
all currently used/mounted block devices (only once)? (Or a filter in
df: df -b or df --block-devices)

..or whatever.. but it is not a systemd issue at all and I think there
is no need to continue the flamewar, since all the information needed to
fix this, is available under /proc ;)

regards,
marius..

-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] when will mount / df get fixed?

[Marius Tolzmann]

Hi..

On 01.10.2012 20:32, Reindl Harald wrote:



and how they should do this after the change that there
is no flag? dispaly a RANDOM line?


That is a possibility. Based upon that you are only interested
in the device anyway, I conclude the mountpoint is irrelevant


that makes preety no sense on a server with  100 bind-mounts
if everytime any of the admins type df he sees different
mountpoints - this is a computer not a gambling machine


Can't you just revert the old behavior by removing the symlink and just 
touching /etc/mtab? Or do I miss something? If your system depends on 
stuff like that, then just do it the way you need it.. It's open source 
and you can do what ever you want?


I think systemd will just issue a warning that you may just want to 
ignore. (Or has that changed in the past and systemd enforces this and 
stops working?)



and these are basic things which should be considered BEFORE
any invasive change and not after the damage is done since
more than a year


Actually for me df always showed every bind mounted mountpoint. Since it 
was recorded in /etc/mtab it also showed which olddir I have mounted on 
which newdir (mount --bind olddir newdir)


like in

filesystem size mounted on
/mnt/whatever  xxx  /wherever

now instead displaying it as /mnt/whatever it just displays as /dev/sdb3 ..

Which is in fact not nice, but hey, it works.

BTW Is there a way to see what olddir was bind mounted on which newdir 
with /etc/mtab being a symlink to /proc(/self)/mounts? Does the kernel 
keep track of this information at all? Should it at all keep track of 
it? And if not, why not? Is this information present in some kernel 
structure which is just not exported via procfs?

Hey, Kernel guys, please help 8)

Because I personally think displaying /dev/sdb4 as a device in 
/proc/mounts for a bind-mount may in fact be wrong. Because i can't use 
the information displayed there to unmount that mountpoint and mount it 
again? Or can I? I don't think so, because the information which 
subdirectory (olddir) was mounted here is not displayed.
(I did not yet do any research on this topic - that is just what came to 
mind while following this discussion)


I really think there is some regression after replacing /etc/mtab with a 
symlink. But I also do think symlinking /etc/mtab was a good thing to 
do: to keep /etc/mtab up-to-date.


IMHO the regression is partially caused by /proc/mounts not showing the 
olddir information but just the device name (/dev/sdXn, /dev/mdXn, ..).


Because it is not /dev/sda1 which is mounted as /. It is / of (the 
filesystem on) /dev/sda1 which is mounted as /. And it may be /tmp/abc 
of /dev/sda1 which is mounted as /home/abc/tmp (and not just /dev/sda1 
mounted as /home/abc/tmp).


But I think this is in fact a kernel issue and has nothing to do with 
systemd - so sorry for the noise here but hopefully someone here can 
follow my thoughts and cares about fixing/changing this so that systemd 
won't be blamed for this again.. 8)


But at last: I also do not think flaming and crying will help to solve 
any issue.


Thanks and bye marius..


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

Re: [systemd-devel] [PATCH] main: fix error message if PR_SET_CHILD_REAPER is not available

[Marius Tolzmann]

Hey..

On 21.08.2012 22:38, shawn wrote:

On Fri, 2012-08-17 at 11:15 +0200, Marius Tolzmann wrote:


But 'git grep PR_SET_CHILD_SUBREAPER' on the 3.3.8 (EOL) branch did
not
return any matches for me. So I guess it may be correct to mention
3.4
here. Also a 'git br -a --contains ebec18a6' states linux-3.4.y as the
first branch to contain Lennarts commit.


oh you are right, my bad.

v3.3-6165-gebec18a means included in 3.4


ok.. I really got confused and started to mistrust the way i do check 
this..  (actually git br -a --contains won't show cherry-picked commits 
as far as I know (now)..)


Thanks for checking it again 8)

Best, marius..


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

Re: [systemd-devel] [PATCH] main: fix error message if PR_SET_CHILD_REAPER is not available

[Marius Tolzmann]

Hi..

On 08/17/12 02:44, shawn wrote:
 On Thu, 2012-08-16 at 18:38 +0200, Marius Tolzmann wrote: 
 ---
 +if (r  0  errno == EINVAL)
  log_error(Perhaps the kernel version is too old ( 
 3.4?));
 
 PR_SET_CHILD_SUBREAPER made it into 3.3, so this should be say (3.3?)

I actually just changed the error handling logic and did not care much
about the content of error messages.. Because this fixes *my* problem..
8) Thats what I like at open source the most: I fix *my* problems and
(try to) share 8)

But 'git grep PR_SET_CHILD_SUBREAPER' on the 3.3.8 (EOL) branch did not
return any matches for me. So I guess it may be correct to mention 3.4
here. Also a 'git br -a --contains ebec18a6' states linux-3.4.y as the
first branch to contain Lennarts commit.

As mentioned before, it may be reasonable to change those message to
log_warning() since it may still be ok not to reparent all childs to
systemd --user. At least if the error is EINVAL, which seems to be the
only error setting PR_SET_CHILD_SUBREAPER may raise (at the moment).

Or if this is worth a log_error(), changing the requirements section in
the README to reflect that linux kernel = 3.4 is required (for the
systemd --user usecase) may be a good idea.

As far as I understand this feature, it is not just to have a stylish
process-list but to be able to predictable handle dying child processes.

Best, marius..

-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Fix error message if PR_SET_CHILD_REAPER is not available

[Marius Tolzmann]

Hi,

I just hit some possible wrong error messages. Since prctl() is a 
system call it won't return -errno but just -1 and set errno to some value.

The attached patch should fix those error messages, if, for example, 
PR_SET_CHILD_REAPER is 
not yet implemented due to an older kernel.

BTW the REQUIREMENTS section in the README still has Linux kernel = 2.6.39 in 
it. May be it 
should at least be updated to reflect a *recommended* version of Linux kernel 
= 3.4?  
Because the messages I just tried to fix are log_error() and not log_warning().

Best,

Marius Tolzmann


Marius Tolzmann (1):
  main: fix error message if PR_SET_CHILD_REAPER is not available

 src/core/main.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.7.5.2

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

[systemd-devel] [PATCH] main: fix error message if PR_SET_CHILD_REAPER is not available

[Marius Tolzmann]

---
 src/core/main.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/core/main.c b/src/core/main.c
index cdd77c1..8973637 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1511,8 +1511,8 @@ int main(int argc, char *argv[]) {
 /* Become reaper of our children */
 r = prctl(PR_SET_CHILD_SUBREAPER, 1);
 if (r  0)
-log_error(Failed to prctl(PR_SET_CHILD_SUBREAPER): 
%s, strerror(-r));
-if (r == -EINVAL)
+log_error(Failed to prctl(PR_SET_CHILD_SUBREAPER): 
%m);
+if (r  0  errno == EINVAL)
 log_error(Perhaps the kernel version is too old ( 
3.4?));
 }
 
-- 
1.7.5.2

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

Re: [systemd-devel] start service only on specific exit status of some prog

[Marius Tolzmann]

On 24.08.2011 16:01, Lennart Poettering wrote:

On Tue, 02.08.11 17:06, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote:


is there a way to execute a program and take its exit status to
evaluate the condition? like ConditionExec or whatever.

is this already possible without getting a failed service?


Hmm, so I think we should make sure that systemd unit files don't become
a programming language. i.e. there needs to be a limit on what we want
to allow to be expressed in unit files. I am tempted to say that checks
like this are probably beyond that limit, and fall into the domain where
shell scripts should be used. I.e. write a tiny shell script that is
executed in ExecStartPre invokes your tool, checks the return code and
then fails if needed.


Hi... thanks for the reply..

i really don't want to implement complex checks within unit files.. but 
currently systemd lacks a clean possibility to implement complex checks 
outside of unit files.


I first tried the StartExecPre= approach.. but it turns out to be 
somehow destructive in combination with Restart=always.. and you end 
with a failed service.


Currently we have a unit that starts a script which starts other units 
via systemctl.. it works.. but this too is not really nice, because you 
can still directly start those unit files by mistake and they won't 
complain about any external conditions..


since i can't figure out a nice way to evaluate complex conditions i 
asked for some help here and proposed something like 
ConditionExec=/some/prog to be able to implement some small c-program to 
do complex condition checking outside of systemd... We just need a way 
to integrate the result without loosing some cool systemd features.. 8)


may be this could be implemented in future releases or is this a real no-go?

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

Re: [systemd-devel] start service only on specific exit status of some prog

[Marius Tolzmann]

On 24.08.2011 18:52, Lennart Poettering wrote:

Hmm, yeah, if ExecStartPre= we put the unit in failure mode.

So, let me see if I got this right: you are looking for something like
ExecStartPre= but twhere the program when it returns non-zero should
just cause the service to be skipped but not be put in failure state?


Yes. that's my request.

something like ConditionExec=/bin/true and ConditionExec=/bin/false so i 
can implement any thinkable logic outside of systemd and still maintain 
access to all features like Restart= etc.


I thought this may be an easy way to expand the already existent 
conditions (ConditionPathExists= etc.)  without implementing too many 
special conditional tests in systemd itself. (e.g. check if the current 
hostname matches some pattern - which was my original issue i tried to 
solve) 8)


bye, marius..

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

Re: [systemd-devel] start service only on specific exit status of some prog

[Marius Tolzmann]

On 24.08.2011 21:21, Lennart Poettering wrote:

On Wed, 24.08.11 21:12, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote:



On 24.08.2011 18:52, Lennart Poettering wrote:

Hmm, yeah, if ExecStartPre= we put the unit in failure mode.

So, let me see if I got this right: you are looking for something like
ExecStartPre= but twhere the program when it returns non-zero should
just cause the service to be skipped but not be put in failure state?


Yes. that's my request.


I have now added this to the TODO list. It won't be easy to add this
though, as execution extrernal processes synchronously is not an
option. More likely I'll add an additional prefix char to ExecStart=
(like -) which would indicate skip-on-fail or so.


I think you mean ExecStartPre= here!?

And thanks for considering implementing this feature sometime.. 8)

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

[systemd-devel] kernel dependency = 2.6.37 now?

[Marius Tolzmann]

hi..

shouldn't the kernel dependency in the README be raised to = 2.6.37 due 
to the fact that logind needs /sys/class/tty/tty0/active support which 
was first released with 2.6.37-rc7 if i don't got something wrong?


currently had trouble to get v33 working with kernel 2.6.35.x..

regards, m.


--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] start service only on specific exit status of some prog

[Marius Tolzmann]

hi..

since conditions specifying wheter a service should start are somehow 
limited to the existence of some files/directories/etc. i was searching 
for something more complex to handle conditional service starts.


is there a way to execute a program and take its exit status to evaluate 
the condition? like ConditionExec or whatever.


currently we need a service that only starts if the current hostname 
matches some value, i.e. only start service on hostA.


or we need to start a service only if some special IP is configured on a 
network interface.


is this already possible without getting a failed service?

bye m.


--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] Preset Files

[Marius Tolzmann]

hi..


On 07/06/11 16:25, Lennart Poettering wrote:
 On Wed, 06.07.11 01:07, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote:
 
 i am just afraid that someday 'systemctl preset' will break my setup
 even if a havn't defined 'enable/disable *' anywhere.
 
 Yes, it's a dangerous tool, but I think the right approach to make it
 less dangerous is adding a number of security precautions here. For
 example, we could say that when you rung systemctl reset without
 further args this would just tell you what it would do, but not actually
 do it. If you then add --force it will actually do it. Or we could alter
 this a bit and use all as special argument for this logic, so that the
 user explicitly has to tell us that presetting everything is really
 really what he wants.

don' get me wrong.. i like the idea of systemctl preset without args
will restore a *configured* default setting..

but i would prefer a behavior where it only would restore a default
setting that is configured explicitly.

so i prefer something like this for the systemctl preset without args
case:

for every unit $u do
   $state = get_unit_preset $u
   if $state==unconfigured = continue loop
   set unit to state to $state
done

(state := enabled | disabled | unconfigured)

instead of something like that:

for every unit $u do
   $state = get_unit_preset $u
   if $state==unconfigured = $state=enable
   set unit to state to $state
done

...so if disable/enable * is explicitly configured... do it..
and if a service does not match any rule.. just keep the current state..

systemctl preset unit may still enable the unit by default if not
configured.. this won't break my system setup.. 8)

at work i am currently the only one who cares about systemd but not the
only one with root access...  but i will be the one to blame if
something breaks: hey, i tried your systemd-thing and entered
'systemctl preset'... now everything is started by default.. i don't
like it.. fix it.. it's your systemd... you are the only one who likes
it.. hrhr.. ..

8)

i will probably end up writing a script creating presets for the
different hosts and updating those presets every time something
changes.. wouldn't be that hard.. but it is different to just ssh-ing to
host X and enable/disable service y...

no matter what... presets are a great idea 8)

--force or keyword all is also a better approach than without args..
so i could blame my co-roots for being stupid and ugly and just go home 8)


bye marius..


-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] possible bug guessing mainpid when service type=forking..

[Marius Tolzmann]

hi..

On 06/20/11 21:36, Lennart Poettering wrote:
 
 This very much sounds as if the service does not wait in the top-level
 process that the daemon process is properly forked and finished writing
 the PID file. systemd tries to read the PID file immediately after the
 top-level process exits which means that systemd will race against the
 daemon there.
 
 So my guess is that ypbind-mt does something like this:
 
fork() -- fork() -- write_pid_file()
exit() exit() run_main_loop()

thats it..

 but it should be doing:
 
fork()  fork() -- write_pid_file()
wait_for_notify()exit() notify_grandparent()
exit()  run_main_loop()
... 

the run-in-foreground patch works fine.. and as far as i understood
Type=forking is just good for compatibility and daemons should not fork
away anymore!?

 i.e. the main process should not exit before it hasn't ensure that the
 PID file of the daemon process has been written. Otherwise any usage of
 the PID file is necessarily racy.

but it doesn't work without setting PIDFile= either - so the PID itself
is racy, too.

 BTW a patch for ypbind-mt adding a -foreground commandline switch will
 be sent to the maintainers soon..
 
 Nice, this is good to hear, Type=simple is definitely the ncier solution.

may be it could be mentioned in the manpage where Type=forking is
explained that there could be a race if the daemon is forking twice or
if it behaves odd in another way.. - GuessMainPID= already states that
it may not work reliable..

there was nothing written to the logs that pointed in that direction and
increasing verbosity changed everything 8) tricky situation and i think
systemd should not be blamed for this.. ever 8)

bye marius..


-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trying to build on a new LFS system.

[Marius Tolzmann]

On 06/21/11 08:24, Stef Bon wrote:
 2011/6/20 Marius Tolzmann tolzm...@molgen.mpg.de:
 Hi there..

 we are also using a self-maintained LFS based gnu/linux here.

 we switched to systemd in Nov 2010 and it worked fine from the start..
 
 What version are you using?

currently systemd v27 on production workstations and v29 on my
workstation.. it works..

 And what version of kernel? Did you have to tune your kernel?? (for
 example devfs..)

kernel 2.6.35.x patched with the 676db4af linux-git commit (cgroupfs:
create /sys/fs/cgroup to mount cgroupfs on)

and kernel 2.6.39.x ..

as far as i can tell from the build logs i activated cgroups, autofs4
and devtmpfs..

i currently don't know the exact kernel options activated to get systemd
working but i think they were mentioned in this list some time ago and
may be explained somewhere else ?!? - i could send you my kernel config
if interested..

bye m.


-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trying to build on a new LFS system.

[Marius Tolzmann]

Hi there..

we are also using a self-maintained LFS based gnu/linux here.

we switched to systemd in Nov 2010 and it worked fine from the start..

since we started a new LFS we decided not to integrate any support for
sysv anymore by compiling systemd with

--with-distro=other
--with-sysvinit-path=
--with-sysvrcd-path=
--with-rootdir=

from the first day..

it may be a good idea not to include any sysv initscripts anymore in LFS
to really get a clean system..

if you can't boot your LFS anymore you may just switch back to the
chrooted environment or try to fix things by providing init=/bin/bash

Be sure to get a recent enough DBUS and udev and activate all the needed
kernel options for cgroup support and autofs.. since LFS didn't provided
this back in Nov 2010 we had some minor trouble there..

but as i said: it just worked.. and we never ended booting up an
unusable system..

bye marius..



On 06/20/11 10:56, Stef Bon wrote:
 Hi,
 
 I'm trying to build systemd on a shiny new LFS system. I roughly followed the
 instructions here:
 
 http://www.linuxfromscratch.org/lfs/view/development/index.html
 
 Since this is a very minimal system, you have to add extra software:
 Right now the output of configure is:
 
 systemd 29
 
 Distribution:other
 SysV compatibility:  yes
 SysV init scripts:   /etc/init.d
 SysV rc?.d directories:  /etc/rc.d
 Gtk: no
 libcryptsetup:   no
 tcpwrap: no
 PAM: no
 AUDIT:   no
 SELinux: no
 binfmt:  yes
 prefix:  /usr/local
 root dir:
 udev rules dir:  /lib/udev/rules.d
 pam modules dir: /lib/./security
 dbus policy dir: /etc/dbus-1/system.d
 dbus session dir:/usr/share/dbus-1/services
 dbus system dir: /usr/share/dbus-1/services/../system-services
 dbus interfaces dir: /usr/share/dbus-1/services/../interfaces
 

-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [bug?] screen not working correctly under systemd

[Marius Tolzmann]

hi..

may be the complete session of the user gets killed after logout..

to prevent this i have set

session required pam_systemd.so create-session=1 kill-user=0 kill-session=0

in my PAM config.. see pam_systemd(8) ..

so screen sessions do continue to run after logout here..

bye m.

On 05/19/11 08:47, microcai wrote:
 When you ssh to an systemd machine, and start a screen session, detach
 and logout.

 Then this screen session will be wipe out by systemd, so , when you
 login back, there will be no screen session out there.

 Is this a bug? of screen or systemd?


-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] user startable services in systemd context

[Marius Tolzmann]

Hi again..

we have a setup where every user can start its own services
(e.g. a webserver, database server, whatever).

if the user wants this service to be started after a reboot he just
tells us the name of its startup files and we add those to our startup
system. The service is then started with user privileges.

the user is able to stop and start the service any time..

is there a way this kind of setup can be configured in systemd?

thats what we would like to do:
- start services unprivileged (this already works with systemd)
- let the user start, stop, restart his service

currently the user is able to stop his service (e.g. just kill it) but
then systemd complains about a stopped service. if the user starts his
service again he starts it in his user session/cgroup which gets moved
to the users master session/cgroup after a logout. this is not very nice.

so i like to clean this mess up a bit but havn't found much information
how this could already be done or if it is even planned to be a possible
configuration in the future.

bye marius


-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] some issues with missing HAVE_SYSV_COMPAT and /run/lock

[Marius Tolzmann]

Hi..

i just built and installed systemd-v23 (upgraded from v19)

since we are using a linux from scratch based distribution i used the
following configure options:

 --with-distro=other \
 --with-sysvinit-path= \
 --with-sysvrcd-path= \
 --with-pamlibdir=/lib/security \
 --with-rootdir=

this also disables SYSV_COMPAT..


after the reboot i experienced some problems with the new /run, /run/lock:

* var-lock.mount is still wanted by local-fs.target but was not
  installed due to missing SYSV_COMPAT

* /run/lock is not mounted/created since tmpfiles.d/legacy.conf is not
  installed (?)

* dependencies on var-lock.mount are also failing with:
  Cannot add dependency job for unit var-lock.mount, ignoring: Unit
   var-lock.mount failed to load: No such file or directory. See system
   logs and 'systemctl status' for details.
  (ATM i don't know which unit triggers this)

So how am i supposed to fix the missing /run/lock issue? i thought
systemd would be responsible for creating this or mounting some tmpfs
(i don't know the status quo in the /run / lock / lockdev discussion ;)

are tmpfiles.d/legacy.conf and var-lock.mount really dependent on the
sysv-compatibility / the existence of sysv-init-directories?
(we don't have any sysv-init scripts installed anymore since we
completly switched to systemd v15 some time ago)


i would greatly appreciate any assistance.. 8)

regards,

marius..



-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] some issues with missing HAVE_SYSV_COMPAT and /run/lock

[Marius Tolzmann]

hi..

On 04/06/11 16:01, Lennart Poettering wrote:
 On Wed, 06.04.11 15:30, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote:
 
 * /run/lock is not mounted/created since tmpfiles.d/legacy.conf is not
   installed (?)
 
 Yes, correct.
 
 So how am i supposed to fix the missing /run/lock issue? i thought
 systemd would be responsible for creating this or mounting some tmpfs
 (i don't know the status quo in the /run / lock / lockdev discussion ;)
 
 Well, we came to the conclusion that /var/lock is just completely broken
 and we only want it on systems caring for legacy support. On legacy-free
 systems that dir shouldn't exist (or at least systemd should not create
 it) since it is deeply broken and we shouldn't bless something that
 broken.

so what is the replacement dir for /var/lock? wasn't it /run/lock?

if it was: how can i fix the missing /run/lock issue on a system without
legacy support (e.g. legacy.conf)?

i am a bit confused here since legacy.conf seems to be responsible for
creating /run/lock stuff which isn't the legacy way to do it (?) but the
proposed new way of handling lockfiles [since /run is new] (?)

or is it that i don't need /run/lock at all?

or short: where are my lockfiles supposed to go with systemd v23? 8)

i really like all the cleanup stuff systemd brings to the gnu/linux
world but it is sometimes very confusing... 8)

m.



-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] some issues with missing HAVE_SYSV_COMPAT and /run/lock

[Marius Tolzmann]

Hi..


 Nothing remotely sane should ever create files with a magically (the
 magic is not even defined) encoded filenames in it, to coordinate
 access to a device.

 It's one of the things where unix had really no idea what they are
 doing, regardless that it's ugly as hell, it just can't work reliably
 ever.

 Just drop all that utter nonsense if you don't need it, and use proper
 locks on the device node that go away when the locking process dies.

 We really don't want that in systemd for new systems.
 
 Marius, do you see anything using /var/lock? At least on my Gentoo
 it's not used (as expected). /var/run (/run) OTOH is full of users :-)


don't get me wrong.. i don't want to have neither /var/lock nor
/run/lock.. (and it was empty on my system, too)

i just was confused why something like /run/lock was introduced in the
first place when it now only gets enabled when legacy support is
requested and everybody wants to get rid off it..
(even the TODO list mentions that on the long run /var/lock should be a
symlink to whatever)

i totally agree removing support for this on new systems.. i just was
confused (again) when i hit the bug where var-lock.mount was still
wanted by local-fs.target but not installed anymore (lennart fixed this)
and i remembered the discussion about all the lock stuff and /run/lock..

so i am very happy with systemd v23 so far and everything works for me
with legacy-support disabled.. 8) (and without /{var,run}/lock .. 8)

the whole lock-issue seems to be something the distributions and
upstream programmers should care about and nothing systemd can fix
directly..

and again: i am really happy with the cleanup issues systemd brings up.. 8)

m.

p.s.: weiter so 8)



-- 
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] how to handle filesystems that do not support d_type in readdirs dirent?

[Marius Tolzmann]

hello..

we are currently using reiserfs on our root-partition..

since reiserfs always sets d_type to DT_UNKNOWN in dirent entries some 
tools like systemd-tmpfiles do not work as expected.


in src/util.c:3905 DT_UNKNOWN is already included when checking file for 
type DT_REG or DT_LNK.


since there seems to be no special handling for symlinks (e.g. checking 
the type of the symlinks destionation) i just fixed scandir_filter to 
also accept DT_UNKNOWN.


(other) places where DT_REG checks may fail on reiserfs or other fs that 
don't support setting the correct type of file in d_type:


src/tty-ask-password-agent.c:510: if (de-d_type != DT_REG)
src/modules-load.c:45: if (d-d_type != DT_REG 
src/tmpfiles.c:781: if (d-d_type != DT_REG 

.. how is this supposed to be handled? if the type of a symlinks 
destination isn't checked the whole check could be skipped at all?


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

Re: [systemd-devel] how to handle filesystems that do not support d_type in readdirs dirent?

[Marius Tolzmann]

hi..

On 03/03/11 13:52, Andrey Borzenkov wrote:

since reiserfs always sets d_type to DT_UNKNOWN in dirent entries some tools
like systemd-tmpfiles do not work as expected.


Hmm .. this could be the reason for my problem with utmp:


it started with a missing utmp and i tracked it down to 
systemd-tempfiles not working at all on reiserfs..




in src/util.c:3905 DT_UNKNOWN is already included when checking file for
type DT_REG or DT_LNK.



Do not assume that everyone is having exactly the same sources as you
:) Either include exact commit number for reference, or better just
name function; they are mostly small enough.


oops.. sorry for that.. i thought i mentioned that i am using the 
systemd v19 sources from the official release..




since there seems to be no special handling for symlinks (e.g. checking the
type of the symlinks destionation) i just fixed scandir_filter to also
accept DT_UNKNOWN.

(other) places where DT_REG checks may fail on reiserfs or other fs that
don't support setting the correct type of file in d_type:

src/tty-ask-password-agent.c:510: if (de-d_type != DT_REG)
src/modules-load.c:45: if (d-d_type != DT_REG
src/tmpfiles.c:781: if (d-d_type != DT_REG

.. how is this supposed to be handled?


Care to provide a patch to include missing DT_UNKNOWN in all places? :)


the question is: how to fix?

why check for regular file/symlink at all when the destination of the 
symlink is not checked again..


so there are (at least) to options to (quick) fix this:
  - remove the whole check..
  - add DT_UNKNOWN and may be in addition check for regular file using
some stat() before reading the config in systemd-tmpfiles..

marius

--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] add extra check for DT_UNKNOWN files in directory scan

[Marius Tolzmann]

Hello..

this looks fine.. and is better than just adding DT_UNKOWN 8)

i additionally patched the cgroup-util.c (see attachment)

thx for the patch..

m.


On 03/03/11 16:27, Andrey Borzenkov wrote:

Some file systems (at least, reiserfs) return DT_UNKNOWN for
every directory entry in readdir(). So far in several places
systemd filtered on DT_REG/DT_LNK and so skipped any file on
such filesystems. It affected systemd-update-utmp, systemd-modules-load
and systemd-tty-ask-password-agent.

This patch adds additional stat() check for file type for DT_UNKNOWN
case. Additionally, it adds check that DT_LNK really points to
regular file.

The patch fixes misterious runlevel entry in utmp discussed in
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001433.html

Reported-By: tolzm...@molgen.mpg.de
Signed-off-by: Andrey Borzenkovarvidj...@gmail.com

---
  src/modules-load.c   |  137 +++---
  src/tmpfiles.c   |   22 ---
  src/tty-ask-password-agent.c |8 ++-
  3 files changed, 94 insertions(+), 73 deletions(-)


--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
diff -Naur systemd-19.orig/src/cgroup-util.c systemd-19/src/cgroup-util.c
--- systemd-19.orig/src/cgroup-util.c   2011-02-21 13:40:01.0 +0100
+++ systemd-19/src/cgroup-util.c2011-03-03 16:27:25.0 +0100
@@ -133,7 +133,18 @@
 while ((de = readdir(d))) {
 char *b;
 
-if (de-d_type != DT_DIR)
+if (de-d_type == DT_UNKNOWN) {
+struct stat st;
+
+if (fstatat(dirfd(d), de-d_name, st, 
AT_SYMLINK_NOFOLLOW)  0) {
+r = -errno;
+goto finish;
+}
+is_dir = S_ISDIR(st.st_mode);
+} else
+is_dir = de-d_type == DT_DIR;
+
+if (!is_dir)
 continue;
 
 if (streq(de-d_name, .) ||
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] add extra check for DT_UNKNOWN files in directory scan

[Marius Tolzmann]

oops.. sorry.. wrong patch sent...

this won't compile.. but since lennart also fixed it it seems to be 
obsolete anyway... 8)



m.


On 03/03/11 16:36, Marius Tolzmann wrote:

Hello..

this looks fine.. and is better than just adding DT_UNKOWN 8)

i additionally patched the cgroup-util.c (see attachment)

thx for the patch..

m.


On 03/03/11 16:27, Andrey Borzenkov wrote:

Some file systems (at least, reiserfs) return DT_UNKNOWN for
every directory entry in readdir(). So far in several places
systemd filtered on DT_REG/DT_LNK and so skipped any file on
such filesystems. It affected systemd-update-utmp, systemd-modules-load
and systemd-tty-ask-password-agent.

This patch adds additional stat() check for file type for DT_UNKNOWN
case. Additionally, it adds check that DT_LNK really points to
regular file.

The patch fixes misterious runlevel entry in utmp discussed in
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001433.html


Reported-By: tolzm...@molgen.mpg.de
Signed-off-by: Andrey Borzenkovarvidj...@gmail.com

---
src/modules-load.c | 137 +++---
src/tmpfiles.c | 22 ---
src/tty-ask-password-agent.c | 8 ++-
3 files changed, 94 insertions(+), 73 deletions(-)




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



--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to handle filesystems that do not support d_type in readdirs dirent?

[Marius Tolzmann]

hi

On 03/03/11 16:30, Lennart Poettering wrote:

On Thu, 03.03.11 13:05, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote:



hello..

we are currently using reiserfs on our root-partition..


Urks, people still use that cruft?


at least we do..


.. how is this supposed to be handled? if the type of a symlinks
destination isn't checked the whole check could be skipped at all?


The check is a good if we can do it cheaply, but if we cannot it should
be acceptable in all these case if we don't do it.

Please check current git (in particular 1a6f4df) if it covers all issues
you raised.


i will check this ASAP...

thx for your support..


marius..

--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Assertion failed in systemd v16

[Marius Tolzmann]

hi..

On 01/18/11 13:30, Alexander E. Patrakov wrote:



As you noticed, this changes the PID, and systemd currently cannot
handle this.

We could however reload the PID file after a reload completed I
guess. (/me adds this to the todo list)


Well, there are cases (live update of nginx, see
http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly)
where the main PID would change without the explicit systemctl reload
command. In the case of nginx, one can follow up the live update with a
dummy systemctl reload, so I am not sure if it matters.

OTOH, maybe it would be better to evaluate the main PID lazily when it
is needed, instead of trying to enumerate all places where it can change
and reloading it there. But this way we will also hide all races caused
by bad PID file handling logic, so I am not sure.



we too use software where the MAINPID changes over time due to 
automatic/on-the-fly reloading of the main binary..


that is how the on-the-fly logic is implemented:
when the modification of the binary is detected
 - the server will spawn a new main process (new MAINPID)
 - when successfully initialized
  - the new process will kill the old one
 - else (on failure) the old process continues until the next
modification is detected

systemd is not notified..

i considered issuing a systemctl reload in the main-process to let 
systemd reload the whole service where ReloadExec would spawn the new 
instance which kills the old one. But the ReloadExec would never return 
and so the state of the service would probably be reloading or 
something and the new MAINPID should be the one of ReloadExec-process..

..this does not seem to work at all..

how is this supposed to be handled in systemd??

m.

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

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

[Marius Tolzmann]

hi again..

On 01/11/11 11:51, Alexander E. Patrakov wrote:

After more research, I found the under-documented lighttpd-angel
program. It does what is needed for babysitting lighttpd: performs the
send SIGINT to the old copy and immediately start the new one dance
when it receives SIGHUP. See
http://blog.lighttpd.net/articles/2007/09/02/there-is-an-angel-for-lighty .
So here is a working unit file for lighttpd, with graceful reloading:


i found this too but thought is was only intended to be included in 
versions 1.5+ of lighttpd.. after compiling and installing the latest 
lighttpd to test the systemd unit i was happy that the angel is 
already shipped in the 1.4.x series.. 8)



If you also want graceful stop, you may want to add:

ExecStop=/bin/kill -INT $MAINPID

but this doesn't work, as lighttpd gets killed immediately. I don't know
why this happens.


have you tried KillMode=process here?


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


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?


bye.. marius..

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

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

[Marius Tolzmann]

hi..

On 01/11/11 16:11, Alexander E. Patrakov wrote:


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.


sorry my fault 8).. i thought it was silently failing and you have to 
check syslog for errors..



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?


Mirkos ExecConfigTest= idea seems to solve this issue perfectly.. what i 
really like: now the configtest-procedure only has to be defined once.. 
and so your unit file will be more readable compared to the very first 
version..


thanks for the unit file.. i will use it soon 8)

cheers, marius..

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

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

[Marius Tolzmann]

hi..


[Unit]
Description=Lighttpd Web Server
After=network.target

[Service]
Type=forking
EnvironmentFile=/etc/conf.d/lighttpd
PIDFile=/var/run/lighttpd.pid
ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf
ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
ExecStop=/bin/kill -INT $MAINPID
ExecReload=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf
ExecReload=/bin/kill -INT $MAINPID
ExecReload=/bin/sleep 1
ExecReload=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
StandardOutput=syslog
StandardError=syslog


i still try to get behind all the systemd magic so i have some questions 
on this unit:


can the initial problem of restarting the lighttpd gracefully be solved 
by something like this?:


[Unit]
..
ConditionPathExists=/etc/lighttpd/lighttpd.conf

[Service]
ExecStartPre=/usr/sbin/lighttpd -t ...
ExecStart=/usr/sbin/lighttpd ...
ExecStop=/bin/kill -INT $MAINPID
ExecReload=/usr/sbin/lighttpd -t ...
ExecReload=/bin/kill -INT $MAINPID
StandardOutput=syslog
Restart=on-success ( or on-abort or always .. don't know what the
 exit-status after graceful kill is in lighty)

and why do you explicitly not use the -D option and let systemd do all 
the forking stuff for you..? you could get rid off the Type= PIDFile= 
lines.. i also removed StandardError=syslog which seems to be redundant 
here..


would this work? or isn't restart intended to be used for those kind of 
things?


SignalStop=SIGINT and SignalReload=SIGINT or something similar may be a 
nice shortcut for doing those kind of things.. Since SignalReload=SIGHUP 
seems to be a way how it is done most of the time?


Another question: Doesn't the default KillMode=control-group would send 
a SIGTERM to the remaining processes of this service immediately after 
the ExecStop= returns and so break the idea behind a graceful shutdown 
where the main-process exits and all running http-requests will be 
finished? (Or is there also a delay of TimeoutSec= between ExecStop= and 
the first SIGTERM?)


..everything is still spinning in my head 8)

marius..


--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)


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

Re: [systemd-devel] syslog.socket vs. syslog.service

[Marius Tolzmann]

hi..


how is this supposed to be configured correctly.. since i think i need
the systemd-kmsg-syslog as long as my syslog.service ist not running
and able to write its logfiles to the filesystem.. ??



If I understood correctly the kmsg-syslog thing just gets all the
messages from kmsg and puts them into the syslog socket /dev/log but not
sure about that.


as far as i understood it read from /dev/log and writes to /dev/kmsg 
since kernellog buffer are large enough to take some more messages..

thats why you get the early boot messages in dmesg.. or isn't it??

since you mentioned that the created socket would buffer all messages 
even if systemd-kmsg-syslog.service is not activated it should be 
possible to link systemd-kmsg-syslog.service to /dev/null and just let a 
late syslog-daemon read from this socket.. ?


i am a bit scared of doing it that way, because everything would 
possibly hang if the kernelbuffer for this socket would be filled up..(?)



but how do i get rid of this socket activated /dev/log handling and
replace it with my syslog.service completely?

Actually I think its not socket activated. It's just that the socket is
created before starting the actual daemon. (socket activation would mean
that the deamon is only started on traffic through that socket). In our
case syslog.service is always started if multi-user.target is started.



thanks @all for the links to all the systemd unit repositories..
- why is it that all *syslog*.service files are WantedBy
multi-user.target and not let's say WantedBy basic.target?



Well all the messages are cached in the socket. So no harm in starting
it late!


but then there is no syslog support (which logs to real files) in other 
targets like rescue.target or whatever.target which don't install the 
multi-user.target.. ?  i would prefer to have syslog support in every 
runlevel / target i boot into.. just for the files and to know what 
happened when i tried to fix some stuff and messed it up completly..8)

(i currently configured it to be wantedby basic.target)


cheers, marius..


--
Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de
--.--
MPI f. molekulare Genetik |
Ihnestrasse 63-73, D-14195 Berlin |   == MarIuX GNU/Linux ==
Phone: +49 (0)30 8413 1709|
--^--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die. by calvin from calvinhobbes ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel