Re: [systemd-devel] [PATCH] swap: introduce Discard property
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: I pushed your patch with some significant changes, and some follow-up cleanups. Please check that things work for you. The problem with reading but back discards settings remains. Zbyszek It works for me, thanks! -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - src/nspawn src/shared
On Mon, Sep 29, 2014 at 9:51 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Sep 29, 2014 at 11:55:09AM -0700, Tom Gundersen wrote:
src/nspawn/nspawn.c | 13 ++---
src/shared/util.c | 18 ++
2 files changed, 24 insertions(+), 7 deletions(-)
New commits:
commit 9fb02b1d5df153aa522256aec821e422cca7f284
Author: Tom Gundersen t...@jklm.no
Date: Mon Sep 29 14:30:15 2014 +0200
util: silence coverity
Make it clear in the code that ignoring a failed safe_ato?() is
intentional.
diff --git a/src/shared/util.c b/src/shared/util.c
index 30b0364..ec33fc1 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3272,8 +3272,13 @@ unsigned columns(void) {
c = 0;
e = getenv(COLUMNS);
-if (e)
-safe_atoi(e, c);
+if (e) {
+int r;
+
+r = safe_atoi(e, c);
+if (r 0) {}
+/* do nothing, we fall back to c = 0 */
Why not just say:
(void) safe_atoi(e, c);
Yeah, that is much nicer. I changed it.
Thanks!
Tom
Zbyszek
+}
if (c = 0)
c = fd_columns(STDOUT_FILENO);
@@ -3306,8 +3311,13 @@ unsigned lines(void) {
l = 0;
e = getenv(LINES);
-if (e)
-safe_atou(e, l);
+if (e) {
+int r;
+
+r = safe_atou(e, l);
+if (r 0) {}
+/* do nothing, we fall back to l = 0 */
+}
if (l = 0)
l = fd_lines(STDOUT_FILENO);
commit e8c8ddccfc63574069c30b7e75f0ccfd5b03eab9
Author: Tom Gundersen t...@jklm.no
Date: Mon Sep 29 13:20:54 2014 +0200
nspawn: log when tearing down of loop device fails
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 4c1cfab..34436b8 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2607,20 +2607,27 @@ static int mount_devices(
static void loop_remove(int nr, int *image_fd) {
_cleanup_close_ int control = -1;
+int r;
if (nr 0)
return;
if (image_fd *image_fd = 0) {
-ioctl(*image_fd, LOOP_CLR_FD);
+r = ioctl(*image_fd, LOOP_CLR_FD);
+if (r 0)
+log_warning(Failed to close loop image: %m);
*image_fd = safe_close(*image_fd);
}
control = open(/dev/loop-control,
O_RDWR|O_CLOEXEC|O_NOCTTY|O_NONBLOCK);
-if (control 0)
+if (control 0) {
+log_warning(Failed to open /dev/loop-control: %m);
return;
+}
-ioctl(control, LOOP_CTL_REMOVE, nr);
+r = ioctl(control, LOOP_CTL_REMOVE, nr);
+if (r 0)
+log_warning(Failed to remove loop %d: %m, nr);
}
static int spawn_getent(const char *database, const char *key, pid_t *rpid)
{
___
systemd-commits mailing list
systemd-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-commits
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Why working this on reboot but not on start up
Hello, I have a problem to run this correct, it is working on a reboot but not on start up. Can any help me for this Problem, Thanks. I make a new service File for the kerberos initialisation this is my construct is any wrong in this files? /etc/tmpfiles.d/kinit.conf d /run/user/0/krb5cc 1777 root root - /etc/systemd/system/kinit.service [Unit] Description=Kerberos initial kinit Wants=SuSEfirewall2_setup.service After=SuSEfirewall2_setup.service [Service] Type=simple ExecStart=/usr/bin/kinit -k host/asmtp.gjn.prv Restart=on-failure RestartSec=30 [Install] WantedBy=multi-user.target /etc/systemd/system/kinit.timer [Unit] Description=Fist Initialisation of KRB5 [Timer] OnBootSec=3min [Install] WantedBy=timers.target Thanks for the help. -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Correct a few typos
--- man/systemd-debug-generator.xml | 2 +- src/tty-ask-password-agent/tty-ask-password-agent.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml index ce4750e530..a2bef5fe28 100644 --- a/man/systemd-debug-generator.xml +++ b/man/systemd-debug-generator.xml @@ -68,7 +68,7 @@ paraIf the optionsystemd.wants=/option option is specified and followed by a unit name, a start job for this unit is added to the initial transaction. This is -useful to start one ore more additional units at +useful to start one or more additional units at boot. May be specified more than once./para paraIf the optionsystemd.debug-shell/option diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c b/src/tty-ask-password-agent/tty-ask-password-agent.c index 8a02fb0b5e..e7cbde285c 100644 --- a/src/tty-ask-password-agent/tty-ask-password-agent.c +++ b/src/tty-ask-password-agent/tty-ask-password-agent.c @@ -183,7 +183,7 @@ static int ask_password_plymouth( uint32_t size; char **l; -/* One ore more answers */ +/* One or more answers */ if (p 5) continue; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tty-ask-password-agent: Allow user input to be echoed
Hi David,
Just a quick follow up on these two patches (sorry for the delay).
On the one hand, we want this interface to be very basic and should
probably not something we should extend to cover all sorts of things.
On the other hand, this usecase (and similar ones where you have a
real password, but maybe it is a one-time password, so you don't care
about hiding it) seems very natural, and the patches are simple.
I'll leave it up to Lennart to decide.
A couple of inline nitpicks:
On Fri, Sep 19, 2014 at 12:09 PM, David Sommerseth dav...@redhat.com wrote:
This is a continuation of the patch ask-password: Add --do-echo to enable
echoing the user input.
This allows user input going via the ask-password-agent to be echoed
as well, if the --do-echo argument is provided to systemd-ask-password.
Again it was preferred to add a new function, ask_password_agent_echo(),
over modifying the ask_password_agent() API to make the use case clearer
and keep backwards compatibility with applications depending on
ask_password_agent().
Signed-off-by: David Sommerseth dav...@redhat.com
No need for s-o-b in systemd.
---
src/ask-password/ask-password.c | 5 -
src/shared/ask-password-api.c | 16 +++-
src/shared/ask-password-api.h | 2 ++
src/tty-ask-password-agent/tty-ask-password-agent.c | 6 --
4 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index c77cc66..c6744b9 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -179,7 +179,10 @@ int main(int argc, char *argv[]) {
} else {
char **l;
-if ((r = ask_password_agent(arg_message, arg_icon, arg_id,
timeout, arg_accept_cached, l)) = 0) {
+r = arg_do_echo ? ask_password_agent_echo(arg_message,
arg_icon, arg_id, timeout, arg_accept_cached, l)
+: ask_password_agent(arg_message, arg_icon, arg_id,
timeout, arg_accept_cached, l);
+
+if (r = 0) {
char **p;
STRV_FOREACH(p, l) {
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index 283bfc2..39c122e 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -311,12 +311,13 @@ fail:
return r;
}
-int ask_password_agent(
+static int __ask_password_agent(
const char *message,
const char *icon,
const char *id,
usec_t until,
bool accept_cached,
+bool do_echo,
char ***_passphrases) {
enum {
@@ -378,10 +379,12 @@ int ask_password_agent(
PID=PID_FMT\n
Socket=%s\n
AcceptCached=%i\n
+DoEcho=%i\n
I would probably rename this to just Echo
NotAfter=USEC_FMT\n,
getpid(),
socket_name,
accept_cached ? 1 : 0,
+do_echo ? 1 : 0,
until);
if (message)
@@ -557,6 +560,17 @@ finish:
return r;
}
+int ask_password_agent(const char *message, const char *icon, const char *id,
+ usec_t until, bool accept_cached, char
***_passphrases) {
+return __ask_password_agent(message, icon, id, until, accept_cached,
false, _passphrases);
+}
+
+int ask_password_agent_echo(const char *message, const char *icon, const
char *id,
+usec_t until, bool accept_cached, char
***_passphrases) {
+return __ask_password_agent(message, icon, id, until, accept_cached,
true, _passphrases);
+}
+
+
int ask_password_auto(const char *message, const char *icon, const char *id,
usec_t until, bool accept_cached, char
***_passphrases) {
assert(message);
diff --git a/src/shared/ask-password-api.h b/src/shared/ask-password-api.h
index c3dde63..d467398 100644
--- a/src/shared/ask-password-api.h
+++ b/src/shared/ask-password-api.h
@@ -28,6 +28,8 @@ int ask_password_tty_echo(const char *message, usec_t
until, const char *flag_fi
int ask_password_agent(const char *message, const char *icon, const char *id,
usec_t until, bool accept_cached, char
***_passphrases);
+int ask_password_agent_echo(const char *message, const char *icon, const
char *id,
+usec_t until, bool accept_cached, char
***_passphrases);
int ask_password_auto(const char *message, const char *icon, const char *id,
usec_t until, bool accept_cached, char
***_passphrases);
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 8a02fb0..90bbd1e 100644
---
Re: [systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input
On Wed, Sep 17, 2014 at 2:26 PM, David Sommerseth dav...@redhat.com wrote: I've been playing with the systemd feature enabled in OpenVPN. And I propose this change to systemd-ask-password to avoid masking usernames. I tried looking for alternative ways querying for usernames through systemd without finding a good solution. This patch has been tested locally on a slightly modified OpenVPN build which calls systemd-ask-password with --do-echo when it queries the user for usernames. If there are better ways how to solve this, please let me know and I'll go that path instead. Similar comments to the other patch (not sure whether or not this api extensions should be done or not), but for the patch itself I suggest using --echo, rather than --do-echo, and I guess we need to update the manpage. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: pass own argv to /run/initramfs/shutdown
On 09/30/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Aug 29, 2014 at 05:51:45PM +0200, Marius Tessmann wrote:
Since commit b1e90ec515408aec2702522f6f68c4920b56375b systemd passes
its log settings to systemd-shutdown via command line parameters.
However, systemd-shutdown doesn't pass these parameters to
/run/initramfs/shutdown, causing it to fall back to the default log
settings.
Hi,
sorry for the late reply.
Your patch should work fine if /run/initramfs/shutdown accepts
those arguments, i.e. if it another systemd binary. But otherwise
it might fail, no?
Well, yes. I didn't really think about other implementations. I just checked
the Dracut source and it shouldn't break anything there since it only parses
the first argument as the verb [1]. I don't know what other implementations
are out there, but I doubt they would break since they have no reason to
parse
anything but the first argument in the first place.
Also, the Initrd Interface [2] doesn't even mention what arguments are
passed
to the shutdown binary (not even the verb), so one could argue that
implementations should expect this to change. ;)
Imho it would be enough to mention this in the release notes so that it can
be fixed if necessary. Other implementations may even want to make use
of the
new parameters. ;)
If possible breakage for other implementations is not acceptable I would
love
to know how else this could/should be fixed properly.
[1]
https://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/99shutdown/shutdown.sh#n7
[2] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/
Zbyszek
This fixes the following bugs about the shutdown not being quiet
despite quiet being in the kernel parameters:
https://bugs.freedesktop.org/show_bug.cgi?id=79582
https://bugs.freedesktop.org/show_bug.cgi?id=57216
---
src/core/shutdown.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 1e88b05..d361cbe 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -313,7 +313,7 @@ int main(int argc, char *argv[]) {
access(/run/initramfs/shutdown, X_OK) == 0) {
r = switch_root_initramfs();
if (r = 0) {
-arguments[0] = (char*) /shutdown;
+argv[0] = (char*) /shutdown;
setsid();
make_console_stdio();
@@ -321,7 +321,7 @@ int main(int argc, char *argv[]) {
log_info(Successfully changed into root pivot.\n
Returning to initrd...);
-execv(/shutdown, arguments);
+execv(/shutdown, argv);
log_error(Failed to execute shutdown binary: %m);
} else
log_error(Failed to switch root to \/run/initramfs\:
%s, strerror(-r));
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input
On 09/30/2014 02:26 PM, Tom Gundersen wrote: On Wed, Sep 17, 2014 at 2:26 PM, David Sommerseth dav...@redhat.com wrote: I've been playing with the systemd feature enabled in OpenVPN. And I propose this change to systemd-ask-password to avoid masking usernames. I tried looking for alternative ways querying for usernames through systemd without finding a good solution. This patch has been tested locally on a slightly modified OpenVPN build which calls systemd-ask-password with --do-echo when it queries the user for usernames. If there are better ways how to solve this, please let me know and I'll go that path instead. Similar comments to the other patch (not sure whether or not this api extensions should be done or not), but for the patch itself I suggest using --echo, rather than --do-echo, and I guess we need to update the manpage. Hmm will this make that password visible to anyone who can watch the user monitor? If that is the case then this is an bad practice since nothing should ever echo the input for passwords in cleartext thus making it visible on the end user monitor or store the password itself in cleartext in the journal ( was that checked? ) and this wont pass any kind of audit compliance administrators and users might have to comply to in their infrastructure... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ask-password: Add --do-echo to enable echoing the user input
Jóhann B. Guðmundsson wrote on 30/09/14 16:19: Hmm will this make that password visible to anyone who can watch the user monitor? If that is the case then this is an bad practice since nothing should ever echo the input for passwords If you read the context of the email this is for use in situations where you are collecting user input which is NOT a password... Read the thread and then you can disagree with it in a proper context ;) 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] ask-password: Add --do-echo to enable echoing the user input
On 09/30/2014 04:08 PM, Colin Guthrie wrote: Jóhann B. Guðmundsson wrote on 30/09/14 16:19: Hmm will this make that password visible to anyone who can watch the user monitor? If that is the case then this is an bad practice since nothing should ever echo the input for passwords If you read the context of the email this is for use in situations where you are collecting user input which is NOT a password... Read the thread and then you can disagree with it in a proper context ;) Less a disagreement more err on the side of caution hence the question ( without reading things in proper context ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why working this on reboot but not on start up
В Tue, 30 Sep 2014 13:24:13 +0200 Günther J. Niederwimmer g...@gjn.priv.at пишет: Hello, I have a problem to run this correct, it is working on a reboot but not on start up. What does not work means exactly? Can any help me for this Problem, Thanks. Without clear explanation what working and what not working is? Unlikely. I make a new service File for the kerberos initialisation this is my construct is any wrong in this files? /etc/tmpfiles.d/kinit.conf d /run/user/0/krb5cc 1777 root root - /etc/systemd/system/kinit.service [Unit] Description=Kerberos initial kinit Wants=SuSEfirewall2_setup.service Why Kerberos initialization *wants* firewall? I can understand After, but I have hard time to understand Wants here. After=SuSEfirewall2_setup.service [Service] Type=simple Do you really mean it? I'd rather expect oneshot here. ExecStart=/usr/bin/kinit -k host/asmtp.gjn.prv Restart=on-failure RestartSec=30 [Install] WantedBy=multi-user.target /etc/systemd/system/kinit.timer [Unit] Description=Fist Initialisation of KRB5 [Timer] OnBootSec=3min [Install] WantedBy=timers.target Why do you need to start it two times - once as normal service and second time as timer? Thanks for the help. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.
On Tue, Sep 30, 2014 at 04:26:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Sep 25, 2014 at 06:12:50PM -0300, Gustavo Sverzut Barbieri wrote: etc.conf was selectively (using m4) using resolved link, now this is moved to systemd-resolved.conf file. The etc.conf can be static and does not need to be generated anymore. systemd.conf was doing all the journal setup, now this is moved to systemd-journald.conf file. Is this useful? We don't support journald-less setups. systemd-remote.conf was renamed to systemd-journal-remote.conf for conssitency. This doesn't feel right either. systemd-remote.conf is not only for systemd-journal-remote, but also for systemd-journal-upload and systemd-journal-gateway, so the rename would be misleading. Current name is also the same as the name of the directory (src/journal-remote), so even if not perfect, it is not accidental. I understand that, this is why I did the rename as people adding new stuff only for upload would remember to create a new file. my idea with split files for upload/remote is that they are vastly different use cases and dependencies. Take an embedded system, it may use upload to keep pushing crashes to manufacturer, takes only curl. OTOH it does not need libmicrohttpd/gnutls to provide remote, that is to be used on their server. of course providing some tmpfiles/sysusers that are not used are not that harmful, BUT to create the split packages they will get in the way, as the file would be needed by both packages, this would need the creation of yet-another package that would be required by both :-/ systemd.conf was doing all the networkd setup, now this is moved to systemd-networkd.conf file. This part probably makes the most sense, since networkd is largely a separate beast. Those filenames form a kind of an interface, since they are overriden by name, so we shouldn't change them lightly. Can you respin the patch with just the networkd change? well, I still hope you consider as per above explanations. if not, could you do it for me? I'm going on vacation with limited connectivity and no PC, fixing the patch from a tablet using some remote build/test will be a PITA :-D otherwise I'm back in 15 days. -- Gustavo Sverzut Barbieri Intel Open source Technology Center ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why working this on reboot but not on start up
Hello, Am Dienstag, 30. September 2014, 20:38:10 schrieb Andrei Borzenkov: В Tue, 30 Sep 2014 13:24:13 +0200 Günther J. Niederwimmer g...@gjn.priv.at пишет: Hello, I have a problem to run this correct, it is working on a reboot but not on start up. What does not work means exactly? Bette I say it works sometime but the most of the Time not Can any help me for this Problem, Thanks. Without clear explanation what working and what not working is? Unlikely. I have a 0/SUCCESS in the status but I have no Principal I make a new service File for the kerberos initialisation this is my construct is any wrong in this files? /etc/tmpfiles.d/kinit.conf d /run/user/0/krb5cc 1777 root root - /etc/systemd/system/kinit.service [Unit] Description=Kerberos initial kinit Wants=SuSEfirewall2_setup.service Why Kerberos initialization *wants* firewall? I can understand After, but I have hard time to understand Wants here. The kerberos Server is on a other System (KVM Client) OK I delete the Wants ;) and change After=network.target After=SuSEfirewall2_setup.service [Service] Type=simple Do you really mean it? I'd rather expect oneshot here. I have a systemd Error with oneshot ExecStart=/usr/bin/kinit -k host/asmtp.gjn.prv Restart=on-failure RestartSec=30 [Install] WantedBy=multi-user.target /etc/systemd/system/kinit.timer [Unit] Description=Fist Initialisation of KRB5 [Timer] OnBootSec=3min [Install] WantedBy=timers.target Why do you need to start it two times - once as normal service and second time as timer? Normal, I like to start only with timer service. -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.
On Tue, Sep 30, 2014 at 04:26:38AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Sep 25, 2014 at 06:12:50PM -0300, Gustavo Sverzut Barbieri wrote: etc.conf was selectively (using m4) using resolved link, now this is moved to systemd-resolved.conf file. The etc.conf can be static and does not need to be generated anymore. systemd.conf was doing all the journal setup, now this is moved to systemd-journald.conf file. Is this useful? We don't support journald-less setups. I did forget about this part but it is important, so here it is: I just tested, although journald-less systems are not supported, they work beautifully (as beautify as it can). and we run great without a dbus-daemon, even if not running kdbus as systemctl bus is private and we can do with that (I didn't even think about that, someone at #systemd alerted me and it will help to stop those people that complain about dbus usage and that we could just do socket, the private socket is basically the same, but the protocol is a standard and not just some random handcrafted one). my goal is to provide a decent systemd package for yocto, it will be split so people can choose what to use, but there are a -essential package that includes sysusers, sysctl, tmpfiles, journald... as well as a -base that includes hostnamed, localed, timedatad... and a -all with all packages that would not be so common in embedded systems such as machined, nspawn... right now I see embedded systems people doing the mistake of running away from systemd with many wrong reasons. One of them is size, but they do compare busybox + sysvinit and that includes nothing. When we compare just systemd to busybox+sysvinit we realize they are not that far away and that reason goes away. Since almost no system will work solely on busybox + syvinit, then people will add stuff on top, and while systemd would pay off, people already made the previous choice to NOT use it... making the mistake even bigger. my hope is to deliver the split packages to the yocto project and some comparison of size and features. even with the bare systemd, no journal or similar, you already get much more, from cgroup management (and proc babysitting) to sandboxing (useful in embedded and in many forms using systemd, from seccomp to selinux), private network, private tmp, etc. You also get timer so no need for cron/at, you get proper dependencies and much more as you know. it will also highlight what you get when you add the different needs. Take runtime package management (rpm/opkg), if there is a package that adds users/groups for its services, traditionally you pull in shadow* packages, which is way bigger than sysusers! -- Gustavo Sverzut Barbieri Intel Open source Technology Center ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] sysusers.d: split files to cope with split packages.
On Tue, Sep 30, 2014 at 04:26:31AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Sep 25, 2014 at 06:12:51PM -0300, Gustavo Sverzut Barbieri wrote: move each user/group creation to a file that represents its own split package, so it's possible to ship them in separate. --- Makefile.am| 33 +++-- sysusers.d/systemd-journal-remote.conf | 9 + sysusers.d/systemd-journal-upload.conf | 8 sysusers.d/systemd-journald.conf | 8 sysusers.d/systemd-kdbus.conf | 8 sysusers.d/systemd-networkd.conf | 8 sysusers.d/systemd-remote.conf | 10 -- sysusers.d/systemd-resolved.conf | 8 sysusers.d/systemd-timesyncd.conf | 8 sysusers.d/systemd.conf| 12 10 files changed, 88 insertions(+), 24 deletions(-) create mode 100644 sysusers.d/systemd-journal-remote.conf create mode 100644 sysusers.d/systemd-journal-upload.conf create mode 100644 sysusers.d/systemd-journald.conf create mode 100644 sysusers.d/systemd-kdbus.conf create mode 100644 sysusers.d/systemd-networkd.conf delete mode 100644 sysusers.d/systemd-remote.conf create mode 100644 sysusers.d/systemd-resolved.conf create mode 100644 sysusers.d/systemd-timesyncd.conf delete mode 100644 sysusers.d/systemd.conf Hm, kdbus is either compiled in, or not, so splitting out configuration doesn't seem useful. I did this because I was trying to make bus-proxyd optional, however it does not work as stdio-bridge uses that. so yes we can leave the kdbus part in without worries. systemd-timesyncd is ~400kb. Other binaries aren't too big either. Splitting everything up complicated things, and I'm not convinced that this is a useful change. indeed they are not big per se, but see my other email about tmpfiles, they contribute to a misinterpretation of systemd. since they are optional I want to make that clear and help the user to choose. I do have a complete set of packages for yocto that generates that nicely and the final system size difference is huge: 7.5 to 30Mb (whole system, not just systemd, but the dependencies, etc -- in contrast sysvinit + busybox is 6.5Mb). as I wrote in the other email, I'll make sure that some packages are highly recommended (ie: journal, udev, sysctl...), but forcing everyone to ship a ntp client (timesyncd) is asking for trouble when people analyze systemd x options. systemd is great and it avoid people doing mistakes where it provides elegant solutions, but we need to get it in :-) -- Gustavo Sverzut Barbieri Intel Open source Technology Center ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: pass own argv to /run/initramfs/shutdown
On Tue, Sep 30, 2014 at 05:02:15PM +0200, Marius Tessmann wrote: On 09/30/2014 05:03 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Aug 29, 2014 at 05:51:45PM +0200, Marius Tessmann wrote: Since commit b1e90ec515408aec2702522f6f68c4920b56375b systemd passes its log settings to systemd-shutdown via command line parameters. However, systemd-shutdown doesn't pass these parameters to /run/initramfs/shutdown, causing it to fall back to the default log settings. Hi, sorry for the late reply. Your patch should work fine if /run/initramfs/shutdown accepts those arguments, i.e. if it another systemd binary. But otherwise it might fail, no? Well, yes. I didn't really think about other implementations. I just checked the Dracut source and it shouldn't break anything there since it only parses the first argument as the verb [1]. I don't know what other implementations are out there, but I doubt they would break since they have no reason to parse anything but the first argument in the first place. Also, the Initrd Interface [2] doesn't even mention what arguments are passed to the shutdown binary (not even the verb), so one could argue that implementations should expect this to change. ;) Imho it would be enough to mention this in the release notes so that it can be fixed if necessary. Other implementations may even want to make use of the new parameters. ;) If possible breakage for other implementations is not acceptable I would love to know how else this could/should be fixed properly. Environment variables? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. But all devices are available from early kernel start: # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 11 Sep 29 20:17 008af19d-2562-49bd-8907-721ea08f3e14 - ../../ubda1 lrwxrwxrwx 1 root root 11 Sep 29 20:17 e2bffa45-d84f-47bc-81ba-e7a395751fa6 - ../../ubda3 lrwxrwxrwx 1 root root 11 Sep 29 20:17 f452f020-a446-41ed-93c0-ee5ce56d6ea4 - ../../ubda2 It feels like some event notification is lost in the boot process or something like this?! What exactly makes the device unit go into the state active/plugged? This is a boot of the Fedora 21 alpha under user mode linux. Any ideas what could be wrong here? Please always CC me and/or the UML mailinglist in case of UML related issues. I'm very interested in having UML work with systemd. Okay Richard, will do so in future. Some more info about the above systemd wait (with systemd.log_level=debug and DEBUG_KOBJECT) Systemd starts and installs a job for each device tagged with systemd: Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34 Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck@dev-ubdb3.service/start as 35 Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1 Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms. Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a). Device unit is waiting: Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device... udev coldplug: Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215 Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer' Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3' So here the udev coldplug triggers the kernel kobject_uevent for 'ubdb3'. I don't understand why the systemd unit doesn't change to PLUGGED here! It should?! Or shouldn't it? systemd dump: Sep 30 18:13:44 servername systemd[1]: - Unit dev-ubdb3.device: Sep 30 18:13:44 servername systemd[1]: Description: dev-ubdb3.device Sep 30 18:13:44 servername systemd[1]: Instance: n/a Sep 30 18:13:44 servername systemd[1]: Unit Load State: loaded Sep 30 18:13:44 servername systemd[1]: Unit Active State: inactive Sep 30 18:13:44 servername systemd[1]: Inactive Exit Timestamp: n/a Sep 30 18:13:44 servername systemd[1]: Active Enter Timestamp: n/a Sep 30 18:13:44 servername systemd[1]: Active Exit Timestamp: n/a Sep 30 18:13:44 servername systemd[1]: Inactive Enter Timestamp: n/a Sep 30 18:13:44 servername systemd[1]: Need Daemon Reload: no Sep 30 18:13:44 servername systemd[1]: Transient: no Sep 30 18:13:44 servername systemd[1]: Slice: n/a Sep 30 18:13:44 servername systemd[1]: CGroup: n/a Sep 30 18:13:44 servername
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
01.10.2014 00:27, Thomas Meyer wrote: Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. But all devices are available from early kernel start: # ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 11 Sep 29 20:17 008af19d-2562-49bd-8907-721ea08f3e14 - ../../ubda1 lrwxrwxrwx 1 root root 11 Sep 29 20:17 e2bffa45-d84f-47bc-81ba-e7a395751fa6 - ../../ubda3 lrwxrwxrwx 1 root root 11 Sep 29 20:17 f452f020-a446-41ed-93c0-ee5ce56d6ea4 - ../../ubda2 It feels like some event notification is lost in the boot process or something like this?! What exactly makes the device unit go into the state active/plugged? This is a boot of the Fedora 21 alpha under user mode linux. Any ideas what could be wrong here? Please always CC me and/or the UML mailinglist in case of UML related issues. I'm very interested in having UML work with systemd. Okay Richard, will do so in future. Some more info about the above systemd wait (with systemd.log_level=debug and DEBUG_KOBJECT) Systemd starts and installs a job for each device tagged with systemd: Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34 Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck@dev-ubdb3.service/start as 35 Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1 Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms. Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a). Device unit is waiting: Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device... udev coldplug: Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215 Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer' Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3' So here the udev coldplug triggers the kernel kobject_uevent for 'ubdb3'. I don't understand why the systemd unit doesn't change to PLUGGED here! It should?! Or shouldn't it? Imho the problem is not specific to UML. Something similar has been triggered on my desktop PC, and nobody replied: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22490.html If this triggers again, I will provide dumps. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Any feedback at all? Please? Am I doing something wrong in posting my patch here? Best Regards, Tobias On Sat, Sep 27, 2014 at 5:59 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Ping? This is really useful to test out the changes proposed in http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Yes, Lennart seems to want to move to something more strict that can also work with the uefi secure boot, but this helps me get a test system of the ground where the / und /usr mounts are defined in the bootloader entries. Even works with encrypted partitions here;-) Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Hi, 2014-09-30 21:18 GMT+02:00 Tobias Hunger tobias.hun...@gmail.com: Any feedback at all? Please? Am I doing something wrong in posting my patch here? No you just need to wait that someone review your patch. It rarely takes more than 2 weeks. Best Regards, Tobias On Sat, Sep 27, 2014 at 5:59 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Ping? This is really useful to test out the changes proposed in http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html Yes, Lennart seems to want to move to something more strict that can also work with the uefi secure boot, but this helps me get a test system of the ground where the / und /usr mounts are defined in the bootloader entries. Even works with encrypted partitions here;-) Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
On Tue, Sep 30, 2014 at 08:27:36PM +0200, Thomas Meyer wrote: Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. What exactly makes the device unit go into the state active/plugged? This is a boot of the Fedora 21 alpha under user mode linux. Some more info about the above systemd wait (with systemd.log_level=debug and DEBUG_KOBJECT) Systemd starts and installs a job for each device tagged with systemd: Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34 Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck@dev-ubdb3.service/start as 35 Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1 Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms. Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a). Device unit is waiting: Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device... udev coldplug: Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215 Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer' Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3' Check the udev database at this moment. In my understanding, to have device deemed ready by systemd, two things must happen for device entry: – TAGS variable must contain ”systemd” – SYSTEMD_READY must be ”1” I don't have UML installation handy to check, but maybe there is missing rule? Rule which is supposed to flip SYSTEMD_READY to ”1”? Some default devices are tagged in 99-systemd.rules; if UML-specific devs are missing, please send a patch. -- Tomasz TorczFuneral in the morning, IDE hacking xmpp: zdzich...@chrome.plin the afternoon and evening. - Alan Cox ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
Am Dienstag, den 30.09.2014, 21:44 +0200 schrieb Tomasz Torcz: On Tue, Sep 30, 2014 at 08:27:36PM +0200, Thomas Meyer wrote: Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. What exactly makes the device unit go into the state active/plugged? This is a boot of the Fedora 21 alpha under user mode linux. Some more info about the above systemd wait (with systemd.log_level=debug and DEBUG_KOBJECT) Systemd starts and installs a job for each device tagged with systemd: Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34 Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck@dev-ubdb3.service/start as 35 Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1 Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms. Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a). Device unit is waiting: Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device... udev coldplug: Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215 Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer' Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3' Check the udev database at this moment. In my understanding, to have device deemed ready by systemd, two things must happen for device entry: – TAGS variable must contain ”systemd” I think the tag is okay: # udevadm info -q all -p /devices/platform/uml-blkdev.1/block/ubdb/ubdb3 P: /devices/platform/uml-blkdev.1/block/ubdb/ubdb3 N: ubdb3 S: disk/by-label/ANACONDA S: disk/by-path/platform-uml-blkdev.1-part3 S: disk/by-uuid/d3f89867-087c-3f26-a261-477750d18179 E: DEVLINKS=/dev/disk/by-label/ANACONDA /dev/disk/by-path/platform-uml-blkdev.1-part3 /dev/disk/by-uuid/d3f89867-087c-3f26-a261-477750d18179 E: DEVNAME=/dev/ubdb3 E: DEVPATH=/devices/platform/uml-blkdev.1/block/ubdb/ubdb3 E: DEVTYPE=partition E: ID_FS_APPLICATION_ID=GENISOIMAGE\x20ISO\x209660\x2fHFS\x20FILESYSTEM\x20CREATOR\x20\x28C\x29\x201993\x20E.YOUNGDALE\x20\x28C\x29\x201997-2006\x20J.PEARSON\x2fJ.SCHILLING\x20\x28C\x29\x202006-2007\x20CDRKIT\x20TEAM E: ID_FS_BOOT_SYSTEM_ID=EL\x20TORITO\x20SPECIFICATION E: ID_FS_LABEL=ANACONDA E: ID_FS_LABEL_ENC=ANACONDA E: ID_FS_SYSTEM_ID=LINUX E: ID_FS_TYPE=hfsplus E: ID_FS_USAGE=filesystem E: ID_FS_UUID=d3f89867-087c-3f26-a261-477750d18179 E: ID_FS_UUID_ENC=d3f89867-087c-3f26-a261-477750d18179 E: ID_FS_VERSION=Joliet Extension E: ID_PART_ENTRY_DISK=98:16 E: ID_PART_ENTRY_NUMBER=3 E: ID_PART_ENTRY_OFFSET=193456 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=50656 E: ID_PART_ENTRY_TYPE=0x0 E: ID_PART_ENTRY_UUID=314777b5-03 E: ID_PART_TABLE_TYPE=dos E: ID_PART_TABLE_UUID=314777b5 E: ID_PATH=platform-uml-blkdev.1 E: ID_PATH_TAG=platform-uml-blkdev_1 E: MAJOR=98 E: MINOR=19 E: SUBSYSTEM=block E: TAGS=:systemd: E:
[systemd-devel] _H Online_ articles about systemd restored by Thorsten Leemhuis
I asked Thorsten Leemhuis of Heise if it wouldn't be possible to bring back the excellent _H Online_ systemd articles that he, Lennart and Kay wrote. They now are here, still without figures: http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html I found these articles extremely helpful when first using systemd.Perhaps the owners of the freedesktop wiki for systemd would care to link to them? Best wishes, Alison Chaiken ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
В Tue, 30 Sep 2014 22:18:04 +0200 Thomas Meyer tho...@m3y3r.de пишет: Am Dienstag, den 30.09.2014, 21:44 +0200 schrieb Tomasz Torcz: On Tue, Sep 30, 2014 at 08:27:36PM +0200, Thomas Meyer wrote: Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. What exactly makes the device unit go into the state active/plugged? This is a boot of the Fedora 21 alpha under user mode linux. Some more info about the above systemd wait (with systemd.log_level=debug and DEBUG_KOBJECT) Systemd starts and installs a job for each device tagged with systemd: Sep 30 18:07:58 localhost systemd[1]: Installed new job dev-ubdb3.device/start as 34 Sep 30 18:07:58 localhost systemd[1]: Installed new job systemd-fsck@dev-ubdb3.service/start as 35 Sep 30 18:07:58 localhost systemd[1]: Enqueued job initrd.target/start as 1 Sep 30 18:07:58 localhost systemd[1]: Loaded units and determined initial transaction in 837.189ms. Sep 30 18:07:58 localhost systemd[1]: Received SIGCHLD from PID 32 (n/a). Device unit is waiting: Sep 30 18:07:58 localhost systemd[1]: Expecting device dev-ubdb3.device... udev coldplug: Sep 30 18:08:02 localhost systemd[360]: Executing: /bin/dracut-pre-trigger Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.dm=0: removing DM RAID activation Sep 30 18:08:02 localhost systemd-udevd[358]: starting version 215 Sep 30 18:08:02 localhost dracut-pre-trigger[360]: rd.md.imsm=0: no MD RAID for imsm/isw raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md.ddf=0: no MD RAID for SNIA ddf raids Sep 30 18:08:03 localhost dracut-pre-trigger[360]: rd.md=0: removing MD RAID activation Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'alarmtimer' (930ef220): fill_kobj_path: path = '/devices/platform/alarmtimer' Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'uml-blkdev.1' (605a1700): fill_kobj_path: path = '/devices/platform/uml-blkdev.1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb' (8c030480): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb1' (93205838): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb1' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb2' (93205638): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb2' Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): kobject_uevent_env Sep 30 18:08:04 localhost kernel: kobject: 'ubdb3' (93205438): fill_kobj_path: path = '/devices/platform/uml-blkdev.1/block/ubdb/ubdb3' Check the udev database at this moment. In my understanding, to have device deemed ready by systemd, two things must happen for device entry: – TAGS variable must contain ”systemd” I think the tag is okay: # udevadm info -q all -p /devices/platform/uml-blkdev.1/block/ubdb/ubdb3 P: /devices/platform/uml-blkdev.1/block/ubdb/ubdb3 N: ubdb3 S: disk/by-label/ANACONDA S: disk/by-path/platform-uml-blkdev.1-part3 S: disk/by-uuid/d3f89867-087c-3f26-a261-477750d18179 E: DEVLINKS=/dev/disk/by-label/ANACONDA /dev/disk/by-path/platform-uml-blkdev.1-part3 /dev/disk/by-uuid/d3f89867-087c-3f26-a261-477750d18179 According to your original post it complaints about device with UUID 008af19d-2562-49bd-8907-721ea08f3e14. Please show information about *this* device, not some random one. E: DEVNAME=/dev/ubdb3 E: DEVPATH=/devices/platform/uml-blkdev.1/block/ubdb/ubdb3 E: DEVTYPE=partition E: ID_FS_APPLICATION_ID=GENISOIMAGE\x20ISO\x209660\x2fHFS\x20FILESYSTEM\x20CREATOR\x20\x28C\x29\x201993\x20E.YOUNGDALE\x20\x28C\x29\x201997-2006\x20J.PEARSON\x2fJ.SCHILLING\x20\x28C\x29\x202006-2007\x20CDRKIT\x20TEAM E: ID_FS_BOOT_SYSTEM_ID=EL\x20TORITO\x20SPECIFICATION E: ID_FS_LABEL=ANACONDA E: ID_FS_LABEL_ENC=ANACONDA E: ID_FS_SYSTEM_ID=LINUX E: ID_FS_TYPE=hfsplus E: ID_FS_USAGE=filesystem E: ID_FS_UUID=d3f89867-087c-3f26-a261-477750d18179 E: ID_FS_UUID_ENC=d3f89867-087c-3f26-a261-477750d18179 E: ID_FS_VERSION=Joliet Extension E: ID_PART_ENTRY_DISK=98:16 E: ID_PART_ENTRY_NUMBER=3 E:
