Re: [systemd-devel] [PATCH] systemd: fall back to mounting /sys/fs/cgroup sans xattr
On Tue, Apr 23, 2013 at 10:13:53AM -0400, Colin Walters wrote: > 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 Thanks, pushed. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V2] systemd-analyse: add "critical-chain" command
On Tue, Apr 23, 2013 at 05:32:29PM +0200, har...@redhat.com wrote: > From: Harald Hoyer > > "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=" 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 @@ > Poettering > lenn...@poettering.net > > + > +Developer > +Harald > +Hoyer > +har...@redhat.com > + > > > > @@ -55,6 +61,9 @@ > systemd-analyze rep="repeat">OPTIONS blame > > > +systemd-analyze rep="repeat">OPTIONS critical-chain > + > + > systemd-analyze rep="repeat">OPTIONS plot > > file.svg > > > @@ -88,6 +97,13 @@ > be slow simply because it waits for the initialization > of another service to complete. > > +systemd-analyze critical-chains Typo (extra 's')? > +prints a tree of the time critical chain of units. I agree that this looks like it'll make it much easier to diagnose issues for the users. It would be great to have some more explanation what is being printed out and why. And also how to interpret results. E.g. it's unclear without reading the code what is +522 ms. > +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. > + > systemd-analyze plot 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. > > +
[systemd-devel] [PATCH v2] systemd-python: attach fields to JournalHandler, add SYSLOG_IDENTIFIER
Arbitrary fields can be attached at the level of the handler,
and they'll be sent with all messages from this handler.
This facility is used to attach SYSLOG_IDENTIFIER to all messages,
since otherwise journald attaches SYSLOG_IDENTIFIER=python or
something similar, which is completely useless.
---
This is part (a) in my email. I think it can go in as is,
independently of other potential improvements.
Zbyszek
src/python-systemd/journal.py | 42 +-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/src/python-systemd/journal.py b/src/python-systemd/journal.py
index 6c740b0..7d42525 100644
--- a/src/python-systemd/journal.py
+++ b/src/python-systemd/journal.py
@@ -27,7 +27,7 @@ import uuid as _uuid
import traceback as _traceback
import os as _os
import logging as _logging
-if _sys.version_info >= (3,):
+if _sys.version_info >= (3,3):
from collections import ChainMap as _ChainMap
from syslog import (LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR,
LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG)
@@ -96,6 +96,11 @@ DEFAULT_CONVERTERS = {
'COREDUMP_TIMESTAMP': _convert_timestamp,
}
+_IDENT_LETTER = set('ABCDEFGHIJKLMNOPQRTSUVWXYZ_')
+
+def _valid_field_name(s):
+return not (set(s) - _IDENT_LETTER)
+
class Reader(_Reader):
"""Reader allows the access and filtering of systemd journal
entries. Note that in order to access the system journal, a
@@ -450,12 +455,6 @@ class JournalHandler(_logging.Handler):
>>> log.setLevel(logging.DEBUG)
-To attach journal MESSAGE_ID, an extra field is supported:
-
->>> import uuid
->>> mid = uuid.UUID('0123456789ABCDEF0123456789ABCDEF')
->>> log.warn("Message with ID", extra={'MESSAGE_ID': mid})
-
To redirect all logging messages to journal regardless of where
they come from, attach it to the root logger:
@@ -466,12 +465,36 @@ class JournalHandler(_logging.Handler):
handler class. Only standard handler configuration options
are supported: `level`, `formatter`, `filters`.
+To attach journal MESSAGE_ID, an extra field is supported:
+
+>>> import uuid
+>>> mid = uuid.UUID('0123456789ABCDEF0123456789ABCDEF')
+>>> log.warn("Message with ID", extra={'MESSAGE_ID': mid})
+
+Fields to be attached to all messages sent through this
+handler can be specified as keyword arguments. This probably
+makes sense only for SYSLOG_IDENTIFIER and similar fields
+which are constant for the whole program:
+
+>>> journal.JournalHandler(SYSLOG_IDENTIFIER='my-cool-app')
+
The following journal fields will be sent:
`MESSAGE`, `PRIORITY`, `THREAD_NAME`, `CODE_FILE`, `CODE_LINE`,
`CODE_FUNC`, `LOGGER` (name as supplied to getLogger call),
-`MESSAGE_ID` (optional, see above).
+`MESSAGE_ID` (optional, see above), `SYSLOG_IDENTIFIER` (defaults
+to sys.argv[0]).
"""
+def __init__(self, level=_logging.NOTSET, **kwargs):
+super(JournalHandler, self).__init__(level)
+
+for name in kwargs:
+if not _valid_field_name(name):
+raise ValueError('Invalid field name: ' + name)
+if 'SYSLOG_IDENTIFIER' not in kwargs:
+kwargs['SYSLOG_IDENTIFIER'] = _sys.argv[0]
+self._extra = kwargs
+
def emit(self, record):
"""Write record as journal event.
@@ -492,7 +515,8 @@ class JournalHandler(_logging.Handler):
THREAD_NAME=record.threadName,
CODE_FILE=record.pathname,
CODE_LINE=record.lineno,
- CODE_FUNC=record.funcName)
+ CODE_FUNC=record.funcName,
+ **self._extra)
except Exception:
self.handleError(record)
--
1.8.2.562.g931e949
___
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
> 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
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 McCollister 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] [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 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
[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
[systemd-devel] [PATCH] python-systemd: add version number
From: Steven Hiscocks
---
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
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] 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
[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] [PATCH V2] systemd-analyse: add "critical-chain" command
From: Harald Hoyer "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=" 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 @@ Poettering lenn...@poettering.net + +Developer +Harald +Hoyer +har...@redhat.com + @@ -55,6 +61,9 @@ systemd-analyze OPTIONS blame +systemd-analyze OPTIONS critical-chain + + systemd-analyze OPTIONS plot > file.svg @@ -88,6 +97,13 @@ be slow simply because it waits for the initialization of another service to complete. +systemd-analyze critical-chains +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. + systemd-analyze plot 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. + + + --fuzz=+ +When used in conjunction +with the critical-chain +command (see above), also show units, which +finished earlier, than the +latest unit in the same branch. The unit of + is seconds unless specified, +i.e. "50ms". + diff --git a/src/analyze/systemd-analyze.c b/src/a
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
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] util-linux logger vs systemd-cat
I found myself in a situation recently where I wanted to log a message from a shell script that included MESSAGE_ID. As far as I can tell there's no utility binary for this. systemd ships systemd-cat which connects to the journal, but it doesn't have support for structured logging; it's just a way to conveniently stream textual output to the journal. But that's not useful to me in this context because in current GNOME-OSTree we already have gdm set up to log the session to the journal; what I want is the ability to output structured messages. util-linux has included a tool "logger" for a log time; it wraps syslog; better, it's more oriented for logging a single message, which is convenient for shell script as in this case. It certainly seems like it could make sense to add a command line switch like --struct=MESSAGE_ID=0ce153587afa4095832d233c17a88001 to logger. Or is there an existing tool for this I'm missing? Should systemd-cat support structured logging? ___ 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
>
> "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=" 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().
> +systemd-analyze tree 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.
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, ×[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
[systemd-devel] [PATCH] systemd-analyse: add "tree" command
From: Harald Hoyer "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=" 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 @@ Poettering lenn...@poettering.net + +Developer +Harald +Hoyer +har...@redhat.com + @@ -55,6 +61,9 @@ systemd-analyze OPTIONS blame +systemd-analyze OPTIONS tree + + systemd-analyze OPTIONS plot > file.svg @@ -88,6 +97,13 @@ be slow simply because it waits for the initialization of another service to complete. +systemd-analyze tree 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. + systemd-analyze plot 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. + + + --fuzz=+ +When used in +conjunction with the +tree command (see +above), also show services, which finished + earlier, than the latest unit +in the same branch. + diff --git a/src/analyze/systemd-analyze.c b/src/analyze/systemd-analyze.c index e648a44..50b0696 100644 --- a/src/analyze/systemd-analyze.c +++ b/src/analyze/systemd-analyze.c @@ -35,6 +35,9 @@ #include "strxcpyx.h" #include "fileio.h" #include "strv.h" +#include "unit-name.h" +#include "special.h" +#inclu
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Tue, Apr 23, 2013 at 2:38 PM, Reindl Harald 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
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 > 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 12:26 AM, Reindl Harald 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
On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett 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
2013/4/23 Alexey Shabalin > 2013/4/23 Josh Triplett > >> On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: >> > On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett >> 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] man: link systemd-static-nodes.service
On Tue, Apr 23, 2013 at 10:06 AM, Umut Tezduyar 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 Josh Triplett > On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: > > On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett > 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] 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 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 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] 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 wrote: > On Mon, Apr 22, 2013 at 6:37 PM, Kay Sievers wrote: > > On Mon, Apr 22, 2013 at 6:27 PM, Tom Gundersen wrote: > >> On Mon, Apr 22, 2013 at 5:13 PM, Umut Tezduyar > 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
