Re: [systemd-devel] [ANNOUNCE] systemd 195
Op 23 okt. 2012, om 02:56 heeft Lennart Poettering lenn...@poettering.net het volgende geschreven: Heya! A non-trivial amount of cool new features, but primarily bug fixes bug fixes bug fixes. In both 194 and 195 I have trouble building system for my embedded systems: | src/journal/journal-gatewayd.c: In function 'respond_oom': | src/journal/journal-gatewayd.c:117:9: warning: implicit declaration of function 'MHD_create_response_from_buffer' [-Wimplicit-function-declaration] | src/journal/journal-gatewayd.c:117:76: error: 'MHD_RESPMEM_PERSISTENT' undeclared (first use in this function) | src/journal/journal-gatewayd.c:117:76: note: each undeclared identifier is reported only once for each function it appears in | src/journal/journal-gatewayd.c: In function 'respond_error': | src/journal/journal-gatewayd.c:148:66: error: 'MHD_RESPMEM_MUST_FREE' undeclared (first use in this function) | src/journal/journal-gatewayd.c: In function 'request_reader_entries': | src/journal/journal-gatewayd.c:186:32: error: 'MHD_CONTENT_READER_END_OF_STREAM' undeclared (first use in this function) | src/journal/journal-gatewayd.c:197:32: error: 'MHD_CONTENT_READER_END_WITH_ERROR' undeclared (first use in this function) | src/journal/journal-gatewayd.c: In function 'request_handler_entries': | src/journal/journal-gatewayd.c:524:9: warning: implicit declaration of function 'MHD_create_response_from_callback' [-Wimplicit-function-declaration] | src/journal/journal-gatewayd.c:524:18: warning: assignment makes pointer from integer without a cast [enabled by default] | src/journal/journal-gatewayd.c: In function 'request_reader_fields': | src/journal/journal-gatewayd.c:585:32: error: 'MHD_CONTENT_READER_END_OF_STREAM' undeclared (first use in this function) | src/journal/journal-gatewayd.c:590:32: error: 'MHD_CONTENT_READER_END_WITH_ERROR' undeclared (first use in this function) | src/journal/journal-gatewayd.c: In function 'request_handler_fields': | src/journal/journal-gatewayd.c:671:18: warning: assignment makes pointer from integer without a cast [enabled by default] | src/journal/journal-gatewayd.c: In function 'request_handler_redirect': | src/journal/journal-gatewayd.c:697:72: error: 'MHD_RESPMEM_MUST_FREE' undeclared (first use in this function) | src/journal/journal-gatewayd.c: In function 'request_handler_file': | src/journal/journal-gatewayd.c:733:9: warning: implicit declaration of function 'MHD_create_response_from_fd_at_offset' [-Wimplicit-function-declaration] | src/journal/journal-gatewayd.c:733:18: warning: assignment makes pointer from integer without a cast [enabled by default] | src/journal/journal-gatewayd.c: In function 'request_handler_machine': | src/journal/journal-gatewayd.c:815:72: error: 'MHD_RESPMEM_MUST_FREE' undeclared (first use in this function) | src/journal/journal-gatewayd.c: In function 'main': | src/journal/journal-gatewayd.c:889:33: error: 'MHD_OPTION_LISTEN_SOCKET' undeclared (first use in this function) Is there a version check for the microhttpd version missing? regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. Because now the application has to decide whether it wants to support EVERY EXISTING SYSTEM OUT THERE or not. Hundreds of millions of Linux systems do not provide this attribute. Applications have to handle the case of not having the 'vlan' device type available attribute essentially forever. So providing it in new kernels provides zero value whatsoever. I'm not applying this patch, sorry. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
On Tue, Oct 23, 2012 at 8:36 AM, David Miller da...@davemloft.net wrote: From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. That makes not much sense, really. Every new interface would fall into that category. At least I can't see any mis-guidance here. The other devtypes for the major netif types are not that much older. Because now the application has to decide whether it wants to support EVERY EXISTING SYSTEM OUT THERE or not. Hundreds of millions of Linux systems do not provide this attribute. Applications have to handle the case of not having the 'vlan' device type available attribute essentially forever. Which is an entirely separate issue, and not a technical reason not to add new interfaces which are already in use for most other types of netifs. So providing it in new kernels provides zero value whatsoever. It sure does provide a value. The kernel can efficiently filter uevents in the socket with this available. All other major types of netdevs support that too, it's just a matter of completeness. For that reason, it looks useful to me. I'm not applying this patch, sorry. That's just sad. Not that I really care about that functionality, but your reasoning is absolutely not transparent. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Sun, Oct 21, 2012 at 1:05 AM, Lennart Poettering lenn...@poettering.net wrote: Heya, I have now found the time to document the journal file format: http://www.freedesktop.org/wiki/Software/systemd/journal-files Comments welcome! (Oh, and it's in the fdo wiki, so if you see a typo or so, go ahead and fix it!) I've quickly read through the document [1] pointed above describing the log on disk format. (I've read it out of curiosity, not with the intention to implement it. Maybe to steal some ideas for the future.) :) (Just as an observation I've also read your essay about this subject [2], and I agree with most of it.) But what I couldn't find in any of these documents (maybe there is in another one), is a justification of the current technical (i.e. implementation) decisions. Mainly: Why did you resort to implementing a new database format, and didn't choose an existing embedded library like BerkeleyDB, LevelDB, etc.? (Advantages / disadvantages?) Just to be clear I don't mean the decision of a completely new logging format (i.e. not compatible with syslog, CEE, etc.) I'm focusing just on the storage engine. For example I could think of: * not relaying on an external embedded storage library, makes the resulting binaries smaller and simpler; (this doesn't seem to be it as systemd already incorporates some other libraries;) * having a custom log implementation makes this job more efficient; (in the long term I don't think beating a library like the ones listed above is feasible without a lot of work;) * log rotation is almost impossible with some of the above cited libraries; (there are other tricks that can be done to achieve such;) Please don't take this as critique of the journal work (I've read some of those too, especially from Rainer, but I'm neutral so far). I just want to understand the decisions. Ciprian. [1] http://www.freedesktop.org/wiki/Software/systemd/journal-files [2] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTspli=1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 195
On Tue, Oct 23, 2012 at 10:42:34AM +0200, Koen Kooi wrote: Op 23 okt. 2012, om 02:56 heeft Lennart Poettering lenn...@poettering.net het volgende geschreven: Heya! A non-trivial amount of cool new features, but primarily bug fixes bug fixes bug fixes. In both 194 and 195 I have trouble building system for my embedded systems: | src/journal/journal-gatewayd.c: In function 'respond_oom': | src/journal/journal-gatewayd.c:117:9: warning: implicit declaration of function 'MHD_create_response_from_buffer' [-Wimplicit-function-declaration] | src/journal/journal-gatewayd.c:117:76: error: 'MHD_RESPMEM_PERSISTENT' undeclared (first use in thHi, those enums seem to have been added in microhttpd v. 0.9.5. Added a check in 59bb9d9. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 15:25, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: But what I couldn't find in any of these documents (maybe there is in another one), is a justification of the current technical (i.e. implementation) decisions. Mainly: That's a valid question to raise. Why did you resort to implementing a new database format, and didn't choose an existing embedded library like BerkeleyDB, LevelDB, etc.? (Advantages / disadvantages?) There are a number of reasons, which one could summarize as: because there is no existing database implementation that would fit the bill: - we needed something small, embeddable, in pure C, so that we can pull it in everywhere. That has a somewhat stable API, is sanely managed upstream, and Free Software. We are OK to add deps to systemd, if there's a good reason to and the dep is well managed. It needed to be OOM safe. - The database should be typeless, and index by all fields, rather than require fixed schemas. It should efficient with large and binary data. - It should not require file locks or communication between multiple readers or between readers and the writer. This is primarily a question of security (we cannot allow users to lock out root or the writer from acessing the logs by taking a lock) and network transparency (file locks on network FS are very very flaky), but also performance. - We wanted something robust for IO failures that focusses on appending new data to the end, rather than overwriting data constantly. - We needed something with in-line compression, and where we can add stuff like FSS to These are the strong requirements, but there are other are ore things to keep in mind: because of the structure of log data, which knows no changes but only appends and the occasional deletion of large chunks, and were data is generally montonically ordered you can a lot of things you cannot do in normal databases. rsyslog apparently chose to use ElasticSearch. It think ElasticSearch is cool, but it already fails for us on the most superficial of things, in that it would be quite ridiculous to pull in Java into all systems for that... ;-) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pm-utils quirks
On Mon, 22.10.12 23:47, Colin Guthrie (gm...@colin.guthr.ie) wrote: So, should the org.freedesktop.UPower.CanSuspend/Hibernate properties be cooked up instead to logind rather than shelling out to pm-is-supported? Yes, I guess. And the clients should probably move over to logind anyway. As well as the above problem, my colleague also pointed out: - up_backend_get_powersave_command (src/linux/up-backend.c line 615) calls /usr/sbin/pm-powersave to apply powersave's adjustments. Well, i think the approach of this is not really liked. Power savings should always be done. So what is the systemd blessed way of doing this? None, really. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Too little information is shown when system enters emergency mode
On Sun, 21.10.12 15:59, Andrey Borzenkov (arvidj...@gmail.com) wrote: Welcome to emergency mode. Use systemctl default or ^D to enter default mode. Give root password for login: systemd 195 will now also mention journalctl -b in this message. Originally this was only in the rescue mode, because of the assumption that if you boot directly to emergency mode then no logs would be in the journal, and hence no point in recommending this command. However, after all most of the times people will end up in emergency mode is when file systems not showing up where journald *is* actually running and includes the desired, useful information. Started /boot/efi [ OK ] Dependency failed. Aborted start of /mnt [ ABORT] Dependency failed. Aborted start of Login Service [ ABORT] Dependency failed. Aborted start of D-Bus System Message Bus [ ABORT] Welcome to emergency mode. Use systemctl default or ^D to enter default mode. Hmm, we definitely should show the initial unit that failed in this output. Can you restest with 195 please? If you find that there's information missing in journalctl -b or in the status output, then please file a bug, we really should place useful information at both. Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: Remove HP iLO from USB HID PM rules
On Mon, Oct 22, 2012 at 3:40 PM, Tony Camuso tcam...@redhat.com wrote: HP iLO fw versions below 1.50 incorrectly report that HP iLO virtual Kbd/Mouse supports remote wakeup. With the rules change in commit 3bfc7a97b1824fcdfb738617d9a5450a20a22a0f, the HP iLO was listed for power control. In iLO fw versions less than 1.50, the iLO Kbd/Mouse become unresponsive once they are suspended. HP iLO fw versions 1.50+ correctly report that they don't support remote wakeup, which makes the rules moot in any case. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Too little information is shown when system enters emergency mode
On Mon, 22.10.12 11:41, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Please note the version of systemd (v44) in openSUSE doesn't have all the needed bits to always display on the screen why dependency failed (and you end up in emergency mode). This is fixed with systemd 195 which should land in Factory pretty soon. As an experiment, I tried the same (add '/dev/sda9 /mnt' to /etc/fstab) under v194-138-g20f59e4, i.e. very recent. After rebooting all I see is the emergency mode prompt. Now the problem is that 'dev-sda9.device' is loaded inactive(dead). This means that it doesn't show up in --failed. So 'systemctl' with various options doesn't show what failed in an easy to recognize way. OTOH 'journalctl -b' is immensly useful: red Timed out waiting for device dev-disk-by\x2duuid\x5cx2fdev\x5cx2fsda9.device. Dependency failed for /mnt. Dependency failed for Local File Systemds. ... /red This is great, and it would be really nice to expose it more. I guess that the first change would be to advertise 'journalctl -b' in the emergency mode intro. I added this yesterday, it is included in 195. Would be nice to also un-eescape the device name: Timed out waiting for device /dev/sda9 should be much more understandable for the non-systemd-knowledgable person than Timed out waiting for device dev-disk-by\x2duuid\x5cx2fdev\x5cx2fsda9.device. This is a cool idea. Adding the inverse of unit_name_mangle(), and showing that if we have a failure on a unit with no sane description string and sounds like an awesome idea (though we probably should show the mangled name as well, dunno, might be useful for proficient folks). The fix might actually be simple, we could transparently do this in unit_description() on access. Added this to the TODO list. But it would be best to provide a short status like: systemd was trying to reach target 'default.target' (which points to 'Multi-User', multi-user.target), but failed, because device /dev/sda9 is missing (dev-disk-by\x2duuid\x5cx2fdev\x5cx2fsda9.device). in turn this caused '/mnt' mount to fail (mnt.mount), in turn this caused 'Local File Systems' target to fail (local-fs.target), ... in turn this caused 'Multi User' target to fail (multi-user.target). Uh, This is quite hard to do, since we don't track the reasons so much. I wonder if a simple list of failure and failure-due-to-dep wouldn't be sufficient, rather than prose here... And a hint how to e.g. temporarily disable the failing mount point. I admit that I'm not sure what is the proper way, short of editing /etc/fstab and rebooting. I wonder if this is something to handle with the explanation database (aka message catalogue) I want to add to the journal. This would optionally augment log entries with static info from the vendor about the issue, with longer help, links and support contact. All this would be keyed off the message ID of a message, and be translated to the local language of the user. My idea is to expose this with journalctl -e or so, where every log line gets this data attched to it, in a block below each line, where it is available. Using the explanation database is a great way to handle this and more errors and get translation and links for free. Would be nice if this output could be easily retrieved again. If the user starts looking at the system, and then forgets what exactly failed, he or she should be able to repeat this short diagnosis. Sounds like a job for journalct -ebp err or so, if we have the explanation database? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgls: correctly ellipsize command lines for PIDs = 1000000
On Fri, 19.10.12 20:15, Mantas Mikulėnas (graw...@gmail.com) wrote: Thanks! Applied. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH RFC] swap: use aliases to group swap units for same device
On Fri, 19.10.12 00:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: A series of .swap units following one another are replaced with a single unit with multiple names. The idea is to simplify things for the user: only one swap unit per swap area. It shouldn't matter whether the swap area was activated by systemd or by direct swapon invocation. The kernel name (from /proc/swaps) is preferred, but if swap is configured through a unit file and not active, that name will be used instead. The case where a swap unit refers (What=) to a symlink should behave better than before. Note: this patch is goes on top of some cleanup patches that are pretty boring and thus I'm not posting them, so it might not apply cleanly. So here's the reason why we use the following scheme for htis, rather than just alias names. And that's simply because a name in /dev can refer to different things during runtime and we cannot model this with aliases. So, basically, if you plug in Disk X first, and Disk Y second, then a swap device symlink /dev/foobar might point to /dev/sda5. But if you plug them in in a different order, then /dev/foobar will point to /dev/sdb5, instead. So initially we have one swap device that is exposed as both /dev/sda5 + /dev/foobar, and then later one that is exposed as /dev/sdb5 + /dev/foobar. Now, if some component depends on /dev/sda5 being enabled as swap, and another component that depends on /dev/foobar being enabled as swap, and we just alias the same object under both names, this will work fine first. But what happens if the swap device goes away and comes back as /dev/sdb5, now you have to split up the names again, since /dev/sda5 stays with the old device unit, but /dev/foobar has to be directed to the new one. And then you'd have to figure out which service depended on which unit name, and fix the dep tree. This basically means that we'd have to have to tracks deps as for names rather than units. But that would drastically complicate things. Instead we chose to let all .swap and .device units live independently under each name, but make them follow other units as needed, and truncate the follow chain when appropriate. In other words: - Unit aliases are useful where the same alias is always assigned to the same unit, and this never changes, except when systemctl daemon-reload is executed. - The following scheme is useful where an alias might dynamically be assigned to different units during runtime, and this can change at any time, without needing systemctl daemon-reload. Does this make any sense? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting/stopping service on net connection
On Fri, 19.10.12 00:01, Dan Tihelka (dtihe...@gmail.com) wrote: Hello, thank you for such a long and detailed answer. I do agree with you in general. Of course, there is an intersection of two words. On one side there is an init daemon being responsible for starting/stopping services. On the second side there is an network management system/daemon handling the net connection. And as it is true that init daemon does not have to handle network status (as you explained), a network manager does not have to start services ... The way (well, you may have a better solution, probably ...) is in communication. I can imagine that the network manager will emit dbus broadcast messages about network up/down, no matter what particularly it means (there may even be several different kinds of signals). If init daemon can handle the dbus signals, users or admins can write services as the reactions to them. And here I don't mean any standardized set of signals which both systems have to implement. It is enough to allow StartOnDBus=user-write-what- require, SopOnDBus=user-write-what-require and similar stuff. Similarly to sockets activation or automounting capability. Do you think that it is the way, or am I completely mistaken? I am a bit afraid of adding a generic rule expression language where you can match everything to do everything. Our current approach is to match on specific changes only: - If a message is sent to a service that is not started, D-Bus can ask systemd to start it. - If systemd receives an explicit request to start something it will do so. Both of these cases are kinda explicit in their behaviour, starting things can be expected to be an effect of this, it's not a hidden side-effect. But this is very different from matching arbitrary signals, where things would become much less obvious. I am tempted to say that the better approach is to make activation explicit rather than implicit with this. If you start allowing flexible expressions on which signal to start what then you will also quickly get into the territory of allowing more complex expressions too (such as, under this condition on this event do this, but under this other condition this instead), and I don't want that really. It is also a bit incompatible with the model how systemd tries to minimize loading things of disk: only when we get one of those explicit requests to start something (as mentioned above) we go to disk and try to find a unit matching this. At any given time systemd only has in memory units that are actually referenced. But if we want to allow a rule set we'd either have to go to disk on any bus signal or always load the ruleset into memory. So, nah, I am not convinced really, that this is rally so desirable. I think the best approach is probably to focus on the specific usecases, and come up with a good approach to handle those, and only if from them it becomes clear that activation-on-arbitrary-bus-signals would be cool and the best solution we should consider them. Hope that makes sense, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, Oct 23, 2012 at 5:39 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 23.10.12 15:25, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: Why did you resort to implementing a new database format, and didn't choose an existing embedded library like BerkeleyDB, LevelDB, etc.? (Advantages / disadvantages?) There are a number of reasons, which one could summarize as: because there is no existing database implementation that would fit the bill: - we needed something small, embeddable, in pure C, so that we can pull it in everywhere. That has a somewhat stable API, is sanely managed upstream, and Free Software. We are OK to add deps to systemd, if there's a good reason to and the dep is well managed. It needed to be OOM safe. - We wanted something robust for IO failures that focusses on appending new data to the end, rather than overwriting data constantly. - We needed something with in-line compression, and where we can add stuff like FSS to Ok. I agree that there are very few libraries that fit here. All I can think of making into here would be BerkeleyDB (but it fails other requirements you've listed below). - The database should be typeless, and index by all fields, rather than require fixed schemas. It should efficient with large and binary data. One thing bothers me: why should it index all fields? (For example indexing by UID, executable, service, etc. makes sense, but I don't think indexing by message is that worthwhile... Moreover by PID or coredump (which I think it is hinted is stored in the journal) doesn't make too much sense either...) - It should not require file locks or communication between multiple readers or between readers and the writer. This is primarily a question of security (we cannot allow users to lock out root or the writer from acessing the logs by taking a lock) and network transparency (file locks on network FS are very very flaky), but also performance. From what I see this is the best reason for the current proposal. Indeed no embedded database library (that I know of) allows both reading and writing at the same time from multiple processes without locking. (Except maybe DJB's CDB and the TinyCDB implementation, but that wouldn't fit the bill here.) Maybe this should go at the top of that document as describing why?. These are the strong requirements, but there are other are ore things to keep in mind: because of the structure of log data, which knows no changes but only appends and the occasional deletion of large chunks, and were data is generally montonically ordered you can a lot of things you cannot do in normal databases. Although I partially agree about this increased flexibility, having a custom format means it is very easy to just start adding features, thus accumulating cruft... Thus maybe a general purpose system would have limited this tendency... rsyslog apparently chose to use ElasticSearch. It think ElasticSearch is cool, but it already fails for us on the most superficial of things, in that it would be quite ridiculous to pull in Java into all systems for that... ;-) I don't even want to imply such a thing solution. (Or at least not for a standalone computer logging system.) BTW, a little bit off-topic: * why didn't you try to implement this journal system as a standalone library, that could have been reused by other systems independently of systemd; (I know this was answered in [2], and that the focus is on systemd, but it seems it took quite a lot of work, and it's a pity it can't be individually reused); * how do you intend to implement something resembly syslog's log centralization? Ciprian. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH RFC] swap: use aliases to group swap units for same device
On Tue, Oct 23, 2012 at 5:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 19.10.12 00:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: A series of .swap units following one another are replaced with a single unit with multiple names. The idea is to simplify things for the user: only one swap unit per swap area. It shouldn't matter whether the swap area was activated by systemd or by direct swapon invocation. The kernel name (from /proc/swaps) is preferred, but if swap is configured through a unit file and not active, that name will be used instead. The case where a swap unit refers (What=) to a symlink should behave better than before. Note: this patch is goes on top of some cleanup patches that are pretty boring and thus I'm not posting them, so it might not apply cleanly. So here's the reason why we use the following scheme for htis, rather than just alias names. And that's simply because a name in /dev can refer to different things during runtime and we cannot model this with aliases. So, basically, if you plug in Disk X first, and Disk Y second, then a swap device symlink /dev/foobar might point to /dev/sda5. But if you plug them in in a different order, then /dev/foobar will point to /dev/sdb5, instead. So initially we have one swap device that is exposed as both /dev/sda5 + /dev/foobar, and then later one that is exposed as /dev/sdb5 + /dev/foobar. Now, if some component depends on /dev/sda5 being enabled as swap, and another component that depends on /dev/foobar being enabled as swap, and we just alias the same object under both names, this will work fine first. But what happens if the swap device goes away and comes back as /dev/sdb5, now you have to split up the names again, since /dev/sda5 stays with the old device unit, but /dev/foobar has to be directed to the new one. And then you'd have to figure out which service depended on which unit name, and fix the dep tree. This basically means that we'd have to have to tracks deps as for names rather than units. But that would drastically complicate things. Instead we chose to let all .swap and .device units live independently under each name, but make them follow other units as needed, and truncate the follow chain when appropriate. In other words: - Unit aliases are useful where the same alias is always assigned to the same unit, and this never changes, except when systemctl daemon-reload is executed. - The following scheme is useful where an alias might dynamically be assigned to different units during runtime, and this can change at any time, without needing systemctl daemon-reload. As a background, it kind of mirrors what udev does with symlinks. Multiple devices can claim the same symlink name at the same time, while only one of them is created in /dev at a given time. Which of the devices actually owns the currently created one in /dev depends on the specified device priority. If no priority is given, it's *usually* the device with the last active event. When a device goes away, and with it the symlink that is the currently created one, the symlink of the device with the next highest priority gets created instead of the one that disappeared. For every symlink in /dev, there is a stack of devices maintained, which can claim the link. Every device change/event re-evaluates which of the devices in the stack should actually get the created/active link. Cheers, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Sun, Oct 21, 2012 at 1:05 AM, Lennart Poettering lenn...@poettering.net wrote: Heya, I have now found the time to document the journal file format: http://www.freedesktop.org/wiki/Software/systemd/journal-files Comments welcome! (Replying directly to this as I want to start another sub-thread...) I'm currently searching for a logging system that has the following feature, which I'm guessing could also be beneficial for systemd on larger systems: * I have multiple processes that I want to log individually; by multiple I mean about 100+ in total (not necessarily on the same system); * moreover these processes are quite dynamic (as in spawn / terminate) hourly or daily; * I need to control the retention policy per process not per entire system; * if needed I want to be able to archive these logs in a per-process (or process type) basis; * as bonus I would like to be able to migrate the logs for a particular process to another system; (In case anyone is wondering what I'm describing, it is a PaaS logging system similar with Heroku's logplex, etc.) The parallel with systemd: * think instead of my processes, of user-sessions and services; (I want to keep some service's (like `sshd`) logs for more time than I want it for DHCP, etc.); * then think about having a journal collecting journals from multiple machines in a central repository; As such, wouldn't a clustering key (like service type, or service type + pid, etc.) would make sense? This would imply: * splitting storage based on this clustering key; (not necessarily one per file, but maybe using some consistent hashing technique, etc.) * having the clustering key as a parameter for querying to restrict index search, etc. Of course all what I've described in the beginning could be emulated with the current journal, either by introducing a special field, or by using the journal library with multiple files (which I haven't checked if it is possible). Ciprian. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 18:48, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: - We needed something with in-line compression, and where we can add stuff like FSS to Ok. I agree that there are very few libraries that fit here. All I can think of making into here would be BerkeleyDB (but it fails other requirements you've listed below). I used BDB in one other project and it makes me shudder. The constant ABI breakages and disk corruptions where aful. Heck, yum as one user of it breaks every second Fedora release with a BDB error where the usual recipe is to remove the yum BDB database so that it is regenerated on next invocation. I am pretty much through with BDB. - The database should be typeless, and index by all fields, rather than require fixed schemas. It should efficient with large and binary data. One thing bothers me: why should it index all fields? (For example indexing by UID, executable, service, etc. makes sense, but I don't think indexing by message is that worthwhile... Moreover by PID or coredump (which I think it is hinted is stored in the journal) doesn't make too much sense either...) Sure, not all fields make sense, but many many do, and we don't really know in advance which ones will, as the vocabulary can be extended by anybody. For example, if Apache decided to do structured logging for errors indexed vserver, then I'd love that, but of course the vserver match would be unknown to everybody else. And that's cool. So, the idea here is really to just index everything, and make it cheap so that if something actually never made sense to be indexed is cheap. In the journal file format indexing field objects that are only referenced once is practically free, as instead of storing an offset to the bsearch object we use for indexing we just store the offset of the referencing entry in-line. - It should not require file locks or communication between multiple readers or between readers and the writer. This is primarily a question of security (we cannot allow users to lock out root or the writer from acessing the logs by taking a lock) and network transparency (file locks on network FS are very very flaky), but also performance. From what I see this is the best reason for the current proposal. Indeed no embedded database library (that I know of) allows both reading and writing at the same time from multiple processes without locking. (Except maybe DJB's CDB and the TinyCDB implementation, but that wouldn't fit the bill here.) Maybe this should go at the top of that document as describing why?. I have added a link to this very thread to the document now to the first section of the document. Although I partially agree about this increased flexibility, having a custom format means it is very easy to just start adding features, thus accumulating cruft... Thus maybe a general purpose system would have limited this tendency... Well, we really try hard to stay focussed, and want the journal to do the things it does well, but not become a super-flexible store-anything database. Of course, we want to pave the way for future extensions, and that's why we built extensibility into the format (and there's a section about that in the spec). BTW, a little bit off-topic: * why didn't you try to implement this journal system as a standalone library, that could have been reused by other systems independently of systemd; (I know this was answered in [2], and that the focus is on systemd, but it seems it took quite a lot of work, and it's a pity it can't be individually reused); Well, for starters we want to be careful where we guarantee interface stability and where not. For example, the C API gives you a very high-level view on the journals, where interleaving of multiple files is hidden. However, if we'd split this out then we'd have to expose much more guts of the implementation, and provide stable API for that, and that's something I don't want. WE want the ability to change the internals of the implementation around and guarantee stability only at the most high level C API that hides it all. The other thing is simply that the stuff is really integrated with each other. The journal sources are small because we reuse a lot of internal C APIs of systemd, and the format exposes a lot of things that are specific to systemd, for example the vocabulary of well-known fields is closely bound to systemd. Also, we believe in the systemd, and in the journal and tight integration between the two, as we consider logging an essential facet of service management. It would be against our goals here to separate them out and turn them back into non-integrated components. * how do you intend to implement something resembly syslog's log centralization? The network model existing since day one is one where we rely on existing file sharing infrastructure to transfer/collect files. I.e. use NFS, SMB, FTP,
Re: [systemd-devel] journald reliability
On Fri, 19.10.12 00:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I think the only real way to solve this cleanly is to extend the kernel to provide SCM_CREDENTIAL and SCM_SECURITY-like auxiliary messages that carries the information we need. More specifically I am hoping that we can get SCM_AUDIT (for the loginuid + sessionid of a process), SCM_EXECINFO (for exe, comm, cmdline), SCM_CGROUP (for cgroup membership). With that we should have all data we need in a safe and secure way. So basically it all comes down to fixing the kernel... Yeah, unfortunately. I remember that maemo used to have issues with syslog blocking. They basically ran into a priority inversion problem, where RT threads ended up waiting for the non-RT syslog. I think large qlen are a pretty good solution for this. OK, but let's say that we have 1000 processes generating messages. journald would be overrun anyway, no matter what the queue size actually is. That is a valid concern. But at one point you *must* make a cut, and say OK, this is now getting way too much, now it is better to drop rather than collecting more and more and more and DoSing the system for good. Which is what we do, though admittedly much too early, but where adding a socktopt for the queue size would help. That said, we probably could improve this worst case scenario a bit. For example, for the syslog forwarding we recently added a scheme where we'd count how much we dropped and we would log this counter as soon as the queue gets unclogged. We did this on request of the HA guys who basically said it's OK if you drop, but you need to tell us about that. So maybe we shoud apply this to log.c and journal-send.c as well, and instead of queing locally we should just count and flush a messages about that when things get unclogged? (added this to the TODO list now) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH RFC] swap: use aliases to group swap units for same device
On Tue, Oct 23, 2012 at 05:48:57PM +0200, Kay Sievers wrote: On Tue, Oct 23, 2012 at 5:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 19.10.12 00:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: A series of .swap units following one another are replaced with a single unit with multiple names. The idea is to simplify things for the user: only one swap unit per swap area. It shouldn't matter whether the swap area was activated by systemd or by direct swapon invocation. The kernel name (from /proc/swaps) is preferred, but if swap is configured through a unit file and not active, that name will be used instead. The case where a swap unit refers (What=) to a symlink should behave better than before. Note: this patch is goes on top of some cleanup patches that are pretty boring and thus I'm not posting them, so it might not apply cleanly. So here's the reason why we use the following scheme for htis, rather than just alias names. And that's simply because a name in /dev can refer to different things during runtime and we cannot model this with aliases. [snip] OK, that makes sense. Thank you both for the explanation. So, back to square one: should the user be presented with one swap device for every name the device can be found under? I think it makes for a crappy interface, because it is hard to distinguish (without actually checking), which .swap units refer to the same thing. One option would be to only show the main unit in systemctl listings, and hide all following units. But this creates units which are hidden, so probably not a good idea. Maybe it is enough to change the DESCRIPTION to show the same thing (e.g. the name the kernel uses)? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
On 10/22/2012 11:36 PM, David Miller wrote: From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. If the application doesn't care, it can use the old way (which at least for me, involves string-comparing the driver name ethtool returns, which sucks at best). And applications that care might suddenly have more features, or be more efficient when running on newer kernels.. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
From: Kay Sievers k...@vrfy.org Date: Tue, 23 Oct 2012 12:34:11 +0200 On Tue, Oct 23, 2012 at 8:36 AM, David Miller da...@davemloft.net wrote: From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. That makes not much sense, really. Every new interface would fall into that category. At least I can't see any mis-guidance here. The other devtypes for the major netif types are not that much older. Only interfaces which provide a facility available in another way fall into this category. Thanks for the scarecrow, but no. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, Oct 23, 2012 at 7:33 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 23.10.12 18:48, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: - We needed something with in-line compression, and where we can add stuff like FSS to Ok. I agree that there are very few libraries that fit here. All I can think of making into here would be BerkeleyDB (but it fails other requirements you've listed below). I used BDB in one other project and it makes me shudder. The constant ABI breakages and disk corruptions where aful. Heck, yum as one user of it breaks every second Fedora release with a BDB error where the usual recipe is to remove the yum BDB database so that it is regenerated on next invocation. I am pretty much through with BDB. :) Yes, now I remember... Each time I upgrade BerkeleyDB `isync` and `bogofilter` gets me in hell... So, the idea here is really to just index everything, and make it cheap so that if something actually never made sense to be indexed is cheap. In the journal file format indexing field objects that are only referenced once is practically free, as instead of storing an offset to the bsearch object we use for indexing we just store the offset of the referencing entry in-line. I guess those offsets are quite cheap, and the in-line entry for the once-only data are ok. But (from what I understand) every value you store has to be searched through the file before storing (to see if it already exists as a value). Thus wouldn't this impact CPU usage? BTW, a little bit off-topic: * why didn't you try to implement this journal system as a standalone library, that could have been reused by other systems independently of systemd; (I know this was answered in [2], and that the focus is on systemd, but it seems it took quite a lot of work, and it's a pity it can't be individually reused); Well, for starters we want to be careful where we guarantee interface stability and where not. For example, the C API gives you a very high-level view on the journals, where interleaving of multiple files is hidden. However, if we'd split this out then we'd have to expose much more guts of the implementation, and provide stable API for that, and that's something I don't want. WE want the ability to change the internals of the implementation around and guarantee stability only at the most high level C API that hides it all. The other thing is simply that the stuff is really integrated with each other. The journal sources are small because we reuse a lot of internal C APIs of systemd, and the format exposes a lot of things that are specific to systemd, for example the vocabulary of well-known fields is closely bound to systemd. I understand this issue with the focus. Nevertheless your journal idea sounds nice, and I hope someone will take it and implement it in a standalone variant. (I hope in a native compilable language...) * how do you intend to implement something resembly syslog's log centralization? The network model existing since day one is one where we rely on existing file sharing infrastructure to transfer/collect files. I.e. use NFS, SMB, FTP, WebDAV, SCP, rsync whatever suits you, and make available at one spot, and journactl -m will interleave them as necessary. By interleave you mean only taking note of new files, not actually rewriting the contents. About the NFS (and other shared FS's) as storage backend I'm not that certain... (And the same about the rest of `scp`, `rsync`, etc.) Maybe a command / option (maybe backed by a `ssh` channel a-la `rsync`) to fetch efficiently journal from other machines. (Not as you describe below, which seems geared towards integration, but strictly geared towards collection.) I am curently working on getting log syncing via both a PUSH and PULL model done. This will be based one existing protocols and standards as much as we can (SSH or HTTP/HTTPS as transport, and JSON and more as payload), and is flexible for others to hook into. For example, I think it would be cool if greylog2 and similar software would just pull the data out of the journal on its own, simply via HTTP/JSON. We make everything available to make this smooth, i.e. we provide clients with stable cursors which they can use to restart operation. Aha. Kind of answers my previous question. Thanks for your time, Ciprian. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 19:11, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: On Sun, Oct 21, 2012 at 1:05 AM, Lennart Poettering lenn...@poettering.net wrote: Heya, I have now found the time to document the journal file format: http://www.freedesktop.org/wiki/Software/systemd/journal-files Comments welcome! (Replying directly to this as I want to start another sub-thread...) I'm currently searching for a logging system that has the following feature, which I'm guessing could also be beneficial for systemd on larger systems: * I have multiple processes that I want to log individually; by multiple I mean about 100+ in total (not necessarily on the same system); * moreover these processes are quite dynamic (as in spawn / terminate) hourly or daily; * I need to control the retention policy per process not per entire system; * if needed I want to be able to archive these logs in a per-process (or process type) basis; * as bonus I would like to be able to migrate the logs for a particular process to another system; (In case anyone is wondering what I'm describing, it is a PaaS logging system similar with Heroku's logplex, etc.) The journal currently cannot do this for you, but what it already can is split up the journal per-user. This is done by default only for login users, (i.e. actual human users), but with the SplitMode= setting in journald.conf can be enabled for system users as well, or turned off entirely. We could extend this switch to allow other split-up schemes. But note that the price you pay for interleaving files on display grows with the more you split things up (O(n) being n number of files to interleave), hence we are a bit conservative here, we don't want to push people towards splitting up things too much, unless they have a really good reason to. BTW, are you sure you actually need processes to split up by? Wouldn't services be more appropriate? The parallel with systemd: * think instead of my processes, of user-sessions and services; (I want to keep some service's (like `sshd`) logs for more time than I want it for DHCP, etc.); * then think about having a journal collecting journals from multiple machines in a central repository; As such, wouldn't a clustering key (like service type, or service type + pid, etc.) would make sense? This would imply: * splitting storage based on this clustering key; (not necessarily one per file, but maybe using some consistent hashing technique, etc.) * having the clustering key as a parameter for querying to restrict index search, etc. Not sure I grok this. Of course all what I've described in the beginning could be emulated with the current journal, either by introducing a special field, or by using the journal library with multiple files (which I haven't checked if it is possible). In general our recommendation is to write as much as possible into the journal as payload, and do filtering afterwards rather then before. i.e. the journal should be the centralization point for things, where different views enable different uses. The main reason the current per-user split logic exists is access control, since by splitting things up in files we can easily use FS ACLs for this, instead of introducing a centralized arbitration engine that enforces access rights. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 20:13, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: In the journal file format indexing field objects that are only referenced once is practically free, as instead of storing an offset to the bsearch object we use for indexing we just store the offset of the referencing entry in-line. I guess those offsets are quite cheap, and the in-line entry for the once-only data are ok. But (from what I understand) every value you store has to be searched through the file before storing (to see if it already exists as a value). Thus wouldn't this impact CPU usage? Looking for pre-existing objects is cheap. It's a hashtable, and hence effectively O(1). The hash table should usually be cached in memory quickly. If the hash table gets too full (over 75% fill-level) we simply rotate the file and start anew. This should result in O(1) all across the hash table as collisions should be the exception. The other thing is simply that the stuff is really integrated with each other. The journal sources are small because we reuse a lot of internal C APIs of systemd, and the format exposes a lot of things that are specific to systemd, for example the vocabulary of well-known fields is closely bound to systemd. I understand this issue with the focus. Nevertheless your journal idea sounds nice, and I hope someone will take it and implement it in a standalone variant. (I hope in a native compilable language...) Why? Why would anybody want to use the journal but not systemd? People who have issues with the latter usually are not rational about these things, and probably have a more philosophical/religious issue with systemd, but then will also have the issues with the journal since it follows the same philosophy and thinking. Also, note that the journal file access in libsystemd-journal works fine on non-systemd too. People can just split this off if they want, and use it indepdently of systemd, the same way they already do it with udev. No need to implement anything anew. The network model existing since day one is one where we rely on existing file sharing infrastructure to transfer/collect files. I.e. use NFS, SMB, FTP, WebDAV, SCP, rsync whatever suits you, and make available at one spot, and journactl -m will interleave them as necessary. By interleave you mean only taking note of new files, not actually rewriting the contents. By interleaving I simply mean interleaving on display, i.e. taking various files from various sources, and presenting them as a continous stream, even though they actually come from many sources. Various sources can be: rotated journals, per-user journal files, journal files from containers of the local host, journal files from other hosts, and more. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 23:43, Alexander E. Patrakov (patra...@gmail.com) wrote: 2012/10/21 Lennart Poettering lenn...@poettering.net: Heya, I have now found the time to document the journal file format: http://www.freedesktop.org/wiki/Software/systemd/journal-files Comments welcome! The doc says these two things: 1) The format is designed to be read and written via memory mapping using multiple mapped windows. 2) A reader should verify all offsets and other data as it reads it. This includes checking for alignment and range of offsets in the file, especially before trying to read it via a memory map. I am worried by the fact that it is not specified what happens if a reader tries to read a file manipulated by a bad writer. Namely, the one that repeatedly writes some valid data into the log in order to lure readers into this area, and then truncates or overwrites it in hope to trigger a SIGBUS or something worse in readers. IMHO if a reader cannot trust the concurrent writer of the file to behave nicely, mmap-based reading should be outright banned. So please - either establish and document some kind of trust model between the reader and the writer, or ban mmap-based reading of non-archived journal files completely. Yeah, we never made this explicit or documented this, but precisely this is the reason why per-user journal files which we split off for access control reasons are not actually owned by the users, but simply accessible to users via file systems ACLs: we want to ensure that users cannot truncate the files to cause journald (or another journalctl) to SIGBUS. With ACLs we can give users read access without the ability to modify their own files. With the journal we try to follow the rule that for mmap() there might be a security boundary between readers and writers, but if so, then it must be privileged on the writer side and unprivileged on the read side, and this must be reflected on the access rights of the file. This probably deserves documentation somewhere. (added to the todo list) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH RFC] swap: use aliases to group swap units for same device
On Tue, 23.10.12 18:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Oct 23, 2012 at 05:48:57PM +0200, Kay Sievers wrote: On Tue, Oct 23, 2012 at 5:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 19.10.12 00:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: A series of .swap units following one another are replaced with a single unit with multiple names. The idea is to simplify things for the user: only one swap unit per swap area. It shouldn't matter whether the swap area was activated by systemd or by direct swapon invocation. The kernel name (from /proc/swaps) is preferred, but if swap is configured through a unit file and not active, that name will be used instead. The case where a swap unit refers (What=) to a symlink should behave better than before. Note: this patch is goes on top of some cleanup patches that are pretty boring and thus I'm not posting them, so it might not apply cleanly. So here's the reason why we use the following scheme for htis, rather than just alias names. And that's simply because a name in /dev can refer to different things during runtime and we cannot model this with aliases. [snip] OK, that makes sense. Thank you both for the explanation. So, back to square one: should the user be presented with one swap device for every name the device can be found under? I think it makes for a crappy interface, because it is hard to distinguish (without actually checking), which .swap units refer to the same thing. Yes, this is the idea we had in mind when we invented the follow thingy. One of the swap devices should be selected as primray device and all others follow it. The primary device should probably be the one listed in /proc/swaps. One option would be to only show the main unit in systemctl listings, and hide all following units. But this creates units which are hidden, so probably not a good idea. Yeah, that's already what we do: systemctl does not list units where follow is set. This means that the user will only see one unit in the list, the primary one, which has the most official name. --all will show all of them however. systemctl status also shows you the Following field. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, Oct 23, 2012 at 9:40 PM, Lennart Poettering lenn...@poettering.net wrote: But note that the price you pay for interleaving files on display grows with the more you split things up (O(n) being n number of files to interleave), hence we are a bit conservative here, we don't want to push people towards splitting up things too much, unless they have a really good reason to. By interleaving I guess you mean: when querying for logs the system will have to open all files and read from them at the same time to give the impression of a merged log, sorted by timestamp (or a similar key). In this case in my use-case this is not an issue, as the real-time logs are required for a particular process, and not for the entire system. BTW, are you sure you actually need processes to split up by? Wouldn't services be more appropriate? When I say processes I actually mean: a couple of processes acting together as an integral logical unit. (Like PostgreSQL which has multiple processes which behave as one group.) And the way I see benefiting from systemd would be creating containers (like LXC) for each such process. As such, wouldn't a clustering key (like service type, or service type + pid, etc.) would make sense? This would imply: * splitting storage based on this clustering key; (not necessarily one per file, but maybe using some consistent hashing technique, etc.) * having the clustering key as a parameter for querying to restrict index search, etc. Not sure I grok this. By cluster key I mean a special key that would direct the entry to one log file or another. In the normal case such a cluster key would be the login user name, etc. (This would also allow events from the same source endup in different log files based on this key.) In one word: a way to partition entries into multiple log files, by setting this special field. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix starting swap unit on symlink made it unstoppable
On Sat, 13.10.12 14:24, Olivier Brunel (i.am.jack.m...@gmail.com) wrote:
Starting a swap unit pointing to (What) a symlink (e.g. /dev/mapper/swap
or /dev/disk/by-uuid/...) would have said unit be marked active, follow
the one using the actual device (/dev/{dm-1,sda3}), but that new unit
would be seen as inactive.
Since all requests to stop swap units would follow/redirect to it,
and it is seen inactive, nothing would be done (swapoff never called).
This is because this unit would be treated twice in
swap_process_new_swap, the second call to swap_add_one causing it to
eventually be marked inactive.
Signed-off-by: Olivier Brunel i.am.jack.m...@gmail.com
---
The patch removes the call to udev_device_get_devnode, assuming that
device nodes (and not symlinks) are used under /proc/swaps, which
seems to be the case.
This is not the case on Fedora at least.
swap.c really needs to handle following devices properly (see other
mail). We cut some corners there, and we shouldn't.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, Oct 23, 2012 at 9:49 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 23.10.12 20:13, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: The other thing is simply that the stuff is really integrated with each other. The journal sources are small because we reuse a lot of internal C APIs of systemd, and the format exposes a lot of things that are specific to systemd, for example the vocabulary of well-known fields is closely bound to systemd. I understand this issue with the focus. Nevertheless your journal idea sounds nice, and I hope someone will take it and implement it in a standalone variant. (I hope in a native compilable language...) Why? Why would anybody want to use the journal but not systemd? People who have issues with the latter usually are not rational about these things, and probably have a more philosophical/religious issue with systemd, but then will also have the issues with the journal since it follows the same philosophy and thinking. Ok. Just to state my bias: I'm currently neutral in the SysV / BSD init vs systemd. I **really** do want to get rid of all the Bash-ism initializing my system (actually I would ban Bash from newer projects). But this is a totally different topic which has been discussed on almost all the mailing lists related to Linux that I'm subscribed to... Thus this is not the direction I want to head this discussion. My real motive for such a detached journaling system, I hope is clear from my other sub-thread of this one related with separating log files: that is I'm searching for a logging system suitable for a PaaS... Also, note that the journal file access in libsystemd-journal works fine on non-systemd too. People can just split this off if they want, and use it indepdently of systemd, the same way they already do it with udev. No need to implement anything anew. Aha. So I could reuse the `libsystemd-journal` without any systemd attachments. Good to know. Hope I didn't start a flame-war with this one. :) Ciprian. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 22:02, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: On Tue, Oct 23, 2012 at 9:40 PM, Lennart Poettering lenn...@poettering.net wrote: But note that the price you pay for interleaving files on display grows with the more you split things up (O(n) being n number of files to interleave), hence we are a bit conservative here, we don't want to push people towards splitting up things too much, unless they have a really good reason to. By interleaving I guess you mean: when querying for logs the system will have to open all files and read from them at the same time to give the impression of a merged log, sorted by timestamp (or a similar key). Yes, turning a number of fragments in various files into one stream of monotonically increasing timestamps. BTW, are you sure you actually need processes to split up by? Wouldn't services be more appropriate? When I say processes I actually mean: a couple of processes acting together as an integral logical unit. (Like PostgreSQL which has multiple processes which behave as one group.) Yeah, on systemd that's called a service, and is implemented as as a cgroup on the lower layers. The journal automatically indexes by service. Try journalctl -u avahi-daemon.service to get all messages from avahi, and avahi only. And the way I see benefiting from systemd would be creating containers (like LXC) for each such process. Our story regarding containers (i.e. where a new PID 1 in the container is running on a host system) is that we suggest that each container runs its own journald instance, and generates is own files, but registers that in the host via symlinks in /var/log/journal. See http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface for more info about that. That way journalctl -m on the host will show you all logs from all containers, nicely interleaved. * having the clustering key as a parameter for querying to restrict index search, etc. Not sure I grok this. By cluster key I mean a special key that would direct the entry to one log file or another. In the normal case such a cluster key would be the login user name, etc. (This would also allow events from the same source endup in different log files based on this key.) In one word: a way to partition entries into multiple log files, by setting this special field. As mentioned we have SplitMode= for this, but it is strictly for UIDs only, since we only need this for access control management, nothing else. Why precisely do you want to split up your log files per-service? That's the bit I don't get. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 22:14, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: Why? Why would anybody want to use the journal but not systemd? People who have issues with the latter usually are not rational about these things, and probably have a more philosophical/religious issue with systemd, but then will also have the issues with the journal since it follows the same philosophy and thinking. Ok. Just to state my bias: I'm currently neutral in the SysV / BSD init vs systemd. I **really** do want to get rid of all the Bash-ism initializing my system (actually I would ban Bash from newer projects). But this is a totally different topic which has been discussed on almost all the mailing lists related to Linux that I'm subscribed to... I am sorry I have to ask, but what's wrong with bash? I mean, it's a shell, but what is worse or better than any other shell about it? What's the benefit of dealing with multiple implementations of a shell? Do you want to waste memory, increase your test matrix, complicate the use, yadda, yadda? I really, really don't buy in this Debian ideology of bash is bad, but dash is awesome, that's just intense BS. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, Oct 23, 2012 at 10:18 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 23.10.12 22:02, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: And the way I see benefiting from systemd would be creating containers (like LXC) for each such process. Our story regarding containers (i.e. where a new PID 1 in the container is running on a host system) is that we suggest that each container runs its own journald instance, and generates is own files, but registers that in the host via symlinks in /var/log/journal. See http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface for more info about that. That way journalctl -m on the host will show you all logs from all containers, nicely interleaved. Aha. Thanks for that pointer. (The only issue with this is that I must trust the service running inside the container to do the right thing, which could be a problem if I run untrusted code that I want to isolate.) But I'll give this one a look. In one word: a way to partition entries into multiple log files, by setting this special field. As mentioned we have SplitMode= for this, but it is strictly for UIDs only, since we only need this for access control management, nothing else. This could be another solution to my problem. Allocate a different UID to each service. Why precisely do you want to split up your log files per-service? That's the bit I don't get. Because in the envisaged PaaS, you have components (services) starting and stopping. Thus I want to be able to easily just remove logs for dead services, or maybe just move them to a different archival service where they get deleted after a period of time. It's purely for administrative purposes. Maybe even to allow the user to download these log files independently. But I understand now how to best solve this requirement without touching the core journald. Thanks, Ciprian. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 22:27, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: In one word: a way to partition entries into multiple log files, by setting this special field. As mentioned we have SplitMode= for this, but it is strictly for UIDs only, since we only need this for access control management, nothing else. This could be another solution to my problem. Allocate a different UID to each service. This is what the Pantheon folks are doing. Instead of running full OSes in their containers they run large number of sandboxes services (using systemd's sandboxing logic), each under a UID of their own. Why precisely do you want to split up your log files per-service? That's the bit I don't get. Because in the envisaged PaaS, you have components (services) starting and stopping. Thus I want to be able to easily just remove logs for dead services, or maybe just move them to a different archival service where they get deleted after a period of time. It's purely for administrative purposes. Maybe even to allow the user to download these log files independently. But I understand now how to best solve this requirement without touching the core journald. Well, but with the journal you can easily filter by service. i.e. journalctl -u foobar will give you a stream that only includes messages form service foobar, but it will look otherwise like /var/log/messages looked. So, unless you have access mode restrictions or really really need to make sure that as soon as a container goes away its logs go away too you could just leave everything in a one pool and then filter on display/download. BTW, you with systemd 195 you can do this: snip systemctl enable systemd-journal-gatewayd.socket wget http://localhost:19531/entries?_SYSTEMD_UNIT=foobar.service /snip And this will give you all messages from foobar.service easy for download, even from another host. Or use: wget --header=Accept: application/json http://localhost:19531/entries?_HOSTNAME=waldo And you'll get a JSON formatted dump of all messages for host/container waldo. And you can easily process that then from your web app to present a per-container log stream to the user. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What is wrong with Bash? [Was: Re: [ANNOUNCE] Journal File Format Documentation]
(Ok. I've just opened another can of works... :) Thus I've changed the subject, not to pollute the journal thread with this issue.) :) On Tue, Oct 23, 2012 at 10:22 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 23.10.12 22:14, Ciprian Dorin Craciun (ciprian.crac...@gmail.com) wrote: Ok. Just to state my bias: I'm currently neutral in the SysV / BSD init vs systemd. I **really** do want to get rid of all the Bash-ism initializing my system (actually I would ban Bash from newer projects). But this is a totally different topic which has been discussed on almost all the mailing lists related to Linux that I'm subscribed to... I am sorry I have to ask, but what's wrong with bash? I mean, it's a shell, but what is worse or better than any other shell about it? What's the benefit of dealing with multiple implementations of a shell? Do you want to waste memory, increase your test matrix, complicate the use, yadda, yadda? I really, really don't buy in this Debian ideology of bash is bad, but dash is awesome, that's just intense BS. Well there's nothing wrong with Bash. I use it extensively in my projects. Just to give some context: I think I've tried almost every sh-flavoured implementation out there: from `ash` (busybox) to `dash`, even Plan9's `rc`, then going through Scheme's `scsh`. Then why would I ban it from projects: because developers (me included half of the times) aren't able to write correct Bash scripts that won't blow in thousands of different subtle ways when dealing with corner cases. Just to give a few hints about what makes me made in Bash: * variable expansion quoting: people always forget to put the $x in the damn double quotes, thus god forbid a space finds it's way in there... * error handling is optional and having reliable error checking is still an unknown for me; (yes I know about `set -E -e -u -o pipefail ...` but that has such subtle issues with subshels, and other features that I still don't know all the rules;) * it is almost impossible to write non-trivial reusable libraries; (I've tried it and it's the most horrible piece of code I have ever written...); * handling signals is a pain... * handling and controlling multiple processes is a joke... (just `` doesn't scale, and I know of `coproc`, only one at a time is supported); (I could keep like this for hours...) Thus to conclude: I would love a UNIX process assembly language. But Bash (or any other `sh` replacement, except maybe `scsh`) is not that one... Ciprian. P.S.: Writing everything in C is not an option due to the low productivity. Maybe Go is the answer... (But I can't find their process composition library... Because there is none...) :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix starting swap unit on symlink made it unstoppable
On 10/23/12 21:05, Lennart Poettering wrote:
On Sat, 13.10.12 14:24, Olivier Brunel (i.am.jack.m...@gmail.com) wrote:
Starting a swap unit pointing to (What) a symlink (e.g. /dev/mapper/swap
or /dev/disk/by-uuid/...) would have said unit be marked active, follow
the one using the actual device (/dev/{dm-1,sda3}), but that new unit
would be seen as inactive.
Since all requests to stop swap units would follow/redirect to it,
and it is seen inactive, nothing would be done (swapoff never called).
This is because this unit would be treated twice in
swap_process_new_swap, the second call to swap_add_one causing it to
eventually be marked inactive.
Signed-off-by: Olivier Brunel i.am.jack.m...@gmail.com
---
The patch removes the call to udev_device_get_devnode, assuming that
device nodes (and not symlinks) are used under /proc/swaps, which
seems to be the case.
This is not the case on Fedora at least.
Oh? I assumed it would be more of a kernel thing, so likely to be the
same everywhere. Also, a quick test in a VM running FC17, when I enable
a swap on /dev/mapper/foo it gets listed as /dev/dm-2 under /proc/swaps,
aka where the symlink points to.
Anyhow...
swap.c really needs to handle following devices properly (see other
mail). We cut some corners there, and we shouldn't.
Does that mean keeping the call to udev_device_get_devnode and simply
using strcmp to make sure the same unit isn't processed twice (which
causes the bug) isn't enough?
At least AFAICS it does fix the bug, and the following seems to be
working fine.
-j
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journalctl | grep -v mail.*
I'm trying to learn journalctl a bit. I'd prefer if I could do a grep -v, but in journalctl using some argument, e.g. -v. E.g. show me all the logs _except_ mail related things: $ journalctl -v -f SYSLOG_FACILITY=2 ideally (could this be implemented?): $ journalctl -v -f SYSLOG_FACILITY=mail I noticed the SYSLOG_FACILITY for postfix is given as 2, shouldn't that be 16? In /usr/include/sys/syslog.h it has 23 for LOG_MAIL, I'd expect that to be in SYSLOG_FACILITY. At the moment I'm still using rsyslog and /etc/syslog.conf allows me to redirect mail related things just fine, example: mail.=debug;mail.=info;mail.=notice -/var/log/mail/info.log Goal: something funny is going on, no clue what is causing it, but not mail messages. They should not be shown as they clutter the output. Maybe you want an entire expression thing on the command line, like find has. At the moment a -v would be more than enough for me. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On 10/23/2012 06:40 PM, Lennart Poettering wrote: The journal currently cannot do this for you, but what it already can is split up the journal per-user. This is done by default only for login users, (i.e. actual human users), but with the SplitMode= setting in journald.conf can be enabled for system users as well, or turned off entirely. We could extend this switch to allow other split-up schemes. But note that the price you pay for interleaving files on display grows with the more you split things up (O(n) being n number of files to interleave), hence we are a bit conservative here, we don't want to push people towards splitting up things too much, unless they have a really good reason to. If I'm understanding this correctly would it not better simply/suffician support splitting the journal up via cli instead of doing it real time ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl | grep -v mail.*
On Tue, 23.10.12 22:38, Olav Vitters (o...@vitters.nl) wrote: I'm trying to learn journalctl a bit. I'd prefer if I could do a grep -v, but in journalctl using some argument, e.g. -v. Negative filtering (i.e. not foo=bar, but foo!=bar) is currently not implemented. I have figured out how to implement this relatively efficiently now, but this will take some time to implement. It's on the TODO list. I noticed the SYSLOG_FACILITY for postfix is given as 2, shouldn't that be 16? In /usr/include/sys/syslog.h it has 23 for LOG_MAIL, I'd expect that to be in SYSLOG_FACILITY. At the moment I'm still using rsyslog and /etc/syslog.conf allows me to redirect mail related things just fine, example: mail.=debug;mail.=info;mail.=notice -/var/log/mail/info.log The full syslog priority field is decoded into PRIORITY= and SYSLOG_FACILITY=, so that it is easy to filter for them independently. The latter has the SYSLOG_ prefix since we consider a bit of an outdated concept. 20 numeric facilities are quite limited, and it is _SYSTEMD_UNIT= usually a much better way to filter things. We do store it however, in order not to lose any data. Messages that are not genreated via syslog( )wil not carry SYSLOG_FACILITY= however, but they will carry the log priority, since that is generally useful functionality. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On Tue, 23.10.12 20:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 10/23/2012 06:40 PM, Lennart Poettering wrote: The journal currently cannot do this for you, but what it already can is split up the journal per-user. This is done by default only for login users, (i.e. actual human users), but with the SplitMode= setting in journald.conf can be enabled for system users as well, or turned off entirely. We could extend this switch to allow other split-up schemes. But note that the price you pay for interleaving files on display grows with the more you split things up (O(n) being n number of files to interleave), hence we are a bit conservative here, we don't want to push people towards splitting up things too much, unless they have a really good reason to. If I'm understanding this correctly would it not better simply/suffician support splitting the journal up via cli instead of doing it real time ? We might add this as a tool one day, but I think it's a good rule to write logs once, and not touch them afterwrads if at all possible, in order not to corrupt what is already written safely. Hence: it's probably a good idea to focus on writing things the right way the first time, instead of focusing on on rewriting them afterwards. Related to the tool you are suggesting I think a tool to merge split off files might be very useful too, to counter the scalability issues of interleaving too many separate files on display. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Journal File Format Documentation
On 10/23/2012 09:19 PM, Lennart Poettering wrote: Related to the tool you are suggesting I think a tool to merge split off files might be very useful too, to counter the scalability issues of interleaving too many separate files on display. Yeah an extension to the journalctl and probably users would like to do as the part of the process when the journal files get rotated on disk ( rotate -- split ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl | grep -v mail.*
On Tue, Oct 23, 2012 at 11:13:32PM +0200, Lennart Poettering wrote: On Tue, 23.10.12 22:38, Olav Vitters (o...@vitters.nl) wrote: I'm trying to learn journalctl a bit. I'd prefer if I could do a grep -v, but in journalctl using some argument, e.g. -v. Negative filtering (i.e. not foo=bar, but foo!=bar) is currently not implemented. I have figured out how to implement this relatively efficiently now, but this will take some time to implement. It's on the TODO list. Cool! I noticed the SYSLOG_FACILITY for postfix is given as 2, shouldn't that be 16? In /usr/include/sys/syslog.h it has 23 for LOG_MAIL, I'd expect that to be in SYSLOG_FACILITY. At the moment I'm still using rsyslog and /etc/syslog.conf allows me to redirect mail related things just fine, example: mail.=debug;mail.=info;mail.=notice -/var/log/mail/info.log The full syslog priority field is decoded into PRIORITY= and SYSLOG_FACILITY=, so that it is easy to filter for them independently. The latter has the SYSLOG_ prefix since we consider a bit of an outdated concept. 20 numeric facilities are quite limited, and it is _SYSTEMD_UNIT= usually a much better way to filter things. We do store it however, in order not to lose any data. I know there are better ways, but for me it is way easier to reuse some existing knowledge. The priority I don't care that much about at the moment, the colours added by journalctl seems to be good enough for now. Logging the mail stuff into multiple files is the way Mageia/Mandriva set it up. Messages that are not genreated via syslog( )wil not carry SYSLOG_FACILITY= however, but they will carry the log priority, since that is generally useful functionality. Postfix should be using mail / 16 as priority, otherwise rsyslog wouldn't have filtered that into /var/log/mail/info.log. And I guess if it didn't use syslog, it shouldn't have SYSLOG_FACILITY. However, I see things like: $ journalctl -n1 -o export SYSLOG_FACILITY=2 __CURSOR=s=d58b63a971464dc0ae21bc409d611941;i=d742;b=3ae5edd0461841d69be6e46800ec3f3b;m=52ffd54860;t=4ccc0b1ec92f9;x=2526026ee985410d __REALTIME_TIMESTAMP=1351027897701113 __MONOTONIC_TIMESTAMP=356479486048 _BOOT_ID=3ae5edd0461841d69be6e46800ec3f3b _TRANSPORT=syslog PRIORITY=6 SYSLOG_FACILITY=2 SYSLOG_IDENTIFIER=postfix/qmgr SYSLOG_PID=2193 MESSAGE=1842050036E: removed _PID=2193 _UID=489 _GID=484 _COMM=qmgr _EXE=/usr/lib64/postfix/qmgr _CMDLINE=qmgr -l -t fifo -u -c _SYSTEMD_CGROUP=/system/postfix.service _SYSTEMD_UNIT=postfix.service _SOURCE_REALTIME_TIMESTAMP=1351027897700510 _MACHINE_ID=73d0b740d3400a0f495236640206 _HOSTNAME=bkor.dhs.org Here, the SYSLOG_FACILITY should have read 16, or am I mistaken? Note that I'm not yet storing things on disk. I assume/hope Mageia will do that soon. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
On Tue, 2012-10-23 at 09:14 -0700, Ben Greear wrote: On 10/22/2012 11:36 PM, David Miller wrote: From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. If the application doesn't care, it can use the old way (which at least for me, involves string-comparing the driver name ethtool returns, which sucks at best). The 'old way' that has only worked since Linux 2.6.29 (3.5 years)? The 'right way' seems to be to query for VLAN information through netlink. But that has only worked since Linux 2.6.23 (5 years ago). The real 'old way' is to use SIOCGIFVLAN. :-/ And applications that care might suddenly have more features, or be more efficient when running on newer kernels.. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vlan: set sysfs device_type to 'vlan'
On 10/23/2012 03:52 PM, Ben Hutchings wrote: On Tue, 2012-10-23 at 09:14 -0700, Ben Greear wrote: On 10/22/2012 11:36 PM, David Miller wrote: From: Doug Goldstein car...@cardoe.com Date: Mon, 22 Oct 2012 00:53:57 -0500 Sets the sysfs device_type to 'vlan' for udev. This makes it easier for applications that query network information via udev to identify vlans instead of using strrchr(). Signed-off-by: Doug Goldstein car...@cardoe.com You're extremely misguided. This change, in fact, makes it ten times harder for such applications to query such devices. If the application doesn't care, it can use the old way (which at least for me, involves string-comparing the driver name ethtool returns, which sucks at best). The 'old way' that has only worked since Linux 2.6.29 (3.5 years)? The 'right way' seems to be to query for VLAN information through netlink. But that has only worked since Linux 2.6.23 (5 years ago). The real 'old way' is to use SIOCGIFVLAN. :-/ Oh, I have the SIOCGIFVLAN fallback in place too. But none of this is easy from a shell script, where reading a sysfs file is quite easy. Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
