[systemd-devel] systemd-cron: retrigger generator after /var is mounted
Hi, I have been maitaining systemd-crontab-generator for some months, this is a generator developped outside of systemd that translates the crontabs in timer service units. I have two unresolved bugs in our tracker that I don't know how to tackle in the most systemd-way. Maybe you know better. Here they are: https://github.com/systemd-cron/systemd-cron/issues/26 -) how can I trigger a rerun of the generator after /var is mounted. There is already a trigger on PathChanged=/var/spool/cron/crontabs, but this doens't work, because cron.target is started after /var is mounted. I already noticed the presence of /run/systemd/generator/var.mount; but I don't know how to glue it together. Current trigger units: https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in --- https://github.com/systemd-cron/systemd-cron/issues/12 - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown, it is not restarted on next reboot. --- Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fsck: re-enable fsck -l
The -l (lock) has been temporary disabled due to conflict with
udev (https://bugs.freedesktop.org/show_bug.cgi?id=79576)
The problem is fixed since util-linux v2.25 (Jul 2014).
---
README | 3 ++-
src/fsck/fsck.c | 13 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/README b/README
index e0edd41..8f7a96e 100644
--- a/README
+++ b/README
@@ -129,8 +129,9 @@ REQUIREMENTS:
During runtime, you need the following additional
dependencies:
-util-linux = v2.19 (requires fsck -l, agetty -s),
+util-linux = v2.19 required for agetty -s
v2.21 required for tests in test/
+ v2.25 required for fsck -l
dbus = 1.4.0 (strictly speaking optional, but recommended)
sulogin (from util-linux = 2.22 or sysvinit-tools, optional but
recommended,
required for tests in test/)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index dfe97bc..70a5918 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -320,16 +320,11 @@ int main(int argc, char *argv[]) {
cmdline[i++] = -T;
/*
- * Disable locking which conflict with udev's event
- * ownershipi, until util-linux moves the flock
- * synchronization file which prevents multiple fsck running
- * on the same rotationg media, from the disk device
- * node to a privately owned regular file.
- *
- * https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
- *
- * cmdline[i++] = -l;
+ * Since util-linux v2.25 fsck uses /run/fsck/diskname.lock files.
+ * The previous versions use flock for the device and conflict with
+ * udevd, see https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
*/
+cmdline[i++] = -l;
if (!root_directory)
cmdline[i++] = -M;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
On Tue, 21.10.14 22:55, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: That way we wouldn't have to allocate an strv, and just open code the search logic. This would then mirror nicely how the pager logic works... I agree but I can't (or I don't know how to do this), because we need to give the paths of the units to execvp, and since the first argument must be the name of the editor, I need to add it to the strv. The original strv is a strv of units path, so I copy it and prepend the name of the editor. The strv is just a string array, you can just go ahead and override its entries. Of course, afterwards deallocating it is not easy, since you'd have to replace the first string again with the the original malloc()ed one, but ultimately this doesn't really matter anyway, since you invoke execlp() which will replace the process and where you won't have time to free the strv anyway. We can do this for the pager because there is no arguments to give, here we have a list of paths. THinking about this: are all those editors actually fine with editing multiple files at once? is nano? Maybe we should invoke them one-by-one instead of just once? (just thinking out loud...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
On Tue, 21.10.14 23:04, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: I think we should really take some inspiration here from how git prepares the editor when asking for commit messages: adding a really useful commented help text to the end of the new file to edit would be really awesome. More specifically, I think we should include an output equivalent to systemctl cat's add the end, commented and prefixed with some clear marker that we can then use to remove the bits again before saving things. Yeah It seems nice. Do you prefer that I add this in the correction of this patch, or with follow-up patches ? follow-up is fine. Hmm, when precisely is this actually triggered? I mean, if the file already exists in /etc we should just edit it there... There is a specific case when this can happen. Imagine you have a unit foobar with FragmentPath=/usr/lib/systemd/system/foobar.service, and you added manually /etc/systemd/system/foobar.service without doing daemon-reload. When avoid_bus() == false, we will get the /usr/*** path, so we need to be sure that the user don't want to overwrite the one in /etc/***. We can avoid this by doing daemon-reload before editing, but I'm not sure this is wanted. Hmm, one option would be not to actually use FragmentPath= as source but to actually look for the file on the client side (in particularly useful when --root= is used...). But maybe that's actually unnecessary, as it only makes the race window smaller, but still leaves it open a bit... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
Am 2014-10-22 10:36, schrieb Lennart Poettering: We can do this for the pager because there is no arguments to give, here we have a list of paths. THinking about this: are all those editors actually fine with editing multiple files at once? is nano? I know for certain that nano, vim, emacs, joe, kwrite and gedit support multiple files on the command line (and switching between them). Therefore, I don't think that will be an issue. The biggest problem I see with this is more the fact that you don't immediately recognize that multiple files are open (and not just in nano, some other editors suffer from the same problem). But calling it mutliple times in sequence is even worse, since then you can't even switch between files and suspend (Ctrl-Z) will probably do some really weird stuff. What about the following? - if there is only one file: call the editor just with the one file - if there is more than one file: create a temporary file in /tmp (that will be deleted afterwards) that contains a list of all files that are opened by the editor + some explanation text (like git/svn/... commit message hints) and put that in front of the list of files that are to be edited. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
On Wed, 22.10.14 00:29, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
Nitpick: please no {} for single-line if blocks.
Oh and about this one, since I saw you mentioning it a couple of times
in other patches sent to the ML, maybe you should add this to the
CODING_STYLE ? I don't see any mention of this in it currently.
Good point! Done!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
On Wed, 22.10.14 11:10, Christian Seiler (christ...@iwakd.de) wrote: Am 2014-10-22 10:36, schrieb Lennart Poettering: We can do this for the pager because there is no arguments to give, here we have a list of paths. THinking about this: are all those editors actually fine with editing multiple files at once? is nano? I know for certain that nano, vim, emacs, joe, kwrite and gedit support multiple files on the command line (and switching between them). Therefore, I don't think that will be an issue. The biggest problem I see with this is more the fact that you don't immediately recognize that multiple files are open (and not just in nano, some other editors suffer from the same problem). But calling it mutliple times in sequence is even worse, since then you can't even switch between files and suspend (Ctrl-Z) will probably do some really weird stuff. What about the following? - if there is only one file: call the editor just with the one file - if there is more than one file: create a temporary file in /tmp (that will be deleted afterwards) that contains a list of all files that are opened by the editor + some explanation text (like git/svn/... commit message hints) and put that in front of the list of files that are to be edited. Sounds OK to me, but then again, it was the user who invoked the command line, he should have known what he did... But anyway, sounds OK anyway, but probably just the cherry on top to add in a later patch! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
On Wed, 22.10.14 01:48, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sat, Oct 18, 2014 at 06:30:02PM +0200, Ronny Chevalier wrote: It helps editing units by either creating a drop-in file, like /etc/systemd/system/my.service.d/amendments.conf, or by copying the original unit from /usr/lib/systemd/ to /etc/systemd/ if the --full option is specified. Then it invokes an editor to the related files and daemon-reload is invoked when the editor exited successfully. Hm, this sequence doesn't sound right. A temporary file should be created, edited, and then atomically put in place, iff the editor exits successfully. I think we should follow in the footsteps of git here... and abort if the editor exits with an error. Hmm, don't smart editors do this anyway when saving a file? I'm not sure abou the name 'amendments.conf'. Wouldn't 'local.conf' be more idiomatic, and also easier to type? I was thinking about this too, and I wanted to propose override.conf instead? The word amendment I only know from the US constitution... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wed, 22.10.14 09:56, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: Hi, I have been maitaining systemd-crontab-generator for some months, this is a generator developped outside of systemd that translates the crontabs in timer service units. I have two unresolved bugs in our tracker that I don't know how to tackle in the most systemd-way. Maybe you know better. Here they are: https://github.com/systemd-cron/systemd-cron/issues/26 -) how can I trigger a rerun of the generator after /var is mounted. generators are rerun if you issue systemctl daemon-reload There is already a trigger on PathChanged=/var/spool/cron/crontabs, but this doens't work, because cron.target is started after /var is mounted. I already noticed the presence of /run/systemd/generator/var.mount; but I don't know how to glue it together. Current trigger units: https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in So, I thought myself a couple of times about adding a cron generator upstream, but always came to the conclusion that having to load the configuration twice during boot-up would be suboptimal. The scheme I'd hence propose is a different one: it's OK to cover /etc/cron.daily and friends natively with a generator (and that's easy as the stuff is in /etc), but for the per-user stuff stored in /var it is a better idea to just leave traditional crond around, however, with one trick: only start it as soon as there is a file dropped into the cron subdir in /var. This way, users can use cron as they always did: as long as they did not install any user cronjobs everything works fine without crond started, and then when they install user cronjobs crond magically gets started in the background. The way how users install cronjobs is by invoking crontab -e anyway, and that tool needs to be installed anyway of the crond package, hence installing crond in a way that it is triggered via a crond.path unit should be OK too. Hope that makes sense? https://github.com/systemd-cron/systemd-cron/issues/12 - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown, it is not restarted on next reboot. Hmm, could you file a bug about this issue on fdo bz? we should probably cover for this nicely. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fsck: re-enable fsck -l
On Wed, 22.10.14 10:28, Karel Zak (k...@redhat.com) wrote: The -l (lock) has been temporary disabled due to conflict with udev (https://bugs.freedesktop.org/show_bug.cgi?id=79576) The problem is fixed since util-linux v2.25 (Jul 2014). Thanks! Applied! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] v216 timers: a configuration for enterprise's needs, features requests
On Wed, 17.09.14 18:31, Daniele Medri (dme...@gmail.com) wrote: Dears, testing timers on systemd v216, I've made a configuration that could be useful for enterprise's needs: https://github.com/dmedri/systemd-enterprise-timers The following ideas could be useful for the editing job. FEATURES REQUESTS 1. in /src/shared/calendarspec.c, calendar_spec_from_string(...), add new cases for: - minutely (OnCalendar=*:0/1:00) - quarterly (OnCalendar=01,04,07,10-01) - semesterly (OnCalendar=01,07-01) Are these proper english words? Not oppposed to adding these though. Can you submit this as patches? Maybe rename semesterly → semianually? Or biannually? quarterly appears to be correct english. Not sure about minutely though, any native speakers have suggestions? 2. add an utils to check OnCalendar= syntax. What should expect an user from the utility of point 2.? - print a list of timestamps from a syntax expression (like the NEXT field in systemctl list-timers --all) - introduce a human readable string for syntax expressions (eg. hourly - Every hour.) that we could translate in different languages and share with desktop applications (eg. for backup, to send email, ...). This sounds like something we could merge upstream, but I'd really prefer to add it to systemd-analyze instead of systemctl. systemd-analyze is something where all debugging/testing tools are placed so far. Any chance you can rework this and submit? Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH 1/2] resolve: resolved-manager: Avoid null dereference
On Sat, 13.09.14 20:40, Tom Gundersen (t...@jklm.no) wrote: Yeah, this could happen. It so happens that the loopback link will always have ifindex 1, so I guess we could just fall back to checking for that if we don't have the real flags. Is that true even in network namespaces? Is this really exported API? I really don't want to rely on behaviour here that is not considered official API of Linux. If it is safe API of Linux, then we really should drop manager_ifindex_is_loopback() entirely, and just always compare the ifindex. Anyone has some pointers where this is made API? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fsck: re-enable fsck -l
22.10.2014 at 10:28 Karel Zak k...@redhat.com wrote:
The -l (lock) has been temporary disabled due to conflict with
udev (https://bugs.freedesktop.org/show_bug.cgi?id=79576)
The problem is fixed since util-linux v2.25 (Jul 2014).
---
README | 3 ++-
src/fsck/fsck.c | 13 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/README b/README
index e0edd41..8f7a96e 100644
--- a/README
+++ b/README
@@ -129,8 +129,9 @@ REQUIREMENTS:
During runtime, you need the following additional
dependencies:
-util-linux = v2.19 (requires fsck -l, agetty -s),
+util-linux = v2.19 required for agetty -s
v2.21 required for tests in test/
+ v2.25 required for fsck -l
Well, actually it should be util-linux = v2.25 now. -l is always enabled,
so on earlier versions of util-linux the bug remains.
dbus = 1.4.0 (strictly speaking optional, but recommended)
sulogin (from util-linux = 2.22 or sysvinit-tools, optional
but recommended,
required for tests in test/)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index dfe97bc..70a5918 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -320,16 +320,11 @@ int main(int argc, char *argv[]) {
cmdline[i++] = -T;
/*
- * Disable locking which conflict with udev's event
- * ownershipi, until util-linux moves the flock
- * synchronization file which prevents multiple fsck running
- * on the same rotationg media, from the disk device
- * node to a privately owned regular file.
- *
- * https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
- *
- * cmdline[i++] = -l;
+ * Since util-linux v2.25 fsck uses /run/fsck/diskname.lock
files.
+ * The previous versions use flock for the device and conflict
with
+ * udevd, see
https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
*/
+cmdline[i++] = -l;
if (!root_directory)
cmdline[i++] = -M;
regards,
--
Maciej Wereski
Samsung RD Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 09:44 AM, Lennart Poettering wrote: So, I thought myself a couple of times about adding a cron generator upstream As far as I can tell generators serve only one purpose and that is to bridge an gap to allow users of consumers of systemd to migrate to it's native format hence I thought that we would only support one native systemd format hence generator for distro-specific or alternative components ( be it cron, be it ifcfg files etc ) to what we provide would be created and handled by downstream or whomever else requires it. Or to put this differently we will not create. come up with, ship ( and thus support those ) generators but expect consumers of systemd to use systemd and it's format natively in their environment. Alexandre why did you decide to write that generate to begin with? Why not migrate what needs to be migrated to native system timer formats for those relevant component and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hi Martin, If you were to phrase your complaints/questions in terms of technical issues, we could probably have a much more useful debate. What is clear is that the systemd project will not do or change anything merely based on some bystanders gut feeling (which is basically what you have argued from). If you are concerned about portability, go ahead, follow the advice given here, start the port and once you hit issues come back and ask questions. Until someone does this, I think we should consider the whole portability issue closed. Same for modularity, make a fork (in the sense Colin used) of the parts of systemd you want to use in isolation, and come back when you run into problems (there surely will be some, but maybe you can still do the things you want). On Wed, Oct 22, 2014 at 2:13 AM, Martin Steigerwald mar...@lichtvoll.de wrote: I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. When you ignore technical answers, and more than insinuate that we use the same vile practices as Microsoft once did (despite you claiming you don't mean to accuse anyone, the way it comes out is a quite strong accusation), you should expect some less than friendly responses. That said, I think Lennart and Colin both went after your arguments not your person (if you bother reading carefully what they wrote). No. I am concerned about both. The functionality that is stuffed inside PID 1 which is more than 1,3 MiB and also sports user session functionality. And what is coupled inside on project, more or less tight. I already answered the issue with user sessions (and so have others), I'm disappointed that you would bring it up again without seeming to have read our replies. As to the size of PID1, why don't you go and study why this is so? The code is there, there are tools to study the binary. Then hopefully you would either agree that the size is unproblematic, or you would come up with some constructive suggestions/patches to change things. It also increases the test matrix. If logind v300 has to work with libsystemd v300 and all future versions then the testing side of things increases in complexity *massively*. Again this causes problems that translate to time and effort of developers that could better be allocated to building a better overall set of building blocks. I do think that the easiest way to do something is not necessarily the best. If you think there is a better way to do things, go ahead, do it. Vaguely complaining that we should have done this or that differently is not going to change any minds. It is worth noting (again) that the way we manage our repository does not mean that others could not make replacements for parts of systemd, the stuff is very modular. But don't take my word for it, start coding and when you run into problems come back with questions. You are probably not getting out of this discussion what you hoped for (I assume). Sorry about that. If you come back with bug reports, feature requests or patches, you will have a much easier time influencing things. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fsck: re-enable fsck -l
On Wed, 22.10.14 12:22, Maciej Wereski (m.were...@partner.samsung.com) wrote: Well, actually it should be util-linux = v2.25 now. -l is always enabled, so on earlier versions of util-linux the bug remains. Indeed, the dependency on the version is not optional. I changed the file accordingly now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote: On 10/22/2014 09:44 AM, Lennart Poettering wrote: So, I thought myself a couple of times about adding a cron generator upstream As far as I can tell generators serve only one purpose and that is to bridge an gap to allow users of consumers of systemd to migrate to it's native format I don't think this is correct. Take, for example, gpt-auto-generator, efi-boot-generator, hibernate-resume-generator... Also, systemd.mount(5) page states: In general, configuring mount points through /etc/fstab is the preferred approach. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Timers without matching units?
Hi, The systemd.timer(5) manpage states: For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. However, if I need the timer unit just to wake up the machine (e. g. I have a GUI alarm which does everything except configuring the wakealarm), I don't need the timer unit to start something else. Does this sound like a valid reason to make timers' Unit= optional? -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
-) how can I trigger a rerun of the generator generators are rerun if you issue systemctl daemon-reload I already know, this is what our trigger unit does. https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in ... after /var is mounted. this is the point I didn't get right. Would linking cron-update.service in new folder (/usr)/lib/systemd/system/var.mount.wants/ do the trick ? I currently start it from /etc/rc.local it's OK to cover /etc/cron.daily and friends natively with a generator The issue with a generator is there must be some name mangling to ensure that the units have an unique name and unit name like 'cron-root-13.timer' in systemctl list-timers are not user friendly. (we use now cron-$filename-$userid-$pkey.timer ) That is why cron.hourly|daily|weekly ... are provided as static units that can be safely referenced in man pages; this way systemd-cron can even work with an empty /etc/crontab . (and that's easy as the stuff is in /etc), but for the per-user stuff stored in /var it is a better idea to just leave traditional crond around, however, with one trick: only start it as soon as there is a file dropped into the cron subdir in /var. This way, users can use cron as they always did: as long as they did not install any user cronjobs everything works fine without crond started, and then when they install user cronjobs crond magically gets started in the background. The way how users install cronjobs is by invoking crontab -e anyway, and that tool needs to be installed anyway of the crond package, hence installing crond in a way that it is triggered via a crond.path unit should be OK too. Hope that makes sense? That makes sense, but I'm not responsible for packaging 'cron' in Debian; that must also work for sysvinit. I doubt someone will like this halfhalf solution. The crontab shipped with systemd-cron is written in python and can't be setgid like the real crontab; so I asked if vixie-crontab could be shipped in an extra standalone package, but I don't expect much more. - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown, it is not restarted on next reboot. Hmm, could you file a bug about this issue on fdo bz? we should probably cover for this nicely. https://bugs.freedesktop.org/show_bug.cgi?id=85321 Ok it's done, it would benefit native units too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wed, 22.10.14 14:48, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote: On 10/22/2014 09:44 AM, Lennart Poettering wrote: So, I thought myself a couple of times about adding a cron generator upstream As far as I can tell generators serve only one purpose and that is to bridge an gap to allow users of consumers of systemd to migrate to it's native format I don't think this is correct. Take, for example, gpt-auto-generator, efi-boot-generator, hibernate-resume-generator... Correct. It's a way how to convert other runtime or static configuration into native configuration. A primary usecase for that is compat, but other runtime parameters are not like that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On Wed, 22.10.14 13:03, Alexandre Detiste (alexandre.deti...@gmail.com) wrote: -) how can I trigger a rerun of the generator generators are rerun if you issue systemctl daemon-reload I already know, this is what our trigger unit does. https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in ... after /var is mounted. this is the point I didn't get right. Would linking cron-update.service in new folder (/usr)/lib/systemd/system/var.mount.wants/ do the trick ? Well, you can order your reload service After=local-fs.target, which should do the trick. As /var might be subdivided into more submounts you really want to order after local-fs.target, and nothing earlier. I currently start it from /etc/rc.local Yuck! Tha'ts more or less obsolete, and is only supported (in a limited way) for compat. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
On Mon, 15.09.14 13:03, Jan Včelák (jan.vce...@nic.cz) wrote: After=syslog.target is redundant since a long time. Consider removing this. And After=network.target usually doesn't do what one might thing it does and with well written software that listens to rtnl or uses IP_FREEBIND not even necessary... OK. I will remove the syslog. But I will have to keep network.target for now as we support non-Linux systems as well. Adding support for rtnl or IP_FREEBIND would mean duplicating a lot of code... probably. Note that invoking IP_FREEBIND is just a single setsockopt() line... 1.) Is it valid to ship both knot.service and knot@.service file? Sure, but for the sake of simplicity and not confusing the user I would avoid this. I'd just ship the templated version, and then maybe add DefaultInstance=something to the [Install] section in order to make one instance the default one... DefaultInstance sounds great. Will this get backported into systemd-stable at some time? Because I'm looking for a solution for RHEL 7. Please file a bug for RHEL 7 and the right peple will make sure this happens. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
Or to put this differently we will not create. come up with, ship ( and thus support those ) generators but expect consumers of systemd to use systemd and it's format natively in their environment. Alexandre why did you decide to write that generate to begin with? Hi, I've been using the systemd-cron Debian package since 2013/10 to take care of /etc/cron.daily/ I soon noticed it wasn't processing the crontabs , I added a symlink on /etc/cron.weekly/ to emulate the one I cared about and forgot about it. Then in june there was a bug filled to remove the Provides: cron-daemon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 This prompted me to find a better solution. Konstantin Stepanov and Why not migrate what needs to be migrated to native system timer formats for those relevant component and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? The rest ? The generator can now handle all possible cases JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Forwarding to syslog missed XX messages
On Mon, 15.09.14 13:20, Reindl Harald (h.rei...@thelounge.net) wrote: anybody an idea why? Sep 15 13:14:43 localhost systemd-journal[4650]: Forwarding to syslog missed 2 messages. Sep 15 13:15:13 localhost systemd-journal[4650]: Forwarding to syslog missed 196 messages. Sep 15 13:15:44 localhost systemd-journal[4650]: Forwarding to syslog missed 236 messages. Sep 15 13:16:14 localhost systemd-journal[4650]: Forwarding to syslog missed 180 messages. Sep 15 13:16:44 localhost systemd-journal[4650]: Forwarding to syslog missed 323 messages. Sep 15 13:17:15 localhost systemd-journal[4650]: Forwarding to syslog missed 232 messages. Sep 15 13:17:45 localhost systemd-journal[4650]: Forwarding to syslog missed 156 messages. Apparently syslog forwarding is on but your syslog implementation is not capable of keeping up processing the messages quickly enough. Note that by default the number of messages that may be queued in the syslog socket is relatively low, you can bump it via /proc/sys/net/unix/max_dgram_qlen, which would allow more messages to be queued so that your syslog implementation has more time to process the messages. Why precisely your syslog implementation is too slow is something you'd have to debug on the side of theat implementation, we cannot determine this from systemd's side. Note that rsyslog doesn't need the syslog forwarding anymore these days, it picks up the messages directly from the journal. You can thus turn syslog forwarding off with ForwardToSyslog=no in journald.conf. In fact, very recent systemd versions actually changed the default here to off, given the fact that rsyslog doesn't need this any more. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 11:16 AM, Alexandre Detiste wrote: Why not migrate what needs to be migrated to native system timer formats for those relevant component and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? The rest ? The generator can now handle all possible cases You did not answer my question. Why dont you migrate the components depending on the core/baseOS and ship cron jobs to native systemd timer units ( and upstream them in the process ) and leave the rest up to the traditional daemons to handle? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
(sorry mail fired up too soon) Or to put this differently we will not create. come up with, ship ( and thus support those ) generators but expect consumers of systemd to use systemd and it's format natively in their environment. Alexandre why did you decide to write that generate to begin with? Hi, I didn't wrote it. I've been using the systemd-cron Debian package since 2013/10 to take care of /etc/cron.daily/ I soon noticed it wasn't processing the crontabs , I added a symlink on /etc/cron.weekly/ to emulate the one I cared about and forgot about it. Then in june there was a bug filled to remove the Provides: cron-daemon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 This virtual package cron-daemon act as a gear box that lets users switch at their will from one cron daemon to another. It documents a specific interface ( /etc/crontab , /etc/cron.*/ ...) Without this Provides:, systemd-cron would had been useless. This prompted me to find a better solution. Konstantin Stepanov (https://github.com/kstep/systemd-crontab-generator) and Dwayne bent (static units, build infrastructure) kindly agreed to let me merge their respective projects to get a full feature systemd-cron package. Then I went on with development. Why not migrate what needs to be migrated to native system timer formats for those relevant component I have no power over this. and leave the rest be handled by the traditional cron daemons since those two components complement each others shortcomings ? The rest ? The generator can now handle all possible cases; it just doesn't send emails like cron; but that will remain an wontfix I guess. Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] help with systemd socket file for programs in the quagga suite
On Sat, 13.09.14 23:04, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Fri, 12 Sep 2014 19:10:01 +0100 lux-integ lux-in...@btconnect.com пишет: On Friday 12 September 2014 18:28:30 Dave Reisner wrote: I'll stop you here. You can't simply synthesize a socket unit for any arbitrary program that uses a socket (regardless of the address family). Socket units are specific to socket-activated services (which requires code changes in the daemon itself) and per-connection spawning. Based on a perusal of the manpage and source, Zebra appears to be neither of these thanks a lot I too checked the man page I found on the internet and found them to be different to doing /usr/sbin/zebra --help I tend to err on the side of trusting the installed more and so why does this line :- ( -z, --socket Set path of zebra socket ) results from /usr/sbin/zebra --help ( and indeed all the programs in the quagga suite ? ) Is it in error ? May be not, but socket activated services in systemd receive socket on stdin/stdout, not as argument. That's not entirely true. In inetd-style activation the sockets are passed as stdin/stdout. On systemd-style activation they are passed as sockets 3,4,5,..., i.e. the ones immediately following stdin/stderr/stdout. But anyway, the gist of it is true: socket activation requires proper support for it in the daemons. And just being able to set the socket path is not enough. Without patching zebra to support proper systemd-style socket activation (or even inetd-style as we support either) this is not available. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev database backwards compatibility guarantees
On Thu, 11.09.14 10:49, Alexander Larsson (al...@redhat.com) wrote: Hi, I'm looking at creating a runtime/app thing for Gnome in the style of: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html However, I noticed that some core dependencies like mesa uses libudev. And in fact, needs user-set additional info not in sysfs. In particular, it reads ID_PATH_TAG on render device nodes to pick what GPU to use in multi-gpu situations (PRIME): http://lists.freedesktop.org/archives/mesa-dev/2014-June/061798.html It seems to me that this means I need the host /run/udev inside the application. I know that the udev database format changed in the past, but can I rely on it being stable in the future, even if the host udev is rev:ed to a later version than what is in the application runtime? Of course, there is also the question of /dev and /sys management in sandboxed apps in general. Clearly any modern app will require some real devices for things like direct rendering. But it would be ideal to not expose everything. How do we see this working? Good question. Ideally we wouldn't expose any raw devices to apps, but I figure this is not going to suffice (already with video4linux and things). Kay, any ideas on the udev database stability? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unprivileged poweroff
On Wed, 10.09.14 16:03, Michal Witanowski (m.witanow...@samsung.com) wrote: Hi, I was wondering if there is a possibility to call systemctl poweroff as non-root user in this scenario: 1.I have no PolicyKit on my system, so I get access denied. 2. Calling with -f parameter also fails, with Must be root error. 3. I'd like to avoid using sudo. Theoretically there is no other way, am I right? But what about CAP_SYS_BOOT? Does the systemctl shouldn't verify if this capability is set and allow non-root user to shut down the system? When used with kdbus we actually do check for that client-side capability. THis is not available on dbus1 however, since we cannot determine the capability racefreely and thus safely. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] transforming Iptables bash script to systemd service file -help
On 21/10/14 20:30, Lennart Poettering wrote: But in cases like the iptables tool (which is written in a style that kinda requires the usage of shell scripts to invoke it, since it is more a programming language and is seldom called just once at boot) If your ruleset is static (e.g. does not depend on the local IP address), it's very close to not needing a shell: all it would need is for systemd to support StandardInput=/a/file/path, or for iptables-restore to support --file /a/file/path, or something similar. iptables-save | sudo tee /etc/my-firewall ip6tables-save | sudo tee /etc/my-firewall6 ExecStart=/bin/sh -c 'iptables-restore /etc/my-firewall' ExecStart=/bin/sh -c 'ip6tables-restore /etc/my-firewall6' S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
On 21/10/14 20:25, Lennart Poettering wrote: Ah, well, at least they should make the lib64 thing arch dependent. Multiarch means that whichever architecture systemd happens to have been compiled for, /lib64 might exist. If it does, it's a system library directory. (Consider an i386 or armhf systemd on a mixed i386 + amd64 or armhf + arm64 system, for instance. On a developer's system, you might even have mixed i386 + amd64 + armhf + s390x or something.) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
Why not migrate what needs to be migrated to native system timer formats This would be the responsability of each individual package manager; after some policy would have mandated it and it's too late before the release freeze. Debian only ships exaclty one timer now: systemd-tmpfiles-clean.timer This may evolve next year after Jessie is released. I would then adapt systemd-cron not to process /etc/cron.d/$(package) if (/usr)/lib/systemd/system/$(package).timer exists . I'll asks what the others downstreams (Arch...) think of it; if it might already be implented that way. Alexandre ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unprivileged poweroff
On 22/10/14 12:37, Lennart Poettering wrote: When used with kdbus we actually do check for that client-side capability. THis is not available on dbus1 however, since we cannot determine the capability racefreely and thus safely ... because the kernel doesn't give us that ability on Unix sockets. See https://bugs.freedesktop.org/show_bug.cgi?id=83499 for more on what Unix socket semantics *do* allow socket-based D-Bus to rely on. A solution requires new kernel features: either something like kdbus, or a way for a Unix socket client to prove to the server that it had a particular capability either at the time the socket opened (a new SCM_CAPABILITIES analogous to SCM_CREDS?) or at the time that a particular message was queued (subtle, probably best avoided). S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timers without matching units?
On Wed, Oct 22, 2014 at 02:50:13PM +0400, Ivan Shapovalov wrote: Hi, The systemd.timer(5) manpage states: For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. However, if I need the timer unit just to wake up the machine (e. g. I have a GUI alarm which does everything except configuring the wakealarm), I don't need the timer unit to start something else. Does this sound like a valid reason to make timers' Unit= optional? Hi, yeah, when timers were implemented, this wasn't possible, but now it makes sense and would be useful. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: Add mapping for special keys on compaq ku 0133 keyboards
The compaq ku 0133 keyboard has 8 special keys at the top: http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg 3 of these use standard HID usage codes from the consumer page, the 5 others use part of the reserved 0x07 - 0x1f range. This commit adds mapping for this keyboard for these reserved codes, making the other 5 keys work. Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Hans de Goede hdego...@redhat.com --- hwdb/60-keyboard.hwdb | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb index 59f467b..06caba9 100644 --- a/hwdb/60-keyboard.hwdb +++ b/hwdb/60-keyboard.hwdb @@ -181,6 +181,13 @@ keyboard:dmi:bvn*:bvr*:bd*:svnCompaq*:pn*Evo*N*:pvr* KEYBOARD_KEY_9e=email KEYBOARD_KEY_9f=homepage +keyboard:usb:v049Fp0051d*dc*dsc*dp*ic*isc*ip*in01* + KEYBOARD_KEY_0c0011=presentation + KEYBOARD_KEY_0c0012=addressbook + KEYBOARD_KEY_0c0013=info + KEYBOARD_KEY_0c0014=prog1 + KEYBOARD_KEY_0c0015=messenger + ### # Dell ### -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 11:26 AM, Alexandre Detiste wrote: it just doesn't send emails like cron; but that will remain an wontfix I guess. Systemd itself does not send email but you can configure the timer units ( the service part ) to do so when they fail via OnFailure=trigger custom email script but you have to do so individually per timer's service units ( you cannot define that Onfailure= behaviour default for all units or just timer units ) . That takes care of failed starting timer jobs which is how I'm accustom to receive notifications from cron ( there seems to be split in practical sense of this as in those that only want to get email when things fail to run and those that always want to get email regardless if they failed to run or not ) The always part you handle in the script being run or via another Exec* line I would recommend you to label the timer in the journal as well for quick searching only for relevant timer info ExecStart=/bin/systemd-cat -t MY TIMER JOB LABEL /usr/bin/$FOO whatever Then run ( or script for email ) something like journalctl SYSLOG_IDENTIFIER=MY TIMER JOB LABEL Which will output you just the info you need. Arguable we should always label timer units in the journal which in turn would take care of that usability bug where users complain about timers being to noisy in log but Lennart can comment on that if he considers that viable solution for that bug. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Hello Martin, Firstly, I apologise if you took what I said as a personal insult. It was not my intention to do so (and I did try to make that explicitly clear in a footnote). I will certainly admit that some of my wording was more directed than I had intended. This is something I would normally edit out and soften on a read over, but time constraints didn't allow me that luxury. That said, I do stand by my general comments. I will attempt a briefer reply below [Spoiler: I failed!] Martin Steigerwald wrote on 22/10/14 01:13: I received this twice on this mailing list. Once from Lennart (being a dick now) and now from you calling me a troll. For the avoidance of doubt, I didn't directly call you a troll. I was trying to point out that even well intentioned discussions, like yours, cat at times become indistinguishable from a trolling discussion. Not deliberate (which trolling is), but because no matter what reply is sent, the participants will not be satisfied with the answers and will continue the discussion. It would appear that this discussion has reached that stage. Over various points, there have been answers given and corrections made, and yet still no acceptance is really given to those decisions - it's at a time like this where further discussion is counter productive to your goal and just serves to alienate people rather than get them any closer to sharing your opinion. I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment. I disagree that this is a hostile environment. It's just that people here will (by definition) generally just disagree with you. I apologise if my reply was worded in an overly-hostile way (I'll try better in this email), but ultimately you're going to get replies here that will generally disagree with your stance. Thats rather much. Really rather much. Way more than traditonal sysvinit covered. This is because traditional sysvinit covered PID 1 and performing it's job (if you consider e.g. killall5 and friends). You seem to be conflating systemd as PID 1 and systemd as a project. These are two completely different things. No. I am concerned about both. The functionality that is stuffed inside PID 1 which is more than 1,3 MiB and also sports user session functionality. You use the term stuffed which is preloaded with negativity. Your wording here would be better if you'd used the more neutral term included in rather than stuffed inside. By using this phrasing you're already building up a barrier and will be polarising upstream developers and will be reflected in their replies. As another technical correction, PID 1 does NOT sport user session functionality. It sports a general resource management concept (scopes and slices) that is a userspace abstraction of the kernel cgroups concept used for resource management. This is seen as core functionality as it's PID1's job to fundamentally fork off other processes. I don't think this is a point of contention. Some people have argued that resource management should NOT be PID1's job, and it should handled by a separate daemon. The argument thus far from the systemd side is that doing this out of process would create a chicken and egg problem. It's PID1's job to fork of processes and configure their resources, but the resource manager processes' forking would have to be special cased as there would be no resource manager available when it was forked. If this sub component fails, then PID1 fails too. It's so tightly coupled that the arguments for doing it out of process are simply not sufficiently compelling, so this special casing is not something systemd developers are comfortable with technically due to both startup and runtime requirements. The user session functionality you speak of is implemented outside of PID1 in logind. Because it also needs to manager resources, it has to work with the resource manager which, as described above, is PID1 in systemd. If other init systems want to do this differently they are welcome to do so. An alternative would be to make the utility functions API stable and export the shared library publicly and give API guarantees, but that puts a lot of pressure and it's a difficult thing to provide and it has long term maintenance overhead. This is something that *costs*. It costs in time/man hours and therefore it carries real overheads. Doing this for the convenience of splitting things out is simply not worth it - especially so as the main people working on these things are the same people. I don´t think it would be just for the convenience of splitting things. It would also be to address the concerns I summarized and that have been made elsewhere. You may heard these concerns often, you may not agree to them. Yet, if you say later that some of these concerns were made 5 years ago already… If those concerns are still there… either… its due to Debian adopting
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
On 10/22/2014 11:51 AM, Alexandre Detiste wrote: Why not migrate what needs to be migrated to native system timer formats This would be the responsability of each individual package manager; after some policy would have mandated it and it's too late before the release freeze. Debian only ships exaclty one timer now: systemd-tmpfiles-clean.timer This may evolve next year after Jessie is released. I would then adapt systemd-cron not to process/etc/cron.d/$(package) if (/usr)/lib/systemd/system/$(package).timer exists . I'll asks what the others downstreams (Arch...) think of it; if it might already be implented that way. In Fedora we had 100 components that shipped cron jobs of some short, out of those, 50 components depend on systemd and then there was further filter due to things not being legacy and no longer used or simply not beneficial to be migrated ( It would just cause administrative nuance in doing so and those 50 jobs or so would have been less for every distro to worry about but I got fedup with how things where handled so I abandoned that feature of mine after correcting the dependence of those 50 components that would definitely not be migrated ) so as I say you should easily be able to migrate that stuff since I dont expect Debian shipping much more than that and well before Jessie gets released, especially now since Ian seems to be keen on misusing the GR process ( and delay the release even further as an result of that ) to hinder the adoption of systemd in the project. Dont hesitate to be in contact if you need help with that since these kind of migration/integration work in distributions with systemd is beneficial to *all* so it does not take many resources from systemd community from every distro to lend a hand and help with that migration. It just requires a bit of organizing and packagers ( in all distros ) to be on stand by when that happens and it will be quickly over. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 21/26] hashmap: rewrite the implementation
On 10/20/2014 08:42 PM, Lennart Poettering wrote:
On Thu, 16.10.14 09:50, Michal Schmidt (mschm...@redhat.com) wrote:
+/* Fields that all hashmap/set types must have */
+struct HashmapBase {
+const struct hash_ops *hash_ops; /* hash and compare ops to use */
+
+union _packed_ {
+struct indirect_storage indirect; /* if has_indirect */
+struct direct_storage direct; /* if !has_indirect */
+};
+
+uint8_t type:2; /* HASHMAP_TYPE_* */
Should probably be a named enum (see above)
+uint8_t has_indirect:1; /* whether indirect storage is
used */
Should really be a bool, no?
Interestingly, changing this confuses pahole greatly.
With all the three bitfields declared as uint8_t pahole showed the struct
layout sanely:
struct HashmapBase {
const struct hash_ops * hash_ops; /* 0 8 */
union {
struct indirect_storage indirect;/* 39 */
struct direct_storage direct;/* 39 */
}; /* 839 */
uint8_ttype:2; /*47: 6 1 */
uint8_thas_indirect:1; /*47: 5 1 */
uint8_tn_direct_entries:3; /*47: 2 1 */
/* size: 48, cachelines: 1, members: 5 */
/* bit_padding: 2 bits */
/* last cacheline: 48 bytes */
};
With type changed to a named enum, has_indirect to bool,
and n_direct_entries to unsigned, pahole says:
base_type__name_to_size: base_type __unknown__
base_type__name_to_size: base_type __unknown__
die__process_inline_expansion: tag not supported (INVALID)!
base_type__name_to_size: base_type __unknown__
...
struct HashmapBase {
const struct hash_ops * hash_ops; /* 0 8 */
union {
struct indirect_storage indirect;/* 39 */
struct direct_storage direct;/* 39 */
}; /* 839 */
/* Bitfield combined with next fields */
enum HashmapType type:2; /*44: 6 4 */
/* XXX 22 bits hole, try to pack */
/* Bitfield combined with next fields */
_Bool has_indirect:1; /*47: 5 1 */
/* Bitfield combined with previous fields */
__unknown__n_direct_entries:3; /*44: 2 0 */
/* size: 48, cachelines: 1, members: 5 */
/* bit holes: 1, sum bit holes: 22 bits */
/* padding: 4 */
/* bit_padding: 252 bits */
/* last cacheline: 48 bytes */
/* BRAIN FART ALERT! 48 != 48 + 0(holes), diff = 0 */
};
But as far as I can tell, generated code looks OK and it still runs
fine, so I won't worry about it.
Michal
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Colin Guthrie wrote in message m1rf8b$ojg$1...@ger.gmane.org: I want to rely on systemd --user to handle PulseAudio's activation (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE might start up their own session stuff and spawn some PA consuming process before systemd --user has reached it's sockets.target and is thus ready and listening on PA's native socket. Interesting, does PA now support socket activation? Mine (pulseaudio 5.0) does not seem to support it. Doesn't seem to be a problem on my machine here (it's working really nicely actually!) but figured I should ask here too. I have been using systemd user sessions for a long time, and it works really well, except for this policykit bug: https://bugs.freedesktop.org/show_bug.cgi?id=67728 For instance since I start dbus under the user session, the dbus activated services also run inside it: CGroup: /user.slice/user-1000.slice/user@1000.service ├─615 /usr/lib/systemd/systemd --user ├─616 (sd-pam) ├─dbus.service │ ├─ 702 /usr/bin/dbus-daemon --session --address=systemd: --nofork │ ├─ 835 /usr/lib/gvfs/gvfs-udisks2-volume-monitor So udisks2 fails to mount my usb keys because it is not under an active session (since it is not launche from my active session) so it gets denied by policykit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?
Lennart Poettering wrote in message 20141020173828.GA4509@gardel-login:
They should probably adopt socket activation anyway, otherwise they'd
be quite annoying on multi-user systems if lingering is used.
I am brainstorming here, but would it make sense to add hooks to logind
when a session is started/closed (both system hooks and user hooks)?
For instance when I log into X, my .xprofile contains
systemctl --no-block --user start xsession@${DISPLAY}.target
to start my user services.
I need to make sure that everyway I have to log into X (with a *DM, with
startx, with xinit) I somehow source .xprofile.
Stopping the started services also involve some contorsion. When I quit X
most of the services started by xsession@$DISPLAY fails because X is no
longer available, and I don't want systemd to try to restart them in this
case. So I need to stop these services whenever X exits.
So inside xsession@.target, I launch xwatch@.service:
[Unit]
Description=Watch for X on display %I
BindsTo=xsession@.target
[Service]
Environment=DISPLAY=%I
SyslogIdentifier=xwatch@%I
ExecStart=/bin/sh -c 'exec %h/mine/script/services/xwatch %I'
Nice=19
[Install]
WantedBy=xsession@.target
with $ cat ~/script/services/xwatch
#!/bin/sh
xprop -spy -root XFree86_VT
systemctl --user stop xsession@$1.target
So whenever my X session stops, xwatch will stop xsession@$DISPLAY.target,
and thus stop all services files that I configured to be PartOf
xsession@.target. For instance xcompmgr@.service:
[Unit]
Description=xcompmgr on display %I
PartOf=xsession@.target
ConditionFileIsExecutable=/usr/bin/xcompmgr
[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/xcompmgr
Restart=on-failure
RestartSec=3
StandardOutput=null
[Install]
WantedBy=xsession@.target
Also=xwatch@.service
It works really well, I can even log onto different X sessions and have the
corresponding services launched into the different $DISPLAY, but having
some close hooks in logind would help getting rid of xwatch.service.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-journald watchdog timeout
On one boot I got a watchdog timeout on systemd-journald: Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M (m Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var is 2 Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not rea Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40 Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: authenticated Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 (capab Oct 21 20:08:25 feanor kernel: wlan0: associated Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link become Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to Persis Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and Directories Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization... Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System Boot/Shutdo Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System Boot/Shutdow Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization. Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization. Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization. Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket. Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0. Oct 21 20:08:25 feanor systemd-networkd[518]: lo : gained carrier Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd[1]: Started Network Service. Oct 21 20:08:25 feanor systemd[1]: Starting Network. Oct 21 20:08:25 feanor systemd[1]: Reached target Network. Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution... Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M (m Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout (li Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2. Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. Te Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout (l Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm timed o Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process exited Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered failed Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff time, Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service... Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Journal Service. As you can see at 20:08:20 things appears to look fine, but everything get stuck during 3 minutes until there is a watchdog timeout for the journal and it gets restarted. Then the boot finished without any further problem. The next time everything worked fine, so I am wondering what could have happened? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix a couple of typos
--- src/systemd/sd-network.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/systemd/sd-network.h b/src/systemd/sd-network.h index 203a2a6a47..bb69940930 100644 --- a/src/systemd/sd-network.h +++ b/src/systemd/sd-network.h @@ -61,7 +61,7 @@ int sd_network_get_operational_state(char **state); int sd_network_get_dns(char ***dns); /* Get NTP entries for all links. These are domain names or string - * reperesentations of IP addresses */ + * representations of IP addresses */ int sd_network_get_ntp(char ***ntp); /* Get the search/routing domains for all links. */ @@ -80,7 +80,7 @@ int sd_network_get_domains(char ***domains); */ int sd_network_link_get_setup_state(int ifindex, char **state); -/* Get operatinal state from ifindex. +/* Get operational state from ifindex. * Possible states: * off: the device is powered down * no-carrier: the device is powered up, but it does not yet have a carrier @@ -101,13 +101,14 @@ int sd_network_link_get_network_file(int ifindex, char **filename); int sd_network_link_get_dns(int ifindex, char ***addr); /* Get NTP entries for a given link. These are domain names or string - * reperesentations of IP addresses */ + * representations of IP addresses */ int sd_network_link_get_ntp(int ifindex, char ***addr); /* Indicates whether or not LLMNR should be enabled for the link * Possible levels of support: yes, no, resolve * Possible return codes: - * -ENODATA: networkd is not aware of the link*/ + * -ENODATA: networkd is not aware of the link + */ int sd_network_link_get_llmnr(int ifindex, char **llmnr); /* Get the DNS domain names for a given link. */ -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix a couple of typos
On Wed, 22.10.14 16:00, Torstein Husebø (torst...@huseboe.net) wrote: Thanks! Applied! --- src/systemd/sd-network.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/systemd/sd-network.h b/src/systemd/sd-network.h index 203a2a6a47..bb69940930 100644 --- a/src/systemd/sd-network.h +++ b/src/systemd/sd-network.h @@ -61,7 +61,7 @@ int sd_network_get_operational_state(char **state); int sd_network_get_dns(char ***dns); /* Get NTP entries for all links. These are domain names or string - * reperesentations of IP addresses */ + * representations of IP addresses */ int sd_network_get_ntp(char ***ntp); /* Get the search/routing domains for all links. */ @@ -80,7 +80,7 @@ int sd_network_get_domains(char ***domains); */ int sd_network_link_get_setup_state(int ifindex, char **state); -/* Get operatinal state from ifindex. +/* Get operational state from ifindex. * Possible states: * off: the device is powered down * no-carrier: the device is powered up, but it does not yet have a carrier @@ -101,13 +101,14 @@ int sd_network_link_get_network_file(int ifindex, char **filename); int sd_network_link_get_dns(int ifindex, char ***addr); /* Get NTP entries for a given link. These are domain names or string - * reperesentations of IP addresses */ + * representations of IP addresses */ int sd_network_link_get_ntp(int ifindex, char ***addr); /* Indicates whether or not LLMNR should be enabled for the link * Possible levels of support: yes, no, resolve * Possible return codes: - * -ENODATA: networkd is not aware of the link*/ + * -ENODATA: networkd is not aware of the link + */ int sd_network_link_get_llmnr(int ifindex, char **llmnr); /* Get the DNS domain names for a given link. */ -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Stop Job for User Manager
Hi all, I'm running into an annoying issue. I use systemd 216 on an Arch box, and systemd 208 on a Fedora box; the issue exists on both. Logins are handled through getty; there is no desktop manager involved. Occasionally, on shutdown, I get a 90 second hold while waiting for a 'Stop Job for User 1000'. Logging out before shutdown reduces, but does not eliminate, the occurrence. The issue is documented in far more detail at https://bugs.freedesktop.org/show_bug.cgi?id=70593 ; I'm the Chris in the comments (starting with #15). I was led here for assistance with the following questions related to this issue: What, exactly, is this stop job? What's it waiting for? Why 90 seconds? Can this duration be changed? Where should I start bughunting here? The bugzilla hasn't had much activity from devs recently; the last official-looking comments deal with systemd-208, last December. I'm not even sure this is actually a 'bug'. For all I know, it's actually, legitimately, waiting for something. The problem is, I have no idea - and don't know how to find out - what it thinks it's waiting for. Any assistance to that end would also be greatly appreciated. Thanks! Chris Bell Ph.D. Student University of South Florida College of Engineering Department of Computer Science and Engineering NarMOS Research Team ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Stop Job for User Manager
Am 22.10.2014 um 16:49 schrieb Chris Bell: I'm running into an annoying issue. I use systemd 216 on an Arch box, and systemd 208 on a Fedora box; the issue exists on both. Logins are handled through getty; there is no desktop manager involved. Occasionally, on shutdown, I get a 90 second hold while waiting for a 'Stop Job for User 1000'. Logging out before shutdown reduces, but does not eliminate, the occurrence. The issue is documented in far more detail at https://bugs.freedesktop.org/show_bug.cgi?id=70593 ; I'm the Chris in the comments (starting with #15). I was led here for assistance with the following questions related to this issue: What, exactly, is this stop job? What's it waiting for? Why 90 seconds? Can this duration be changed? Where should I start bughunting here? there are more rough edges in that context that below is a system-session triggered by SSHD with openssh-chroot in combination with pam-mysql - obviously the user-manager inherits the sshd-chroot and so can't call the kill command [root@sftp:~]$ ps aux | grep 29657 29657 0.0 0.4 46580 4288 ?Ss Okt17 0:00 /usr/lib/systemd/systemd --user root 31532 0.0 0.2 112684 2160 pts/0S+ 16:51 0:00 /usr/bin/grep --color 29657 [root@sftp:~]$ kill 29657 [root@sftp:~]$ cat messages Oct 22 16:51:48 sftp systemd: Failed at step CHDIR spawning /usr/bin/kill: No such file or directory Oct 22 16:51:48 sftp systemd: systemd-exit.service: main process exited, code=exited, status=200/CHDIR Oct 22 16:51:48 sftp systemd: Failed to start Exit the Session. Oct 22 16:51:48 sftp systemd: Dependency failed for Exit the Session. Oct 22 16:51:48 sftp systemd: Oct 22 16:51:48 sftp systemd: Unit systemd-exit.service entered failed state. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald watchdog timeout
On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: On one boot I got a watchdog timeout on systemd-journald: Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M (m Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var is 2 Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not rea Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40 Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: authenticated Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 (capab Oct 21 20:08:25 feanor kernel: wlan0: associated Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link become Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to Persis Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and Directories Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization... Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System Boot/Shutdo Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System Boot/Shutdow Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization. Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization. Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization. Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket. Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0. Oct 21 20:08:25 feanor systemd-networkd[518]: lo : gained carrier Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd[1]: Started Network Service. Oct 21 20:08:25 feanor systemd[1]: Starting Network. Oct 21 20:08:25 feanor systemd[1]: Reached target Network. Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution... Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M (m Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout (li Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2. Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. Te Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout (l Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm timed o Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process exited Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered failed Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff time, Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service... Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Journal Service. As you can see at 20:08:20 things appears to look fine, but everything get stuck during 3 minutes until there is a watchdog timeout for the journal and it gets restarted. Then the boot finished without any further problem. The next time everything worked fine, so I am wondering what could have happened? That's difficult to say just from these logs. Can you reliably reproduce this? If so, can you attach strace to journald before this happens and see what it is doing? What I find interesting is that after the 3min pause suddenly the network driver allocates irq 55. This kinda makes me wonder if this might be a kernel/driver problem of some kind, where for some reason userspace (and hence journald) don't get scheduled? What distro/version/arch is this? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timers without matching units?
On Wed, 22.10.14 14:05, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Oct 22, 2014 at 02:50:13PM +0400, Ivan Shapovalov wrote: Hi, The systemd.timer(5) manpage states: For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. However, if I need the timer unit just to wake up the machine (e. g. I have a GUI alarm which does everything except configuring the wakealarm), I don't need the timer unit to start something else. Does this sound like a valid reason to make timers' Unit= optional? Hi, yeah, when timers were implemented, this wasn't possible, but now it makes sense and would be useful. I added this to the TODO list for now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] New systemd bindings for GLib
On Wed, 10.09.14 09:12, Tristan Brindle (tcbrin...@gmail.com) wrote: Hi all, I needed to use systemd for a new project, and I was surprised to find that there was no nice client library available wrapping the D-Bus API in GObjects (or at least, if one exists, Google couldn’t find it). So I wrote one myself. The code is available at https://github.com/tcbrindle/systemd-glib It uses Vala for code generation rather than gdbus-codegen because honestly I just like Vala’s generated C API better, but my original version using gdbus-codegen is available in the gdbus branch of the above repo if people prefer that. This is all new code and hasn’t been heavily tested, so if there are any bugs please let me know. Thanks for doing this. I have now added a link to this from the Related Packages part of the systemd homepage: http://www.freedesktop.org/wiki/Software/systemd (at the bottom) Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: Add mapping for special keys on compaq ku 0133 keyboards
On Wed, 22.10.14 14:09, Hans de Goede (hdego...@redhat.com) wrote: The compaq ku 0133 keyboard has 8 special keys at the top: http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg 3 of these use standard HID usage codes from the consumer page, the 5 others use part of the reserved 0x07 - 0x1f range. This commit adds mapping for this keyboard for these reserved codes, making the other 5 keys work. Thanks! Applied! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Forwarding to syslog missed XX messages
On Wed, 22.10.14 14:28, Reindl Harald (h.rei...@thelounge.net) wrote: Why precisely your syslog implementation is too slow is something you'd have to debug on the side of theat implementation, we cannot determine this from systemd's side. Note that rsyslog doesn't need the syslog forwarding anymore these days, it picks up the messages directly from the journal. You can thus turn syslog forwarding off with ForwardToSyslog=no in journald.conf. In fact, very recent systemd versions actually changed the default here to off, given the fact that rsyslog doesn't need this any more that is in fact the case on all of my machines so why does systemd-journal complain about missed forwarding at all? We increase the counter each time we try to send something to the other syslogd and get EAGAIN back, which is an indication tht the socket buffer is full at the moment. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timers without matching units?
El 22/10/14 a las #4, Ivan Shapovalov escribió: Hi, The systemd.timer(5) manpage states: For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. I guess for now you can create a dummy unit that executes /bin/true to workaround this limitation. ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] runtime configurable timer
On Thu, 11.09.14 17:45, WaLyong Cho (walyong@samsung.com) wrote: (I will happy there is already similar method already exist.) systemd already has similar functionality systemd-run but that is only for scope or service unit. I think that is useful run a service without unit file on permanent storage. As a similar method, is it possible to generate or configure timer unit on runtime? Currently not, but this would be certainly useful. Honestly, now, I need a runtime configurable timer interface. If systemd has this then I can reduce one of daemon. Currently pid1's StartTransientUnit() bus call already takes four arguments arguments: 1. a name for the unit to create and start 2. a mode how to start it 3. an array with properties for the unit 4. an array conisting of unit names plus a property array each, which is supposed to contain additional unit definitions which can be referenced by the main unit you are creating. Now, while the method takes that fourth argument it is actually just ignored. The plan was (and still is) to beef this up and make it useful for installing both a transient service and a timer unit at once. More specifically: to implement something that would work like at a client would invoke StartTransientUnit(), create the timer unit as primary unit, and then include the service definition for the service to eventually start in the second array. I would love to see this getting fully implemented now, it would be great if systemd-run would get an --on-calendar= switch or so, which makes use of this behaviour. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] runtime configurable timer
On Wed, 17.09.14 16:20, WaLyong Cho (walyong@samsung.com) wrote: Before start working it, we need some of discussion about how make the transient unit. I think we have two options. One is, as you said, make systemd-at and the other is add option to systemd-run. (e.g. --OnCalendar=, --OnActiveSec= or so) I'd vote for the latter, and call the options --on-calendar= and --on-active-sec= and so on. (CameCase as command line arguments is not really that common) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald watchdog timeout
From Lennart Poettering, Wed 22 Oct 2014 at 16:59:09 (+0200) : On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: That's difficult to say just from these logs. Yeah that was what I feared. Can you reliably reproduce this? If so, can you attach strace to journald before this happens and see what it is doing? Un(?)fortunately no. What I find interesting is that after the 3min pause suddenly the network driver allocates irq 55. This kinda makes me wonder if this might be a kernel/driver problem of some kind, where for some reason userspace (and hence journald) don't get scheduled? I am not sure this is related, on a non troublesome boot I also have similar lines: Oct 22 09:12:39 feanor systemd[1]: Started Network Service. Oct 22 09:12:39 feanor systemd[1]: Starting Network. Oct 22 09:12:39 feanor systemd[1]: Reached target Network. Oct 22 09:12:39 feanor systemd[1]: Starting Network Name Resolution... Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 22 09:12:39 feanor systemd-resolved[526]: Using system hostname 'feanor'. Oct 22 09:12:39 feanor systemd[1]: Started Network Name Resolution. Oct 22 09:12:39 feanor systemd[1]: Starting Multi-User System. Oct 22 09:12:39 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 22 09:12:39 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read Oct 22 09:12:39 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40 What distro/version/arch is this? Up to date archlinux, kernel 3.16.4-1-ARCH x86_64, systemd 216-3. -- Damien Robert http://www.normalesup.org/~robert/pro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] dbus: introduce new method call NewTransientUnit
On Tue, 07.10.14 14:20, WaLyong Cho (walyong@samsung.com) wrote: It similar with StartTransientUnit but the NewTransientUnit does not start the unit immediately. Newly generated transient unit can be activated by systemctl start. So far units are immediately GC'ed when they aren't running or otherwise referenced anymore. That's really a behaviour I'd like to retain. Hence, let's just make the final argument of StartTransientUnit() do something useful, so that there's one primary unit to create and start, plus any number of additional units that can be referenced by the primary one, but are not started immediately. (see other mail for details) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] run: introduce timer support option
On Tue, 07.10.14 14:20, WaLyong Cho (walyong@samsung.com) wrote:
If systemd-run is called with timer option, then systemd-run call
NewTransientUnit with service unit. And also call StartTransientUnit
with timer unit which has same name with the service. So actually, two
method call is coming and two transient unit is generated. One is
service and the other is timer.
Supported timer options are --after=, --after-boot=, --after-startup=,
--after-active=, --after-inactive=, --calendar=, --accuracy= and
--wake-system. Each option corresponding with OnActiveSec=,
OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=,
AccuracySec= and AccuracySec= of timer respectively.
Hmm, I'd really like to stay close to the underlying props here in
naming, and call the options --on-boot=, --on-inactive= and so on
(the -sec suffix we can probably drop).
The AccuracySec= and WakeSystem= stuff I think we don't need to cover
with a command line argument of its own, we can cover that with
--property=.
+static bool with_timer = false;
+static char *arg_after = NULL;
+static char *arg_after_boot = NULL;
+static char *arg_after_startup = NULL;
+static char *arg_after_active = NULL;
+static char *arg_after_inactive = NULL;
+static char *arg_calendar = NULL;
+static char *arg_accuracy = NULL;
+static bool arg_wake_system = false;
I'd just do one arg_on_timer usec_t variable to store most of the
--on-xyz= values in. Plus one arg_on_calendar to hold the calendar
expression. This should be much simpler than keeping one variable
around for each.
+case ARG_AFTER:
+r = parse_sec(optarg, u);
+if (r 0) {
+log_error(Failed to parse timer value: %s,
optarg);
+return r;
+}
+arg_after = optarg;
+with_timer = true;
+break;
This stuff really should not store the string, but the parsed value.
(I'll leave the rest unreviewed for now, please rework this first to
make use of the fourth StartTransientUnit() bus call argument!)
Thanks,
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] [use after free] Avoid using m-kdbus after freeing it.
On Wed, 10.09.14 12:20, philippedesw...@gmail.com (philippedesw...@gmail.com)
wrote:
From: Philippe De Swert philippedesw...@gmail.com
m-kdbus could be freed before it is released. Changing the
order fixes the issue.
David applied this now, but actually, just for the sakes of archives,
this is a false positive. The KDBUS_CMD_FREE ioctl and the free() are
never invoked at the same time. Either the message is stored in a
kdbus buffer in which case we issue KDUS_CMD_FREE, or it's stored in a
malloc()ed area, in which case we call free().
This commit hence was entirely bogus, but of course doesn't matter.
Found with Coverity. Fixes: CID#1237798
Signed-off-by: Philippe De Swert philippedesw...@gmail.com
---
src/libsystemd/sd-bus/bus-message.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-message.c
b/src/libsystemd/sd-bus/bus-message.c
index d00455a..bfb14fc 100644
--- a/src/libsystemd/sd-bus/bus-message.c
+++ b/src/libsystemd/sd-bus/bus-message.c
@@ -127,9 +127,6 @@ static void message_free(sd_bus_message *m) {
message_reset_parts(m);
-if (m-free_kdbus)
-free(m-kdbus);
-
if (m-release_kdbus) {
uint64_t off;
@@ -137,6 +134,9 @@ static void message_free(sd_bus_message *m) {
ioctl(m-bus-input_fd, KDBUS_CMD_FREE, off);
}
+if (m-free_kdbus)
+free(m-kdbus);
+
sd_bus_unref(m-bus);
if (m-free_fds) {
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/5] Coverity fixes
On Wed, 10.09.14 13:51, Philippe De Swert (philippedesw...@gmail.com) wrote: Ok so it has been taken into use and can actually somehow be considered part of the coding style? The mail was still speculating about it and I could not quickly see a confirmation of this. Yes, it is the coding style now, also see the CODING_STYLE text file in the git repo. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Lennart Poettering lenn...@poettering.net We are always interested in technical feedback. I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting). Here is an example of what I consider a social/political problem stemming from technical decisions: Say you are a housing developer. After many calculations, you have decided that the best design for housing is a cube. It has a high volume-to-surface-area ratio, which allows it to house the most people with minimal heating/cooling loss to the outside environment. It is easier to build than a sphere (which would have a higher volume-to-surface-area ratio). To further maximize efficiency, each building will be a multi-unit dwelling. Interior units will have very little heat transfer to the outside, because the surrounding units help insulate them. However, I don't want to share walls with another family, so I decide to buy a standalone house even though it is technically less efficient. That's my choice, and choice is great, right. But then I try to buy an air conditioner (cooling unit), and I find out that it is only compatible with your multi-dwelling cube house. Why? Because you have integrated some wonderful sensor technology into your buildings that the air conditioner manufacturer wants to take advantage of. So now I have a choice: live in the house of my choice with no air conditioner, or live in your building with an air conditioner. If you had designed your sensor system to be a separate piece, rather than integrating it directly into the building, I could buy any house I want and still have an air conditioner. But because of your design choices (as well as the choices of the air conditioning manufacturer), my choice of housing is limited or even eliminated. Tightly integrating the sensor system into the building may have been the technically best solution, but it has negative consequences in non-technical areas. I hope you will give consideration to the non-technical as well as the technical when making your design decisions. In case anybody's having trouble with the analogy: The cube house is systemd. The sensor technology is logind. The air conditioner is pretty much any Gnome application. The non-cube house is any other init system besides systemd. -Rob ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote: We are always interested in technical feedback. I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting). Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! Thank you for your understanding! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
On Sun, Oct 12, 2014 at 12:57 AM, Tom Gundersen t...@jklm.no wrote: On Fri, Sep 26, 2014 at 4:52 AM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, On Thu, Sep 25, 2014 at 04:56:55PM -0700, James Lott wrote: Actually, the reason I am using dhcpcd fro mthe command line is as a debugging measure, because I originally setup a .network file for this interface to attempt to allow systemd-networkd to handle acquiring the DHCP lease. You could run networkd manually as # SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd but this will also show endless DISCOVER attempts. In my case, I controlled the DHCP server, and according to its logs the lease is actually assigned but the client never receives it. So, I suspect a bug either in kernel or systemd because packets get lost in the bridge (or bond in my case). I suspect the former because restarting networkd didn't help (i.e. the DHCP lease never got received). Yuck. I'm really not a fan of netctl, and would probably sooner hack together some oneshot service files that manually setup the interfaces and acquire leases. So it sounds like systemd-networkd is not quite ready for prime time when it comes to being a complete interface management solution. I guess that's what I get for living life on the edge ;) Netctl is better in this situation because it allows ordering of different profiles w.r.t. each other because they are just systemd services (in networkd language this would be ordering of different .net* units if such existed). So you can first set up vlans, then bridge and do the DHCP stuff. There is an additional problem with networkd: you never know how to order against it. Sure there are network* targets (and ideally things _should_ work) but they are useless in this context because they can be reached before (virtual) devices are actually initialized. OTOH, when a netctl script successfully returns, you know that things are properly set up. Hopefully this thread attracts relevant attention because I don't know how to debug this... Hi Leonid and James, Thanks for debugging this so far, I'll take a look next week. Cheers, Tom Hi guys, I finally got around to have a look at this. I can reproduce the problem, and for me a workaround is to set RequestBroadcast=yes in the DHCP section in the .network file for your host0 interface in the container. Does that work for you too. We should probably come up with some better way to handle this, but it is not clear to me at the moment how this can best be done to work nicely out of the box. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd.link] How to use NamePolicy=mac?
On Wed, Oct 8, 2014 at 10:04 AM, Moviuro movi...@gmail.com wrote: Hi all! In order to fix in an easily predictable manner the interfaces' names, I went and wrote the following .link file: /etc/systemd/network/00-default.link [Link] NamePolicy=mac MACAddressPolicy=persistent Looks good. I daemon-reload, reboot: $ ip a [...] 4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:aa:aa:d2 brd ff:ff:ff:ff:ff:ff [...] [...] However, $ udevadm test-builtin net_setup_link /sys/class/net/eth0 calling: test-builtin load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-default.link Created link configuration context. ID_NET_DRIVER=smsc95xx Config file /etc/systemd/network/00-default.link applies to device eth0 ID_NET_NAME=enxb827ebd2 Looks bad. This is a bug somewhere, if ID_NET_NAME is set, then also your if should get renamed. Does this also happen if you reboot, and can you reproduce with current git? I'll take a look. Thanks for the report! Cheers, Tom unload module index Unloaded link configuration context. Also, # /lib/systemd/systemd-udevd --debug device 0xb78bb3f8 has devpath '/devices/virtual/block/ram9' restoring old watch on '/dev/ram9' adding watch on '/dev/ram9' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram8' restoring old watch on '/dev/ram8' adding watch on '/dev/ram8' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram7' restoring old watch on '/dev/ram7' adding watch on '/dev/ram7' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram5' restoring old watch on '/dev/ram5' adding watch on '/dev/ram5' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram14' restoring old watch on '/dev/ram14' adding watch on '/dev/ram14' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram2' restoring old watch on '/dev/ram2' adding watch on '/dev/ram2' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram15' restoring old watch on '/dev/ram15' adding watch on '/dev/ram15' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram6' restoring old watch on '/dev/ram6' adding watch on '/dev/ram6' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram4' restoring old watch on '/dev/ram4' adding watch on '/dev/ram4' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram3' restoring old watch on '/dev/ram3' adding watch on '/dev/ram3' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram13' restoring old watch on '/dev/ram13' adding watch on '/dev/ram13' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram11' restoring old watch on '/dev/ram11' adding watch on '/dev/ram11' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop6' restoring old watch on '/dev/loop6' adding watch on '/dev/loop6' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram12' restoring old watch on '/dev/ram12' adding watch on '/dev/ram12' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop3' restoring old watch on '/dev/loop3' adding watch on '/dev/loop3' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop5' restoring old watch on '/dev/loop5' adding watch on '/dev/loop5' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram1' restoring old watch on '/dev/ram1' adding watch on '/dev/ram1' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram0' restoring old watch on '/dev/ram0' adding watch on '/dev/ram0' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop7' restoring old watch on '/dev/loop7' adding watch on '/dev/loop7' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram10' restoring old watch on '/dev/ram10' adding watch on '/dev/ram10' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop1' restoring old watch on '/dev/loop1' adding watch on '/dev/loop1' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop2' restoring old watch on '/dev/loop2' adding watch on '/dev/loop2' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop4' restoring old watch on '/dev/loop4' adding watch on '/dev/loop4' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop0' restoring old watch on '/dev/loop0' adding watch on '/dev/loop0' device 0xb78bb3f8 has devpath '/devices/platform/mmc- bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0/mmcblk0p2' restoring old watch on '/dev/mmcblk0p2' adding watch on '/dev/mmcblk0p2' device 0xb78bb3f8 has devpath '/devices/platform/mmc- bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0/mmcblk0p1' restoring old watch on '/dev/mmcblk0p1' adding watch on '/dev/mmcblk0p1' device 0xb78bb3f8 has devpath '/devices/platform/mmc- bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0' restoring old watch on '/dev/mmcblk0' adding watch on '/dev/mmcblk0' === trie on-disk === tool version: 216 file size:
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote: Hi guys, I finally got around to have a look at this. I can reproduce the problem, and for me a workaround is to set RequestBroadcast=yes in the DHCP section in the .network file for your host0 interface in the container. Does that work for you too. Hmm, maybe the default .network file we ship for this case should include this setting? Or will it in turn break the non-bridged veth setups? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: allow specification of DHCP route metric
On Mon, 08.09.14 15:09, Tom Gundersen (t...@jklm.no) wrote: Applied. Thanks! Hmm, the route metric for dhcp routes is now configurable. But what about implied routes created due to static IP configuration? I wonder if it wouldn't be a better idea to move RouteMetric= from the [DHCP] section into the [Network] section, and make it affect all routes, regardless if created implicitly due to static IP configuration, or if created due to DHCP configuration or created via explicit [Route] blocks. (Of course, the latter should allow individual overrides, and they already do...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
On Wed, 22.10.14 18:28, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: I'm not sure abou the name 'amendments.conf'. Wouldn't 'local.conf' be more idiomatic, and also easier to type? I was thinking about this too, and I wanted to propose override.conf instead? The word amendment I only know from the US constitution... Ok, both are fine for me. I'd prefer override still... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald watchdog timeout
On Wed, Oct 22, 2014 at 4:59 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 22.10.14 13:10, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: On one boot I got a watchdog timeout on systemd-journald: Oct 21 20:08:21 feanor systemd-journal[213]: Permanent journal is using 68.7M (m Oct 21 20:08:21 feanor systemd-journal[213]: Time spent on flushing to /var is 2 Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not rea Oct 21 20:08:25 feanor kernel: wlan0: authenticate with f4:ca:e5:cc:c7:40 Oct 21 20:08:25 feanor kernel: wlan0: send auth to f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: authenticated Oct 21 20:08:25 feanor kernel: wlan0: associate with f4:ca:e5:cc:c7:40 (try 1/3) Oct 21 20:08:25 feanor kernel: wlan0: RX AssocResp from f4:ca:e5:cc:c7:40 (capab Oct 21 20:08:25 feanor kernel: wlan0: associated Oct 21 20:08:25 feanor kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link become Oct 21 20:08:20 feanor systemd[1]: Started Trigger Flushing of Journal to Persis Oct 21 20:08:20 feanor systemd[1]: Started Create Volatile Files and Directories Oct 21 20:08:20 feanor systemd[1]: Starting Network Time Synchronization... Oct 21 20:08:20 feanor systemd[1]: Starting Update UTMP about System Boot/Shutdo Oct 21 20:08:20 feanor systemd[1]: Started Update UTMP about System Boot/Shutdow Oct 21 20:08:20 feanor systemd[1]: Started Network Time Synchronization. Oct 21 20:08:20 feanor systemd[1]: Starting System Initialization. Oct 21 20:08:21 feanor systemd[1]: Reached target System Initialization. Oct 21 20:08:21 feanor systemd[1]: Starting sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Listening on sshd.socket. Oct 21 20:08:21 feanor systemd[1]: Starting D-Bus System Message Bus Socket. Oct 21 20:08:25 feanor systemd-logind[516]: New seat seat0. Oct 21 20:08:25 feanor systemd-networkd[518]: lo : gained carrier Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd-logind[516]: Watching system buttons on /dev/inpu Oct 21 20:08:25 feanor systemd[1]: Started Network Service. Oct 21 20:08:25 feanor systemd[1]: Starting Network. Oct 21 20:08:25 feanor systemd[1]: Reached target Network. Oct 21 20:08:25 feanor systemd[1]: Starting Network Name Resolution... Oct 21 20:11:20 feanor systemd-journal[574]: Permanent journal is using 75.1M (m Oct 21 20:11:20 feanor kernel: e1000e :00:19.0: irq 55 for MSI/MSI-X Oct 21 20:11:20 feanor kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not read Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service watchdog timeout (li Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Getty on tty2. Oct 21 20:11:20 feanor systemd[1]: lightdm.service start operation timed out. Te Oct 21 20:11:20 feanor systemd[1]: systemd-timesyncd.service watchdog timeout (l Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service stop-sigterm timed o Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service: main process exited Oct 21 20:11:20 feanor systemd[1]: Unit systemd-journald.service entered failed Oct 21 20:11:20 feanor systemd[1]: systemd-journald.service has no holdoff time, Oct 21 20:11:20 feanor systemd[1]: Stopping Journal Service... Oct 21 20:11:20 feanor systemd[1]: Starting Journal Service... Oct 21 20:11:20 feanor systemd[1]: Started Journal Service. As you can see at 20:08:20 things appears to look fine, but everything get stuck during 3 minutes until there is a watchdog timeout for the journal and it gets restarted. Then the boot finished without any further problem. The next time everything worked fine, so I am wondering what could have happened? That's difficult to say just from these logs. Can you reliably reproduce this? If so, can you attach strace to journald before this happens and see what it is doing? I am wondering if we should send another signal that generates core when the watchdog is not fed. It would be nice to get the coredump of a frozen process. Umut What I find interesting is that after the 3min pause suddenly the network driver allocates irq 55. This kinda makes me wonder if this might be a kernel/driver problem of some kind, where for some reason userspace (and hence journald) don't get scheduled? What distro/version/arch is this? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [PATCH] build-sys: make hibernation support configure option also handle hybrid-sleep; fix indentation
On Tue, 09.09.14 01:40, Ivan Shapovalov (intelfx...@gmail.com) wrote: The patch by Umut did miss at least hybrid-sleep -- it involves hibernation as well (hybrid sleep is a hibernation followed by S3 rather than S4 powerdown). Also, it messed up indentation a bit (Makefile.am seems to use tabs), which I fixed as well. This patch was applied a while back by Tom. Thanks! And I wonder, maybe it makes sense to conditionalize sleep (suspend) support as well as hibernation? Or are there use-cases when suspend is possible, but not hibernation? Yes, suspend is much better supported thatn hibernation, usually. I'd take a patch to make it optional too, I guess. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald watchdog timeout
On Wed, 22.10.14 18:35, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: That's difficult to say just from these logs. Can you reliably reproduce this? If so, can you attach strace to journald before this happens and see what it is doing? I am wondering if we should send another signal that generates core when the watchdog is not fed. It would be nice to get the coredump of a frozen process. Oh indeed, we should probably send a SIGABRT in this case. Makes a ton of sense. Love it! Added to the TODO list. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Log unit's name instead of unit's description?
On Mon, 08.09.14 11:56, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 05/09/14 18:22, Jakub Klinkovský wrote: What is the reason behind logging unit's description? Consider the following journal message (from `journalctl -b`): systemd[1]: Starting A secure, fast, compliant and very flexible web-server... As a data point, Debian's init scripts have traditionally combined the description and name like this: Starting miscellaneous widget daemon: miscd. Starting Apache web server: apache2. Perhaps something like this would make more (grammatical and UI) sense for a systemd unit named miscd.service with Description=Miscellaneous widget daemon, in a way that degrades gracefully if the maintainer has (IMO incorrectly) used a Description like the one quoted above? systemd[1]: Starting miscd.service (Miscellaneous widget daemon)... systemd[1]: Started miscd.service (Miscellaneous widget daemon). systemd[1]: Starting apache2.service (Apache web server)... systemd[1]: Started apache2.service (Apache web server). or systemd[1]: Starting miscd.service: Miscellaneous widget daemon... systemd[1]: Started miscd.service: Miscellaneous widget daemon. systemd[1]: Starting apache2.service: Apache web server... systemd[1]: Started apache2.service: Apache web server. As a native Speaker of a Language that does not capitalize Nouns :-) I've always found Starting Miscellaneous widget daemon a bit jarring. Or is the intention that that unit should have had miscellaneous widget daemon, without the initial capital, as its Description? Hmm, this is something to think about. I have for now added this to the TODO list. That said, the boot output is supposed to be pretty stuff, hence at least should contain the pretty description. We can also add the non-pretty one, but that would certainly make the strings even longer... So far, our idea was to enable unit file authors to control what is shown. The burden is currently on them to set the description to something really useful. However, I do agree with the sentiment that including the unit name might be useful too, since it would make the log output more actionable, if you follow what I mean. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Fri, 05.09.14 20:34, Tobias Hunger (tobias.hun...@gmail.com) wrote: Heya, Sorry for the late response, been travelling for a month, and then have been more travelling, and still trying to process all the mails that queued up since. On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering lenn...@poettering.net wrote: Yeah, we want to encourage distros to install kernels into /usr, somewhere next to where the kmods already are, and then copy that over where necessary into the used boot partition. We actually have sime infrastructure for this in place in systemd, in the install-kernel script, which also has a man page. Any place that you would care to recomend? It would suck to have each distro put kernels somewhere else. Hmm, dunno, I figure Kay/Harald might have an idea about this. Kay? Harald? I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. Note that at least chromeos doesn't do this. They update the whole OS at once, including the kernel. And never kernel and /usr independently. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Well, gummiboot picks a kernel with the initrd attached. the initrd then finds the right /usr tree according to the information it contains. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. Well, I think kernel and /usr hierarchy really belong together. If you pick a kernel you thus implicitly also pick a /usr tree. (Of course, this strict we only need to be for a verified boot. For other cases, we of course can allow passing arbitrary kernel cmdline options, to pick different usr tree. The user should be able to override things, unless the device is in trusted mode) How do I boot the version I ran before the upgrade in case the upgrade failed? In general the rule should probably be to go back in version one-by-one if a kernel/system failed to boot. THe boot loader should by default boot the newest kernel, thus the newest /usr, too. if that for some reason nerver finishes, on next reboot it should pick the kernel one version older, and so on. I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: add CAP_MAC_OVERRIDE in journald for SMACK issue
On Thu, 11.09.14 15:54, juho son (juho80@samsung.com) wrote: We don't use S-O-b on systemd... I will send again follow. Oh, that was just a hint for the future, no need to redo the patch just to drop s-o-b. We usually drop it though while committing. Anyway, merged your repost. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please help: systemd special targets activaton order for fast boot
On Fri, 05.09.14 13:52, Viswambharan, Vibin (V.) (vvi...@visteon.com) wrote: 1/ Is there a recommended way to re-organize the boot target order ( I don't see there is a way to fit my userlevel application executables or deamons needed for early functionality to be associated with these primitive target appearing in the boot chain. Well, the unit files are all just text files, you can mostly just edit them and adjust to your needs. That said, the default unit files contain pretty minimal dependencies only, just the stuff that is really needed. Hence optimizing the dependencies is not rally typically necessary or sometimes even possible. Usually, if there's something you want to run earlier than the default, you can move them into the early boot process, but if you do this you need to write that program in a style that it is capable of working in such an early-boot environment. Among other things this means no access to /var and suchlike, no persistent storage. Also, no access to D-Bus, and so on. 2/ Is there a way to define custom target like early-boot.target and can be placed well on top of these special targets which can be used to start my user space applications that needs to be started well early during the boot process ( for example my full functional UI to be available within 8 sec from a cold boot which is has a X11 dependency) . So I mean that I need a way to start the X11 and my UI executable soon after systemd gets initialized and very early during the boot process.Currently the service files for the X11 and UI after associated with the basic.target and now the service activation can happen only around 7 sec after power on and when the basic.target is activated. You can add such a service to the normal target, but set DefaultDependencies=no for it. If you do the service will not be ordered after basic.target (which is the default), thus run in the early-boot mode described above. However, be careful, as pointed out above. 3/ Is there any special consideration to disable these special targets like (swap.target,local-fs target if they are not used in the embedded devices?). Well, they cost nothing if there are no swaps or local file systems to mount. I'd suggest not to bother. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please help: systemd special targets activaton order for fast boot
On Fri, 05.09.14 16:17, Chaiken, Alison (alison_chai...@mentor.com) wrote: (BTW, Lennart and Kai, is there a reason this great article couldn't be hosted at freedesktop.org or 0pointer.de?) Well, not sure if we own all the rights to be able to do that. As it appears h-online.com is back up though, at least as an archive. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-215: could not boot, missing /dev/disk/...-part2 symlink
On Tue, 02.09.14 11:15, Alexander E. Patrakov (patra...@gmail.com) wrote:
Hello.
I have a Gentoo system, with btrfs on /dev/sda2 (also known as
/dev/disk/by-id/ata-OCZ-VECTOR_OCZ-Z5CB4KC20X0ZG7F8-part2) and with dracut
038 with Gentoo patches that you can view here:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/dracut/files/
(see 0038-*)
Today, I powered the computer on (without applying any updates since the
previous successful boot), but the boot stalled, and I was dropped into an
emergency shell. I have saved the SOS report, see the attachment.
As you can see, /dev/sda2 exists, but the link doesn't. udevadm trigger
helped it to appear, and the boot continued.
I initially thought that it might be due to locking that systemd-udevd
applies to block devices for the period of running its IMPORT{program}
rules. Look: if in worker_new() the lock is not acquired successfully, then
the event processing is skipped (and this also means symlinks are not
created). But then there should be an Unable to flock debug message in
journalctl -b -p debug, and it doesn't exist. So it must be something
else. Any other ideas?
Have you enabled CONFIG_FHANDLE in your kernel? If not, enable it.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting configurable set of services first
On Tue, 02.09.14 10:06, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, I would like to start a configurable set of services first and the services are wanted by multi-user.target. I am using a service to jump to multi-user.target and I was wondering if we can support this use case natively by systemd. multi-user.target.wants A.service B.service C.service D.service default.target stage.target stage.target.wants (These are set by generator) A.service C.service switcher.service switcher.service (This is generated by generator) [Unit] Description=Switch to multi-user.targe After=A.service C.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/systemctl --no-block start multi-user.target This way I am jumping from one target to another target during runtime. - What stage.target wants is dynamic. If it was static, my job would have been very simple. - I am aware of StartupCPUShares but it is not the ultimate solution A) there is a configurable minimum quota in CFS which still gives CPU to other processes. B) We still fork other processes and this causes changes in timeout values of other processes. - Adding dynamically After= to B and D service files is not the ultimate solution either because B and D might be socket/dbus activated by A or C. Should this be something we should support natively by systemd? As discussed at th systemd hackfest: I am a bit conservative about this as it introduces plenty chance for deadlocks, where services might trigger/request some other unit but we'd delay it until the later stage... I think the implementation you chose is actually pretty good. I am not sure though that we should do this upstream. I mean, I really would prefer if we'd dump as much work as possible on the IO elevator and CPU scheduler, and then adjust the priorities of it to give hints what matters more. Trying to second-guess the elevator and scheduler in userspace feels a bit like chickening out to me, even though I am sure that it might be something that one has to do for now, in the real world... There's one change I'd really like to see done though in systemd, that might make things nicer for you. Currently, it's undefined in systemd which job is dispatched first, if multiple jobs can be executed. That means when we are about to fork off a number of processes there's no way to control which one gets forked off first. I'd be willing to merge a patch that turns this into a prioq, so that some priority value can be configured (or automatically derived) for each unit, and the one with the highest priority would win, and be processed first. This would not provide you with everything what you want, but would make things a bit nicer when we dump all possible work on the scheduler/elevator, because after all we cannot really dump all work at the same time, and hence should at least give you control in which order to dump it, if you follow what I mean. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: pass own argv to /run/initramfs/shutdown
On Tue, 30.09.14 17:02, Marius Tessmann (mus@gmail.com) wrote: On 09/30/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Aug 29, 2014 at 05:51:45PM +0200, Marius Tessmann wrote: Since commit b1e90ec515408aec2702522f6f68c4920b56375b systemd passes its log settings to systemd-shutdown via command line parameters. However, systemd-shutdown doesn't pass these parameters to /run/initramfs/shutdown, causing it to fall back to the default log settings. Hi, sorry for the late reply. Your patch should work fine if /run/initramfs/shutdown accepts those arguments, i.e. if it another systemd binary. But otherwise it might fail, no? Well, yes. I didn't really think about other implementations. I just checked the Dracut source and it shouldn't break anything there since it only parses the first argument as the verb [1]. I don't know what other implementations are out there, but I doubt they would break since they have no reason to parse anything but the first argument in the first place. Also, the Initrd Interface [2] doesn't even mention what arguments are passed to the shutdown binary (not even the verb), so one could argue that implementations should expect this to change. ;) Imho it would be enough to mention this in the release notes so that it can be fixed if necessary. Other implementations may even want to make use of the new parameters. ;) If possible breakage for other implementations is not acceptable I would love to know how else this could/should be fixed properly. [1] https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/99shutdown/shutdown.sh#n7 [2] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ Patch looks fine to me, but Harald (as dracut guy) shoiuld say something about this before we merge this. Harald? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bridge not picking up DHCP address
On Fri, 29.08.14 16:22, Mauricio Tavares (raubvo...@gmail.com) wrote: Heya, it's fun picking up two month old threads! ;-) So I have a system 2 interfaces, each of them using dhcp in different networks (both served by the same nameserver but in different vlans). Let's begin by showing my config files: Anyway, just to make sure this is not forgotten: this is being discussed now again in this thread. http://lists.freedesktop.org/archives/systemd-devel/2014-October/024296.html (or well, at least I *think* this is the same issue. If not, and your problem continues to exist, say something) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd build dependency on dbus
On Mon, 25.08.14 21:58, Filipe Brandenburger (filbran...@google.com) wrote: On Wed, Aug 20, 2014 at 3:27 PM, Lennart Poettering lenn...@poettering.net wrote: Well, we have our own dbus library implementation since a while (sd-bus) that supports both dbus1 and kdbus as transport. We only link against libdbus1 in a test to validate our marshalling against the dbus1 one. That's interesting. Indeed it would be good to clarify that libdbus is not required at build time (except for the test case, and maybe it can be made optional or dynamic loaded in that one?) There seems to be other configurations that are pulled from dbus, like the dbuspolicydir, dbussessionservicedir, etc. The current configure.ac logic is actually broken. We pretend that dbus was optional, but we use it's pkg-config file to derive the default paths you point out. We should fix that. Happy to take a patch. Also added a TODO list item for this. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] journalctl: Allow to disable line cap with --lines=all
On Sun, 31.08.14 11:12, Jan Janssen (medhe...@web.de) wrote: @@ -68,7 +68,7 @@ static bool arg_follow = false; static bool arg_full = true; static bool arg_all = false; static bool arg_no_pager = false; -static int arg_lines = -1; +static int arg_lines = -2; Humm. No, please don't! This is ugly. Don't introduce constant values without giving them a name, expecting everybody to remember the numeric values you assign. I have have now pushed a patch that fixes this and introduces proper enum values ARG_LINE_DEFAULT and ARG_LINE_ALL to use. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] firstboot: remove extra paranoia in --root checking
On Thu, 28.08.14 13:30, Dave Reisner (dreis...@archlinux.org) wrote: Some package managers will chroot before running post-install and post-upgrade scripts. Doing this prevents systemd-firstboot from being used piecemeal at installation or upgrade time, as the --root=/ will be cleverly ignored. There's already enough sanity checks in this tool that we don't also need add intelligence on top of the --root parameter. If a sys-admin wants to run this tool with --root=/, I see no reason why we should actively stop them. Hmmm, I now commited a different patch that just removes the --setup-machine-id refusal to operate on /. After all, if the machine id is really missing in the root fs there's no reason to block this off. This should fix your issue too, right? Could you check please? (Reducing arg_root == / into arg_root = NULL is really more about optimization I guess, so I figured we should leave it in). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bootchart: only show printable processes
On Thu, 28.08.14 00:44, WaLyong Cho (walyong@samsung.com) wrote:
On 08/27/2014 03:49 AM, Lennart Poettering wrote:
On Tue, 26.08.14 18:11, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Tue, Aug 26, 2014 at 5:07 PM, WaLyong Cho walyong@samsung.com
wrote:
This case really shouldn't be happen. (But actually sometime that was
happen.) Eeven if happened we maybe want to see the bootchart exclude
not printable processes.
---
src/bootchart/svg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index 135883f..9b7de33 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -1014,6 +1014,9 @@ static void svg_ps_bars(void) {
if (!enc_name)
continue;
+if (!utf8_is_printable(enc_name, strlen(enc_name)))
+continue;
+
/* leave some trace of what we actually filtered etc. */
svg(!-- %s [%i] ppid=%i runtime=%.03fs --\n,
enc_name, ps-pid,
ps-ppid, ps-total);
If the name is not printable, wouldn't it be better to show it in
escaped form rather than pretend it doesn't exist at all?
Yeah I agree. I'd love to merge a patch that intrdouces
utf8_escape_non_printable() or so, that works similar to
utf8_escape_invalid(), but also escapes non-printable chars, and then
make use of this here...
OK, but I'm confusing. We already have *cescape*. Is it not enough with
*cescape*?
cescape() escapes all chars 32 and = 127, that means it only leaves
ASCII printable characters, but not UTF8 printable characters, since
most of them are encoded in 127...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: do server_vacuum for sigusr1
On Thu, 28.08.14 21:33, WaLyong Cho (walyong@samsung.com) wrote: runtime journal is migrated to system journal when only /run/systemd/journal/flushed exist. It's ok but according to this the system journal directory size(max use) can be over the config. If journal is not rotated during some time the journal directory can be remained as over the config(or default) size. To avoid, do server_vacuum just after the system journal migration from runtime. OK, makes sense. Applied! Thanks! --- src/journal/journald-server.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c index 01da38b..7e85892 100644 --- a/src/journal/journald-server.c +++ b/src/journal/journald-server.c @@ -1224,6 +1224,7 @@ static int dispatch_sigusr1(sd_event_source *es, const struct signalfd_siginfo * touch(/run/systemd/journal/flushed); server_flush_to_var(s); server_sync(s); +server_vacuum(s); return 0; } -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote: Hi guys, I finally got around to have a look at this. I can reproduce the problem, and for me a workaround is to set RequestBroadcast=yes in the DHCP section in the .network file for your host0 interface in the container. Does that work for you too. Hmm, maybe the default .network file we ship for this case should include this setting? Or will it in turn break the non-bridged veth setups? Yeah, there is no perfect option. Some networks will filter broadcast messages (though that is arguably even more broken than filtering messed up unicast ones). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
On Fri, 12.09.14 15:25, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Tobias Geerinckx-Rice tobias.geerinckx.r...@gmail.com Step back, and define exactly what it is you actually need^Wwant to do. For a certain entry in /etc/fstab (which will in practice always have the option nofail), if the device is not available until booting is over (which I'm willing to denote with a specified period of time), after that, it will not be automatically mounted if it becomes available. This is currently not available, and it sounds very special and racy to support it upstream I think. Sorry! If you want to hack something up like this, I'd recommend writing a timer unit/cronjob that creates a file $PATH after $SECONDS after boot. Then, add a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and write into it: [Unit] ConditionFileExists=!/the/file/you/create That way the mount unit will always be queued, but will actually be conditionalized out $SECONDS after boot, if you follow what I mean. Hope this is helpful. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
On Wed, 22.10.14 20:49, Tom Gundersen (t...@jklm.no) wrote: On Wed, Oct 22, 2014 at 6:23 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 22.10.14 18:16, Tom Gundersen (t...@jklm.no) wrote: Hi guys, I finally got around to have a look at this. I can reproduce the problem, and for me a workaround is to set RequestBroadcast=yes in the DHCP section in the .network file for your host0 interface in the container. Does that work for you too. Hmm, maybe the default .network file we ship for this case should include this setting? Or will it in turn break the non-bridged veth setups? Yeah, there is no perfect option. Some networks will filter broadcast messages (though that is arguably even more broken than filtering messed up unicast ones). Hmm? Not following. I understood that RequestBroadcast=yes is necessary to make dhcp work on the Linux kernel bridge. Or is that a misunderstanding? What I am wondering about specifically is whether 80-container-host0.network shall default to RequestBroadcast=yes, or not? Aso, if there are some networks that require the bit set, and others that require it unset, what about trying the other after not getting a reply on the first? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User systemd unit files
On Wed, Oct 22, 2014 at 12:20 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 11.09.14 07:07, Chris Morgan (chmor...@gmail.com) wrote: Hmm. I figured that the environment was used when the systemd user instance was started. I tried systemctl --user set-environment and it shows up if I use show-environment but even if I use SYSTEMD_UNIT_PATH (I was typing on mobile and mistakenly typed USER instead of UNIT), and reloaded the daemon it doesn't appear to be taking effect, the test unit file I created isn't located. SYSTEMD_UNIT_PATH should still work. You have to specify it in the user@.service template unit file, then reload the daemon and restart that service. Otherwise it will not take effect. Make sure to then check if it is properly set by looking at /proc/$PID/environ for the systemd user instance. That all said, for testing purposes systemd-nspawn is probably the much better idea. I mean, we wrote it only for the purpose of testing... Lennart -- Lennart Poettering, Red Hat I ended up getting pretty much everything working. Right now we are using the same service files on desktop as on embedded (albeit they are being partially generated by cmake's configure_file() macro) To recap, on the desktop we: - Generate service files from blah.service.in files during the build, this lets us put in hardcoded paths etc for things that need them. - Run a script that uses 'systemctl link' to link to the users systemd folder - Run another script to start the services On embedded side we: - Generate the service files... - Run the normal 'systemctl enable xxx' - Let the system start the services up at boot time. The only wrinkle I've run into is that the version of systemd on f20 is old and doesn't appear to support things like 'systemctl start company*', so we have to iterate through a manually built list of service names. I'm hoping f21 resolves this. Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
Hi Lennart, On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering lenn...@poettering.net wrote: Sorry for the late response, been travelling for a month, and then have been more travelling, and still trying to process all the mails that queued up since. No problem at all:-) On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. That implies that each installation snapshot must come with an initrd, even if the only change to earlier versions is the snapshot name. That sounds suboptimal to me. But then I am playing with atomic upgrades for a while now and in practice each snapshots comes with its own initrd anyway. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. Note that at least chromeos doesn't do this. They update the whole OS at once, including the kernel. And never kernel and /usr independently. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Well, gummiboot picks a kernel with the initrd attached. the initrd then finds the right /usr tree according to the information it contains. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. Well, I think kernel and /usr hierarchy really belong together. If you pick a kernel you thus implicitly also pick a /usr tree. (Of course, this strict we only need to be for a verified boot. For other cases, we of course can allow passing arbitrary kernel cmdline options, to pick different usr tree. The user should be able to override things, unless the device is in trusted mode) How do I boot the version I ran before the upgrade in case the upgrade failed? In general the rule should probably be to go back in version one-by-one if a kernel/system failed to boot. THe boot loader should by default boot the newest kernel, thus the newest /usr, too. if that for some reason nerver finishes, on next reboot it should pick the kernel one version older, and so on. I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. I agree that this should work for secure boot and a classic distribution upgrade. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. Those were the last bits I needed for my grand atomic upgrade scheme to work without me having to patch stuff locally:-) Now I can proceed to move more of my systems over to actually use it. PS: Your scheme was significantly simpler to get up and running than the ostree-approach I tried before. But maybe that was just because I started out with a working ostree setup:-) Best Regards, Tobias ___ systemd-devel mailing list
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- Original Message - From: Lennart Poettering lenn...@poettering.net On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote: We are always interested in technical feedback. I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting). Please, let's discuss this elsewhere. Let's keep a strict technical focus on this ML! Thank you for your understanding! Lennart It is your ML, so I will oblige. But I think it is a mistake to not consider a broader view of your project than just the strictly technical aspects. -Rob ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
From: Lennart Poettering lenn...@poettering.net We are always interested in technical feedback. We are not very interested in FUD mails that tell us how we'd force people, how we'd behave like microsoft and so on. That's not useful, that's pretty much only hurtful. I haven't read this full thread, and it probably isn't useful for me to do so. But it seems that the first question to be answered by the developers is: Are they concerned that uptake is not as fast as they'd like? and if the answer to that is Yes, then: Would they like to hear feedback from users as to what they might do about it? There's no point in jabbering about it unless the answer to the second question is Yes. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH 1/2] resolve: resolved-manager: Avoid null dereference
On Wed, 22.10.14 22:12, Tom Gundersen (t...@jklm.no) wrote: On Wed, Oct 22, 2014 at 12:19 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 13.09.14 20:40, Tom Gundersen (t...@jklm.no) wrote: Yeah, this could happen. It so happens that the loopback link will always have ifindex 1, so I guess we could just fall back to checking for that if we don't have the real flags. Is that true even in network namespaces? Is this really exported API? I really don't want to rely on behaviour here that is not considered official API of Linux. If it is safe API of Linux, then we really should drop manager_ifindex_is_loopback() entirely, and just always compare the ifindex. Anyone has some pointers where this is made API? We may want to ask the kernel guys to export LOOPBACK_IFINDEX, as it is not at the moment. However, I think relying on it is fine even without that as the kernel will BUG_ON if lo does not have ifindex 1[0], and no other netdev can have ifindex 1[1]: /* The loopback device is special if any other network devices * is present in a network namespace the loopback device must * be present. BTW, I changed resolved now to only use LOOPBACK_IFINDEX when identifying loopback devices, and dropped the code that checks for IFF_LOOPBACK. That should simplify things a bit. I also documented the situation around LOOPBACK_IFINDEX in the comments. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] mac: rename apis with mac_{selinux/smack}_ prefix
On Thu, 16.10.14 16:59, WaLyong Cho (walyong@samsung.com) wrote:
-if (smack_label_ip_in_fd(fd, s-smack_ip_in) 0)
-log_error_unit(UNIT(s)-id, smack_label_ip_in_fd:
%m);
+if (mac_smack_ip_in_fd(fd, s-smack_ip_in) 0)
+log_error_unit(UNIT(s)-id,
-mac_smack_ip_in_fd: %m);
I think this call should still contern a verb of some kind, do
indicate what it does. mac_smack_label_ip_in_fd() or even
mac_smack_relabel_ip_in_fd() or so?
--- a/src/resolve/resolved-dns-domain.c
+++ b/src/resolve/resolved-dns-domain.c
@@ -169,7 +169,7 @@ int dns_label_escape(const char *p, size_t l, char **ret)
{
return r;
}
-int dns_label_apply_idna(const char *encoded, size_t encoded_size, char
*decoded, size_t decoded_max) {
+int dns_mac_selinux_apply_idna(const char *encoded, size_t
encoded_size, char *decoded, size_t decoded_max) {
THis looks like a copy/past error. This is not a security label here,
but just a part of a DNS domain
Otherwise looks good!
Could you please fix and rebase the series? I promise I will merge
this quickly now, sorry reviewing this so slowly! It must have been
awful constantly rebasing this without getting this merged! Sorry for
that!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] udev: do NOT re-label smack
On Thu, 16.10.14 16:59, WaLyong Cho (walyong@samsung.com) wrote: If selinux is disabled and smack is only enabled, smack label is relable-ed by label_fix. To avoid, make only be labeled for selinux. --- src/udev/udev-node.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c index 9796672..6dd4e74 100644 --- a/src/udev/udev-node.c +++ b/src/udev/udev-node.c @@ -317,8 +317,8 @@ static int node_permissions_apply(struct udev_device *dev, bool apply, } /* set the defaults */ -if (!selinux) -label_fix(devnode, true, false); +if (!selinux use_selinux()) +mac_selinux_fix(devnode, true, false); Hmm, but doesn't mac_selinux_fix() check for use_selinux() internally anyway? Checking this outside sounds redundant, no? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] mac: rename apis with mac_{selinux/smack}_ prefix
On Wed, 22.10.14 23:12, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 16.10.14 16:59, WaLyong Cho (walyong@samsung.com) wrote: -if (smack_label_ip_in_fd(fd, s-smack_ip_in) 0) -log_error_unit(UNIT(s)-id, smack_label_ip_in_fd: %m); +if (mac_smack_ip_in_fd(fd, s-smack_ip_in) 0) +log_error_unit(UNIT(s)-id, -mac_smack_ip_in_fd: %m); I think this call should still contern a verb of some kind, do indicate what it does. mac_smack_label_ip_in_fd() or even mac_smack_relabel_ip_in_fd() or so? Or maybe even mac_smack_fix_ip_in_fd()? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: Allow specifiying a name on the kernel command line
On Fri, 29.08.14 15:28, Jan Janssen (medhe...@web.de) wrote: heya, sorry for the late review! Hmm, not generally opposed to allowing this to be configured on the kernel cmdline, but this is so awfully asymmetric now. luks.uuid= so far accepts a single UUID, but may be specified multiple times luks.options= accepts a UUID, followed by a =, followed by the options for that specific volume, may be specified multiple times luks.key= accepts a single key file, but may be specified a single time only Now you want to extend: luks.uuid= would then accept a UUID, followed by a :, followed by the dm name for the specific volume Correct? I really don't like that. It's already awfull chaotic, and now it becomes even worse... Maybe, to stay uniform, introduce luks.name=$UUID=$NAME or so? this would map the luks.options= syntax at least (not that that was a particularly pretty syntax, but well...). In fact, we should probably extend luks.key= to also accept a syntax for this: luks.key=$UUID=$KEY or so... Any maybe if luks.options= does not start with $UUID= it should just be considered the default options for all entries. Does that make any sense? For now, could you rework your patch to follow this scheme? (I mean, only do the luks.name= syntax the way I propose above, not the other stuff). I'd prefer if we'd push all luks partitions that are configured into a Hashmap btw, keyed by the uuid, and with a new struct as value, where we can fill things in. Constantly iterating through the various arrays over and over again is neither pretty nor efficient. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: grant systemd-journal group permission
On Fri, 29.08.14 22:03, WaLyong Cho (walyong@samsung.com) wrote: On 08/27/2014 02:55 AM, Lennart Poettering wrote: On Tue, 26.08.14 15:43, WaLyong Cho (walyong@samsung.com) wrote: There is no Bofore= or After= dependencies between systemd-journald.service and systemd-tmpfiles-setup.service. So if both /run/log/journal and /var/log/journal does not exist then those can be make as root:root and also its ids directory and journal files. To make sure, do chown systemd-journal group to journal directories and files. Hmm? /run/log/journal will be recursively updated, and /var/log/journal is not created by journald ever, but only by tmpfiles, which uses g+s to ensure all files that will be created have the right owner from the beginning. I hope you test like me. Set *Storage=persistent* in journald.conf and remove(back it up to other) /var/log/journal and restart. Ah, umm. Yuck. Storage=persistent is indeed a different case... Hmm, not sure what we can do here. We cannot do NSS lookups in journald though, we need to find another way. Hmm, one idea is to make systemd-journal-flush synchronous, and then order it before systemd-tmpfiles. That way, if Storage=persistent is set we would *know* that the dir is first created, and tmpfiles could then just adjust the ACLs for it... However, making systemd-journal-flush isn't that easy I fear. It would be easy if we had dbus as IPC, but that's something we cannot use unless we have kdbus, since we cannot allow a cyclic loop between dbus-daemon logging to journald, and journald waiting for dbus I need to think about this more... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compatibility between D-Bus and kdbus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/10/2014 15:33, Simon McVittie wrote: [cut] Resource limits === Some resource limits are lower in kdbus than in dbus-daemon. In kdbus, the number of unread messages per recipient is limited to 256, with up to 16 per uid; subsequent broadcasts are silently dropped, and subsequent unicast messages cause the sender to block. The message header (fixed-length header and header fields) is limited to 2 MiB in kdbus, whereas on dbus-daemon it may be up to a configurable limit, by default 32 MiB for the system bus or 128 MiB for the session bus. Broadcast messages (header + body) have the same 2 MiB limit, but unicast message bodies may be any size: kdbus itself does not impose any limit. I don't know whether anything sends broadcasts as large as 2 MiB (Tracker perhaps?): if you do, please share. Tracker's GraphUpdated will 'compress' its payload by sending numerical ID's that represent the graph, resource, property and sometimes value to signal inserts and deletes on a graph. It has two triggers to invoke it (which also flushes it) When the amount of events is larger than a certain number: https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n25 https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n312 And timer based as configured as graphupdated_delay (dconf config): https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n297 Some more explanation here: http://pvanhoof.be/blog/index.php/2010/08/24/trackers-new-class-signal-system-being-developed Of greater concern is an API which I always considered to be for debugging purposes only. That's the Query API on Resources1 of Tracker: libtracker-sparql will not ever use it, the library will either use a direct connection with sqlite's meta.db using WAL journaling for read queries, or fall back to using FD passing with as you mentioned in your mail pipe() and vmsplice(). That's the Steroids1 D-Bus interface of Tracker's SPARQL endpoint. Although I consider the Query API on Resources1 to be a private or debug D-Bus API, it can indeed cause a very large DBusMessage. This was once put in place to guard ourselves against it: https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n50 https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n111 Some explanation here: https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n27 [cut] Comments, corrections? (To the dbus list, please.) Kind regards, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJUSCi9AAoJEEP2NSGEz4aDDKEH/RDRuIHtmUljzdYX7XQqGA6N I/0DAaCHRCg0D2az9MbzgEnrFrvVmhACtGrFcWA15hfasNadcCmPnIBRJk84WOld rELimMayQ8wyCsKlCBszoAjQKVe4Qr5KVw3zVNBTPvfs6xsqdeGFSaNbFDrrCZtC 5SmwnlI9ezenJ3+EjAbTqPUDi7rMciA4BvDWI0HSa4TQD/ggtnHnVyikff6POPX7 BQcHp65vBSCvz+mwVPUawTI04l3MC8UXzMOYw/I+UduESnptbD7ZyJ0GzUY7rxxI Se/Et+ijSBCdvb3cuBnDk14kZ+slJFEBrYLsukZVdQ8hqzm1NmU0/XBsMK3eN+c= =GA7y -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: grant systemd-journal group permission
On Wed, 22.10.14 23:53, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 29.08.14 22:03, WaLyong Cho (walyong@samsung.com) wrote: On 08/27/2014 02:55 AM, Lennart Poettering wrote: On Tue, 26.08.14 15:43, WaLyong Cho (walyong@samsung.com) wrote: There is no Bofore= or After= dependencies between systemd-journald.service and systemd-tmpfiles-setup.service. So if both /run/log/journal and /var/log/journal does not exist then those can be make as root:root and also its ids directory and journal files. To make sure, do chown systemd-journal group to journal directories and files. Hmm? /run/log/journal will be recursively updated, and /var/log/journal is not created by journald ever, but only by tmpfiles, which uses g+s to ensure all files that will be created have the right owner from the beginning. I hope you test like me. Set *Storage=persistent* in journald.conf and remove(back it up to other) /var/log/journal and restart. Ah, umm. Yuck. Storage=persistent is indeed a different case... Hmm, not sure what we can do here. We cannot do NSS lookups in journald though, we need to find another way. Hmm, one idea is to make systemd-journal-flush synchronous, and then order it before systemd-tmpfiles. That way, if Storage=persistent is set we would *know* that the dir is first created, and tmpfiles could then just adjust the ACLs for it... However, making systemd-journal-flush isn't that easy I fear. It would be easy if we had dbus as IPC, but that's something we cannot use unless we have kdbus, since we cannot allow a cyclic loop between dbus-daemon logging to journald, and journald waiting for dbus I need to think about this more... OK, I thought a bit about this more. And now changed systemd-journal-flush.service to be asynchronous, so that it can be ordered before systemd-tmpfiles-setup.service and the ownership of the dirs can be correctly applied. Please give this a test run. I implemented this via a new journalctl --flush command which will first send SIGUSR1 to journald, and then wait for /run/systemd/journal/flushed to appear in the FS which is what journald uses internally to remember if it already flushed the journal or not. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Wed, 22.10.14 21:08, Tobias Hunger (tobias.hun...@gmail.com) wrote: My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. That implies that each installation snapshot must come with an initrd, even if the only change to earlier versions is the snapshot name. That sounds suboptimal to me. Correct. I can see that for some uses this might appear as overkill, but in general I would not make much of a distinction between the kernel and the basic userspace here, they really belong together. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. I figure they want to make sure the files in the initrd are actually always identical to the source they are copied from in /usr. That kinda requires updating the initrd on each update of /usr. secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. I agree that this should work for secure boot and a classic distribution upgrade. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. I am working on it, but there are a couple of things I still need to work on before the release. Sorry! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Tracker] How to use cgroups for Tracker?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/10/2014 13:21, Lennart Poettering wrote: Well, looking at that bug it appears to me that this is caused because you try to use inotify for something it shouldn't be used for: to recursively watch an entire directory subtree. If you fake recursive fs watching by recursively adding all subdirs to the inotify watch then of course you eat a lot of CPU. The appropriate fix for this is to not make use of inotify this way, which might mean fixing the kernel to provide recursive subscription to fs events for unpriviliged processes. Sorry if that's disappointing, but no amount of cgriups can work around that. Don't try to work around limitations of kernel APIs by implementing inherently not scalabale algorithms in userspace. I mean, you implemented something that scales O(n) with n the numbers of dirs. That's what you need to fix, there's no way around that. Just looking for magic wands in cgroups and scheduling facilities to make an algorithm that fundamentally scales badly acceptable is not going to work. The problem with allowing unprivileged processes is that a misbehaving process will cause the kernel to buffer events for it, forcing the kernel to dynamically allocate memory. Not something kernel or inotify developers will like a lot. I guess the kernel could reduce the buffer by not storing the null-terminated name of the inotify_event, and reconstructing it on-demand at the read() moment .. but that still means buffering. I guess that's why we have /proc/sys/fs/inotify/max_queued_events FSEvents 'solves' this by having a well behaved single process journalling it to disk, and then providing an API for other consumers to query the journal. We could develop a privileged well behaving such process that does exactly that. We need writable storage in $HOME/.cache/tracker anyway, tracker-miner-fs could register itself to it to get such logs written in the user's .cache location. Maybe that's something for systemd to provide :-)? I wonder how well that will burn in the plasma-hot flamewars surrounding poor systemd. /me hides Kind regards, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJUSDVJAAoJEEP2NSGEz4aDPsYH/1y6F1N67RyvBd50QEBHh7fH m4AezEi4a+nFZVxFW3iXfLyp0Df0kkXSRwZAGgAOTVXbbrvi8aOmuFYSIsAqUuaU 9m98Dh6gTM1Zusa79sWLT1Ktp8bJ9Pa+dNenjXU2cizwkhuqYd58P4SoWAjbUDaA quQVMrPD50Jyjf6zfCe2IeSUhG0v0leazs6o2XxmKSSNs/EBXf32w17GZd8dh3FX 8QcCxtTz+Lz+LJ92fwYEPPVh094hu0X79pB8st3ES0b+iZLaoDPrPRiOJn2kAETx S+4V0F5/bQf4lQ8eTRHn7UDjOLLvqZ4PgsBAwSskVjykfCgCu9N+qEBlg5Ho6d4= =HIJP -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
