Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
Hi, I have attached the rebased updated patch. I am working on git and I can't run make all update-man-list. Sorry for the trouble. Thanks On Mon, Apr 22, 2013 at 10:13 PM, Tom Gundersen t...@jklm.no wrote: On Mon, Apr 22, 2013 at 6:37 PM, Kay Sievers k...@vrfy.org wrote: On Mon, Apr 22, 2013 at 6:27 PM, Tom Gundersen t...@jklm.no wrote: On Mon, Apr 22, 2013 at 5:13 PM, Umut Tezduyar u...@tezduyar.com wrote: The way I see it is systemd-tmpfiles-setup.service is no different than systemd-static-nodes.service except later is restricted to /dev and runs before udev. Hm, if we want to take that view, then it might make sense to rename it systemd-tmpfiles-setup-dev.service (or something like that). I don't have a strong opinion either way. Yeah, I think that makes sense. Ok. I pushed the rename. Umut, if you post a rebase of your patch I'll apply it. Cheers, Tom 0001-man-link-systemd-tmpfiles-setup-dev.service.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
'Twas brillig, and Josh Triplett at 22/04/13 22:53 did gyre and gimble: On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. From what I gather what you're trying to solve here is a packaging problem - i.e. that multiple packages may have a requirement for a given user to exist and that if said packages are removed, the user should disappear again? If that is the case, then shouldn't the code actually be part of a packaging helper script rather than managed by a daemon? Also, if there is a .d folder setup here who owns those files? e.g. if I have postfix and cyrus-imapd packages, both will want the mail user. In that case who owns the /usr/lib/passwd.d/news file? They kinda both do need to provide that file, but that's wrong in and off itself - you'd be better creating a structure for this. Also the nothing uses the UID or GID anymore test is a bit hard is it not? I mean we'd have to check all file ownership and ACL entries on all mounted filesystems would we not? Sounds like a bad idea to me. All in all I still thing this is better handled by packaging helper scripts. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
2013/4/23 Josh Triplett j...@joshtriplett.org On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. :) realy need new bike? please see http://www.openwall.com/tcb/ This alternative to /etc/shadow in ALTLinux sinse 2000. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
On Tue, Apr 23, 2013 at 10:06 AM, Umut Tezduyar u...@tezduyar.com wrote: I have attached the rebased updated patch. Applied. I am working on git and I can't run make all update-man-list. Sorry for the trouble. I just added it to your patch. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
2013/4/23 Alexey Shabalin a.shaba...@gmail.com 2013/4/23 Josh Triplett j...@joshtriplett.org On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. :) realy need new bike? please see http://www.openwall.com/tcb/ This alternative to /etc/shadow in ALTLinux sinse 2000. sorry, TCB support only shadow in different files, not passwd and group. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Alexey Shabalin -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. How would we notice showing up for system ids which will not go through pam? This will only work for things logging-in or authenticating otherwise, right? Or did you mean nss lookups? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. How do we find out that there is nothing on the file system? 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. You mean user namespaces here? Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. How would installing a setgid tool from a package work? When would the tool get the right gid assigned at installation time? That stuff needs to be verifiable, we would record these ownerships somewhere else to be able to reproduce them? How do we cover the magic numbers recorded in the inodes of persistent filesystems? Unfortunately they don't work like 'tar' and have only the ids and not the names in it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 12:26 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem More of this type of comments and you will have a problem posting on this list. If you are unable to moderate your style yourself, I will do that for you, no problem. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
Am 23.04.2013 13:33, schrieb Kay Sievers: On Tue, Apr 23, 2013 at 12:26 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem More of this type of comments and you will have a problem posting on this list. If you are unable to moderate your style yourself, I will do that for you, no problem sorry but you are hyper-sensible there was no single bad word and Leave only root in /etc/passwd and /etc/group is a proposal which can not be a design target because it is from the sort of i propose to throw anything away how user-management works and any downstream distribution should change later with breaking any compatibility 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] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 2:38 PM, Reindl Harald h.rei...@thelounge.net wrote: More of this type of comments and you will have a problem posting on this list. If you are unable to moderate your style yourself, I will do that for you, no problem sorry but you are hyper-sensible I just have enough of your attitude and comments. You are on moderation now. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-analyse: add tree command
From: Harald Hoyer har...@redhat.com tree prints a tree of the critical chain of units $ ./systemd-analyze tree graphical.target @1.226s └─multi-user.target @1.226s └─nfs-lock.service @961ms +265ms └─rpcbind.service @958ms +1ms └─network.target @957ms └─NetworkManager.service @434ms +522ms └─basic.target @428ms └─sockets.target @428ms └─dbus.socket @428ms └─sysinit.target @427ms └─systemd-tmpfiles-setup.service @411ms +15ms └─local-fs.target @410ms └─boot-efi.automount @410ms └─boot.mount @397ms +9ms └─local-fs-pre.target @192ms └─systemd-udevd.service @187ms +5ms └─systemd-udevd-control.socket @140ms └─-.mount With the --fuzz=ms parameter one can display more units around the critical units. $ ./systemd-analyze --fuzz=10 tree └─multi-user.target @1.226s └─nfs-lock.service @961ms +265ms ├─rpcbind.service @958ms +1ms │ └─network.target @957ms │ └─NetworkManager.service @434ms +522ms │ ├─basic.target @428ms │ │ ├─sockets.target @428ms │ │ │ ├─dbus.socket @428ms │ │ │ │ └─sysinit.target @427ms │ │ │ │ ├─systemd-tmpfiles-setup.service @411ms +15ms │ │ │ │ │ └─local-fs.target @410ms │ │ │ │ │ └─boot-efi.automount @410ms │ │ │ │ │ └─boot.mount @397ms +9ms │ │ │ │ │ └─local-fs-pre.target @192ms │ │ │ │ │ └─systemd-udevd.service @187ms +5ms │ │ │ │ │ ├─systemd-udevd-control.socket @140ms │ │ │ │ │ │ └─-.mount │ │ │ │ │ └─systemd-udevd-kernel.socket @140ms │ │ │ │ └─swap.target @421ms │ │ │ │ └─dev-disk-by\x2duuid-swap @414ms +6ms │ │ │ │ └─systemd-journald.socket │ │ │ ├─rpcbind.socket @428ms │ │ │ └─cups.socket @428ms │ │ ├─paths.target @428ms │ │ │ └─cups.path @428ms │ │ ├─timers.target @427ms │ │ │ └─systemd-tmpfiles-clean.timer @427ms │ │ └─sysinit.target @427ms │ │ └─... │ └─dbus.socket @428ms │ └─... └─network.target @957ms └─... --- man/systemd-analyze.xml | 27 src/analyze/systemd-analyze.c | 345 +- 2 files changed, 370 insertions(+), 2 deletions(-) diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index 9f313d7..a084c64 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -34,6 +34,12 @@ surnamePoettering/surname emaillenn...@poettering.net/email /author +author +contribDeveloper/contrib +firstnameHarald/firstname +surnameHoyer/surname +emailhar...@redhat.com/email +/author /authorgroup /refentryinfo @@ -55,6 +61,9 @@ commandsystemd-analyze arg choice=opt rep=repeatOPTIONS/arg blame /command /cmdsynopsis cmdsynopsis +commandsystemd-analyze arg choice=opt rep=repeatOPTIONS/arg tree /command +/cmdsynopsis +cmdsynopsis commandsystemd-analyze arg choice=opt rep=repeatOPTIONS/arg plot arg choice=optgt; file.svg/arg/command /cmdsynopsis cmdsynopsis @@ -88,6 +97,13 @@ be slow simply because it waits for the initialization of another service to complete./para +paracommandsystemd-analyze tree/command prints +a tree of the critical chain of units. +Note that the output might be misleading as the +initialization of one service might depend on socket +activation and because of the parallel execution +of units./para + paracommandsystemd-analyze plot/command prints an SVG graphic detailing which system services have been started at what time, highlighting the time they @@ -181,6 +197,17 @@ unit name must match one of given values./para/listitem /varlistentry + +varlistentry + termoption--fuzz=/optionlt;milliseconds/term + +listitemparaWhen used in +conjunction with the +commandtree/command command (see +above), also show services, which
Re: [systemd-devel] [PATCH] systemd-analyse: add tree command
On Tue, 23.04.13 15:04, har...@redhat.com (har...@redhat.com) wrote:
From: Harald Hoyer har...@redhat.com
tree prints a tree of the critical chain of units
Really nice work! However, maybe the name tree is suboptimal? You
already say critical chain, maybe we should name it something like
this too? Esepcially, since by default it's not a tree at all...
Maybe systemd-analyze time-chain or systemd-analyze critical-chain
or so? Anybody else got ideas?
With the --fuzz=ms parameter one can display more units around
the critical units.
As mentioned on Google+, we really should treat all time units uniformly
and encode them internally in usec_t, and parse them via parse_sec().
+paracommandsystemd-analyze tree/command prints
+a tree of the critical chain of units.
+Note that the output might be misleading as the
+initialization of one service might depend on socket
+activation and because of the parallel execution
+of units./para
Needs to mention that this means critical as in time not as in
importance...
+static int list_dependencies_print(const char *name, int level, unsigned int
branches,
+ bool last, struct unit_times *times,
struct boot_times *boot) {
+int i;
+char ts[FORMAT_TIMESPAN_MAX], ts2[FORMAT_TIMESPAN_MAX];
Nitpick: in most areas of systemd we tried to use unsigned rather than
int, where signedness never makes sense. int is more often than not
just the type people will default when they just need a variable, but I
think we should always think about the valid range of a variable when
declaring it.
+
+for (i = level - 1; i = 0; i--) {
+printf(%s, draw_special_char(branches (1 i) ?
DRAW_TREE_VERT : DRAW_TREE_SPACE));
+}
Single-line blocks please without {}.
+for (i = 0; i n; i++) {
+hashmap_put(h, times[i].name, times[i]);
+}
Same here. Also, lacks failure check (OOM...).
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] systemd: fall back to mounting /sys/fs/cgroup sans xattr
On Mon, 2013-04-22 at 22:10 -0400, Zbigniew Jędrzejewski-Szmek wrote: xattrs on cgroup fs were added back in v3.6-rc3-3-g03b1cde. But we support kernels = 2.6.39, and we also support kernels compiled w/o xattr support, so it's better to fall back to mounting without xattr support. Yes this works; just applied the patch on top of your previous one in gnome-ostree buildmaster and booted in qemu. Tested-by: Colin Walters walt...@verbum.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] systemd-python: add SYSLOG_IDENTIFIER to JournalHandler
On Mon, Apr 22, 2013 at 11:31 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
Otherwise, we get SYSLOG_IDENTIFIER=python or something
similar, which is completely useless.
I think we shouldn't be creating one-off arguments for every possible
field someone might want to add, but something more generic -- take a
dict as argument for example.
Ideally it would be possible to attach custom journal fields to the
Python root logger and have them propagate to all loggers from there.
But I tried and couldn't make it work without the code getting really
ugly. Here are some of my thoughts on the topic:
http://lists.freedesktop.org/archives/systemd-devel/2012-October/006937.html
And a reply:
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007372.html
Note that Python's SysLogHandler has something vaguely similar, but
it's pretty annoying to use. It's not a constructor argument, but an
attribute you have to override and is simply prepended to the syslog
message so you also have to include the separating colon and space
(like in the C syslog API).
import logging, logging.handlers
h=logging.handlers.SysLogHandler(address='/dev/log')
h.ident='somename: '
l= logging.getLogger('froggerlogger')
l.propagate = False
l.addHandler(h)
l.warning('foo')
Regards,
Marti
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH V2] systemd-analyse: add critical-chain command
From: Harald Hoyer har...@redhat.com critical-chain prints a tree of the critical chain of units $ ./systemd-analyze critical-chain graphical.target @1.226s └─multi-user.target @1.226s └─nfs-lock.service @961ms +265ms └─rpcbind.service @958ms +1ms └─network.target @957ms └─NetworkManager.service @434ms +522ms └─basic.target @428ms └─sockets.target @428ms └─dbus.socket @428ms └─sysinit.target @427ms └─systemd-tmpfiles-setup.service @411ms +15ms └─local-fs.target @410ms └─boot-efi.automount @410ms └─boot.mount @397ms +9ms └─local-fs-pre.target @192ms └─systemd-udevd.service @187ms +5ms └─systemd-udevd-control.socket @140ms └─-.mount With the --fuzz=ms parameter one can display more units around the critical units. $ ./systemd-analyze --fuzz=10 critical-chain └─multi-user.target @1.226s └─nfs-lock.service @961ms +265ms ├─rpcbind.service @958ms +1ms │ └─network.target @957ms │ └─NetworkManager.service @434ms +522ms │ ├─basic.target @428ms │ │ ├─sockets.target @428ms │ │ │ ├─dbus.socket @428ms │ │ │ │ └─sysinit.target @427ms │ │ │ │ ├─systemd-tmpfiles-setup.service @411ms +15ms │ │ │ │ │ └─local-fs.target @410ms │ │ │ │ │ └─boot-efi.automount @410ms │ │ │ │ │ └─boot.mount @397ms +9ms │ │ │ │ │ └─local-fs-pre.target @192ms │ │ │ │ │ └─systemd-udevd.service @187ms +5ms │ │ │ │ │ ├─systemd-udevd-control.socket @140ms │ │ │ │ │ │ └─-.mount │ │ │ │ │ └─systemd-udevd-kernel.socket @140ms │ │ │ │ └─swap.target @421ms │ │ │ │ └─dev-disk-by\x2duuid-swap @414ms +6ms │ │ │ │ └─systemd-journald.socket │ │ │ ├─rpcbind.socket @428ms │ │ │ └─cups.socket @428ms │ │ ├─paths.target @428ms │ │ │ └─cups.path @428ms │ │ ├─timers.target @427ms │ │ │ └─systemd-tmpfiles-clean.timer @427ms │ │ └─sysinit.target @427ms │ │ └─... │ └─dbus.socket @428ms │ └─... └─network.target @957ms └─... --- - renamed tree to critical-chain - use parse_sec() - clarify time critical - code beautification man/systemd-analyze.xml | 28 src/analyze/systemd-analyze.c | 348 +- 2 files changed, 374 insertions(+), 2 deletions(-) diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index 9f313d7..8a9e58c 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -34,6 +34,12 @@ surnamePoettering/surname emaillenn...@poettering.net/email /author +author +contribDeveloper/contrib +firstnameHarald/firstname +surnameHoyer/surname +emailhar...@redhat.com/email +/author /authorgroup /refentryinfo @@ -55,6 +61,9 @@ commandsystemd-analyze arg choice=opt rep=repeatOPTIONS/arg blame /command /cmdsynopsis cmdsynopsis +commandsystemd-analyze arg choice=opt rep=repeatOPTIONS/arg critical-chain /command +/cmdsynopsis +cmdsynopsis commandsystemd-analyze arg choice=opt rep=repeatOPTIONS/arg plot arg choice=optgt; file.svg/arg/command /cmdsynopsis cmdsynopsis @@ -88,6 +97,13 @@ be slow simply because it waits for the initialization of another service to complete./para +paracommandsystemd-analyze critical-chains/command +prints a tree of the time critical chain of units. +Note that the output might be misleading as the +initialization of one service might depend on socket +activation and because of the parallel execution +of units./para + paracommandsystemd-analyze plot/command prints an SVG graphic detailing which system services have been started at what time, highlighting the time they @@ -181,6 +197,18 @@ unit name must match one of given values./para/listitem /varlistentry + +varlistentry + termoption--fuzz=/optionlt;timespan/term + +listitemparaWhen used in conjunction +
[systemd-devel] [RFC][PATCH] Escape unit name from udev
This patch escapes a unit name which was derived from udev.
Please imagine following udev rule.
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%p.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%r.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%S.service
When unit name is derived from udev via
udev_device_get_property_value(), the name may contains '/' if
ENV{SYSTEMD_WANTS} has the udev options $devpath(%p), $root(%r), or
$sys(%S). However, '/' is a invalid char for unit name so processing
of this rule fails as Invalid argument with following message.
Apr 22 13:21:37 localhost systemd[1]: Failed to load device unit: Invalid
argument
Apr 22 13:21:37 localhost systemd[1]: Failed to process udev device event:
Invalid argument
This patch escapes those invalid chars in a unit name.
Tested with 202, and confirmed to apply cleanly on top of commit 195f8e36.
Thanks,
Takahiro
---
src/core/device.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/core/device.c b/src/core/device.c
index 734d3f3..7b28aba 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -281,16 +281,22 @@ static int device_update_unit(Manager *m, struct
udev_device *dev, const char *p
size_t l;
FOREACH_WORD_QUOTED(w, l, wants, state) {
-char *e;
+char *e, *n;
e = strndup(w, l);
if (!e) {
r = -ENOMEM;
goto fail;
}
-
-r = unit_add_dependency_by_name(u, UNIT_WANTS,
e, NULL, true);
+n = unit_name_mangle(e);
+if (!n) {
+r = -ENOMEM;
+goto fail;
+}
free(e);
+
+r = unit_add_dependency_by_name(u, UNIT_WANTS,
n, NULL, true);
+free(n);
if (r 0)
goto fail;
}
--
1.8.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SyncIntervalSec not good on battery
Hi: The journal's new SyncIntervalSec is cool when you are plugged to an stable source of energy but it is not when on battery, where it will wake up the disk .. could it be possible to skip it when ConditionACPower=false ? Cheers . ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SyncIntervalSec not good on battery
On Tue, 23.04.13 15:29, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Hi: The journal's new SyncIntervalSec is cool when you are plugged to an stable source of energy but it is not when on battery, where it will wake up the disk .. could it be possible to skip it when ConditionACPower=false ? Note that this only configures the maximum time to keep unwritten log messages in memory. If there's nothing unwritten, then we won't wake up at all. Or to turn this around: if this configured value is an issue, then better fix that specific software that constantly wakes up and generates messages. If the machine is idle, then nothing should log and nothing needs to be written. If the machine is not idle, and something logged, then we should flush it to disk eventually. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] python-systemd: add version number
From: Steven Hiscocks ste...@hiscocks.me.uk
---
Hi,
I thought it would be useful to have a version number in the python systemd
module.
I'm not overly familiar with Make, etc. but hopefully I've taken the right
approach. :)
Thanks
Steven Hiscocks
Makefile.am| 3 +++
src/python-systemd/{__init__.py = __init__.py.in} | 1 +
2 files changed, 4 insertions(+)
rename src/python-systemd/{__init__.py = __init__.py.in} (95%)
diff --git a/Makefile.am b/Makefile.am
index d594a3d..718e6f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3868,6 +3868,9 @@ src/%.policy.in: src/%.policy.in.in Makefile
%.rules: %.rules.in Makefile
$(SED_PROCESS)
+src/python-systemd/%: src/python-systemd/%.in
+ $(SED_PROCESS)
+
%.sh: %.sh.in Makefile
$(SED_PROCESS)
$(AM_V_GEN)chmod +x $@
diff --git a/src/python-systemd/__init__.py b/src/python-systemd/__init__.py.in
similarity index 95%
rename from src/python-systemd/__init__.py
rename to src/python-systemd/__init__.py.in
index 0d56b99..7109f2a 100644
--- a/src/python-systemd/__init__.py
+++ b/src/python-systemd/__init__.py.in
@@ -16,3 +16,4 @@
#
# You should have received a copy of the GNU Lesser General Public License
# along with systemd; If not, see http://www.gnu.org/licenses/.
+__version__ = '@PACKAGE_VERSION@'
--
1.8.2.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] disabling shared mount propagation
Hello all This change, which made mount propagation default to shared: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0 and which went into Fedora 17 in January 2013: http://lists.fedoraproject.org/pipermail/package-announce/2013-January/095395.html is causing some headaches with some services of ours that use unshare to get a new mount namespace and make some private mounts which we don't want propagated. For now, we'd simply like to revert to private mount propagation. A code comment in the change says: If specific setups need other settings they can reset the propagation mode to private if needed. What is the recommended way to do this during early boot? Was the fstab way of doing it (mentioned in the Git commit message) ever implemented? More details: We need to reset this before any of our services run. We are activating services to manage individual disks with SYSTEMD_WANTS via udev, which includes mounting the file system in a private mount namespace, via a unshare in the ExecStart= part. One hack would be to have this unit do ExecStartPre=mount --make-rprivate / but that seems quite gross. Any advice appreciated. Regards Albert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 01:45:32AM +0200, Tom Gundersen wrote: On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. Not commenting on the overall idea, but if you are going to do something like this, at least allow the the files not to exist at all, and in this case a default entry for the root user to be assumed. Sure, seems easy enough to make that entry synthetic as part of the PAM module. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On 04/20/2013 08:04 AM, Koen Kooi wrote: Op 18 apr. 2013, om 19:18 heeft George McCollistergeorge.mccollis...@gmail.com het volgende geschreven: On 04/10/2013 12:03 PM, Koen Kooi wrote: Hi, I have a bit of a heisenbug where dropbear.socket will just die and needs a systemctl restart dropbear.socket. I can't tell why it's dying, just that it does within 3 days of uptime. After restarting it it seems to be rock solid again for at least some weeks. The real way to fix this is to find out why it dies, but till someone figures that out I'm looking to a way to automatically restart the socket when it fails, kinda like Restart=Always for services. Is such a thing possible? This is with 195 and 196, haven't tried 201 yet. I'm having exactly the same problem with sshd.socket (openssh) with systemd 197. I've done a netstat after it dies (just says dead no useful information) and port 22 still shows up under listening. systemctl start sshd.socket fixes the problem. I just upgraded to systemd 201 so I'll let you know if the problem shows up again. The problem happens intermittently so its been a bit elusive. It is indeed elusive, it hasn't happened to me in the past week, so progress is slow on this. regards, Koen This is really strange but I think I just accidentally found a way to reproduce the problem. 1) Reboot 2) Verify ssh works 3) login as root and run: systemctl --system daemon-reload Can't ssh anymore. If I do 'systemctl start sshd.socket' I can ssh again and doing 'systemctl --system daemon-reload' again doesn't seem to break it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] systemd-python: add SYSLOG_IDENTIFIER to JournalHandler
On Tue, Apr 23, 2013 at 06:54:55PM +0300, Marti Raudsepp wrote:
On Mon, Apr 22, 2013 at 11:31 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
Otherwise, we get SYSLOG_IDENTIFIER=python or something
similar, which is completely useless.
I think we shouldn't be creating one-off arguments for every possible
field someone might want to add, but something more generic -- take a
dict as argument for example.
That'd be relatively easy to do. But there's the question what
fields can be meaningfully attached at (a) the handler level and at
(b) logger level and what at (c) individual event level.
It'd be strange to all messages from a program to include a fixed set
of repeating fields in (a). We already have PRIORITY set from the log
level, SYSLOG_IDENTIFIER should of course be added, but that's about
it. We can allow additional fields with a few lines of code.
(b) is technically hard, IIUC, because of python logging API
limiations.
(c) should be possible.
Ideally it would be possible to attach custom journal fields to the
Python root logger and have them propagate to all loggers from there.
But I tried and couldn't make it work without the code getting really
ugly. Here are some of my thoughts on the topic:
http://lists.freedesktop.org/archives/systemd-devel/2012-October/006937.html
And a reply:
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007372.html
Note that Python's SysLogHandler has something vaguely similar, but
it's pretty annoying to use. It's not a constructor argument, but an
attribute you have to override and is simply prepended to the syslog
message so you also have to include the separating colon and space
(like in the C syslog API).
import logging, logging.handlers
h=logging.handlers.SysLogHandler(address='/dev/log')
h.ident='somename: '
l= logging.getLogger('froggerlogger')
l.propagate = False
l.addHandler(h)
l.warning('foo')
This is analogous to case (a), we can do that better.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
