Re: [systemd-devel] How to set complex environment for apache?
Am 24.05.2012 01:56, schrieb Lennart Poettering: > On Wed, 23.05.12 16:45, Joachim Banzhaf (joachim.banz...@googlemail.com) > wrote: > >> Am 22.05.2012 22:51, schrieb Zbigniew Jędrzejewski-Szmek: >>> On 05/22/2012 10:46 PM, Joachim Banzhaf wrote: >>>> It sets and modifies environment variables. I'll have a look and try, >>> See also Environment= and EnvironmentFile= in systemd.exec(5). >>> >>> Zbyszek >> >> I tried now. Not sure if the result is optimal, but it might still help >> others with a similar problem. >> >> The DB2 provided profile script (for now) only sets and changes >> environment variables (PATH, LD_LIBRARY_PATH, CLASSPATH, DB2INSTANCE), >> with some if/else logic based on what product options are installed or not. >> >> I cannot use the script as is in ExecStartPre because this only allows >> binaries. >> I even tried /bin/bash script, but as expected the changed environment >> is not inherited by ExecStart >> >> So the only systemd options (I know of now) left are Environment and >> EnvironmentFile. >> I went with EnvironmentFile, because that is what I used before. I just >> added the variables by hand instead of by sourcing the db2profile >> script. This worked (I had to export the variables to make it backward >> compatible with SysV init though). >> >> If I'd use this approach with systemd and DB2 I'd have to manually >> analyze changes in the db2profile and try to mimic that with every >> fixpack or special build delivered by IBM. Too error prone, not acceptable. >> >> Finally I tried this, and it worked. But I am not sure about side effects: >> >> I changed >>ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start' >> to >>ExecStart=/bin/bash -c '. /home/db2inst1/sqllib/db2profile; >> /usr/sbin/start_apache2 -D SYSTEMD -k start' >> >> Thanks for you support! > > This solution is pretty much what I'd recommend too. Would adding an "exec" allow to get rid of the bash? Will this have any advantages? ExecStart=/bin/bash -c '. /home/db2inst1/sqllib/db2profile; exec /usr/sbin/start_apache2 -D SYSTEMD -k start' For some cases it would be nice if you could run an command to set complex environments. Something like: EnvironmentExec=/home/db2inst1/sqllib/db2profile But instead of just reading the file, it's executed and the environment variables are taken. Another idea I had was to have the possibility to set single variables which can be used in the Exec command by executing external commands. But I think this would made systemd too complex... Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cgls - Memory overflow
Am 10.05.2012 14:45, schrieb Sven Anders: > Hello! > > I'm experiencing a problem with systemd-cgls while testing systemd. > > I run systemd for tests on a small KVM VM with ~700MB RAM and no swap. > > If I execute the "systemd-cgls" command, I see the tree but without > the command lines of the executables. I only see "n/a". > > Example: > > └ system > ├ 1 n/a > ├ sshd.service > │ ├ 608 n/a > │ ├ 639 n/a > │ ├ 641 n/a > │ ├ 671 n/a > │ └ 672 n/a > [...] Hello! I trace the problem down to a possible compiler problem. I'm using gcc 4.5.1. If I compile the tool with make V=1 CFLAGS="-O3 -g -march=pentium3" I'll have the problems. If I'm using "-O2" or "-march=pentium2" instead, it will work. Does anybody have the gcc 4.5.1 to confirm this and also is able to try this on a newer gcc version? If this problem does exist on newer gcc too, I will try to find the cause of this. If it's gone on newer gcc, I think I have to use a newer compiler... Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cgls - Memory overflow
Am 10.05.2012 22:33, schrieb Michal Schmidt:
> On 05/10/2012 02:45 PM, Sven Anders wrote:
>> If I execute the "systemd-cgls" command, I see the tree but without
>> the command lines of the executables. I only see "n/a".
>
>> open("/proc/300/cmdline", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 7
>> mmap2(NULL, 1075859456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>> 0) = -1 ENOMEM (Cann
>> ot allocate memory)
>
> Do you have the COLUMNS environment variable set to some interesting value?
> Does it work if you set it to something sane?:
> COLUMNS=80 systemd-cgls
COLUMNS is set to 80, so that's not the problem.
What I find curious is, that it reads the correct command line and then opens
the
/proc file again, but this time it fails. What happened to the first read?
I checked the code, but could not see any reason for this on the first look.
I did not see any mmap in the code causing this nor any reason, why this should
be
triggered by any libc function...
Regards
Sven Anders
--
Sven Anders () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
<>___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-cgls - Memory overflow
Hello!
I'm experiencing a problem with systemd-cgls while testing systemd.
I run systemd for tests on a small KVM VM with ~700MB RAM and no swap.
If I execute the "systemd-cgls" command, I see the tree but without
the command lines of the executables. I only see "n/a".
Example:
└ system
├ 1 n/a
├ sshd.service
│ ├ 608 n/a
│ ├ 639 n/a
│ ├ 641 n/a
│ ├ 671 n/a
│ └ 672 n/a
├ getty@.service
│ ├ tty1
│ │ ├ 302 n/a
│ │ └ 610 n/a
│ └ tty2
│ └ 301 n/a
├ webredirect.service
│ └ 300 n/a
├ confgui.service
│ └ 299 n/a
├ dbus.service
│ └ 340 n/a
├ systemd-logind.service
│ └ 294 n/a
├ systemd-journald.service
│ └ 174 n/a
└ udev.service
├ 171 n/a
├ 348 n/a
└ 349 n/a
I investigated this further with strace and get the following errors:
[...]
access("/sys/fs/cgroup/systemd/system/webredirect.service", F_OK) = 0
open("/sys/fs/cgroup/systemd/system/webredirect.service/cgroup.procs",
O_RDONLY|O_LARGEFILE|O_CLO
EXEC) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40047000
read(6, "300\n", 4096) = 4
open("/proc/300/cmdline", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 7
fstat64(7, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40048000
read(7, "/usr/sbin/webredirect\0-f\0", 1024) = 25
close(7)= 0
munmap(0x40048000, 4096)= 0
read(6, "", 4096) = 0
open("/proc/300/cmdline", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 7
mmap2(NULL, 1075859456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cann
ot allocate memory)
mmap2(NULL, 1075859456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cann
ot allocate memory)
brk(0x81ff6000) = 0x41de2000
mmap2(NULL, 1075990528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cann
ot allocate memory)
close(7)
[...]
The command line is read successfully, but it's opened a second time and this
time the
tool tries to memory map 1.075.859.456 bytes. Why? I think it will work, if I
add swap space
or provide more RAM. But the tool should work with small RAM too...
Regards
Sven Anders
--
Sven Anders () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
<>___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SegFaults?!
Am 04.05.2012 12:28, schrieb Sven Anders: > Am 03.05.2012 21:12, schrieb Sven Anders: >> Am 03.05.2012 18:33, schrieb Lennart Poettering: >>> On Thu, 03.05.12 18:14, Sven Anders (and...@anduras.de) wrote: >>> >>>> I'm getting some SegFaults, which I can not explain. I think the problem >>>> lies somewhere in my configuration or systemd makes some assumptions and >>>> my system does not fulfill these requirements. >>>> Nevertheless, I think the tools should not SegFault but issue an error >>>> instead. By now I have no real idea where the problem lies. >>>> If I run the tool in valgrind, they work. >>> >>> Hmm, I don't see how a system call would result in a SIGSEGV. This is >>> really weird... >>> >>> The fd[] array passed to pipe() is allocated on the stack. This suggests >>> that your stack is getting corrupted somehow. >>> >>> Do things work correctly if you run stuff with --no-pager? >> >> Curiously not. Only if I run this in valgrind... >> >> I had another strange SegFault when using systemd-journalctl, but this >> is now gone... So I suspected a misconfiguration first... >> >> This is the same compilation and other tools and systemd itself are >> running fine. I'm trying this in KVM with Linux kernel 3.2.2. > > This only sees to happen, if I link the binaries with -pie . Have no idea > what is causing this yet. Will investigating this further... Ok, just for reference. I track the problem down. My problem was, that the libraries were compiled without the PIE flags and the executable were linked with -pie. I corrected this and it works now without any problems... Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SegFaults?!
Am 03.05.2012 21:12, schrieb Sven Anders: > Am 03.05.2012 18:33, schrieb Lennart Poettering: >> On Thu, 03.05.12 18:14, Sven Anders (and...@anduras.de) wrote: >> >>> I'm getting some SegFaults, which I can not explain. I think the problem >>> lies somewhere in my configuration or systemd makes some assumptions and >>> my system does not fulfill these requirements. >>> >>> Nevertheless, I think the tools should not SegFault but issue an error >>> instead. By now I have no real idea where the problem lies. >>> If I run the tool in valgrind, they work. >> >> Hmm, I don't see how a system call would result in a SIGSEGV. This is >> really weird... >> >> The fd[] array passed to pipe() is allocated on the stack. This suggests >> that your stack is getting corrupted somehow. >> >> Do things work correctly if you run stuff with --no-pager? > > Curiously not. Only if I run this in valgrind... > > I had another strange SegFault when using systemd-journalctl, but this > is now gone... So I suspected a misconfiguration first... > > This is the same compilation and other tools and systemd itself are > running fine. I'm trying this in KVM with Linux kernel 3.2.2. This only sees to happen, if I link the binaries with -pie . Have no idea what is causing this yet. Will investigating this further... Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SegFaults?!
Am 03.05.2012 18:33, schrieb Lennart Poettering:
> On Thu, 03.05.12 18:14, Sven Anders (and...@anduras.de) wrote:
>
>> Hello!
>>
>> I'm getting some SegFaults, which I can not explain. I think the problem
>> lies somewhere in my configuration or systemd makes some assumptions and
>> my system does not fulfill these requirements.
>>
>> Nevertheless, I think the tools should not SegFault but issue an error
>> instead. By now I have no real idea where the problem lies.
>>
>> If I run the tool in valgrind, they work.
>>
>> Do you have any idea?
>
> Hmm, I don't see how a system call would result in a SIGSEGV. This is
> really weird...
>
> The fd[] array passed to pipe() is allocated on the stack. This suggests
> that your stack is getting corrupted somehow.
>
> Do things work correctly if you run stuff with --no-pager?
Curiously not. Only if I run this in valgrind...
I had another strange SegFault when using systemd-journalctl, but this
is now gone... So I suspected a misconfiguration first...
This is the same compilation and other tools and systemd itself are
running fine. I'm trying this in KVM with Linux kernel 3.2.2.
(gdb) run
Starting program: /usr/bin/systemd-cgls --no-pager
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00a2 in ?? ()
(gdb) bt
#0 0x00a2 in ?? ()
#1 0x40126a86 in access () at ../sysdeps/unix/syscall-template.S:82
#2 0x80004107 in cg_fix_path (path=0x8000c040 "/sys/fs/cgroup/systemd",
result=0xb960) at src/cgroup-util.c:1065
#3 0x800034cf in show_cgroup_by_path (path=0x8000c040
"/sys/fs/cgroup/systemd", prefix=0x80008784 "", n_columns=162,
kernel_threads=false)
at src/cgroup-show.c:176
#4 0x800037b6 in show_cgroup (controller=0x80007f5e "name=systemd",
path=0x80008712 "/", prefix=0x0, n_columns=0, kernel_threads=false) at
src/cgroup-show.c:257
#5 0x80002fbc in main (argc=2, argv=0xbae4) at src/cgls.c:148
(gdb) up
#1 0x40126a86 in access () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
in ../sysdeps/unix/syscall-template.S
(gdb) up
#2 0x80004107 in cg_fix_path (path=0x8000c040 "/sys/fs/cgroup/systemd",
result=0xb960) at src/cgroup-util.c:1065
1065access(path, F_OK) >= 0) {
These are the last lines of a strace:
[...]
830 stat64(".", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
830 stat64("/var/tmp/systemd-44", {st_mode=S_IFDIR|0775, st_size=4096, ...})
= 0
830 open("/proc/1/cgroup", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
830 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
830 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x4002d000
830 read(3, "5:freezer:/\n4:devices:/\n3:cpuacc"..., 1024) = 74
830 close(3) = 0
830 munmap(0x4002d000, 4096) = 0
830 lstat64("/sys/fs/cgroup", {st_mode=S_IFDIR|0755, st_size=180, ...}) = 0
830 lstat64("/sys/fs", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
830 ioctl(1, TIOCGWINSZ, {ws_row=35, ws_col=162, ws_xpixel=0, ws_ypixel=0}) = 0
830 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
830 +++ killed by SIGSEGV (core dumped) +++
Really strange!
Regards
Sven Anders
--
Sven Anders () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
<>___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SegFaults?!
/unix/syscall-template.S
(gdb) up
#2 0x8000cea0 in pager_open () at src/pager.c:66
66 if (pipe(fd) < 0) {
(gdb) print fd
$1 = {22, 0}
(gdb) up
#3 0x8000a22e in pager_open_if_enabled (bus=0x80018710, args=0xbae8, n=0)
at src/login/loginctl.c:72
72 pager_open();
My processes:
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.5 9204 4520 ?Ss 14:19 0:00 /sbin/init
root 2 0.0 0.0 0 0 ?S14:19 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ?S14:19 0:00 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ?S14:19 0:12 [kworker/0:0]
root 5 0.0 0.0 0 0 ?S14:19 0:00 [kworker/u:0]
root 6 0.0 0.0 0 0 ?S14:19 0:00 [migration/0]
root 7 0.0 0.0 0 0 ?S< 14:19 0:00 [cpuset]
root 8 0.0 0.0 0 0 ?S< 14:19 0:00 [khelper]
root 9 0.0 0.0 0 0 ?S14:19 0:00 [kdevtmpfs]
root10 0.0 0.0 0 0 ?S14:19 0:00 [sync_supers]
root11 0.0 0.0 0 0 ?S14:19 0:00 [bdi-default]
root12 0.0 0.0 0 0 ?S< 14:19 0:00 [kintegrityd]
root13 0.0 0.0 0 0 ?S< 14:19 0:00 [kblockd]
root14 0.0 0.0 0 0 ?S< 14:19 0:00 [ata_sff]
root15 0.0 0.0 0 0 ?S14:19 0:00 [khubd]
root16 0.0 0.0 0 0 ?S< 14:19 0:00 [md]
root19 0.0 0.0 0 0 ?S14:19 0:00 [kswapd0]
root20 0.0 0.0 0 0 ?S14:19 0:00 [fsnotify_mark]
root21 0.0 0.0 0 0 ?S< 14:19 0:00 [crypto]
root26 0.0 0.0 0 0 ?S14:19 0:00 [scsi_eh_0]
root27 0.0 0.0 0 0 ?S14:19 0:00 [scsi_eh_1]
root30 0.0 0.0 0 0 ?S< 14:19 0:00 [kpsmoused]
root31 0.0 0.0 0 0 ?S14:19 0:00 [kworker/0:2]
root32 0.0 0.0 0 0 ?S14:19 0:00 [kworker/u:3]
root79 0.0 0.0 0 0 ?S14:19 0:00 [kjournald]
root 126 0.0 0.0 0 0 ?S14:19 0:00 [kjournald]
root 127 0.0 0.0 0 0 ?S< 14:19 0:00 [loop0]
root 131 0.0 0.0 0 0 ?S< 14:19 0:00 [loop1]
root 134 0.0 0.0 0 0 ?S< 14:19 0:00 [loop2]
root 159 0.0 0.2 3264 1800 ?Ss 14:19 0:00 /lib/udev/udevd
root 164 0.0 0.4 10612 3248 ?Ss 14:19 0:01
/lib/systemd/systemd-journald
root 165 0.0 0.0 0 0 ?S14:19 0:00 [kauditd]
4 222 0.0 0.2 6652 2124 ?Ss 14:19 0:00
/usr/bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation
root 285 0.0 0.0 3180 668 ?S14:19 0:00 /lib/udev/udevd
root 286 0.0 0.0 3180 668 ?S14:19 0:00 /lib/udev/udevd
root 290 0.0 0.2 6716 2132 tty1 Ss 14:19 0:00 /bin/login --
root 291 0.0 0.0 4000 708 tty2 Ss+ 14:19 0:00 /sbin/agetty
tty2 38400
root 294 0.0 0.0 0 0 ?S14:19 0:00 [vballoon]
root 299 0.0 0.2 5640 2180 tty1 S+ 14:20 0:00 -bash
root 335 0.0 0.3 6076 2412 ?Ss 14:25 0:00 /usr/sbin/sshd
-D
root 370 0.0 0.3 8636 2580 ?Rs 14:26 0:01 sshd:
root@pts/0
root 372 0.0 0.3 5764 2368 pts/0Ss 14:26 0:01 -bash
root 673 0.0 0.0 0 0 ?S17:58 0:00 [flush-8:0]
root 744 0.0 0.1 3436 888 pts/0R+ 18:10 0:00 ps axuw
--
Sven Anders () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
<>___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Act on exit code differently?
Am 21.04.2012 13:47, schrieb Lennart Poettering: > On Wed, 18.04.12 13:54, Sven Anders (and...@anduras.de) wrote: > >> Hello! >> >> Is it possible to act differently on exit codes? > > No. This is currently not possible. > >> The service may terminate fatal or temporarily. >> >> If the termination is temporarily (exit codes 0|12|13|14|15|16|17) I want the >> service to be respawned. On Exit codes 1|6|8|10|11|18|19 it should respawn, >> but >> with a longer sleep. >> Otherwise on the fatal case (exit codes 5|2|3|4|7|9) it should not try to >> respawn >> the service. > > This is a relatively complex restart logic. It probably is a better idea > to implement that as child process of systemd. Hm, ok. It's just the "pppd" daemon I want to handle by systemd. I will check the alternatives. Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Typo
Hello! I just want to report a small typo in file "src/install.c" (it's "src/shared/install.c" in the current tree): Line 1938: [UNIT_FILE_ENABLED_RUNTIME] = "enabled-runtie", Should be "enable-runtime", Regards Sven -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Act on exit code differently?
Hello! Is it possible to act differently on exit codes? The service may terminate fatal or temporarily. If the termination is temporarily (exit codes 0|12|13|14|15|16|17) I want the service to be respawned. On Exit codes 1|6|8|10|11|18|19 it should respawn, but with a longer sleep. Otherwise on the fatal case (exit codes 5|2|3|4|7|9) it should not try to respawn the service. Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Am 26.03.2012 19:37, schrieb Lennart Poettering: > > I mean, allowing configuration of separate values for normal user logins > makes sense. For system services not so much. But with these settings > you'd configure the latter, not the former, hence I have trouble seeing > the usefulness of allowing two values to be configured. > > pam_limits is usually used to apply resource limits to normal logins. Just me 2¢: It would only make sense to set a default limit for the user processes, if the system do not use any other mechanism (like pam) to set it. Maybe useful for embedded systems, where pam isn't installed? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logind.service failed
Am 26.03.2012 00:06, schrieb Kay Sievers: > On Sun, Mar 25, 2012 at 22:02, Sven Anders wrote: >> I'm trying to switch to systemd, but I have some minor problem. >> >> "systemctl status systemd-logind.service" reports failure. >> The error message is the following: >> >> Linux/OS (d-login)[206]: Failed at step CAPABILITIES... >> >> I made a strace on systemd and it seems, that the following >> call fails: >> prctl(0x18 /* PR_??? */, 0x24, 0, 0xbff824c0, 0x3) = -1 EINVAL (Invalid >> argument) >> >> I looked at the code and in execute.c I found a loop >> for (i = 0; i <= cap_last_cap(); i++) >> >> cap_last_cap() uses the CAP_LAST_CAP define. Fine, this is set to 35 (0x23) >> >> If I do a "cat /proc/sys/kernel/cap_last_cap" it returns 35 (ok, the same...) >> >> So, why is the program trying to set 0x24? >> >> (I'm tested this on the kernel version 3.2.2) >> >> Maybe anyone has an idea? > > You compiled systemd with the same kernel version as you run it and > see the failure? > > Kay Yes! And this is what makes me curious... But I will recheck this to be absolutely sure. Is it possible, that the cap_last_cap value is reduced during runtime? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-logind.service failed
Hello! I'm trying to switch to systemd, but I have some minor problem. "systemctl status systemd-logind.service" reports failure. The error message is the following: Linux/OS (d-login)[206]: Failed at step CAPABILITIES... I made a strace on systemd and it seems, that the following call fails: prctl(0x18 /* PR_??? */, 0x24, 0, 0xbff824c0, 0x3) = -1 EINVAL (Invalid argument) I looked at the code and in execute.c I found a loop for (i = 0; i <= cap_last_cap(); i++) cap_last_cap() uses the CAP_LAST_CAP define. Fine, this is set to 35 (0x23) If I do a "cat /proc/sys/kernel/cap_last_cap" it returns 35 (ok, the same...) So, why is the program trying to set 0x24? (I'm tested this on the kernel version 3.2.2) Maybe anyone has an idea? Regards Sven Anders -- Sven Anders () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
