Re: [systemd-devel] [Patch] build issues on ppc
Lennart Poettering píše v Út 18. 12. 2012 v 18:20 +0100: On Tue, 18.12.12 17:56, Lukáš Nykrýn (lnyk...@redhat.com) wrote: Hello, systemd-196 won't build on ppc https://bugzilla.redhat.com/show_bug.cgi?id=888255. I think that sufficient patch would be: diff --git a/Makefile.am b/Makefile.am index 804cc04..acbb12b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1068,7 +1068,8 @@ libsystemd_core_la_SOURCES = \ src/core/syscall-list.c \ src/core/syscall-list.h \ src/core/audit-fd.c \ - src/core/audit-fd.h + src/core/audit-fd.h \ + src/libsystemd-daemon/sd-daemon.c Hmm, but libsystemd_core_la_LIBADD already pulls in libsystemd-daemon.la. So why pull the .c file in too? This doesn't look like the right fix to me. Lennart Sorry I overlooked it. But then I am not sure, why the build is failing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udevd: add missing : to getopt_long 'e'
Parameter -e is set without additional argument in getopt
and this leads to segfault when calling 'systemd-udevd -e'.
---
src/udev/udevd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index ebd601e..ffc48a0 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1097,7 +1097,7 @@ int main(int argc, char *argv[])
for (;;) {
int option;
-option = getopt_long(argc, argv, c:deDtN:hV, options, NULL);
+option = getopt_long(argc, argv, c:de:DtN:hV, options, NULL);
if (option == -1)
break;
--
1.7.11.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch] build issues on ppc
On Wed, 19.12.12 11:13, Lukáš Nykrýn (lnyk...@redhat.com) wrote: Hmm, but libsystemd_core_la_LIBADD already pulls in libsystemd-daemon.la. So why pull the .c file in too? This doesn't look like the right fix to me. Sorry I overlooked it. But then I am not sure, why the build is failing. Neither am I. Given that this is specific to PPC might be worth pinging a PPC guru about this for help? 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] daemon migration tutorial
On Fri, 14.12.12 12:15, Dennis Semakin (insan...@yandex.ru) wrote: Hello, I just want to ask you a question about daemon migration to systemd. I have daemon source code, I want to use it with systemd. Where can I find the information about this? Is there any centralized tutorial or document which contains the clear description of how to redesign daemon source code for using with systemd? Or this information is scattered on the following websites http://0pointer.de/blog/projects/socket-activation.html http://0pointer.de/blog/projects/socket-activation2.html http://0pointer.de/blog/projects/journal-submit.html http://www.freedesktop.org/wiki/Software/systemd Note that systemd is compatible with SysV in most regards. So, migration to systemd should be pretty trivial in the best case. However, if you want to take benefit of specific systemd features (such as socket activation), then the documents linked above and paritcularly daemon(7) should tell you what to do. daemon(7) is the document that comes closest to the centralized tutorial you requetsed. 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] [PATCH] coredumpctl: check return of strndup
--- src/journal/coredumpctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/journal/coredumpctl.c b/src/journal/coredumpctl.c index f9cebb7..4f0ed58 100644 --- a/src/journal/coredumpctl.c +++ b/src/journal/coredumpctl.c @@ -262,7 +262,7 @@ static int retrieve(const void *data, return 0; *var = strndup((const char*)data + ident, len - ident); -if (!var) +if (!*var) return log_oom(); return 0; -- 1.7.11.7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] eudev fork and patches there
On Mon, 17.12.12 12:17, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Hi, eudev has made a project annoucement [1], and I thought it would be worthwhile to go through their patches and cherry-pick. I've now done that (until cc5c144a70fc37e 'Merge pull request #32') and the results regarding patches which can be used directly are not very impressive: one patch to fix clang warnings. There are quite a few build/compiler-warning in their tree, but they just seem to be fixes for problems introduced with their changes. Potentially usefull would also be the patch c189ab 'Fix unused result warnings', but it would be good if somebody familar with the code took a look if it is enough to print warnings (or even if they should be printed) or some more definite action should be taken. Looking over this I am actually quite sure that these invocations do not need to be checked specifically. i.e. the errors can be safely ignored, or are detected later on the control flow anyway. Given that this is udev code, Kay probably should have a closer look before we decide to ignore this entirely. (In contrast to checking frwite() and friends on every single invocation it is usually nicer to just check ferror() after one is done with everything one had to do...) Also potentially usefull are the changes to allow 'make distcheck' without gtk-doc, but they are spread out over multiple commits in a messy way, so could only be used as inspiration. Well, make distcheck is supposed to be invoked right before doing a release. As such it damn well should check if the gtk-doc stuff builds correctly, as that's part of the release. Hence I think this change is counterproductive... There's also nice patch bfc850 'Add fallback path when accept4() is not available.' Do we care about kernels 2.6.28? (This version is according to man accept4(2), patch text mentions different versions.) I am pretty sure that if people care about this, they should patch proper accept4 support into their libc rather than patching all consumers of libc to work without it. Fix the issues where they are, it's less work and more correct anyway. 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] coredumpctl: check return of strndup
On Wed, 19.12.12 14:38, Lukas Nykryn (lnyk...@redhat.com) wrote: Applied! Thanks! --- src/journal/coredumpctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/journal/coredumpctl.c b/src/journal/coredumpctl.c index f9cebb7..4f0ed58 100644 --- a/src/journal/coredumpctl.c +++ b/src/journal/coredumpctl.c @@ -262,7 +262,7 @@ static int retrieve(const void *data, return 0; *var = strndup((const char*)data + ident, len - ident); -if (!var) +if (!*var) return log_oom(); return 0; 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] After firmare
On Wed, 12.12.12 15:57, John Tobias (john.tobias...@gmail.com) wrote: Hi All, I have a network.service (pls see below) for my wireless interface: [Unit] Description=Network [Service] Restart=on-failure ExecStart=/usr/sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf [Install] WantedBy=multi-user.target One of the problem was the systemd called the said script before the kernel loads the firmware(/lib/firmware/TIInit_7.2.31.bts). I would like to know if there's a way to determine if the firmware is already loaded before the systemd execute the said service?. This looks like a driver issue to me. Normally the kernel should issue the firmware request as necessary, and the device should not show up in udev before it is properly initialized. kay? 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] vmware-datarecovery+systemd.automount+EVC = crash
On Fri, 14.12.12 06:04, Reindl Harald (h.rei...@thelounge.net) wrote: WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130() Hardware name: VMware Virtual Platform Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi This doesnt look in anyway related to systemd... 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] After firmare
On Wed, Dec 19, 2012 at 3:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 12.12.12 15:57, John Tobias (john.tobias...@gmail.com) wrote: I have a network.service (pls see below) for my wireless interface: [Unit] Description=Network [Service] Restart=on-failure ExecStart=/usr/sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf [Install] WantedBy=multi-user.target One of the problem was the systemd called the said script before the kernel loads the firmware(/lib/firmware/TIInit_7.2.31.bts). I would like to know if there's a way to determine if the firmware is already loaded before the systemd execute the said service?. This looks like a driver issue to me. Normally the kernel should issue the firmware request as necessary, and the device should not show up in udev before it is properly initialized. There are all sorts of models used for loading firmware. We don't know which one is used or what to expect here. We only about the existence of the device, and will not get any further event for it. I guess systemd/udev just isn't the right tool to find out about the actual state of the network interface. The tools which talk to the interface should deal with that themselves, or a higher-level some network management service needs to fill the gap here to hook things up. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added support for EnvironmentDir
On Mon, 10.12.12 17:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Pekka Lundstrom at 10/12/12 13:56 did gyre and gimble: + termvarnameEnvironmentDir=/varname/term +listitemparaSimilar to +varnameEnvironmentFile=/varname but +reads the environment variables from a +directory containing files. Each file in +that directory named with .conf suffix +is read and prosessed and these files +should follow same syntax as files +listed with varnameEnvironmentFile=/varname. While not commenting on the need/usefulness etc. of the patch, would it be possible to make the EnvironmentFile directive simply support globbing? e.g. Rather than doing: EnvironmentDir=/etc/foo.d I could just have: EnvironmentFile=/etc/foo.d/*.conf That would, to me at least, seem slightly cleaner than adding a new directive to parse (although this is just my opinion at first glance - others may disagree!). I agree with Colin. This would be much nicer with globbing. Also, it would then be a natural extension to allow multiple files to be specified in a single line: EnvironmentFile=/etc/foo.conf /etc/foo.conf.d/*.conf /run/foo.conf.d/*.conf I'd be happy to merge such a patch. 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] udev device mapper rules for early boot?
On Fri, 14.12.12 08:44, Nikolaus Rath (nikol...@rath.org) wrote: Looking at the relevant scripts, there doesn't seem to be any way to do that either. I can only enable or disable lvm in initrd globally, but I need to keep it enabled to mount the root fs. However, I just looked at the devices from an initrd shell and found something peculiar: all the /dev/dm-* devices are owed by uid 0, gid 0, only the device I'm interested in is owned by 1000:0. So apparently my udev rule actually works just fine in the initrd, but something later on changes the permissions again, setting all the devices to root:disk instead. Any suggestions how to find out what's responsible for that? Note that when the system is running and I re-enable the volume, it is created with the correct permissions (1000:disk). What LVM does with the udev rules, is rather special. I'd encourage you to contact the LVM folks about this, they probably can help you better than we We generally retrigger all devices after transitioning to the main system from the initrd. That should usually ensure that the rules of the main system are applied. However, afaik the LVM folks do something weird to avoid that... Please talk to them. Or maybe Kay has another idea? 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] Added support for EnvironmentDir
On 12/19/2012 06:00 PM, Lennart Poettering wrote: On Mon, 10.12.12 17:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Pekka Lundstrom at 10/12/12 13:56 did gyre and gimble: +termvarnameEnvironmentDir=/varname/term +listitemparaSimilar to +varnameEnvironmentFile=/varname but +reads the environment variables from a +directory containing files. Each file in +that directory named with .conf suffix +is read and prosessed and these files +should follow same syntax as files +listed with varnameEnvironmentFile=/varname. While not commenting on the need/usefulness etc. of the patch, would it be possible to make the EnvironmentFile directive simply support globbing? e.g. Rather than doing: EnvironmentDir=/etc/foo.d I could just have: EnvironmentFile=/etc/foo.d/*.conf That would, to me at least, seem slightly cleaner than adding a new directive to parse (although this is just my opinion at first glance - others may disagree!). I agree with Colin. This would be much nicer with globbing. Also, it would then be a natural extension to allow multiple files to be specified in a single line: EnvironmentFile=/etc/foo.conf /etc/foo.conf.d/*.conf /run/foo.conf.d/*.conf I'd be happy to merge such a patch. Lennart OK, I'll redo the feature. t. Pekka ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add %U for uids in units
On Fri, 07.12.12 00:01, Daniel Wallace (danielwall...@gtmanfred.com) wrote:
Thanks, applied.
---
man/systemd.unit.xml | 5 +
src/core/unit-printf.c | 17 +++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 35644d3..bf91b4e 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -264,6 +264,11 @@
entryThis is the name of the configured user of
the unit, or (if none is set) the user running the systemd instance./entry
/row
row
+entryliteral%U/literal/entry
+entryUser uid/entry
+entryThis is the uid of the configured user of the
unit, or (if none is set) the user running the systemd instance./entry
+ /row
+ row
entryliteral%h/literal/entry
entryUser home directory/entry
entryThis is the home directory of the configured
user of the unit, or (if none is set) the user running the systemd
instance./entry
diff --git a/src/core/unit-printf.c b/src/core/unit-printf.c
index a8eb60a..a58c96c 100644
--- a/src/core/unit-printf.c
+++ b/src/core/unit-printf.c
@@ -123,6 +123,8 @@ static char *specifier_user_name(char specifier, void
*data, void *userdata) {
ExecContext *c;
int r;
const char *username;
+uid_t uid;
+char *printed = NULL;
assert(u);
@@ -134,11 +136,21 @@ static char *specifier_user_name(char specifier, void
*data, void *userdata) {
/* fish username from passwd */
username = c-user;
-r = get_user_creds(username, NULL, NULL, NULL, NULL);
+r = get_user_creds(username, uid, NULL, NULL, NULL);
if (r 0)
return NULL;
-return strdup(username);
+switch (specifier) {
+case 'U':
+if (asprintf(printed, %d, uid) 0)
+return NULL;
+break;
+case 'u':
+printed = strdup(username);
+break;
+}
+
+return printed;
}
static char *specifier_user_home(char specifier, void *data, void *userdata)
{
@@ -292,6 +304,7 @@ char *unit_full_printf(Unit *u, const char *format) {
{ 'r', specifier_cgroup_root, NULL },
{ 'R', specifier_cgroup_root, NULL },
{ 't', specifier_runtime, NULL },
+{ 'U', specifier_user_name, NULL },
{ 'u', specifier_user_name, NULL },
{ 'h', specifier_user_home, NULL },
{ 's', specifier_user_shell, NULL },
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] vmware-datarecovery+systemd.automount+EVC = crash
On Wednesday, December 19, 2012 03:52:08 PM Lennart Poettering wrote: On Fri, 14.12.12 06:04, Reindl Harald (h.rei...@thelounge.net) wrote: WARNING: at fs/ext4/super.c:339 ext4_journal_start_sb+0x11e/0x130() Hardware name: VMware Virtual Platform Modules linked in: binfmt_misc cls_u32 sch_htb xt_hl xt_LOG xt_limit xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_iprange xt_multiport vmw_balloon crc32c_intel ghash_clmulni_intel vmxnet3 vmw_pvscsi This doesnt look in anyway related to systemd... The warnigns are coming from ext4 driver so I'd start there... Thanks, Dmitry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added support for EnvironmentDir
On Wed, Dec 19, 2012 at 8:00 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 10.12.12 17:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Pekka Lundstrom at 10/12/12 13:56 did gyre and gimble: + termvarnameEnvironmentDir=/varname/term +listitemparaSimilar to +varnameEnvironmentFile=/varname but +reads the environment variables from a +directory containing files. Each file in +that directory named with .conf suffix +is read and prosessed and these files +should follow same syntax as files +listed with varnameEnvironmentFile=/varname. While not commenting on the need/usefulness etc. of the patch, would it be possible to make the EnvironmentFile directive simply support globbing? e.g. Rather than doing: EnvironmentDir=/etc/foo.d I could just have: EnvironmentFile=/etc/foo.d/*.conf That would, to me at least, seem slightly cleaner than adding a new directive to parse (although this is just my opinion at first glance - others may disagree!). I agree with Colin. This would be much nicer with globbing. Also, it would then be a natural extension to allow multiple files to be specified in a single line: EnvironmentFile=/etc/foo.conf /etc/foo.conf.d/*.conf /run/foo.conf.d/*.conf I'd be happy to merge such a patch. Pekka, this will help a lot - thanks - looking forward to seeing this feature. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] eudev fork and patches there
]] Lennart Poettering (In contrast to checking frwite() and friends on every single invocation it is usually nicer to just check ferror() after one is done with everything one had to do...) In that case, it's probably better to explicitly ignore the return value by casting it to void and so avoid warnings from the compiler. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add hibernate and hybrid-sleep to zsh-completion
On Wed, 19.12.12 12:28, Daniel Wallace (danielwall...@gtmanfred.com) wrote:
Applied. Thanks
---
shell-completion/systemd-zsh-completion.zsh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/systemd-zsh-completion.zsh
index 93d64b3..ee68ac7 100644
--- a/shell-completion/systemd-zsh-completion.zsh
+++ b/shell-completion/systemd-zsh-completion.zsh
@@ -329,6 +329,8 @@ _outputmodes() {
try-restart:Restart one or more units if active
reload-or-restart:Reload one or more units if possible, otherwise start
or restart
force-reload:Reload one or more units if possible, otherwise restart if
active
+hibernate:Hibernate the system
+hybrid-sleep:Hibernate and suspend the system
reload-or-try-restart:Reload one or more units if possible, otherwise
restart if active
isolate:Start one unit and stop all others
kill:Send signal to processes of a unit
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] [RFC/PATCH] journal: new logging macros to include _SYSTEMD_UNIT
On Wed, 05.12.12 10:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Adding _SYSTEMD_UNIT= to log lines allows them to be shown in 'systemctl status' output, etc. A new set of macros and functions is added. This allows for less verbose notation than using log_struct() explicitly. Just a few example log lines are modified to show the usage. Cool stuff. I actually had something similar on my list for quite some time. I'd prefer though not to litter the very generic log.c with unit specific stuff. So, maybe we can find a way that we can implement some generic macros which can be used as basis for specific object-type-specific log messages? i.e. something such as log_object_debug(), log_object_info(), ... which we can use to define log_unit_debug(), log_unit_info(), ... in unit.h, but to log_job_debug(), log_job_info(), ... in job.h, and similar. After all, units are not the only objects we deal with, there's much more. For example, maybe udev would like to make use for that for its devices, and so on... Really like the idea! 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] Too many incoming connections (64)
On Sun, 02.12.12 03:13, Dimitrios Apostolou (ji...@gmx.net) wrote: Hello list, some socket activated service gave me the error message you can see on the subject, maybe systemd should be more verbose in that case. Please see attached patch (untested). 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] [PATCH] *.py: don't hardcode /usr/bin/python
On Sat, 01.12.12 09:34, Ramkumar Ramachandra (artag...@gmail.com) wrote: Michael Biebl wrote: 2012/11/30 Ramkumar Ramachandra artag...@gmail.com: Execute python using /usr/bin/env python instead of hard-coding the I'm not really a fan of using /usr/bin/env, as you can pick up a random python version depending on how your PATH is setup. Besides, you need to spawn an additional binary. I would assume that pretty much every distro ships the python interpreter as /usr/bin/python. I don't follow your reasoning: it is idiomatic to use /usr/bin/env $interpreter, because every distro does not necessarily ship it as /usr/bin/$interpreter. Always doing two exec()s instead of one sounds suboptimal to me. Given that this script is not supposed to be copiable to other distros, I'd suggest to detect the python part as configure time (which we do anyway in @PYTHON@) and rewrite the scripts to use that. That way, we don't do the unnecessary double exec() and we have the benefit that the scripts are executed with the same python version as was used to configure the build tree, which I think is quite desirable... Does that make sense? 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] .journal~ files
On Thu, 29.11.12 10:34, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: El 29/11/12 07:24, Colin Guthrie escribió: Hi, I have several .journal~ files in my journal dir... without me digging into the source, can someone explain what these are and if I can safely remove them (as they are quite large!) like most other ~ files. Cheers Col The real problem behind is this: systemd-journald[186]: File /var/log/journal/fa719ecdd32d41b7ed0ff54502b6/system.journal corrupted or uncleanly shut down, renaming and replacing. In current versions, the journal files are always corrupt after reboot, I am not sure why though. That would indicate that the journal is not shut down cleanly before we go down. 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] how to start a service when another sevice stops
On Fri, 30.11.12 23:40, Reindl Harald (h.rei...@thelounge.net) wrote: Am 30.11.2012 23:28, schrieb Khem Raj: I have a scenario where, I have foo.service which runs on boot and later bar.service runs and it has to stop foo.service which I achieved by declaring it as Conflicts= in the unit file but I would like to restart foo.service when bar.service is stopped. I have run out of ideas on how to achieve that. I am looking for help ExecStopPost=/bin/systemctl start whatever.service Yeah, this is what I would suggest too. Or, possibly the reverse, i.e. use ExecStartPre=/usr/bin/systemctl stop foobar.service in the second service. 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] pam_systemd: new option for the session class
On Tue, 27.11.12 23:16, Matthew Monaco (dgbale...@0x01b.net) wrote:
I don't see any reason why every DM (LightDM for me) needs code to support
this.
It looks to me like its safe to just point to the data in argv, let me
know if it isn't.
Sounds like a good idea. A few comments though:
+termoptionclass=/option/term
+
+listitemparaTakes a string
+argument which sets the session class.
+This takes precedent over the
XDG_SESSION_CLASS
+environmental variable./para/listitem
+/varlistentry
Hmm, takes precdence over XDG_SESSION_CLASS? I'd always do things the
other way round, i.e. that the runtime param overrides the statically
configured param.
+} else if (startswith(argv[i], class=)) {
+
+if (class) {
+ *class = argv[i] + 6;
+}
No {} for single-line if blocks please... This is not PHP ;-)
-class = pam_getenv(handle, XDG_SESSION_CLASS);
+if (isempty(class))
+class = pam_getenv(handle, XDG_SESSION_CLASS);
Please invert this logic, see above...
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] ExecRestart
On Wed, 28.11.12 22:41, Brandon Black (blbl...@gmail.com) wrote: The daemon's fast restart code does all of the expensive startup operations in the new daemon first (e.g. parsing large data input), then signals the existing daemon to shut itself down, waits for it to release its critical resources (e.g. sockets, pidfile), and finally takes over those resources and finishes starting itself. Basically it's using the overlap to avoid long service downtimes during that initial parsing phase (and if that parsing fails, it leaves the old daemon running to boot). We specifically don't allow ExecRestart= in order to guarantee that all restarts are comprehensive and really do what is necessary to be done. For example, we consider it a good thing to kill all processes forked off a daemon when we restart the daemon. We can do this easily with the information from the cgroup, and we generally believe that such a killing spree is best done from outside the daemon in question rather from the suicidal daemon itself. That said I do acknowledge that there is a bit of value of supporting daemons which can do reexec on their own, where reexec is something between the superficial reload and the hardcore restart. In fact I am kinda interested to implement reexec in some of systemd's own services (such as journald), so that open sockets are kept around. Now, the reason why we have no support for a nice reexec verb yet is simply because I am a bit afraid of adding something that might turn-out not to be necessary, and that might just be a special case of reload after all. I mean, the difference between retsart and reload is kinda complex already, and adding a third verb (plus all the various transitive products of this such as try-restart, reload-or-restart for reexec) makes me feel a bit uncomfortable. Or in other words: I am pretty sure that we should not alter the current restart logic, and should not introduce ExecRestart=. However, we really should think about either introducing ExecReexec= or somehow making ExecReload= useful for reexec-style reloading, too. But I haven't made my mind up on this, how this could look like. Michal, Zbigniew, Kay, do you have ideas about 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] logind 196 keeps on locking my session
On Wed, 28.11.12 10:31, Paul Neumann (paul1...@yahoo.de) wrote: Hi all, the new lock setting of HandleLidSwitch for logind in systemd 196 does not work correctly for me. After setting the option and closing the lid of my laptop, my session gets locked. However, as soon as I unlock the session, it instantly gets locked again. The following messages appear in the journal: systemd-logind[325]: Lid closed. systemd-logind[325]: Locking sessions... Whereas the second message is repeated a couple of hundred times per second. I am using the lockscreen of gnome-screensaver in case that matters and I would appreciate if someone could have a look into this. GNOME watches the lid siwtch on its own anyway, so you have two clients watching the lid switch and handling on it? 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] [RFC][PATCH 2/2] systemctl: switch-root - read init= from /proc/cmdline
On Wed, 28.11.12 01:30, Tom Gundersen (t...@jklm.no) wrote:
If the path to init is not specified as an argumnt to systemctl, but
init= is given on the kernel commandline, use that.
This means the initrd does not need glue code to parse the kernel
commandline before passing on init= to systemctl.
Looks OK.
-const char *root, *init;
+int r;
+const char *root;
+char *init = NULL;
Might want to use _cleanup_free_ for this.
l = strv_length(args);
if (l 2 || l 3) {
@@ -3332,9 +3334,22 @@ static int switch_root(DBusConnection *bus, char
**args) {
}
root = args[1];
-init = l = 3 ? args[2] : ;
-return bus_method_call_with_reply (
+if (l = 3) {
+init = strdup(args[2]);
+} else {
Please don't use {} for single-line if blocks. This isn't PHP ;-)...
+parse_env_file(/proc/cmdline, WHITESPACE,
+ init, init,
+ NULL);
+
+if (!init)
+init = strdup();
+
+}
You should check init for OOM here.
+
+log_debug(switching root - root: %s; init: %s, root, init);
+
+r = bus_method_call_with_reply (
bus,
org.freedesktop.systemd1,
/org/freedesktop/systemd1,
@@ -3345,6 +3360,10 @@ static int switch_root(DBusConnection *bus, char
**args) {
DBUS_TYPE_STRING, root,
DBUS_TYPE_STRING, init,
DBUS_TYPE_INVALID);
+
+free(init);
+
+return r;
}
static int set_environment(DBusConnection *bus, char **args) {
Otherwise looks good.
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] [RFC][PATCH 1/2] fstab-generator: generate new_root.mount in initrd
On Wed, 28.11.12 01:30, Tom Gundersen (t...@jklm.no) wrote:
The configuration is taken from /proc/cmdline, aiming at emulating the
behavior of the kernel when no initramfs is used.
The supported options are: root=, rootfstype=, rootwait=, rootflags=,
ro, and rw. rootdelay= was dropped, as it is not really useful in a
systemd world, but could easily be added.
Cc: Harald Hoyer har...@redhat.com
Cc: Dave Reisner dreis...@archlinux.org
---
Hi guys,
Together with the next patch this aims to add enough kernel commandline
parsing support
to systemd so that it can be used in an initramfs without any extra glue to
parse the
command line and pass on the correct parameters to systemd.
A patch exists using this work to add (shell-free) systemd support to Arch's
mkinitcpio [0].
This is based on similar work in dracut.
Comments welcome,
Sounds good! A few comments:
Tom
[0]:
https://mailman.archlinux.org/pipermail/arch-projects/2012-November/003446.html
src/fstab-generator/fstab-generator.c | 159
+-
1 file changed, 135 insertions(+), 24 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index ba55f2c..8b0b548 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -202,18 +202,21 @@ static bool mount_is_network(struct mntent *me) {
fstype_is_network(me-mnt_type);
}
-static int add_mount(const char *what, const char *where, struct mntent *me)
{
+static int add_mount(const char *what, const char *where, const char *type,
const char *opts,
+ int passno, bool wait, bool noauto, bool nofail, bool
automount, bool isbind, bool isnetwork,
+ const char *source) {
char *name = NULL, *unit = NULL, *lnk = NULL, *device = NULL,
*automount_name = NULL, *automount_unit = NULL;
FILE *f = NULL;
-bool noauto, nofail, automount, isbind, isnetwork;
int r;
const char *post, *pre;
assert(what);
assert(where);
-assert(me);
+assert(type);
+assert(opts);
+assert(source);
-if (streq(me-mnt_type, autofs))
+if (streq(type, autofs))
return 0;
if (!is_path(where)) {
@@ -225,15 +228,6 @@ static int add_mount(const char *what, const char
*where, struct mntent *me) {
mount_point_ignore(where))
return 0;
-isnetwork = mount_is_network(me);
-isbind = !!hasmntopt(me, bind);
-
-noauto = !!hasmntopt(me, noauto);
-nofail = !!hasmntopt(me, nofail);
-automount =
-hasmntopt(me, comment=systemd.automount) ||
-hasmntopt(me, x-systemd.automount);
-
if (isnetwork) {
post = SPECIAL_REMOTE_FS_TARGET;
pre = SPECIAL_REMOTE_FS_PRE_TARGET;
@@ -264,10 +258,12 @@ static int add_mount(const char *what, const char
*where, struct mntent *me) {
goto finish;
}
-fputs(# Automatically generated by systemd-fstab-generator\n\n
+fprintf(f,
+ # Automatically generated by systemd-fstab-generator\n\n
[Unit]\n
- SourcePath=/etc/fstab\n
- DefaultDependencies=no\n, f);
+ SourcePath=%s\n
+ DefaultDependencies=no\n,
+ source);
if (!path_equal(where, /))
fprintf(f,
@@ -293,14 +289,18 @@ static int add_mount(const char *what, const char
*where, struct mntent *me) {
FsckPassNo=%i\n,
what,
where,
-me-mnt_type,
-me-mnt_passno);
+type,
+passno);
-if (!isempty(me-mnt_opts)
-!streq(me-mnt_opts, defaults))
+if (!isempty(opts)
+!streq(opts, defaults))
fprintf(f,
Options=%s\n,
-me-mnt_opts);
+opts);
+
+if (wait)
+fprintf(f,
+TimeoutSec=0\n);
fflush(f);
if (ferror(f)) {
@@ -459,7 +459,13 @@ static int parse_fstab(void) {
if (streq(me-mnt_type, swap))
k = add_swap(what, me);
else
-k = add_mount(what, where, me);
+k = add_mount(what, where, me-mnt_type,
me-mnt_opts,
+ me-mnt_passno, false, !!hasmntopt(me,
noauto),
+ !!hasmntopt(me, nofail),
+ hasmntopt(me,
comment=systemd.automount) ||
+ hasmntopt(me, x-systemd.automount),
+
Re: [systemd-devel] Force rotating the journal?
On Wed, 28.11.12 10:14, Dave Reisner (d...@falconindy.com) wrote: I'm not sure when it happened, but rotation used to be off by a difference of whatever the MaxFileSize option was, e.g. if you had a 200M MaxUse and a 50M MaxFileSize, then you'd see usage up to 250M before old logs were expired. I reported this, and there was a TODO item added. Yeah, the TODO list item is actually really hard to fix, since we have multiple journal files fro writing open: i.e. one for the each user plus the system one. If each file can grow to N bytes in size, and we should enforce a total of M, then it's not sufficient to delete files until we reach the limit of M-N, since if we grow multiple files then we might still easily hit the M limit without noticing... Not sure what we can do to properly fix this so that we can guarantee that SystemMaxUse= is actually really the maximum use, and that we never ever write a single byte more than this. At least with 196 (maybe earlier), this no longer holds true any more. The journal appears to just ignore settings in journald.conf and grow without bound: $ grep -E 'SystemMax(Use|FileSize)' /etc/systemd/journald.conf SystemMaxUse=200M SystemMaxFileSize=50M $ journalctl --disk-usage Journals take up 436.0M on disk. Forcing rotation opens a new file, but old logs are not expired, leaving disk usage way above the set maximum. There also seems to be a recent issue with more uncleanly closed journal files showing up. Unless I umount my root at shutdown (with initramfs magic), I can very reliably expect that the journal will mark the last used file as unclean on the next bootup. My suspicion is that the journal doesn't take into account these uncleanly closed files when calculating disk usage for rotation, but I've not had time to confirm that. Umm. Sounds like a bug, could you file this on fdo bz, plz? 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] journal space requirements
On Thu, 29.11.12 10:37, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, So a couple complaints/queries are beginning trickling in regarding journal space requirements. A user was complaining that rotated journals were taking up too much room and they could be compressed down etc. I did explain that a rotated journal is really any different to the current journal other than it can be sealed, but I do fear he has some kind of point regarding long term storage. Should there be some kind of journal archiver system that will run xz -9 on older journals? Is this something that's being planned or is it left as an exercise for the reader to implement such long term storage/archiving systems? IMO it would be nice to be able to trigger such service when the journal is rotated (i.e. a templated unit) that can either just compress the journal in place (assuming the user does not want to be able to read from it actively any more) or copy a compressed version to some archive dir to do with as the user pleases. As Kay already pointed out it's a bit hard to fully compress the files including the metadata if we still want to allow implicit efficient merging of all accessible journal files rotated or not. It's the tradeoff: either you index everything and can access it very efficiently, so that it becomes so cheap you can just do it implicitly and always, or you reach the best possible compression... I think we have a couple of other options though. For example, it has been suggested we should drop lower-prio msgs when rotating. I think it would make a lot of sense to implement something like this on rotation, i.e. where we just rewrite the entire file dropping all debug messages, so that as older things get the less detail we maintain... 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] eudev fork and patches there
On Wed, 19.12.12 20:38, Tollef Fog Heen (tfh...@err.no) wrote: ]] Lennart Poettering (In contrast to checking frwite() and friends on every single invocation it is usually nicer to just check ferror() after one is done with everything one had to do...) In that case, it's probably better to explicitly ignore the return value by casting it to void and so avoid warnings from the compiler. We don't use the compiler warning flags that would trigger warnings like these... I am not too much of a fan of prefixing every second line with (void) 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] logind 196 keeps on locking my session
On Thu, Dec 20, 2012 at 12:47 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.11.12 10:31, Paul Neumann (paul1...@yahoo.de) wrote: Hi all, the new lock setting of HandleLidSwitch for logind in systemd 196 does not work correctly for me. After setting the option and closing the lid of my laptop, my session gets locked. However, as soon as I unlock the session, it instantly gets locked again. The following messages appear in the journal: systemd-logind[325]: Lid closed. systemd-logind[325]: Locking sessions... Whereas the second message is repeated a couple of hundred times per second. I am using the lockscreen of gnome-screensaver in case that matters and I would appreciate if someone could have a look into this. GNOME watches the lid siwtch on its own anyway, so you have two clients watching the lid switch and handling on it? I don't think it does anymore. gnome-settings-daemon does not grab the handle-lid-switch inhibitor by default – only when there are external displays connected (to completely prevent suspending). -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .journal~ files
El mié 19 dic 2012 19:25:13 CLST, Lennart Poettering escribió: On Thu, 29.11.12 10:34, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: El 29/11/12 07:24, Colin Guthrie escribió: Hi, I have several .journal~ files in my journal dir... without me digging into the source, can someone explain what these are and if I can safely remove them (as they are quite large!) like most other ~ files. Cheers Col The real problem behind is this: systemd-journald[186]: File /var/log/journal/fa719ecdd32d41b7ed0ff54502b6/system.journal corrupted or uncleanly shut down, renaming and replacing. In current versions, the journal files are always corrupt after reboot, I am not sure why though. That would indicate that the journal is not shut down cleanly before we go down. Lennart Of course, unfortunately it happends after every reboot, no matter what. It appears to be some kind of race condition, I have 2 boxes with fast ssd disks where it happends, and one ARM system which significantly slower storage (MMC card) where it happends rarely. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] *.py: don't hardcode /usr/bin/python
On Wed, Dec 19, 2012 at 11:02:30PM +0100, Lennart Poettering wrote: On Sat, 01.12.12 09:34, Ramkumar Ramachandra (artag...@gmail.com) wrote: Michael Biebl wrote: 2012/11/30 Ramkumar Ramachandra artag...@gmail.com: Execute python using /usr/bin/env python instead of hard-coding the I'm not really a fan of using /usr/bin/env, as you can pick up a random python version depending on how your PATH is setup. Besides, you need to spawn an additional binary. I would assume that pretty much every distro ships the python interpreter as /usr/bin/python. I don't follow your reasoning: it is idiomatic to use /usr/bin/env $interpreter, because every distro does not necessarily ship it as /usr/bin/$interpreter. Always doing two exec()s instead of one sounds suboptimal to me. Given that this script is not supposed to be copiable to other distros, I'd suggest to detect the python part as configure time (which we do anyway in @PYTHON@) and rewrite the scripts to use that. That way, we don't do the unnecessary double exec() and we have the benefit that the scripts are executed with the same python version as was used to configure the build tree, which I think is quite desirable... I had a patch moving all .py files to .py.in and then translating them during build process to insert proper values of $PYTHON and $PACKAGE_VERSION (for --version and --help). Didn't post because I thought it is too much noise for little gain. I'll dig it up, clean up, and post here. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
