Re: [systemd-devel] Add ARCH parameter to /etc/os-release
Op 18 apr. 2013, om 14:08 heeft Lennart Poettering het volgende geschreven: > On Thu, 18.04.13 09:26, Koen Kooi (k...@dominion.thruhere.net) wrote: > >> So it returns something that could be considered usefull on my laptop, but >> the output on the beaglebone is useless. On ARM you need to know the >> following to see if you can execute the binary: >> >> 1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a) >> 2) OABI or EABI >> 3) floating point calling conventions, softp vs hardfp > > Are these even encoded in the ELF header? If you take an armv7a binary > and execute it on arm5te, what happens? will the kernel quickly say > "Nah, incompatible binary"? Or will it run until the first unknown > instruction comes and the segfault or sigbus? Usually sigbus, but it depends on what you're trying to mix. It's a mess on ARM, don't try to understand it :) regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Service unit issue: starts manually but doesn't start on boot
Greetings, I hope this issue is familiar to someone here. I wrote a unit file for a service called "wsgw". It starts fine with `systemctl start wsgw`, and `systemctl enable wsgw` goes smoothly, but the service doesn't start on boot. My only diagnostic so far has been running `systemctl status wsgw`. When I do this after a boot, I get the following: wsgw.service - WebSockets Gateway for pianod Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled) Active: inactive (dead) since Thu, 18 Apr 2013 21:06:37 -0700; 1h 0min ago Process: 874 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/wsgw.service When I then run `systemctl start wsgw; systemctl status wsgw` I get: wsgw.service - WebSockets Gateway for pianod Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled) Active: active (running) since Thu, 18 Apr 2013 22:09:40 -0700; 7ms ago Main PID: 2565 (wsgw) CGroup: name=systemd:/system/wsgw.service ? 2565 /usr/sbin/wsgw -p 8000 pianod,localhost,4445,text One thing I notice between the failed-on-boot and succeeded-on-manual-start cases is that the environment variables appear to be unsubstituted in the failed-on-boot case. But of course, one looks like it is reprinting the ExecStart line, and one looks like it's listing the actual command for the successfully running process, so this difference may be expected. I have confirmed that executing the wsgw with no arguments or blank arguments does cause an exit with status 0. It seems like lots of invalid arguments all produce exits with status 0 actually, so probably I should talk to the main developer about making these exit codes more helpful. Also the timestamp on the failed status is wrong; it's an hour earlier than it should be. I have another service with a very similar setup that doesn't have this issue. Links to the two unit files and the EnvironmentFile for each (wsgw is the one with the issue, pianod is very similar but works on boot): http://svn.deviousfish.com/wsgw/contrib/wsgw.service http://svn.deviousfish.com/wsgw/contrib/wsgw.env http://svn.deviousfish.com/pianod/pianod/contrib/pianod.service http://svn.deviousfish.com/pianod/pianod/contrib/pianod.env I've run `systemd --test --system --unit=multi-user.target` and compared the wsgw and pianod sections of output and no significant differences jump out at me. I have this issue on both a RaspberryPi running ArchLinuxARM, and an x86_64 running FedoraCore17. Thanks for reading, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 202
Heya! Many fixes, some additions, and a lot of (experimental) kdbus work. kdbus is coming along nicely, BTW. http://www.freedesktop.org/software/systemd/systemd-202.tar.xz CHANGES WITH 202: * The output of 'systemctl list-jobs' got some polishing. The '--type=' argument may now be passed more than once. A new command 'systemctl list-sockets' has been added which shows a list of kernel sockets systemd is listening on with the socket units they belong to, plus the units these socket units activate. * The experimental libsystemd-bus library got substantial updates to work in conjunction with the (also experimental) kdbus kernel project. It works well enough to exchange messages with some sophistication. Note that kdbus is not ready yet, and the library is mostly an elaborate test case for now, and not installable. * systemd gained a new unit 'systemd-static-nodes.service' that generates static device nodes earlier during boot, and can run in conjunction with udev. * libsystemd-login gained a new call sd_pid_get_user_unit() to retrieve the user systemd unit a process is running in. This is useful for systems where systemd is used as session manager. * systemd-nspawn now places all containers in the new /machine top-level cgroup directory in the name=systemd hierarchy. libvirt will soon do the same, so that we get a uniform separation of /system, /user and /machine for system services, user processes and containers/virtual machines. This new cgroup hierarchy is also useful to stick stable names to specific container instances, which can be recognized later this way (this name may be controlled via systemd-nspawn's new -M switch). libsystemd-login also gained a new call sd_pid_get_machine_name() to retrieve the name of the container/VM a specific process belongs to. * bootchart can now store its data in the journal. * libsystemd-journal gained a new call sd_journal_add_conjunction() for AND expressions to the matching logic. This can be used to express more complex logical expressions. * journactl can now take multiple --unit= and --user-unit= switches. * The cryptsetup logic now understands the "luks.key=" kernel command line switch for specifying a file to read the decryption key from. Also, if a configured key file is not found the tool will now automatically fall back to prompting the user. * Python systemd.journal module was updated to wrap recently added functions from libsystemd-journal. The interface was changed to bring the low level interface in s.j._Reader closer to the C API, and the high level interface in s.j.Reader was updated to wrap and convert all data about an entry. Contributions from: Anatol Pomozov, Auke Kok, Harald Hoyer, Henrik Grindal Bakken, Josh Triplett, Kay Sievers, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas Marius Vollmer, Martin Jansa, Martin Pitt, Michael Biebl, Michal Schmidt, Mirco Tischler, Pali Rohar, Simon Peeters, Steven Hiscocks, Tom Gundersen, Zbigniew Jędrzejewski-Szmek Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V2] cryptsetup: ask for password, if key file cannot be accessed
On Thu, 18.04.13 09:41, har...@redhat.com (har...@redhat.com) wrote: > From: Harald Hoyer > > If the key file cannot be accessed, we can at least ask for the > password. Looks good! Applied! (I didn't test it though, but I hope you did? ;-)) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-logind: Fix linking by reordering libraries in LDADD
On Thu, Apr 18, 2013 at 8:32 PM, Josh Triplett wrote: > libsystemd-audit needs functions from libsystemd-shared, so > libsystemd-audit needs to appear first. Otherwise: > > CCLD systemd-logind > ./.libs/libsystemd-audit.a(audit.o): In function `audit_session_from_pid': > /home/josh/src/systemd/src/shared/audit.c:50: undefined reference to > `detect_container' Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-logind: Fix linking by reordering libraries in LDADD
libsystemd-audit needs functions from libsystemd-shared, so libsystemd-audit needs to appear first. Otherwise: CCLD systemd-logind ./.libs/libsystemd-audit.a(audit.o): In function `audit_session_from_pid': /home/josh/src/systemd/src/shared/audit.c:50: undefined reference to `detect_container' --- Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..dede567 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3461,8 +3461,8 @@ systemd_logind_CFLAGS = \ systemd_logind_LDADD = \ libsystemd-label.la \ - libsystemd-shared.la \ libsystemd-audit.la \ + libsystemd-shared.la \ libsystemd-daemon.la \ libsystemd-dbus.la \ libudev.la -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On 04/10/2013 12:03 PM, Koen Kooi wrote: Hi, I have a bit of a heisenbug where dropbear.socket will just die and needs a systemctl restart dropbear.socket. I can't tell why it's dying, just that it does within 3 days of uptime. After restarting it it seems to be rock solid again for at least some weeks. The real way to fix this is to find out why it dies, but till someone figures that out I'm looking to a way to automatically restart the socket when it fails, kinda like Restart=Always for services. Is such a thing possible? This is with 195 and 196, haven't tried 201 yet. regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I'm having exactly the same problem with sshd.socket (openssh) with systemd 197. I've done a netstat after it dies (just says dead no useful information) and port 22 still shows up under listening. systemctl start sshd.socket fixes the problem. I just upgraded to systemd 201 so I'll let you know if the problem shows up again. The problem happens intermittently so its been a bit elusive. Regards, George McCollister ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] buildsys: Add --disable-tests to avoid building tests
On Thu, 18.04.13 14:40, Henrik Grindal Bakken (h...@ifi.uio.no) wrote: > This patch adds --disable-tests to configure. It is based on a patch > posted by Thierry Reding in 2010. The motivation for adding it is that > some tests fail link-time when cross-compiling. > > The patch adds a new Makefile variable -- manual_tests -- and uses > that instead of noinst_PROGRAMS. However, if ENABLE_TESTS is true, > the former is added to the latter. It also renames noinst_tests to > simply tests. Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On Thu, 18.04.13 16:38, Thomas Bächler (tho...@archlinux.org) wrote: > Am 18.04.2013 16:04, schrieb Lennart Poettering: > > That said, screen should probably set up a new PAM session of its own > > and detach from the original one. > > That sounds like a good idea - unfortunately, screen does not seem to > have PAM session support at all, and I couldn't find the obvious place > to add this inside screen (I didn't invest much time in it either). This > would allow screen sessions to be tracked by logind instead of having > many "State=closing" sessions floating around. BTW, this probably needs sokme changes in systemd too. Since right now, if you open a PAM session from a process that is already part of a PAM session logind will just return the same data as the first time. So to make this work properly, we'd to define a way how certain PAM services can explicitly ask to get a new session assigned. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
Am 18.04.2013 16:04, schrieb Lennart Poettering: > That said, screen should probably set up a new PAM session of its own > and detach from the original one. That sounds like a good idea - unfortunately, screen does not seem to have PAM session support at all, and I couldn't find the obvious place to add this inside screen (I didn't invest much time in it either). This would allow screen sessions to be tracked by logind instead of having many "State=closing" sessions floating around. Has anyone worked on this? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=
On Thu, 18.04.13 08:46, Harald Hoyer (har...@redhat.com) wrote: > > Then, the whole PID file story looks like a mess to me anyway, modern > > daemons should not use PID files anyway... Even more, making them > > configurable sounds really wrong. If this is about allowing > > instantiation, then people can use %i in the PID file name, and be done > > with it, but otherwise this sounds like a completely ridiculous > > configuration option in sysconfig, like the first one to get rid > > of... So the usecase already sounds really wrong to me, to start with. > > > > This really sounds like a bug to me we should close WONTFIX with a nice > > explanation. I know Tom won't like that, but well, sometimes we have to > > say No to wishes. > > > > I know I though different about this in January (and commented so in the > > bug), but in retrospect I must disagree with myself on this... > > fair enough, care to close the bug then? OK, done! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On Thu, 18.04.13 09:28, Koen Kooi (k...@dominion.thruhere.net) wrote: > > And if the somebody invokes shutdown() on the listening socket (not the > > connection socket), but that's a really weird thing to do. But people do > > weird things, and this has occured before. > > > > Otherwise I have no idea what could have happened. Any chance you can > > reproduce this with strace attached to PID 1 or so? > > Still trying to reproduce it in a way I can instrument it. > > > Is dropbear forked off one instance per connection, or one instance for > > all? > > Looks like one instance per connection. Hmm, if so dropbear would never get access to the listening socket, to issue a "shutdown()" on it. This becomes weirder and weirder. If you manage to reproduce it, it would be good to get the full output of "systemctl show -a" for the socket unit. > But I'm going to replace dropbear with openssh in the medium term > because dropbear doesn't do enough PAM to register itself with logind, > so things like 'screen' get killed on logout. You could work around this by use KillMode=process. That said, screen should probably set up a new PAM session of its own and detach from the original one. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for su command to be ignored in target?
On 04/17/2013 04:16 PM, Lennart Poettering wrote: On Wed, 17.04.13 16:08, Mark Hounschell (ma...@compro.net) wrote: That looks OK. Can you try the logger thing I suggested? That should tell us if the transition works at all... Sorry, I had a dentist Apt. Uh, I put this as the first command in the /lcrs/sh.lcrs script: /bin/su -m -c "logger test" lcrs This comes out in the log: 2013-04-17T15:41:29.754272-04:00 utils-linux systemd-logind[1722]: New session c1 of user lcrs. 2013-04-17T15:41:29.829129-04:00 utils-linux logger: test 2013-04-17T15:41:29.831565-04:00 utils-linux systemd-logind[1722]: Removed session c1. A couple of strange things now. The rest of the script works fine now??? I removed the logger test and rebooted. The script is still working Is there something being cached somewhere? I swear anything I used su for was borked until I added that extra line??? Hmm, no clue. If the logger thing worked, then maybe the next thing would be to patch the script you start via su and add a logger line to the beginning and to the end of it it, and check if that still is generated. I added these to the script started at beginning and end and the messages are still generated. I hate problems that just go away with no explanation. In any case, thanks for fixing it for me. You must have magical powers?? Regards Mark ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add ARCH parameter to /etc/os-release
Okey, okey, you are right. Don't add ARCH to os-release ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v4] buildsys: Add --disable-tests to avoid building tests
This patch adds --disable-tests to configure. It is based on a patch posted by Thierry Reding in 2010. The motivation for adding it is that some tests fail link-time when cross-compiling. The patch adds a new Makefile variable -- manual_tests -- and uses that instead of noinst_PROGRAMS. However, if ENABLE_TESTS is true, the former is added to the latter. It also renames noinst_tests to simply tests. --- Makefile.am | 30 ++ configure.ac |5 + 2 files changed, 23 insertions(+), 12 deletions(-) diff --git a/Makefile.am b/Makefile.am index 7b4b2d8..80d0f1f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -124,9 +124,15 @@ dbusinterface_DATA = dist_dbussystemservice_DATA = check_PROGRAMS = check_DATA = -noinst_tests= -noinst_PROGRAMS = $(noinst_tests) -TESTS = $(noinst_tests) +tests= +manual_tests = +if ENABLE_TESTS +noinst_PROGRAMS = $(manual_tests) $(tests) +TESTS = $(tests) +else +noinst_PROGRAMS = +TESTS = +endif udevlibexec_PROGRAMS = AM_CPPFLAGS = \ @@ -1063,7 +1069,7 @@ CLEANFILES += \ src/core/org.freedesktop.systemd1.policy.in # -- -noinst_PROGRAMS += \ +manual_tests += \ test-engine \ test-ns \ test-loopback \ @@ -1074,7 +1080,7 @@ noinst_PROGRAMS += \ test-watchdog \ test-log -noinst_tests += \ +tests += \ test-job-type \ test-env-replace \ test-strbuf \ @@ -1145,7 +1151,7 @@ test_hostname_LDADD = \ libsystemd-core.la if ENABLE_EFI -noinst_PROGRAMS += \ +manual_tests += \ test-efivars test_efivars_SOURCES = \ @@ -1726,7 +1732,7 @@ libsystemd_bus_la_LIBADD = \ noinst_LTLIBRARIES += \ libsystemd-bus.la -noinst_tests += \ +tests += \ test-bus-marshal \ test-bus-signature \ test-bus-chat \ @@ -2074,7 +2080,7 @@ TESTS += \ test/udev-test.pl \ test/rules-test.sh -noinst_PROGRAMS += \ +manual_tests += \ test-libudev \ test-udev @@ -2527,7 +2533,7 @@ test_id128_LDADD = \ libsystemd-shared.la \ libsystemd-id128-internal.la -noinst_tests += \ +tests += \ test-id128 pkginclude_HEADERS += \ @@ -2835,10 +2841,10 @@ catalog-remove-hook: UNINSTALL_DATA_HOOKS += \ catalog-remove-hook -noinst_PROGRAMS += \ +manual_tests += \ test-journal-enum -noinst_tests += \ +tests += \ test-journal \ test-journal-send \ test-journal-syslog \ @@ -3536,7 +3542,7 @@ test_inhibit_CFLAGS = \ $(AM_CFLAGS) \ $(DBUS_CFLAGS) -noinst_PROGRAMS += \ +manual_tests += \ test-login \ test-inhibit diff --git a/configure.ac b/configure.ac index 519f1a9..aec85ea 100644 --- a/configure.ac +++ b/configure.ac @@ -880,6 +880,11 @@ AS_IF([test "x$0" != "x./configure"], [ AC_SUBST([INTLTOOL_UPDATE], [/bin/true]) ]) +AC_ARG_ENABLE(tests, + [AC_HELP_STRING([--disable-tests], [disable tests])], + enable_tests=$enableval, enable_tests=yes) +AM_CONDITIONAL(ENABLE_TESTS, [test x$enable_tests = xyes]) + AC_SUBST([dbuspolicydir], [$with_dbuspolicydir]) AC_SUBST([dbussessionservicedir], [$with_dbussessionservicedir]) AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir]) -- 1.7.10.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add ARCH parameter to /etc/os-release
On Thu, 18.04.13 09:26, Koen Kooi (k...@dominion.thruhere.net) wrote: > So it returns something that could be considered usefull on my laptop, but > the output on the beaglebone is useless. On ARM you need to know the > following to see if you can execute the binary: > > 1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a) > 2) OABI or EABI > 3) floating point calling conventions, softp vs hardfp Are these even encoded in the ELF header? If you take an armv7a binary and execute it on arm5te, what happens? will the kernel quickly say "Nah, incompatible binary"? Or will it run until the first unknown instruction comes and the segfault or sigbus? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add ARCH parameter to /etc/os-release
]] Koen Kooi > But it does answer the "can I nspawn into this rootfs?" question for > different architectures like powerpc vs x86 :) No, it doesn't. You'll have false negatives, think about binfmt_misc combined with qemu user emulation for instance. The right way to see if you can do that is to try. Just like you shouldn't use access(2) and then open(2) it, you should just open it and handle failure. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Per-instance override with foobar.service.d
On 18/04/13 01:27, Lennart Poettering wrote: On Mon, 08.04.13 20:08, John Lane (syst...@jelmail.com) wrote: I'm trying out the new foobar.service.d way of overriding unit files. I thought that I'd be able to have a number of service instances that were overridden differently but that does not seem to be the case (or, at least, I can't get it to work). I first updated to systemd 200 and tried foobar.service.d with foobar.service.d/custom.conf; this works as described on the man page and release notes. I've also tried: foobar@.service and foobar@.service.d/myinstance.conf foobar@.service and foobar@myinstance.service.d/myinstance.conf This should definitely work, and if it doesn't this sounds like oversight. I have added to the TODO list to fix this. which don't work so I guess this isn't implemented. If so, would something like that be a reasonable request to be considered ? I was thinking... foobar@.service foobar@.service.d/myfirstinstance.conf foobar@.service.d/mysecondinstance.conf where the relevant .conf would be selected based on the instance name. This sounds redundant and confusing, no? I mean, if we'd implement that you only could have exctly one drop-in file pre instance, and that wold be a serious limitation, no? yes - agree - foobar@myinstance.service.d/ is the better option for instance-specific configs and, if that's on the TODO list - great! I was also wondering why the need for a separate sub-directory when there's only one file inside it. Could a file like "foobar.service.conf" be considered as an alternative (and, perhaps, foo...@myinstance.service.conf) ? I'd prefer not adding to much redundancy here. Also, the .d/ scheme for multiple drop-ins is also kinda known vocabulary on Unix already, so we thought to stick to it, and have things a bit uniform... My thoughts were merely following on from what has gone before, like on Xorg where you can either have a single .conf or a .d containing multiple configs. I think requiring a .d when you know there is only going to be a single file is overkill but that's just personal preference. I mean, I can be conviced to add something if it really makes sense. But for that it better not add redundancy, or if it does then you need a really strong case for it... No really strong case here - just a suggestion. Lennart Regards, John ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] disable/enable vs reenable
Hi, If one executes: $ sudo systemctl enable getty@tty1.service ln -s '/usr/lib/systemd/system/getty@.service' '/etc/systemd/system/getty.target.wants/getty@tty1.service' and then you decide to override getty@.service: $ sudo cp /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty@.service the override does not work, as expected, because the symbolic link points to /usr..., not the overridden service file: $ ls -l /etc/systemd/system/getty.target.wants/ total 0 lrwxrwxrwx 1 root root 38 Apr 18 08:41 getty@tty1.service -> /usr/lib/systemd/system/getty@.service The documentation for reenable indicates that it should fix this problem: reenable NAME... Reenable one or more unit files, as specified on the command line. This is a combination of disable and enable and is useful to reset the symlinks a unit is enabled with to the defaults configured in the [Install] section of the unit file. But it does not work: $ sudo systemctl reenable getty@tty1.service Failed to issue method call: File exists However, disabling and enabling *does* work and gives the desired result: $ sudo systemctl disable getty@tty1.service rm '/etc/systemd/system/getty.target.wants/getty@tty1.service' $ sudo systemctl enable getty@tty1.service ln -s '/etc/systemd/system/getty@.service' '/etc/systemd/system/getty.target.wants/getty@tty1.service' Is this a bug, a documentation problem or neither? (using Arch Linux with systemd 201) Regards -- Ross Lagerwall ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH V2] cryptsetup: ask for password, if key file cannot be accessed
From: Harald Hoyer
If the key file cannot be accessed, we can at least ask for the
password.
---
Remove access() call and check the return value of
crypt_activate_by_keyfile_offset()
src/cryptsetup/cryptsetup.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 376f748..a24e61a 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -500,6 +500,11 @@ int main(int argc, char *argv[]) {
if (key_file)
k = crypt_activate_by_keyfile_offset(cd,
argv[2], CRYPT_ANY_SLOT, key_file, opt_keyfile_size,
opt_keyfile_offset, flags);
+if (k < 0) {
+log_error("Failed to activate with key
file '%s': %s", key_file, strerror(-k));
+key_file = NULL;
+continue;
+}
else {
char **p;
--
1.8.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
Op 17 apr. 2013, om 21:05 heeft Lennart Poettering het volgende geschreven: > On Wed, 10.04.13 19:03, Koen Kooi (k...@dominion.thruhere.net) wrote: > >> Hi, >> >> I have a bit of a heisenbug where dropbear.socket will just die and >> needs a systemctl restart dropbear.socket. I can't tell why it's >> dying, just that it does within 3 days of uptime. After restarting it >> it seems to be rock solid again for at least some weeks. >> >> The real way to fix this is to find out why it dies, but till someone >> figures that out I'm looking to a way to automatically restart the >> socket when it fails, kinda like Restart=Always for services. Is such >> a thing possible? This is with 195 and 196, haven't tried 201 yet. > > So, two things: > > When a service continuously dies we'll put the listening socket into > fail state eventually. But you can see these ones easily in "systemctl > status", since they have a specific result > "service-failed-permanent". (results are shown next to the "Active:" > field if a unit failed). > > And if the somebody invokes shutdown() on the listening socket (not the > connection socket), but that's a really weird thing to do. But people do > weird things, and this has occured before. > > Otherwise I have no idea what could have happened. Any chance you can > reproduce this with strace attached to PID 1 or so? Still trying to reproduce it in a way I can instrument it. > Is dropbear forked off one instance per connection, or one instance for > all? Looks like one instance per connection. But I'm going to replace dropbear with openssh in the medium term because dropbear doesn't do enough PAM to register itself with logind, so things like 'screen' get killed on logout. regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add ARCH parameter to /etc/os-release
Op 17 apr. 2013, om 20:19 heeft Lennart Poettering het volgende geschreven: > On Mon, 08.04.13 22:09, Askar Safin (safinas...@mail.ru) wrote: > >> >>> I'm not sure what problem the proposal is trying to solve. Maybe it'd >>> be clearer if that was provided. >> I want to know what is the arches of the systems on my computer. I. e. I >> want to do the following: >> >> for DISK in /dev/sd*; do >> mount "$DISK" /mnt >> source /mnt/etc/os-release >> echo "Arch of $DISK is $ARCH" >> done >> >> And I want to use this $ARCH to do "setarch", i. e.: >> mount /dev/some-dev /mnt >> source /mnt/etc/os-release >> setarch "$ARCH" chroot /mnt >> So, this /mnt system will see "uname -m" output which is meaningful for the >> system. > > My suggestion would be to write a little tool that does the equivalent > to this: > > readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq > > This will list you the architectures for which you have dynamic loaders > installed. Since the dynamic loaders are hardcoded in all dynamic ELF > binaries this list will tell you binaries of which archs you can execute > on your system. On my i7 laptop: [koen@rrMBP mplayer2]$ readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq Advanced Micro Devices X86-64 Intel 80386 And on a cortex A8 device: root@beaglebone:~# readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq ARM So it returns something that could be considered usefull on my laptop, but the output on the beaglebone is useless. On ARM you need to know the following to see if you can execute the binary: 1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a) 2) OABI or EABI 3) floating point calling conventions, softp vs hardfp The first item is like i386, i486 etc. It's compatible only one way. The second is academical at this point, only luddites running kernel 2.4 are interested in OABI. And then we get to the clusterfuck, floatingpoint ABI. I need to install binutils on my hardfloat system to see if that also says 'ARM', I bet it does. But it does answer the "can I nspawn into this rootfs?" question for different architectures like powerpc vs x86 :) regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
