Re: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Alberto Bertogli]

I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...


On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
 On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
 
  a) getting the name of the cryptdev that the password request
  corresponds to currently involves parsing the prompt message
  (Please enter passphrase for disk %s!) which is obviously not a
  real solution...
  
  This issue is fixable with minor upstream changes, e.g. by extending
  the PasswordAgent protocol to add Subsystem=cryptsetup and
  Target=diskname entries to the ask. file.
 
 I'd be fine with adding a field Id= or so, which then is filled by an
 identifier of some kind be the cryptsetup tool that is useful to
 identify the device to query things on. for example:
 Id=cryptsetup:/dev/sda5 or so could be one way how this could be
 filled in. We wouldn't enfoce any kind of syntax on this, just suggest
 some common sense so that people choose identifiers that are unlikely to
 clash with other subsystems, and somewhat reasonable to read...

... and I ran into a problem with this, because in practise this field
can look like:

  Id=cryptsetup:ST1234AB567-1CD234 (cbackups) on /var/backups/

for a crypttab line like:

  cbackups /dev/disk/by-id/ata-ST1234AB567-1CD234_1XY2ZWAB-part2 cbackups 
luks,keyscript=/usr/bin/kxc-cryptsetup


because it comes from the name, which seems to be constructed for
human consumption, at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n596

So a password agent _still_ needs to resort to brittle parsing of the
Id field in order to find the corresponding crypttab entry.


Would changing get_password() to take an additional id, which would be
the volume name (argv[2]), and use that for the ask_password_auto() id,
be ok with you?

That would allow password agents to have a reliable id to work with
without doing brittle parsing, and matching what's in crypttab.


In theory, existing code should not need to adjust to the change, as the
proposed change is already a possibility when neither the mount point or
description are available, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n607
I don't know of any password agents to verify in practise, though.



  b) the password agent implementation in systemd doesn't seem to
  handle binary strings (i.e. strings with '\0'), as can be seen by
  calls to e.g. strlen()...
  
  Whether making it binary safe would be a major change or not is
  something I haven't researched yet but it seems like a change that
  should be generally useful upstream...
 
 I'd be OK with this, as discussed at FOSDEM, and I see you already
 posted a ptach for this.

Has this been merged?

Is it safe for a password agent to write content with \0 back to the
socket?

Thanks!
Alberto


[1]: In case it helps anyone else, I added the initramfs option to
crypttab as a workaround, which works in my case because the script
(kxc) is initramfs-ready.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd looping too fast after an automatic attempt to restart anacron

[Alberto Bertogli]

Hi!

I noticed by chance that systemd was using ~15% of a CPU in my laptop,
according to top.

This is on Debian testing, systemd 215-12.

The machine has been up since January, but this started to happen
earlier today, while I was asleep, and it seems to be correlated with an
automatic restart of anacron.

The 3.18.3 kernel was built from vanilla sources and has never had
problems with systemd so far.

I asked on #systemd and they suggested me to post here, following up
with the information requested at
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028541.html
(which seems to be a similar problem, if not the same).

So below I paste some general information that I sent on IRC, the gdb
output as requested in the email from February, and some information about the
suspicious anacron restart.


I hope this helps! I won't restart systemd for a day or two (unless it
gets worse, I can spare 15% of a CPU), so if there's any other
information you need, please let me know.

Thanks!
Alberto


- 8 - 8 - 8 - 8 - 8 -

top reports systemd (pid/tid 1) consuming ~15% of a CPU all the time.

vmstat shows high CPU usage with almost nothing running (not even a
browser) and a lot of context switches:

procs ---memory-- ---swap-- -io -system-- --cpu-
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 1  0  0 1775176 158244 126783200 0 0  341 45293  5  3 92  
0  0
 0  0  0 1775176 158244 126783200 0 0  352 50775  5  3 93  
0  0
 2  0  0 1775920 158244 126783200 080  341 16583  4  2 93  
1  0
 0  0  0 1774796 158244 126783200 0 0  330 32687  4  2 94  
0  0
 0  0  0 1774812 158244 126783600 0 0  337 50805  5  3 92  
0  0


$ tail /var/log/syslog
Mar 28 09:51:14 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:15 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:16 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:17 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:19 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:20 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:21 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:22 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:24 hostname systemd[1]: Looping too fast. Throttling execution a 
little.
Mar 28 09:51:25 hostname systemd[1]: Looping too fast. Throttling execution a 
little.


An strace shows it quite busy too, doing the same loop over an over. Here's
a snippet:

1 09:46:32 timerfd_settime(12, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={5864380, 69834}}, NULL) = 0
1 09:46:32 epoll_wait(4, {{EPOLLOUT, {u32=2552835776, 
u64=139752198713024}}}, 41, 0) = 1
1 09:46:32 clock_gettime(CLOCK_BOOTTIME, {5864326, 657137453}) = 0
1 09:46:32 recvmsg(17, 0x7fff5f588a80, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily 
unavailable)
1 09:46:32 timerfd_settime(12, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={5856161, 19834}}, NULL) = 0
1 09:46:32 epoll_wait(4, {{EPOLLOUT, {u32=2552835776, 
u64=139752198713024}}, {EPOLLIN, {u32=3, u64=3}}}, 41, 0) = 2
1 09:46:32 clock_gettime(CLOCK_BOOTTIME, {5864326, 657236489}) = 0
1 09:46:32 read(12, \1\0\0\0\0\0\0\0, 8) = 8
1 09:46:32 recvmsg(17, 0x7fff5f588a80, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily 
unavailable)
1 09:46:32 timerfd_settime(12, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={5864380, 69834}}, NULL) = 0
1 09:46:32 epoll_wait(4, {{EPOLLOUT, {u32=2552835776, 
u64=139752198713024}}}, 41, 0) = 1
1 09:46:32 clock_gettime(CLOCK_BOOTTIME, {5864326, 657356895}) = 0
1 09:46:32 recvmsg(17, 0x7fff5f588a80, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily 
unavailable)
1 09:46:32 timerfd_settime(12, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={5856161, 19834}}, NULL) = 0
1 09:46:32 epoll_wait(4, {{EPOLLOUT, {u32=2552835776, 
u64=139752198713024}}, {EPOLLIN, {u32=3, u64=3}}}, 41, 0) = 2
1 09:46:32 clock_gettime(CLOCK_BOOTTIME, {5864326, 657456514}) = 0
1 09:46:32 read(12, \1\0\0\0\0\0\0\0, 8) = 8
1 09:46:32 recvmsg(17, 0x7fff5f588a80, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily 
unavailable)
1 09:46:32 timerfd_settime(12, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={5864380, 69834}}, NULL) = 0
1 09:46:32 epoll_wait(4, {{EPOLLOUT, {u32=2552835776, 
u64=139752198713024}}}, 41, 0) = 1
1 09:46:32 clock_gettime(CLOCK_BOOTTIME, {5864326, 657575831}) = 0
1 09:46:32 recvmsg(17, 0x7fff5f588a80,