Re: [systemd-devel] Problems with SWAP in 204
On 06/19/2013 03:39 AM, Tom Gundersen wrote: On Wed, Jun 19, 2013 at 12:16 AM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: When booting, I get a few errors related to swap; in particular: Failed to reread /proc/swaps: File exists swapon: /dev/sda3: swapon failed: Device or resource busy The output of systemctl --full --all --type=swap might be useful as well. Attached. /Henrik sudo systemctl --full --all --type=swap --- UNIT LOAD ACTIVE SUBJOB DESCRIPTION dev-disk-by\x2did-ata\x2dST1000DM003\x2d1CH162_S1D5J022\x2dpart3.swap loaded inactive dead start /dev/disk/by-id/ata-ST1000DM003-1CH162_S1D5J022-part3 dev-disk-by\x2did-ata\x2dST1000DM003\x2d1CH162_S1D5J022\x2dpart4.swap loaded active active /dev/disk/by-id/ata-ST1000DM003-1CH162_S1D5J022-part4 dev-disk-by\x2did-wwn\x2d0x5000c5005b0246f0\x2dpart3.swap loaded inactive dead start /dev/disk/by-id/wwn-0x5000c5005b0246f0-part3 dev-disk-by\x2did-wwn\x2d0x5000c5005b0246f0\x2dpart4.swap loaded active active /dev/disk/by-id/wwn-0x5000c5005b0246f0-part4 dev-disk-by\x2dpartlabel-Linux\x5cx20swap.swap loaded active active /dev/disk/by-partlabel/Linux\x20swap dev-disk-by\x2dpartuuid-0febfdc2\x2d2901\x2d41ce\x2db9a3\x2d4eabb17d8a4c.swap loaded active active /dev/disk/by-partuuid/0febfdc2-2901-41ce-b9a3-4eabb17d8a4c dev-disk-by\x2dpartuuid-557e61b0\x2d28ee\x2d40cb\x2d9c06\x2d4d083a86e131.swap loaded inactive dead start /dev/disk/by-partuuid/557e61b0-28ee-40cb-9c06-4d083a86e131 dev-disk-by\x2duuid-066af73a\x2dd8fd\x2d49b7\x2db806\x2d05f625681d4d.swap loaded active active /dev/disk/by-uuid/066af73a-d8fd-49b7-b806-05f625681d4d dev-disk-by\x2duuid-e84600d2\x2d060e\x2d4758\x2da0aa\x2de31a069f3ac8.swap loaded active active /dev/disk/by-uuid/e84600d2-060e-4758-a0aa-e31a069f3ac8 dev-sda3.swap loaded failed failed /dev/sda3 dev-sda4.swap loaded active active /dev/sda4 LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB= The low-level unit activation state, values depend on unit type. JOB= Pending job for the unit. 11 loaded units listed. To show all installed unit files use 'systemctl list-unit-files'. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with SWAP in 204
2013/6/19 Henrik /KaarPoSoft hen...@kaarposoft.dk: Dear all, hei, I am experiencing a strange problem with swap using systemd 204. Any help in diagnosing this would be most appreciated. I have 64 GB of physical memory, and two 64 GB swap partitions. Do these have the same partlabel? I think this might couse confusion for systemd/udev My fstab is attached. When booting, I get a few errors related to swap; in particular: Failed to reread /proc/swaps: File exists In my (untested) theory this is because your swap is mounted (by the initrd?) and while loading existing swaps from /proc/swaps systemd tries to create /dev/disk/by-partlabel/Linux\x20swap.swap twice, failing the second time. swapon: /dev/sda3: swapon failed: Device or resource busy probably similar to above, when sda4 comes online systemd tries to activate all services belonging to it, blkid tells that partlabel is Linux swap so systemd tries to activate /dev/disk/by-partlabel/Linux\x20swap.swap but /dev/disk/by-partlabel/Linux\x20swap is a symlink to /dev/sda3 which is already activated. A full journalctl -b | grep -i swap is atached as swap1.txt However, swapon seems to be happy: swapon -s Filename TypeSizeUsedPriority /dev/sda4 partition6710886001 /dev/sda3 partition6710886001 Every now and again, I get journal messages about swap; see journalctl -b | grep -i swap attached as swap2.txt When executing systemctl poweroff most of the time the machine just powers off as expeced. However, sometimes the poweroff gets stuck (hanging for at least 15 minutes). This happens very late in the poweroff, so there is nothing in the logs. However, a screenshot is attached: swap.png even though i am not sure what is happening here, it also talks about /dev/disk/by-partlabel/Linux\x20swap so it is probably the same issue as above Your insights into what I might be doing wrong would be most appreciated /Henrik If the above is the case and changing the partlabel of one of the swap devices solves the problem, then this is a bug in systemd since nothing obligates parlabel to be unique. I will probably try and reproduce this here later today. hilsen Simon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: switch to journal when socket is listening
On Thu, Jun 13, 2013 at 9:26 PM, Umut Tezduyar u...@tezduyar.com wrote:
systemd starts using journal as soon as the journal
socket is in listening state instead of waiting for
journal's socket to switch to 'running' state.
---
src/core/manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index f16621a..cebc43e 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2613,7 +2613,8 @@ void manager_recheck_journal(Manager *m) {
return;
u = manager_get_unit(m, SPECIAL_JOURNALD_SOCKET);
-if (u SOCKET(u)-state != SOCKET_RUNNING) {
+if (u SOCKET(u)-state != SOCKET_RUNNING
+ SOCKET(u)-state != SOCKET_LISTENING) {
log_close_journal();
return;
}
Hi,
Due to a race condition (at least I think) between systemd and
journald, systemd might keep logging to kmsg even though journal is up
and running. Systemd switches to using journal for logging when both
journal's socket and service are in running state. Occasionally I
have ended up finding my system in the following state after booting
to basic.target.
systemd-journald.service loaded active running Journal Service
systemd-journald.socketloaded active listening Journal Socket
At this point journal is up, program's stdout/err is sent to journal
(can be seen by journalctl) but systemd still thinks journal is not
usable for its own logging and keeps logging to kmsg.
If you are using kernel 3.5, the effect of the problem is not being
able to see systemds logs in journalctl.
---
I think what is happening is both journald and systemd are racing for
the EPOLLIN event on the journal's sockets. If journal is receiving
EPOLLIN events all the time, then systemd will never get notified of
the activity on the sockets and never switch the socket to running
state.
If I disable the EPOLLIN event registration on the journald side, I
can see that systemd-journald.socket switches to running state %100.
Since systemd-journal.socket and systemd-journal.service are starting
on boot up anyways, I don't see the necessity of waiting for
systemd-journald.socket to go to running state.
If anyone would like to get more information, I can reproduce the
problem pretty often. I have tried both kernel 3.4 and 3.8 as well as
different ISAs.
I see the problem. In most other cases it never mattered that the
socket's state is correctly updated. I guess it actually does for the
journald socket at least.
The cleanest way to fix this appears to me is updating the socket's
state to RUNNING as soon as its matching service is activated, instead
of only when we receive EPOLLIN. We already get notifications when the
service dies, we should just extend that for when the service starts up.
As it turns out this recently became a bit easier with the unit logic,
there's now a trigger_notify() callback in UnitVTable that is invoked
each time a unit that is triggered by a unit changes state. It's
probably just a matter of adding a callback in there, and doing a simple
state change. Patch appreciated (though I added this to the TODO list,
too.)
(In fact, service.c's service_notify_sockets_dead() should probably be
replaced by the same trigger_notify() handler, if possible, but that's
just the cherry on top).
Lennart
--
Lennart Poettering - Red Hat, Inc.
Hi Lennart,
I didn't quite understand how this could end up in a deadlock
(http://lists.freedesktop.org/archives/systemd-devel/2013-June/011404.html)
I think in general we could be having a problem when a service could
be started by both socket activation and as part of a target.wants. It
could be that first data coming in the socket might trigger an event
that is being caught by systemd but not the service itself (even
though service is up) and this might cause the service receive the
first package delayed (in the event of the next data).
I will try to implement your changes with trigger_notify in couple of
weeks if no one gets to it before me.
Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with SWAP in 204
On 06/19/2013 12:10 PM, Peeters Simon wrote: 2013/6/19 Henrik /KaarPoSoft hen...@kaarposoft.dk: Dear all, hei, I am experiencing a strange problem with swap using systemd 204. Any help in diagnosing this would be most appreciated. I have 64 GB of physical memory, and two 64 GB swap partitions. Do these have the same partlabel? I think this might couse confusion for systemd/udev Only one of the partitions has a partlabel at all. Output of blkid attached. My fstab is attached. When booting, I get a few errors related to swap; in particular: Failed to reread /proc/swaps: File exists In my (untested) theory this is because your swap is mounted (by the initrd?) and while loading existing swaps from /proc/swaps systemd tries to create /dev/disk/by-partlabel/Linux\x20swap.swap twice, failing the second time. My initrd does not mount swap: http://sourceforge.net/p/kaarpux/code/ci/master/tree/master/packages/l/linux.files/init swapon: /dev/sda3: swapon failed: Device or resource busy probably similar to above, when sda4 comes online systemd tries to activate all services belonging to it, blkid tells that partlabel is Linux swap so systemd tries to activate /dev/disk/by-partlabel/Linux\x20swap.swap but /dev/disk/by-partlabel/Linux\x20swap is a symlink to /dev/sda3 which is already activated. [...] even though i am not sure what is happening here, it also talks about /dev/disk/by-partlabel/Linux\x20swap so it is probably the same issue as above If the above is the case and changing the partlabel of one of the swap devices solves the problem, then this is a bug in systemd since nothing obligates parlabel to be unique. As per my input above, it does not seem to be a problem with identical PARTLABELs. However, I do think that you are on to something important here! According to the output of systemctl --full --all --type=swap (attached in previous mail) it seems that systemd is trying to activate swap by every naming scheme (id, uuid, partuuid, partlabel, /dev) without realizing that they symlink to the the same (two) partitions. /Henrik blkid | grep swap - /dev/sda3: UUID=066af73a-d8fd-49b7-b806-05f625681d4d TYPE=swap PARTLABEL=Linux swap PARTUUID=557e61b0-28ee-40cb-9c06-4d083a86e131 /dev/sda4: UUID=e84600d2-060e-4758-a0aa-e31a069f3ac8 TYPE=swap /dev/sdc39: UUID=a306e5d1-9bd1-4b7a-96f4-70c2245dcd39 TYPE=swap ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jun 18, 2013 at 4:43 AM, Auke-jan H Kok auke-jan.h@intel.com
wrote:
On Mon, Jun 17, 2013 at 9:37 PM, Kyungmin Park kmp...@infradead.org wrote:
Hi Elena,
On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com)
wrote:
Hi,
This is the patch for review for enabling smack labelling for device
nodes.
The functionality and reasoning is inside. I will be happy to answer
any questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it generic
enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning this?
Sorry for the silence, it seems like I totally missed these replies (got
buried in my mailbox)!
Sure, I can make a change, but I am not exactly sure what you mean by this:
XATTR{security.SMACK64}=label. Adding simple HAVE_SMACK ifdeffery is
easy, but the later part I didn't really understand.
If it is just longer to explain it to me, Auke, you can go ahead and make a
change and I will just learn from looking into it :) Unfortunately, I don't
know systemd code well enough.
Best Regards,
Elena.
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Describe handling of an AF_UNIX socket
Describe how to handle an AF_UNIX socket, with Accept set to false, received from systemd, upon exit. Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com --- man/systemd.socket.xml | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index 6dc847d..f1e7d40 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -381,9 +381,15 @@ performance reasons, it is recommended to write new daemons only in a way that is suitable for -optionAccept=false/option. This -option is mostly useful to allow -daemons designed for usage with +optionAccept=false/option. A daemon +listening on an AF_UNIX socket may, but does not need to, call + citerefentryrefentrytitleclose/refentrytitlemanvolnum2/manvolnum/citerefentry +or + citerefentryrefentrytitleshutdown/refentrytitlemanvolnum2/manvolnum/citerefentry +on the received socket before exiting. However, +it must not unlink the socket from a +filesystem. This option is mostly useful +to allow daemons designed for usage with citerefentryrefentrytitleinetd/refentrytitlemanvolnum8/manvolnum/citerefentry, to work unmodified with systemd socket activation./para/listitem -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Text input on startup (tty-force) disabling after a few seconds
Hi everyone, I'm somewhat new to systemd and have a problem. I would like to run a custom script with systemd on startup that will ask me for a password and mount a Truecrypt volume with it. The script and unit file I wrote can be found below. Now, this setup does work *somewhat* - basically it will ask me for my Truecrypt password on startup and do the mounting as it should. But when I wait a few seconds during startup, entering the password no longer works. I just have a few seconds after the password prompt appearing to enter it; if I wait 5-10 seconds nothing will happen anymore. That seems like weird and unintended behaviour to me. Is this a bug, or can you point me in the right direction about what I'm doing wrong if I want some sort of keyboard interaction during system startup with systemd? I mean, that is a useful and sometimes needed feature, right? Unit file: --- [Unit] Description=Mount Truecrypt-encrypted filesystems ConditionFileIsExecutable=/usr/bin/truecrypt Requires=truecrypt-unmount.service Before=display-manager.service [Service] Type=oneshot ExecStart=/etc/mount_truecrypt StandardInput=tty-force RemainAfterExit=yes [Install] WantedBy=multi-user.target /etc/mount_truecrypt: --- #!/bin/bash sudo echo Please enter the password to mount your TrueCrypt volumes... stty -echo read password stty echo echo C: echo $password | sudo truecrypt -t -k --fs-options=rw,exec,users,async,uid=root,gid=users,umask=077,noatime --mount-options=system --protect-hidden=no /dev/sda1 /media/C /dev/null echo ...done. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles, man: Add xattr support to tmpfiles
Hello, On 17.06.2013 at 18:18 Lennart Poettering lenn...@poettering.net wrote: I think adding this certainly makes sense, but I am not sure I like the syntax. Maybe it would be simpler to add an extra char for this (a or so?). That way creating a dir and applying an xattr would require two lines instead of one, but the stuff isn't atomic anyway. Admittedly adding a new a isn't particularly nice either, but I have no better idea than that... I've looked into your way and found some problems. In parse_line(), after creating, item is added to hashmap. Key is path, which already exists in map. So adding a would require changing key (path + type?). Problem on user side is that order matters - if user would add a entry first, than setting attribute would fail, because file wouldn't exist yet. Should I continue adding a, look into Karols proposition or my original patch is acceptable? Anybody having other ideas? I've also found something which looks like a typo in lines 782 - 787: case RELABEL_PATH: r = glob_item(i, item_set_perms); if (r 0) return 0; break; Shouldn't it be return r? If it's not, then should I add comment, that it's on purpose? regards, Maciej -- Maciej Wereski Samsung RD Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problems with SWAP in 204
'Twas brillig, and Henrik /KaarPoSoft at 19/06/13 13:06 did gyre and gimble: However, I do think that you are on to something important here! According to the output of systemctl --full --all --type=swap (attached in previous mail) it seems that systemd is trying to activate swap by every naming scheme (id, uuid, partuuid, partlabel, /dev) without realizing that they symlink to the the same (two) partitions. This did used to be a problem a while back but I thought it had been fixed... perhaps it's regressed in some capacity (or it could just be different but similar symptoms) 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] Text input on startup (tty-force) disabling after a few seconds
2013/6/19 Natanji nata...@gmail.com: Hi everyone, I'm somewhat new to systemd and have a problem. I would like to run a custom script with systemd on startup that will ask me for a password and mount a Truecrypt volume with it. The script and unit file I wrote can be found below. Now, this setup does work *somewhat* - basically it will ask me for my Truecrypt password on startup and do the mounting as it should. But when I wait a few seconds during startup, entering the password no longer works. I just have a few seconds after the password prompt appearing to enter it; if I wait 5-10 seconds nothing will happen anymore. That seems like weird and unintended behaviour to me. Is this a bug, or can you point me in the right direction about what I'm doing wrong if I want some sort of keyboard interaction during system startup with systemd? I mean, that is a useful and sometimes needed feature, right? Unit file: --- [Unit] Description=Mount Truecrypt-encrypted filesystems ConditionFileIsExecutable=/usr/bin/truecrypt Requires=truecrypt-unmount.service Before=display-manager.service [Service] Type=oneshot ExecStart=/etc/mount_truecrypt StandardInput=tty-force RemainAfterExit=yes [Install] WantedBy=multi-user.target /etc/mount_truecrypt: --- #!/bin/bash sudo echo Please enter the password to mount your TrueCrypt volumes... stty -echo read password stty echo echo C: echo $password | sudo truecrypt -t -k --fs-options=rw,exec,users,async,uid=root,gid=users,umask=077,noatime --mount-options=system --protect-hidden=no /dev/sda1 /media/C /dev/null echo ...done. It might be a bug in the tty-force handling, but this is not a usecase for tty-force, you would be better of using systemd-ask-password I sugest you drop the StandardInput=tty-force from the service file and use this as /etc/mount_truecrypt #!/bin/sh systemd-ask-password Please enter the password to mount your TrueCrypt volumes... | truecrypt -t -k --fs-options=rw,exec,users,async,uid=root,gid=users,umask=077,noatime --mount-options=system --protect-hidden=no /dev/sda1 /media/C /dev/null # that is one line, but gmail will probably break it ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking socket activated services is broken
On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl mbi...@gmail.com wrote: Hi, I've run systemctl mask rsyslog.service, but the service can still be started via systemctl start rsyslog.service or by generating a log message. Looks like a bug to me. Why would it be? Masking just removes the unit from the dependency tree of a target - I kinda prefer being able to mask and manually start a unit. The alternative, which is what you suggest, is that the administrator is prohibited from starting a unit - sounds much worse to me. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking socket activated services is broken
[stupid gmail which dropped the systemd-devel mailing list, so quoting it full here] 2013/6/19 Kok, Auke-jan H auke-jan.h@intel.com: On Wed, Jun 19, 2013 at 9:47 AM, Michael Biebl mbi...@gmail.com wrote: 2013/6/19 Kok, Auke-jan H auke-jan.h@intel.com: On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl mbi...@gmail.com wrote: Hi, I've run systemctl mask rsyslog.service, but the service can still be started via systemctl start rsyslog.service or by generating a log message. Looks like a bug to me. Why would it be? Masking just removes the unit from the dependency tree of a target - I kinda prefer being able to mask and manually start a unit. The alternative, which is what you suggest, is that the Hm, are you maybe confusing disable with mask here? disable usually removes the unit from the various target.wants. And here I agree with you completely: One should still be able to start a disabled service manually. you're right - I was indeed confused with disable... I can see how masking a service that is socket activated shouldn't ever restart it... seems as if something is completely ignoring the symlink. I still think that the root user should be able to start stuff that has been disabled but in this case it probably doesn't make any sense. mask is the big hammer, a service which is masked should not be started, no matter how the start request is triggered: manually, via targets or (socket/D-Bus) activation To illustrate the problem: (non socket-activated service) root@pluto:~# systemctl start cron.service root@pluto:~# systemctl status cron.service cron.service - Command Scheduler Loaded: loaded (/lib/systemd/system/cron.service; enabled) Active: active (running) since Mi 2013-06-19 19:28:42 CEST; 3s ago Main PID: 26041 (cron) CGroup: name=systemd:/system/cron.service └─26041 /usr/sbin/cron -f Jun 19 19:28:42 pluto systemd[1]: Started Command Scheduler. Jun 19 19:28:43 pluto /usr/sbin/cron[26041]: (CRON) INFO (pidfile fd = 3) Jun 19 19:28:43 pluto /usr/sbin/cron[26041]: (CRON) INFO (Skipping @reboot jobs -- not system startup) root@pluto:~# systemctl stop cron.service root@pluto:~# systemctl mask cron.service ln -s '/dev/null' '/etc/systemd/system/cron.service' root@pluto:~# systemctl start cron.service Failed to issue method call: Unit cron.service is masked. In contrast to a socket-activated service (rsyslog) root@pluto:~# systemctl status rsyslog.service rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled) Active: active (running) since Mi 2013-06-19 17:34:39 CEST; 1h 54min ago Main PID: 644 (rsyslogd) CGroup: name=systemd:/system/rsyslog.service └─644 /usr/sbin/rsyslogd -n Jun 19 17:34:39 pluto systemd[1]: Started System Logging Service. root@pluto:~# systemctl stop syslog.socket rsyslog.service root@pluto:~# systemctl mask rsyslog.service ln -s '/dev/null' '/etc/systemd/system/rsyslog.service' root@pluto:~# systemctl start rsyslog.service root@pluto:~# systemctl status rsyslog.service rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service; masked) Active: active (running) since Mi 2013-06-19 19:30:07 CEST; 4s ago Main PID: 26099 (rsyslogd) CGroup: name=systemd:/system/rsyslog.service └─26099 /usr/sbin/rsyslogd -n Jun 19 19:30:07 pluto systemd[1]: Starting System Logging Service... Jun 19 19:30:07 pluto systemd[1]: Started System Logging Service. See the inconsistency? In case of rsyslog, I can also trigger the start, by starting syslog.socket again and running logger. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Text input on startup (tty-force) disabling after a few seconds
Didn't cryptsetup recently get TC support? Could you use that (i.e. /etc/crypttab? On Jun 19, 2013 6:01 PM, Peeters Simon peeters.si...@gmail.com wrote: 2013/6/19 Natanji nata...@gmail.com: Hi everyone, I'm somewhat new to systemd and have a problem. I would like to run a custom script with systemd on startup that will ask me for a password and mount a Truecrypt volume with it. The script and unit file I wrote can be found below. Now, this setup does work *somewhat* - basically it will ask me for my Truecrypt password on startup and do the mounting as it should. But when I wait a few seconds during startup, entering the password no longer works. I just have a few seconds after the password prompt appearing to enter it; if I wait 5-10 seconds nothing will happen anymore. That seems like weird and unintended behaviour to me. Is this a bug, or can you point me in the right direction about what I'm doing wrong if I want some sort of keyboard interaction during system startup with systemd? I mean, that is a useful and sometimes needed feature, right? Unit file: --- [Unit] Description=Mount Truecrypt-encrypted filesystems ConditionFileIsExecutable=/usr/bin/truecrypt Requires=truecrypt-unmount.service Before=display-manager.service [Service] Type=oneshot ExecStart=/etc/mount_truecrypt StandardInput=tty-force RemainAfterExit=yes [Install] WantedBy=multi-user.target /etc/mount_truecrypt: --- #!/bin/bash sudo echo Please enter the password to mount your TrueCrypt volumes... stty -echo read password stty echo echo C: echo $password | sudo truecrypt -t -k --fs-options=rw,exec,users,async,uid=root,gid=users,umask=077,noatime --mount-options=system --protect-hidden=no /dev/sda1 /media/C /dev/null echo ...done. It might be a bug in the tty-force handling, but this is not a usecase for tty-force, you would be better of using systemd-ask-password I sugest you drop the StandardInput=tty-force from the service file and use this as /etc/mount_truecrypt Didn't cryptsetup recently get TC support? Could you use that (i.e. /etc/crypttab? Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking socket activated services is broken
В Wed, 19 Jun 2013 09:36:49 -0700 Kok, Auke-jan H auke-jan.h@intel.com пишет: On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl mbi...@gmail.com wrote: Hi, I've run systemctl mask rsyslog.service, but the service can still be started via systemctl start rsyslog.service or by generating a log message. Looks like a bug to me. Why would it be? Masking just removes the unit from the dependency tree of a target - I kinda prefer being able to mask and manually start a unit. masked unit does not exist. Its content is /dev/null, so there is nothing to start. It is just placeholder. I'm not sure whether it is still possible to start unit using full name but it definitely should not be possible to start unit using unit name, by any means. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking socket activated services is broken
On Wed, Jun 19, 2013 at 07:31:44PM +0200, Michael Biebl wrote: 2013/6/19 Kok, Auke-jan H auke-jan.h@intel.com: On Wed, Jun 19, 2013 at 9:47 AM, Michael Biebl mbi...@gmail.com wrote: 2013/6/19 Kok, Auke-jan H auke-jan.h@intel.com: On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl mbi...@gmail.com wrote: Hi, I've run systemctl mask rsyslog.service, but the service can still be started via systemctl start rsyslog.service or by generating a log message. Looks like a bug to me. Why would it be? Masking just removes the unit from the dependency tree of a target - I kinda prefer being able to mask and manually start a unit. The alternative, which is what you suggest, is that the Hm, are you maybe confusing disable with mask here? disable usually removes the unit from the various target.wants. And here I agree with you completely: One should still be able to start a disabled service manually. you're right - I was indeed confused with disable... I can see how masking a service that is socket activated shouldn't ever restart it... seems as if something is completely ignoring the symlink. I still think that the root user should be able to start stuff that has been disabled but in this case it probably doesn't make any sense. mask is the big hammer, a service which is masked should not be started, no matter how the start request is triggered: manually, via targets or (socket/D-Bus) activation [...] See the inconsistency? In case of rsyslog, I can also trigger the start, by starting syslog.socket again and running logger. From the man page: If a unit file is empty (i.e. has the file size 0) or is symlinked to /dev/null its configuration will not be loaded and it appears with a load state of masked, and cannot be activated. Use this as an effective way to fully disable a unit, making it impossible to start it even manually. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Text input on startup (tty-force) disabling after a few seconds
'Twas brillig, and Peeters Simon at 19/06/13 16:51 did gyre and gimble: It might be a bug in the tty-force handling, but this is not a usecase for tty-force, you would be better of using systemd-ask-password I sugest you drop the StandardInput=tty-force from the service file and use this as /etc/mount_truecrypt #!/bin/sh systemd-ask-password Please enter the password to mount your TrueCrypt volumes... | truecrypt -t -k --fs-options=rw,exec,users,async,uid=root,gid=users,umask=077,noatime --mount-options=system --protect-hidden=no /dev/sda1 /media/C /dev/null # that is one line, but gmail will probably break it For more info on this approach see here: http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/ But if Tom is correct (and he usually is) that's probably the simplest route forward. 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] Masking socket activated services is broken
2013/6/19 Michael Biebl mbi...@gmail.com: To illustrate the problem: (non socket-activated service) ... In contrast to a socket-activated service (rsyslog) ... See the inconsistency? In case of rsyslog, I can also trigger the start, by starting syslog.socket again and running logger. I've tried it with another socket activated service (avahi-daemon) and could not reproduce the problem there. So this might be specific to rsyslog / the sylsog integration. Usually we have foo.service and a corresponding foo.socket. With syslog, the rsyslog.service (or syslog-ng.service) use the syslog.service Alias to map to syslog.socket Maybe systemd get's confused because of this. I've filed a bug now: https://bugs.freedesktop.org/show_bug.cgi?id=65946 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Describe handling of an AF_UNIX socket
On Wed, Jun 19, 2013 at 5:59 AM, Łukasz Stelmach l.stelm...@samsung.com wrote: Describe how to handle an AF_UNIX socket, with Accept set to false, received from systemd, upon exit. Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com --- man/systemd.socket.xml | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) Applied, thanks! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Delay dbus connection for user session
On Tue, Jun 4, 2013 at 10:31 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 29.05.13 08:59, Yang Chengwei (chengwei.y...@intel.com) wrote:
diff --git a/src/core/manager.c b/src/core/manager.c
index 0508628..467b5ba 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -503,7 +503,7 @@ int manager_new(SystemdRunningAs running_as, Manager
**_m) {
goto fail;
/* Try to connect to the busses, if possible. */
-r = bus_init(m, running_as != SYSTEMD_SYSTEM);
+r = bus_init(m, running_as != SYSTEMD_SYSTEM running_as !=
SYSTEMD_USER);
if (r 0)
goto fail;
So, I've looked at this code again as I've spotted this problem over a
year ago, and I'm wondering if this entire section should just be
removed, since running_as only has 2 values (_SYSTEM and _USER)
anyway...
Would there be any objection to just dropping these 4 lines entirely?
Lennart, Kay? I don't see how we'd have a 3rd manager type here.
Yes, just in that case. If all of you agreed, I'd like submit a V2 to
drop these lines.
Hmm, this would break my usual testing routine, where i run user systemd
against a bus daemon that is already running... I have no doubt that
dropping the check entirely is the right way to go eventually, but maybe
we can find a better way so that this continues to work for me until
GNOME has switched over to systemd as service manager.
I'm kinda dumb for not thinking this over, but, if you already have a
dbus-daemon running, you have DBUS_SESSION_BUS_ADDRESS set.
So, the whole idea of connection to a session bus if
DBUS_SESSION_BUS_ADDRESS is unset makes no sense whatsoever.
Lennart, would you agree that we could just do something like:
if (getenv(DBUS_SESSION_BUS_ADDRESS))
// attempt to init dbus early
else
// debug message printing out that an attempt to connect to an
existing session bus was not done
I think that solves your use case, and will remove the whole dbus init
attempt for folks running under a user session where this is not
needed.
Thanks,
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
