Re: [systemd-devel] [opensuse-factory] [RFC] sysvinit: plan B
Le dimanche 23 septembre 2012 à 06:23 +0200, Jan Engelhardt a écrit : On Friday 2012-09-07 15:43, Michal Vyskocil wrote [http://lists.opensuse.org/opensuse-factory/2012-09/msg00396.html]: Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init It would seem more advantageous to change the systemd package, and provide an extra binary there that reuses the parser code to give users the possibility to start/stop/restart programs using unit files in a non-systemd environment. . First, I don't see the point of doing a separate package at all for sysvinit compatibility. Second, if people want to use .service, they should use systemd. I don't want us to spend time in doing some strange backport from one new technology to another one when plan to drop. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't get systemd-cryptsetup to automount my /home
On Sun, 23.09.12 13:33, Dennis Ek (dennis.a...@gmail.com) wrote: First of all: I'm running the latest Arch Linux (complete with the latest systemd and everything else) and I've encrypted both my / and /home. Now, the problem is that I can't get my /home to automount once I've mounted my /. My /etc/crypttab looks like this: home /dev/sda3 /etc/homepwd I've created /etc/homepwd using echo password /etc/homepwd And yes, I've entered the correct password. When I boot I get dropped to a rescue shell because I can't mount /home. Here's my journalctl output: systemd-cryptsetup[293]: Invalid passphrase. systemd-cryptsetup[293]: Set cipher aes, mode xts-plain, key size 512 bits for device /dev/sda3. systemd-cryptsetup[293]: Invalid passphrase. systemd-cryptsetup[293]: Too many attempts. I've tried playing with the permissions (even did a chmod 777), but I still can't get systemd-cryptsetup to realize that the file contains the correct password. So, what to do? This is LUKS, right? It does work with cryptsetup luksOpen? Have you tried entering the password on the kbd, rather than via a file? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] src/journal/test-mmap-cache.c is missing
On Sat, 22.09.12 11:04, Khem Raj (raj.k...@gmail.com) wrote: Hi Lennert Commit f801968466fed39d50d410b30ac828c26722cc95 added mmap_cache test to Makefile.am but the C file is missing. Sorry, corrected. I do wonder how this slipped through both make distcheck and Koji, though... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 191
On Fri, 21.09.12 19:24, Dave Reisner (d...@falconindy.com) wrote: On Sat, Sep 22, 2012 at 12:41:49AM +0200, Lennart Poettering wrote: Heya, http://www.freedesktop.org/software/systemd/systemd-191.tar.xz This is primarily a bugfix release. This does not build from git: make[2]: *** No rule to make target `src/journal/test-mmap-cache.c', needed by `src/journal/test-mmap-cache.o'. Stop. make[2]: *** Waiting for unfinished jobs Did you forget to commit a file? Yes, I did. Sorry for that. Fixed now. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Prevent cryptsetup from logging plain-text passphrases from /etc/crypttab
On Sat, 22.09.12 00:47, Karel Tuma (karel.t...@gmail.com) wrote: Just got bitten by this one. Instead, just warn the user legacy syntax is no longer supported. Hmm, honestly, I think we should make this work. I don't see why a split out password file should be any more/less secure than crypttab itself, if both have the same minimal access modes. So, instead of generating an error message here I really would like to just make this work again. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-journald.service failed to start with systemd v189
Hi, Sometimes (around 1% of the time) my system doesn't start correctly. the init process takes 100% CPU. systemd-journal.service is not started correctly, and systemd tries to restart it in a loop. The log is here : http://pastebin.ca/2207127 From my understanding, the problem begins with [ 12.169769] systemd[1]: Child 138 died (code=exited, status=1/FAILURE) [ 12.169799] systemd[1]: Child 138 belongs to systemd-journald.service [ 12.169830] systemd[1]: systemd-journald.service: main process exited, code=exited, status=1 I would like to activate journald logs to see if there is debug output for this error. But i have no idea how to activate journal logs. I'm running angstrom and systemd v189 with a linux kernel v3.2.19 on arm cortex a8 CPU. Maybe somebody will have an idea ? -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Sun, 23.09.12 18:20, Ali Lown (a...@lown.me.uk) wrote: I responded too early, mdadm has caused its own set of problems: - During the boot process, the mdXpX.device don't get marked as active automatically causing X.mount based on those devices to fail. Once I get to the emergency shell, simply calling 'systemctl daemon-reload' reloads the mdXpX.device items which are now marked as active (why?). Hmm, might be related to 44b5651f19b60a84dbfdbb0ea13196b784080c8b? Are you running a version with this, or without? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Mon, Sep 24, 2012 at 11:54:17AM +0200, Lennart Poettering wrote: On Sun, 23.09.12 18:20, Ali Lown (a...@lown.me.uk) wrote: I responded too early, mdadm has caused its own set of problems: - During the boot process, the mdXpX.device don't get marked as active automatically causing X.mount based on those devices to fail. Once I get to the emergency shell, simply calling 'systemctl daemon-reload' reloads the mdXpX.device items which are now marked as active (why?). Hmm, might be related to 44b5651f19b60a84dbfdbb0ea13196b784080c8b? Are you running a version with this, or without? OP said that he tested with f6c2e2 and v189. Both are later. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bug 55213
On Sat, 22.09.12 17:00, Allin Cottrell (cottr...@wfu.edu) wrote: Just wanting to register the hope that this bug... https://bugs.freedesktop.org/show_bug.cgi?id=55213 gets a high priority. I was bitten by it with the systemd 190 release, and I gather it's still outstanding in version 191. Having process 1 segfault is not pleasant... Yes, this bug apparently has bitte a lot of people, I'll make sure it is fixed before 192. let's follow up the discussion on the bug report. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way of configuring service
On Sun, 23.09.12 23:04, Dan Tihelka (dtihe...@gmail.com) wrote:
Dear all,
I porting the start scripts of cruisecontrol system to the native systemd
service configuration. It goes quiet well, the only trouble I have with the
options configuration.
Since cruisecontrol is written in Java, there are two ways of how to
configure
the daemon (and CC use them both): -D java properties and classic command
line options passed to the main jar.
I want to have the whole service highly configurable, So I have decided to
define Environment= item for each particular option. The result looks like:
Environment=cc.prop.item1=-Dcc.XXX=value1
Environment=cc.prop.item2=-Dcc.XXX=value1
Environment=cc.prop.item3=-Dcc.XXX=value1
Environment=cc.prop.item4=
Environment=cc.prop.item5=
Environment=cc.opt.item1=-opt1 val1
Environment=cc.opt.item2=-opt2 val2
Environment=cc.opt.item3=-opt3 val3
Environment=cc.opt.item4=
Environment=cc.opt.item4=
Environment=cc.install.dir=/usr/shared/cruisecontrol
Hmm, so systemd unit files are not really supposed to the place where
daemon-specific configuration bits are encoded. If a daemon requires
specific configuration my recommendation is always to introduce a proper
configuaration file for it, and not to encode this via env vars or in
the cmdline. Administrators will thank you for it!
I have observed that the env must be used in form ${XXX} when it is the part
of larger string (despite the form ${XXX} having its special
meaning).
Yes, please see the documentation for this in the section about
ExecStart= in systemd.service(5)
2)
The second issue is that (if I understand it right) everything I define by
Environment= will appear in ENV variables of the process started. Is
is true?
Yes, as the name suggests env vars specified in Evironment= actually
do change the environment.
What If I don't want to export those variables to the service? I would guess
that it is the reason why -D properties are used instead of raw ENV
variables (which could simply be used as well)
systemd unit files are not supposed to be a macro engine, or a
programming language. My recommendation would be to fix the daemon to
read a normal configuration file natively and if that's ot possible just
wrap it in a normal shell script, rather then tryig to hammer unit files
into what you need here.
I mean, I do understand your needs, but we deliberately try to keep unit
files simple and devoid of any programming language antics. Because we
already have a pretty good one for these kinds of thigs, if that's what
you need, and that's shell.
I hope this is understandable,
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hang when mounting NFS via systemd
On Sun, 23.09.12 17:21, Bardur Arantsson (s...@scientician.net) wrote: Hi all, (Hopefully this list is appropriate for this -- please let me know if there's a more appropriate one.) I'm having a little trouble with NFS mounts when starting them via systemd, but I'm hoping that I may have missed something obvious. Here's the snippet from /etc/fstab: 192.168.0.1:/srv/vg0p-data /data nfs \ defaults,proto=tcp,nfsvers=4,vers=4,noauto 0 1 (Line split here for readability, it's a single line in the actual file.) When I run # systemctl --version systemd 189 arch +PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT \ +LIBCRYPTSETUP +GCRYPT +ACL +XZ # systemctl start data.mount I get the output A dependency job failed. See system journal for details. after a longish timeout (guessing it's the default 90s). In the journal I get: Sep 23 17:08:45 gwendolyn systemd[1]: Job 192.168.0.1:-srv-vg0p\x2ddata.device/start timed out. Sep 23 17:08:45 gwendolyn systemd[1]: Job data.mount/start failed with result 'dependency'. This indicates a bug i systemd actually. For some reason systemd appears to believe that your NFS share is a device to wait for. I tried to fix this in git with two commits. Please test! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: set seal even for readonly journalfiles
On Sat, 22.09.12 21:45, Mirco Tischler (mt...@gmx.de) wrote: journalctl needs to know wether the file has been sealed to be able to do verification. Thanks, applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald.service failed to start with systemd v189
On Mon, 24.09.12 11:43, Nicolas Aguirre (aguirre.nico...@gmail.com) wrote: Hi, Sometimes (around 1% of the time) my system doesn't start correctly. the init process takes 100% CPU. systemd-journal.service is not started correctly, and systemd tries to restart it in a loop. The log is here : http://pastebin.ca/2207127 From my understanding, the problem begins with [ 12.169769] systemd[1]: Child 138 died (code=exited, status=1/FAILURE) [ 12.169799] systemd[1]: Child 138 belongs to systemd-journald.service [ 12.169830] systemd[1]: systemd-journald.service: main process exited, code=exited, status=1 I would like to activate journald logs to see if there is debug output for this error. But i have no idea how to activate journal logs. I'm running angstrom and systemd v189 with a linux kernel v3.2.19 on arm cortex a8 CPU. Maybe somebody will have an idea ? Hmm, most likely there's something in server_init() in journald.c failing. Normally, if something fails there it should print a message to kmsg about that. But apparently we missued something there... :-( Could you try to add log_notice() messages at various spots in server_init() and check if you can spot where the problem is generated? you should see the messages in kmsg. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cryptsetup on FakeRAID fails with timeout
FW back onto the mailing list: As the devices report ATM (after a manual mounting following systemd failure): /dev/md0: P: /devices/virtual/block/md0 N: md0 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVNAME=/dev/md0 E: DEVPATH=/devices/virtual/block/md0 E: DEVTYPE=disk E: ID_PART_TABLE_TYPE=dos E: MAJOR=9 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=19557 /dev/md0p1: P: /devices/virtual/block/md0/md0p1 N: md0p1 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVNAME=/dev/md0p1 E: DEVPATH=/devices/virtual/block/md0/md0p1 E: DEVTYPE=partition E: ID_PART_ENTRY_DISK=9:0 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1953122304 E: ID_PART_ENTRY_TYPE=0x5 E: ID_PART_TABLE_TYPE=dos E: MAJOR=259 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=2 E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: E: USEC_INITIALIZED=40061 /dev/md0p5 and /dev/md0p6 also report SYSTEMD_READY=0 So, the tag isn't being set correctly? Ali On 24 September 2012 11:11, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.09.12 10:59, Ali Lown (a...@lown.me.uk) wrote: As described in OP, I am running f6c2e28b07a0d24c68f7780fc986ac3619fdcbdb, so I am running with 44b5651f19b60a84dbfdbb0ea13196b784080c8b. I confirmed that the line added in 44b exists in /usr/lib64/udev/rules.d/99-systemd.rules. Hmm, please try to debug this by checking for the systemd tag and the SYSTEMD_READY field for the md device. systemd will pick up block devices only if the tag is set and the field is 1. Use udevadm info /dev/md0 (or suchlike) for this. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: allow Age to be set to 0d
On Fri, 21.09.12 12:36, Tom Gundersen (t...@jklm.no) wrote: On Tue, Sep 11, 2012 at 12:52 AM, Lennart Poettering lenn...@poettering.net wrote: What is the intended behaviour of an age setting of 0? Not sure I understand your question. For all intents and purposes 0s is the same as 1us (or something else sufficiently small). I.e., the file is cleaned up every time systemd-tmpfiles --clean is called. This is probably not something you want during normal operation (though some obviously do). However, it is useful when testing systemd-tmpfiles, and surprising that it does not work. Ah, OK. This makes sense I guess. The reason I was asking is that 0 in contexts like these often has some kind of special meaning, for example turn aging off or so. Could you add a sentence or so to the man page explaining what age of 0 means? Something like Settig age to 0 has the effect of unconditional clean-up on every run of systemd-tmpfiles --cleanup or so. If it wasn't clear to me (even though I must admit your assumption is actually kinda obvious) it probably isn't clear to other people either. Can you update the patch with the man page fix? I'll then merge it. (Oh, BTW, can I interest you in git access? I think it would be cool and could commit this right-away yourself. Please create an fdo ticket: http://www.freedesktop.org/wiki/AccountRequests I'll then OK they and reassign so that you get commit access.) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Mon, 24.09.12 12:22, Ali Lown (a...@lown.me.uk) wrote: FW back onto the mailing list: As the devices report ATM (after a manual mounting following systemd failure): /dev/md0: P: /devices/virtual/block/md0 N: md0 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb E: DEVNAME=/dev/md0 E: DEVPATH=/devices/virtual/block/md0 E: DEVTYPE=disk E: ID_PART_TABLE_TYPE=dos E: MAJOR=9 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=19557 /dev/md0p1: P: /devices/virtual/block/md0/md0p1 N: md0p1 L: 100 S: disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVLINKS=/dev/disk/by-id/md-uuid-ee87365a:bf0826c6:0825cc4b:d1c49ecb-part1 E: DEVNAME=/dev/md0p1 E: DEVPATH=/devices/virtual/block/md0/md0p1 E: DEVTYPE=partition E: ID_PART_ENTRY_DISK=9:0 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1953122304 E: ID_PART_ENTRY_TYPE=0x5 E: ID_PART_TABLE_TYPE=dos E: MAJOR=259 E: MD_DEVICES=2 E: MD_LEVEL=raid1 E: MD_METADATA=0.90 E: MD_UUID=ee87365a:bf0826c6:0825cc4b:d1c49ecb E: MINOR=2 E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: E: USEC_INITIALIZED=40061 /dev/md0p5 and /dev/md0p6 also report SYSTEMD_READY=0 So, the tag isn't being set correctly? The tag is there correctly (i.e. as you ca see in the TAGS= field, which includes systemd for both cases). My edcuated guess is that this is a result of you having a partition table on top of md, which causes the md rules in 99-systemd.rules not have ay effect on the partition block devices. Kay, Harald, could you please have a look into this? The current udev rule probably needs some updating to deal with setups like these. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
On Mon, Sep 24, 2012 at 2:32 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 24.09.12 12:22, Ali Lown (a...@lown.me.uk) wrote: /dev/md0p1: P: /devices/virtual/block/md0/md0p1 E: DEVTYPE=partition E: SUBSYSTEM=block E: SYSTEMD_READY=0 E: TAGS=:systemd: /dev/md0p5 and /dev/md0p6 also report SYSTEMD_READY=0 So, the tag isn't being set correctly? The tag is there correctly (i.e. as you ca see in the TAGS= field, which includes systemd for both cases). My edcuated guess is that this is a result of you having a partition table on top of md, which causes the md rules in 99-systemd.rules not have ay effect on the partition block devices. Not sure, if that's the whole story: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d2fff1ced447c09c6601a6617300467ccd81660b The current rules always marked all MD partitions as inactive, which does not sound right. We are not even sure if the partitions would ever get a change event later. Please try if that makes things better, as said, there might be more needed than that. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald.service failed to start with systemd v189
2012/9/24 Lennart Poettering lenn...@poettering.net: On Mon, 24.09.12 11:43, Nicolas Aguirre (aguirre.nico...@gmail.com) wrote: Hi, Sometimes (around 1% of the time) my system doesn't start correctly. the init process takes 100% CPU. systemd-journal.service is not started correctly, and systemd tries to restart it in a loop. The log is here : http://pastebin.ca/2207127 From my understanding, the problem begins with [ 12.169769] systemd[1]: Child 138 died (code=exited, status=1/FAILURE) [ 12.169799] systemd[1]: Child 138 belongs to systemd-journald.service [ 12.169830] systemd[1]: systemd-journald.service: main process exited, code=exited, status=1 I would like to activate journald logs to see if there is debug output for this error. But i have no idea how to activate journal logs. I'm running angstrom and systemd v189 with a linux kernel v3.2.19 on arm cortex a8 CPU. Maybe somebody will have an idea ? Hmm, most likely there's something in server_init() in journald.c failing. Normally, if something fails there it should print a message to kmsg about that. But apparently we missued something there... :-( Could you try to add log_notice() messages at various spots in server_init() and check if you can spot where the problem is generated? you should see the messages in kmsg. Lennart -- Lennart Poettering - Red Hat, Inc. Ok, I did what you said, and it appears that the problem is located in journald.c, in system_journal_open function, when it tries to read the machine-id, it can't open /etc/machine-id. My RFS is readonly , I use Ubi/Ubifs root filesystem. To fix the problem of machine-id i added a symbolic link : ln -sf /var/volatile/machine-id /etc/machine-id IIRC systemd creates this machine-id file once, but in my case it's created every time i boot because /var/volatile is tmpfs. It seems that this symbolic link is broken when journald service starts, sometimes. To fix my problem, i will create a service which will mount the fs in rw, create the /etc/machine-id and remount fs in ro if the machine-id is not found. It should work in my case because i'm using ubifs, but how to fix such problem in case of squashfs for example ? I don't have found the root cause, btw but it's a good start, thanks for your advises Regards, -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd segfaulting after commit 877d54e9b09e093c2102f519a84e2a52637ae035
On Sunday, September 23, 2012, Allin Cottrell cottr...@wfu.edu wrote: On Sun, 23 Sep 2012, Colin Walters wrote: On Sat, 2012-09-22 at 16:34 -0700, Khem Raj wrote: git bisect tells me that its happening due to commit 877d54e9b09e093c2102f519a84e2a52637ae035 Author: Lennart Poettering lenn...@poettering.net Date: Fri Aug 24 22:21:20 2012 +0200 journal: generate structured journal messages for a number of events I am using gcc 4.7.2 + glibc 2.16 + binutils 2.22 + kernel 3.4.10 I get this too in GNOME-OSTree (fork of Poky edison, gcc 4.6, eglibc 2.13). I had been thinking it was http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47025 [...] I think it's https://bugs.freedesktop.org/show_bug.cgi?id=55213 The reporter explains clearly that the new journald code invokes undefined behavior in relation to vsnprintf() and vasprintf(): it may work on some systems but in general cannot be relied upon to work, and it segfaults on some systems. The reporter also provides a patch. Yes that patch fixes my problem -- Allin Cottrell Department of Economics Wake Forest University, NC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald.service failed to start with systemd v189
On Mon, Sep 24, 2012 at 5:04 PM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: 2012/9/24 Lennart Poettering lenn...@poettering.net: On Mon, 24.09.12 11:43, Nicolas Aguirre (aguirre.nico...@gmail.com) wrote: Sometimes (around 1% of the time) my system doesn't start correctly. the init process takes 100% CPU. systemd-journal.service is not started correctly, and systemd tries to restart it in a loop. The log is here : http://pastebin.ca/2207127 From my understanding, the problem begins with [ 12.169769] systemd[1]: Child 138 died (code=exited, status=1/FAILURE) [ 12.169799] systemd[1]: Child 138 belongs to systemd-journald.service [ 12.169830] systemd[1]: systemd-journald.service: main process exited, code=exited, status=1 I would like to activate journald logs to see if there is debug output for this error. But i have no idea how to activate journal logs. I'm running angstrom and systemd v189 with a linux kernel v3.2.19 on arm cortex a8 CPU. Maybe somebody will have an idea ? Hmm, most likely there's something in server_init() in journald.c failing. Normally, if something fails there it should print a message to kmsg about that. But apparently we missued something there... :-( Could you try to add log_notice() messages at various spots in server_init() and check if you can spot where the problem is generated? you should see the messages in kmsg. Lennart -- Lennart Poettering - Red Hat, Inc. Ok, I did what you said, and it appears that the problem is located in journald.c, in system_journal_open function, when it tries to read the machine-id, it can't open /etc/machine-id. My RFS is readonly , I use Ubi/Ubifs root filesystem. To fix the problem of machine-id i added a symbolic link : ln -sf /var/volatile/machine-id /etc/machine-id IIRC systemd creates this machine-id file once, but in my case it's created every time i boot because /var/volatile is tmpfs. It seems that this symbolic link is broken when journald service starts, sometimes. To fix my problem, i will create a service which will mount the fs in rw, create the /etc/machine-id and remount fs in ro if the machine-id is not found. It should work in my case because i'm using ubifs, but how to fix such problem in case of squashfs for example ? I don't have found the root cause, btw but it's a good start, thanks for your advises We expect a writable /etc or machine-id file. If you don't care about a persistent/stable one, you can make it an empty file and systemd will take care to mount a randomly-created one there. So provide a machine-id in /etc or an empty file, but not a dangling symlink please. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald.service failed to start with systemd v189
On Mon, Sep 24, 2012 at 05:04:11PM +0200, Nicolas Aguirre wrote: 2012/9/24 Lennart Poettering lenn...@poettering.net: Ok, I did what you said, and it appears that the problem is located in journald.c, in system_journal_open function, when it tries to read the machine-id, it can't open /etc/machine-id. My RFS is readonly , I use Ubi/Ubifs root filesystem. To fix the problem of machine-id i added a symbolic link : ln -sf /var/volatile/machine-id /etc/machine-id IIRC systemd creates this machine-id file once, but in my case it's created every time i boot because /var/volatile is tmpfs. It seems that this symbolic link is broken when journald service starts, sometimes. Systemd will attempt to do something similar if it can't read /etc/machine-id. It generates a machine-id in /run and bind-mounts it on top of /etc/machine-id. This fails if the file is missing, since it needs the file to exist as a mount point, but if you put an empty machine-id there then it will generate it correctly. Systemd falls back to a random machine-id as a last resort, it will use the d-bus machine id file or the machine id passed by the virtualization software, so if you set the d-bus machine id, it should also work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: allow Age to be set to 0d
On Mon, Sep 24, 2012 at 12:28 PM, Lennart Poettering lenn...@poettering.net wrote: Ah, OK. This makes sense I guess. The reason I was asking is that 0 in contexts like these often has some kind of special meaning, for example turn aging off or so. Ah, got it. Could you add a sentence or so to the man page explaining what age of 0 means? Something like Settig age to 0 has the effect of unconditional clean-up on every run of systemd-tmpfiles --cleanup or so. If it wasn't clear to me (even though I must admit your assumption is actually kinda obvious) it probably isn't clear to other people either. Makes sense. Will do. BTW, can I interest you in git access? Sure, that would be nice. I opened a ticket here: https://bugs.freedesktop.org/show_bug.cgi?id=55287. I think it would be cool and could commit this right-away yourself. Will do as soon as it is approved. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way of configuring service
On 9/24/12, Lennart Poettering lenn...@poettering.net wrote: On Sun, 23.09.12 23:04, Dan Tihelka (dtihe...@gmail.com) wrote: Dear all, I porting the start scripts of cruisecontrol system to the native systemd service configuration. It goes quiet well, the only trouble I have with the options configuration. Since cruisecontrol is written in Java, there are two ways of how to configure the daemon (and CC use them both): -D java properties and classic command line options passed to the main jar. I want to have the whole service highly configurable, So I have decided to define Environment= item for each particular option. The result looks like: Environment=cc.prop.item1=-Dcc.XXX=value1 Environment=cc.prop.item2=-Dcc.XXX=value1 Environment=cc.prop.item3=-Dcc.XXX=value1 Environment=cc.prop.item4= Environment=cc.prop.item5= Environment=cc.opt.item1=-opt1 val1 Environment=cc.opt.item2=-opt2 val2 Environment=cc.opt.item3=-opt3 val3 Environment=cc.opt.item4= Environment=cc.opt.item4= Environment=cc.install.dir=/usr/shared/cruisecontrol Hmm, so systemd unit files are not really supposed to the place where daemon-specific configuration bits are encoded. If a daemon requires specific configuration my recommendation is always to introduce a proper configuaration file for it, and not to encode this via env vars or in the cmdline. Administrators will thank you for it! OK, thanks. I will try to change cruisecontrol in this way. But still, there are java-specific options which must be set (and may be required to be customized) as well - for example the -Xmx or -Xms settings. And I am most likely not able to change it in java :-) So, how to handle those? Yes, it can (rather simply) be done through shell wrapper, but my intention was to try to avoid it (well, it was motivated by the aim of systemd anyway - to get rid off shell scripts from boot sequence). On the other hand, I understand that you don't want to create a mega-features-everything-capable-shell-replacement ... Anyway, one more ask - I have filled feature request at https://bugs.freedesktop.org/show_bug.cgi?id=55163 Do you think that it is doable or completely useless? Where to look in systemd code to implement this? Thank you, Dan What If I don't want to export those variables to the service? I would guess that it is the reason why -D properties are used instead of raw ENV variables (which could simply be used as well) systemd unit files are not supposed to be a macro engine, or a programming language. My recommendation would be to fix the daemon to read a normal configuration file natively and if that's ot possible just wrap it in a normal shell script, rather then tryig to hammer unit files into what you need here. -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OSTree mount integration
On Sun, 23.09.12 22:26, Colin Walters (walt...@verbum.org) wrote: So I have this boot into chroot system that I wrote for GNOME: https://live.gnome.org/OSTree/ Where the two interesting aspects here are: 1) I want the ability to allow people to try GNOME builds natively without destroying their root partition - hence, chroots. 2) This allows for fully atomic upgrades. Now, basically right now systemd doesn't understand the fact that it's in a chroot, and fails to do things like remount the rootfs read-only when rebooting, etc. https://live.gnome.org/OSTree/MultipleRoots Hmm, why do you use chroot()? I think for these kind of OS booting games chroot() is not really the best way to do things, you actually want proper bind mounts for that. i.e. my suggestion would be to patch dracut (or write a dracut module) that sets up your target OS tree with /var and friends directly, and then transitions directly to it via moving it to / rather than first moving into the host OS tree via a move/bind mount and then using chroot() for the second step. (That said, whether you do this in one or two steps is not important, what is important however is that you do not use chroot()). Is there any opposition to having systemd support this setup? It already detects virtualization and containers at the moment, so it seems like it'd make sense. I'm totally willing to change around the bind mount setup, but I think the most basic support is going to be basically just looking for the root filesystem on /sysroot instead of /. If there's no objections I'll be looking at doing some patches for the GNOME 3.8 cycle. I am not totally against that, but I'd really like to keep explicit virtualization checks at a minimum and use them as solution only if nothing else works nicely. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way of configuring service
The EnvironmentFile= option may be useful for specifying a sort of poor man's configuration file. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald.service failed to start with systemd v189
On Mon, 24.09.12 17:04, Nicolas Aguirre (aguirre.nico...@gmail.com) wrote: To fix my problem, i will create a service which will mount the fs in rw, create the /etc/machine-id and remount fs in ro if the machine-id is not found. It should work in my case because i'm using ubifs, but how to fix such problem in case of squashfs for example ? /etc/machine-id really needs to exist. Either as a valid file or as an empty file we can over-mount with something randomly generated at boot. Also see machine-id(5) for more information about this. We probably should make PID 1 refuse boot-up entirely if the file is not around, so that this is not that difficult to debug and stumble over. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way of configuring service
Hi Dan, Am Montag, 24. September 2012, 21:58:17 schrieb Daniel Tihelka: On 9/24/12, Lennart Poettering lenn...@poettering.net wrote: Hmm, so systemd unit files are not really supposed to the place where daemon-specific configuration bits are encoded. If a daemon requires specific configuration my recommendation is always to introduce a proper configuaration file for it, and not to encode this via env vars or in the cmdline. Administrators will thank you for it! OK, thanks. I will try to change cruisecontrol in this way. But still, there are java-specific options which must be set (and may be required to be customized) as well - for example the -Xmx or -Xms settings. And I am most likely not able to change it in java :-) So, how to handle those? Yes, it can (rather simply) be done through shell wrapper, but my intention was to try to avoid it (well, it was motivated by the aim of systemd anyway - to get rid off shell scripts from boot sequence). On the other hand, I understand that you don't want to create a mega-features-everything-capable-shell-replacement ... True, true...but a shell script doesn't *have* to be as ugly as what comes with some widely used java frameworks and contain like 2k LOC of the most abominable shell code history has seen just to collect what ends up in a bunch of env vars and options to the java binary - of which the location is first determined via large parts of this wrapper... Actually I think it's a bug in the JRE if things can only be configured on the command line and not via a (possibly JAR-specific) config file... anyway, this seems like be one of the few cases where EnvironmentFile= might be the best solution. As opposed to Environment= this makes it very easy for the user to override some settings. You could e.g. run java ... $JAVA_OPTS together with EnvironmentFile=-... (not teh minus) so the file doesn't even have to exist, but iff the user wants/needs to tweak memory options, it's only a matter of adding e.g. JAVA_OPTS=-Xms... -Xmx... to the env file. With Environment=... you require the user to overwrite the whole unit instead. HTH, Malte ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OSTree mount integration
On Mon, 2012-09-24 at 22:19 +0200, Lennart Poettering wrote: i.e. my suggestion would be to patch dracut (or write a dracut module) that sets up your target OS tree with /var and friends directly, and then transitions directly to it via moving it to / rather than first moving into the host OS tree via a move/bind mount and then using chroot() for the second step. (That said, whether you do this in one or two steps is not important, what is important however is that you do not use chroot()). For reference by the way, the current ostree_switch_root code that gets called from dracut is here: http://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-switch-root.c (It's a fork of util-linux switch_root). The issue with your suggestion I think is that the deployment root as I call them (ostree chroots) isn't a mount point, so I can't just MS_MOVE move the whole directory to /. Although I can make it into a mount point I guess with the trick of bind-mounting it to itself, and then move that? Hm. So something something like this, from dracut's perspective, where /sysroot is the target rootfs, and its / is the initramfs: mount(/sysroot/ostree/current/,/sysroot/ostree/current/) move(/dev, /sysroot/ostree/current/dev) move(/proc, /sysroot/ostree/current/proc) move(/sys, /sysroot/ostree/current/sys) bind(/sysroot, /sysroot/ostree/current/sysroot) bind(/sysroot/home, /sysroot/ostree/current/home) bind(/sysroot/ostree/var, /sysroot/ostree/current/var) bind(/sysroot/ostree/current-etc, /sysroot/ostree/current/etc) move(/sysroot/ostree/current/, /) execv(/sbin/init) I may try this and see if it works. But I don't think this will exactly the solve all the problems. In this case / is still a bind mount, not the real backing store. So for example if I have a normal / entry in /etc/fstab, systemd is going to fail to remount it read/write. (Right now, rather hackily, I just remount the backing store r/w in ostree_switch_root, but...) One notable complication with this whole setup is the read-only bind mount over /usr (and /bin, /lib at the moment), which I've elided from the above. I am not totally against that, but I'd really like to keep explicit virtualization checks at a minimum and use them as solution only if nothing else works nicely. Right, definitely agree. But even with the above setup I'm not sure how we can completely avoid it. I should get a chance to try out some patches here within a few weeks. The main thing that needs fixing is /etc/fstab : https://mail.gnome.org/archives/ostree-list/2012-September/msg8.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best way of configuring service
'Twas brillig, and Malte Starostik at 24/09/12 22:52 did gyre and gimble: Hi Dan, Am Montag, 24. September 2012, 21:58:17 schrieb Daniel Tihelka: On 9/24/12, Lennart Poettering lenn...@poettering.net wrote: Hmm, so systemd unit files are not really supposed to the place where daemon-specific configuration bits are encoded. If a daemon requires specific configuration my recommendation is always to introduce a proper configuaration file for it, and not to encode this via env vars or in the cmdline. Administrators will thank you for it! OK, thanks. I will try to change cruisecontrol in this way. But still, there are java-specific options which must be set (and may be required to be customized) as well - for example the -Xmx or -Xms settings. And I am most likely not able to change it in java :-) So, how to handle those? Yes, it can (rather simply) be done through shell wrapper, but my intention was to try to avoid it (well, it was motivated by the aim of systemd anyway - to get rid off shell scripts from boot sequence). On the other hand, I understand that you don't want to create a mega-features-everything-capable-shell-replacement ... True, true...but a shell script doesn't *have* to be as ugly as what comes with some widely used java frameworks and contain like 2k LOC of the most abominable shell code history has seen just to collect what ends up in a bunch of env vars and options to the java binary - of which the location is first determined via large parts of this wrapper... Actually I think it's a bug in the JRE if things can only be configured on the command line and not via a (possibly JAR-specific) config file... anyway, this seems like be one of the few cases where EnvironmentFile= might be the best solution. As opposed to Environment= this makes it very easy for the user to override some settings. You could e.g. run java ... $JAVA_OPTS together with EnvironmentFile=-... (not teh minus) so the file doesn't even have to exist, but iff the user wants/needs to tweak memory options, it's only a matter of adding e.g. JAVA_OPTS=-Xms... -Xmx... to the env file. With Environment=... you require the user to overwrite the whole unit instead. Well, you can use Environment= and EnvironmentFile=- in combination here. Set the default JAVA_OPTS with Environment= (assuming the values really are specific to this service) and then allow the user to optionally override them via the EnvironmentFile all without having to copy/edit the unit itself. I'm not really a java guru, but is it common that some JAVA_OPTS might be valid for multiple, different services? If so, then it would be worth defining a central (i.e. not service specific) EnvironmentFile that is sourced for all java services (e.g. /etc/sysconfig/java) but still allow a service specific env file to override it (e.g. /etc/sysconfig/myservice). In this case you'd just specificy two EnvironmentFile=- lines in the unit. This might or might not make sense as I said, so feel free to come to your own conclusions here. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OSTree mount integration
On Mon, 24.09.12 18:12, Colin Walters (walt...@verbum.org) wrote: On Mon, 2012-09-24 at 22:19 +0200, Lennart Poettering wrote: i.e. my suggestion would be to patch dracut (or write a dracut module) that sets up your target OS tree with /var and friends directly, and then transitions directly to it via moving it to / rather than first moving into the host OS tree via a move/bind mount and then using chroot() for the second step. (That said, whether you do this in one or two steps is not important, what is important however is that you do not use chroot()). For reference by the way, the current ostree_switch_root code that gets called from dracut is here: http://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-switch-root.c (It's a fork of util-linux switch_root). The issue with your suggestion I think is that the deployment root as I call them (ostree chroots) isn't a mount point, so I can't just MS_MOVE move the whole directory to /. Although I can make it into a mount point I guess with the trick of bind-mounting it to itself, and then move that? Instead of moving it you can simply bind mount it to / instead. (But note that bind mounting on itself is not really considered a trick, it's actually a core part of the kernel API). Hm. So something something like this, from dracut's perspective, where /sysroot is the target rootfs, and its / is the initramfs: mount(/sysroot/ostree/current/,/sysroot/ostree/current/) Hmm, so the dir is already a mount point? move(/dev, /sysroot/ostree/current/dev) move(/proc, /sysroot/ostree/current/proc) move(/sys, /sysroot/ostree/current/sys) Note that you need /run here, too. We need the runtime data from the initrd in the host system too. More importatnly though note that systemd will do this bit for you anyway btw, as part of systemctl switch-root. You just need to pass it the right path. (See src/core/switch-root.c which is the code in PID1 that backs systemctl switch-root). bind(/sysroot, /sysroot/ostree/current/sysroot) bind(/sysroot/home, /sysroot/ostree/current/home) bind(/sysroot/ostree/var, /sysroot/ostree/current/var) bind(/sysroot/ostree/current-etc, /sysroot/ostree/current/etc) THis is the part that is actually truly ostree specific, and should be in a dracut module. move(/sysroot/ostree/current/, /) execv(/sbin/init) This is what systemd already can do for you. But I don't think this will exactly the solve all the problems. In this case / is still a bind mount, not the real backing store. So for example if I have a normal / entry in /etc/fstab, systemd is going to fail to remount it read/write. No, this should work properly. We accept mounts as they are, we do not check the backing device of this, and the root fs check ignores /etc/fstab anyway and uses stat() to determine the backing device. Note that OLPC is actually using a setup very similar to yours. It appears to work fine for them these days. I should get a chance to try out some patches here within a few weeks. The main thing that needs fixing is /etc/fstab : https://mail.gnome.org/archives/ostree-list/2012-September/msg8.html I can't say I follow here. The root fsck is very special. It is not done via fsck@.service, but via root-fsck.service, and follows very different semantics, as it requires read-only root. On top of that we actually do the root fsck in the initrd anyway, to avoid having to run the fsck tool from the disk it is supposed to check/fix. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] New SELinux Patch to fix gettys not starting and poweroff/reboot commands from userspace working.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lots of new debugging/Error messages, to figure out what was failing.
Fix audit messages to not add cmdline of path if it does not exist.
Fix handling of initilization of selinux libraries.
Use log_error instead of log_full(LOG_ERROR
If bus_get_selinux_security_context fails, try to get the PID of the remote
connection and use this to get security context.
Set r -errno when the error happens, not on exit.
Use selinux_getenforce() rather then relying on global, since the global is
not always up2date.
Call multiple dbus_message_get_args to try to get name field. One with three
params, one with two and one with one. dbus-manager needs to be cleaned up,
and then we could change SELinux patch to take either a unit file or just a
path.
Stop returning errors, if SELinux can not complete checks. We can probably
turn this back on, but I wanted to make sure systemd would work in the field
before tightening this up.
You also need an updated SELINux policy to make this work.
selinux-policy-3.11.1-24.fc18.noarch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBhECMACgkQrlYvE4MpobOv1ACfdXIAZ0WVim8I3wRAK2IlsLcB
150An0e8+Uv/EkPZWzrtytURUIOvwvDC
=uv/J
-END PGP SIGNATURE-
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 8513634..9587065 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -252,9 +252,22 @@ static int audit_callback(void *auditdata, security_class_t cls,
{
struct auditstruct *audit = (struct auditstruct *) auditdata;
snprintf(msgbuf, msgbufsize,
- name=\%s\ cmdline=\%s\ auid=%d uid=%d gid=%d,
- audit-path, audit-cmdline, audit-loginuid,
+ auid=%d uid=%d gid=%d,
+ audit-loginuid,
audit-uid, audit-gid);
+
+if (audit-path) {
+ strncat(msgbuf, path=\, msgbufsize);
+ strncat(msgbuf, audit-path, msgbufsize);
+ strncat(msgbuf,\, msgbufsize);
+}
+
+if (audit-cmdline) {
+ strncat(msgbuf, cmdline=\, msgbufsize);
+ strncat(msgbuf, audit-cmdline, msgbufsize);
+ strncat(msgbuf,\, msgbufsize);
+}
+
return 0;
}
@@ -295,7 +308,7 @@ static int access_init(void) {
int r = -1;
if (avc_open(NULL, 0)) {
-log_full(LOG_ERR, avc_open failed: %m\n);
+log_error(avc_open failed: %m);
return -errno;
}
@@ -329,13 +342,13 @@ static int selinux_init(Manager *m, DBusError *error) {
/* if not first time is not set, then initialize access */
r = access_init();
if (r 0) {
-dbus_set_error(error, BUS_ERROR_ACCESS_DENIED, Unable to initialize SELinux.);
+dbus_set_error(error, BUS_ERROR_ACCESS_DENIED, Failed to initialize SELinux.);
return r;
}
-first_time = 0;
}
+first_time = 0;
return 0;
}
@@ -392,6 +405,7 @@ static int get_calling_context(
const char *sender;
int r;
+int fd;
/*
If sender exists then
@@ -401,17 +415,22 @@ static int get_calling_context(
sender = dbus_message_get_sender(message);
if (sender) {
r = bus_get_selinux_security_context(connection, sender, scon, error);
-if (r 0)
-return -EINVAL;
-} else {
-int fd;
-r = dbus_connection_get_unix_fd(connection, fd);
-if (! r)
-return -EINVAL;
+if (r == 0)
+return 0;
-r = getpeercon(fd, scon);
-if (r 0)
-return -errno;
+log_debug(bus_get_selinux_security_context failed %m);
+}
+
+r = dbus_connection_get_unix_fd(connection, fd);
+if (! r) {
+log_error(bus_connection_get_unix_fd failed %m);
+return -EINVAL;
+}
+
+r = getpeercon(fd, scon);
+if (r 0) {
+log_error(getpeercon failed %m);
+return -errno;
}
return 0;
@@ -461,15 +480,18 @@ static int selinux_access_check(DBusConnection *connection, DBusMessage *message
audit.path = path;
r = get_calling_context(connection, message, scon, error);
-if (r != 0)
+if (r != 0) {
+log_error(Failed to get caller's security context on: %m);
goto finish;
-
+}
if (path) {
tclass = service;
/* get the file context of the unit file */
r = getfilecon(path, fcon);
if (r 0) {
-log_full(LOG_ERR, Failed to get security
