Re: [systemd-devel] Socket is dying, how to automatically restart it?
Op 23 apr. 2013, om 23:03 heeft George McCollister george.mccollis...@gmail.com het volgende geschreven: On 04/20/2013 08:04 AM, Koen Kooi wrote: Op 18 apr. 2013, om 19:18 heeft George McCollistergeorge.mccollis...@gmail.com het volgende geschreven: On 04/10/2013 12:03 PM, Koen Kooi wrote: Hi, I have a bit of a heisenbug where dropbear.socket will just die and needs a systemctl restart dropbear.socket. I can't tell why it's dying, just that it does within 3 days of uptime. After restarting it it seems to be rock solid again for at least some weeks. The real way to fix this is to find out why it dies, but till someone figures that out I'm looking to a way to automatically restart the socket when it fails, kinda like Restart=Always for services. Is such a thing possible? This is with 195 and 196, haven't tried 201 yet. I'm having exactly the same problem with sshd.socket (openssh) with systemd 197. I've done a netstat after it dies (just says dead no useful information) and port 22 still shows up under listening. systemctl start sshd.socket fixes the problem. I just upgraded to systemd 201 so I'll let you know if the problem shows up again. The problem happens intermittently so its been a bit elusive. It is indeed elusive, it hasn't happened to me in the past week, so progress is slow on this. ¸ regards, Koen This is really strange but I think I just accidentally found a way to reproduce the problem. 1) Reboot 2) Verify ssh works 3) login as root and run: systemctl --system daemon-reload Can't ssh anymore. If I do 'systemctl start sshd.socket' I can ssh again and doing 'systemctl --system daemon-reload' again doesn't seem to break it. I did a daemon reload the past week as well after reboot and yesterday my workstation suspended and dropped the connection, so I had to reconnect, which failed. regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn/LXC containers pam login failure
Following the suggestion in the systemd-nspawn manpage I populated
a mini Fedora 19 chroot, on a Fedora 19 host
# yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer \
--disablerepo='*' --enablerepo=fedora \
install systemd passwd yum fedora-release vim-minimal
# chroot /srv/mycontainer passwd
# systemd-nspawn -bD /srv/mycontainer
Systemd boots up nicely presents a login prompt, but it is impossible
to actually login, PAM always denying the attempts.
Debugging this, there seem to be two issues
1. pam_loginuid.so tries to write to /proc/self/loginuid but is denied
by the kernel.
My kernel has CONFIG_AUDIT_LOGINUID_IMMUTABLE=y which means once a
loginuid is set (in this case from my ssh session into the host),
it can't be changed (eg by the 'login' process inside the container).
From the KConfig comment, this appears to have been a new feature
built explicitly for systemd based hosts.
The loginuid appears to be inherited across fork/exec so, AFAICT,
the only way to avoid this is to spawn the container from something
which does not already have a loginuid set, eg systemd itself or
some other process not associated with a login session.
Not being able to spawn containers from a login session on the host
is kind of a PITA for development / debuging :-(
Seems we need to find a way to have systemd-nspawn ensure that the
'init' process inside the container does not have a 'loginuid' set,
even if the thing starting the container does. On the flipside, it
seems this would violate the kernel security design for this feature ?
If that were the case, then the pam_loginuid module might need to
be made a no-op inside containers.
2. The audit_log_acct_message() method which is called by pretty
much any PAM module returns EPERM
There is no actual syscall returning EPERM here. The EPERM
appears to be coming back inside the netlink reply message
from the kernel audit subsystem. Since pretty much every PAM
module sends audit messages, this causes them all to return
fatal errors, failing the login attempt
The _pam_audit_writelog() method does have code to ignore
EPERM, but it only does so if 'getuid() != 0'. The container
login process has uid == 0, so EPERM is treated as fatal. The
easy (but not neccessarily correct) fix is to change
diff -rup Linux-PAM-1.1.6.orig/libpam/pam_audit.c
Linux-PAM-1.1.6.new/libpam/pam_audit.c
--- Linux-PAM-1.1.6.orig/libpam/pam_audit.c 2012-08-15
12:08:43.0 +0100
+++ Linux-PAM-1.1.6.new/libpam/pam_audit.c 2013-05-09
10:17:48.679403471 +0100
@@ -46,7 +46,7 @@ _pam_audit_writelog(pam_handle_t *pamh,
pamh-audit_state |= PAMAUDIT_LOGGED;
if (rc 0) {
- if (rc == -EPERM getuid() != 0)
+ if (rc == -EPERM)
return 0;
if (errno != old_errno) {
old_errno = errno;
but I'd rather like to understand why the kernel audit netlink
layer is replying with EPERM in the first place. The container
has CAP_AUDIT_WRITE capability.
Instead of removing the 'getuid() != 0' check, another option
would be to augment it to also check /proc/1/environ for any
'container' env variable.
If I remove the pam_loginuid module and also apply that above audit
patch to PAM, then I can successfuly login to a container launched
by systemd-nspawn. It would obviously be preferrable to figure out
what needs to be done to make this work out of the box though.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn/LXC containers pam login failure
On Thu, 09.05.13 11:38, Daniel P. Berrange (berra...@redhat.com) wrote:
Following the suggestion in the systemd-nspawn manpage I populated
a mini Fedora 19 chroot, on a Fedora 19 host
# yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer \
--disablerepo='*' --enablerepo=fedora \
install systemd passwd yum fedora-release vim-minimal
# chroot /srv/mycontainer passwd
# systemd-nspawn -bD /srv/mycontainer
Systemd boots up nicely presents a login prompt, but it is impossible
to actually login, PAM always denying the attempts.
Yeah, this is a known problem. We generally suggest to turn off audit
by booting with audit=0 on the kernel cmdline for now:
https://fedoraproject.org/wiki/Features/SystemdLightweightContainers
I guess I should add a comment about this to nspawn's man page too.
The audit folks are working on adding container awareness to the audit
subsystem in the kernel (which basically means that audit messages carry
the outside PID of PID1 of the container, so that auditd can track this
properly). Currently audit is completely confused by PID
namespacing. Also, we want them to fix for us that opening a PID
namespace resets loginuid in the container to -1. We have discussed this
several times with them, and they wanted to something about it, but so
far nothing happened. But we'll have another meeting about this next
week, so I can put some pressure on this.
Debugging this, there seem to be two issues
1. pam_loginuid.so tries to write to /proc/self/loginuid but is denied
by the kernel.
My kernel has CONFIG_AUDIT_LOGINUID_IMMUTABLE=y which means once a
loginuid is set (in this case from my ssh session into the host),
it can't be changed (eg by the 'login' process inside the container).
From the KConfig comment, this appears to have been a new feature
built explicitly for systemd based hosts.
The loginuid appears to be inherited across fork/exec so, AFAICT,
the only way to avoid this is to spawn the container from something
which does not already have a loginuid set, eg systemd itself or
some other process not associated with a login session.
Not being able to spawn containers from a login session on the host
is kind of a PITA for development / debuging :-(
Seems we need to find a way to have systemd-nspawn ensure that the
'init' process inside the container does not have a 'loginuid' set,
even if the thing starting the container does. On the flipside, it
seems this would violate the kernel security design for this feature ?
If that were the case, then the pam_loginuid module might need to
be made a no-op inside containers.
The right approach to me here is the aforementioned resetting of
loginuid when a new PID namespace is opened.
2. The audit_log_acct_message() method which is called by pretty
much any PAM module returns EPERM
There is no actual syscall returning EPERM here. The EPERM
appears to be coming back inside the netlink reply message
from the kernel audit subsystem. Since pretty much every PAM
module sends audit messages, this causes them all to return
fatal errors, failing the login attempt
The _pam_audit_writelog() method does have code to ignore
EPERM, but it only does so if 'getuid() != 0'. The container
login process has uid == 0, so EPERM is treated as fatal. The
easy (but not neccessarily correct) fix is to change
diff -rup Linux-PAM-1.1.6.orig/libpam/pam_audit.c
Linux-PAM-1.1.6.new/libpam/pam_audit.c
--- Linux-PAM-1.1.6.orig/libpam/pam_audit.c 2012-08-15
12:08:43.0 +0100
+++ Linux-PAM-1.1.6.new/libpam/pam_audit.c 2013-05-09
10:17:48.679403471 +0100
@@ -46,7 +46,7 @@ _pam_audit_writelog(pam_handle_t *pamh,
pamh-audit_state |= PAMAUDIT_LOGGED;
if (rc 0) {
- if (rc == -EPERM getuid() != 0)
+ if (rc == -EPERM)
return 0;
if (errno != old_errno) {
old_errno = errno;
I tried to get a patch like this into PAM actually, but Steve (of
course) said nononono! He's really married to the idea that audit breaks
everything on any kind of error... This is kinda sad though, as
otherwise this would have allowed us to turn off auditing in the
container completely by removing CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE
of the container...
I guess libvirt-lxc is in a slightly better situation here regarding
audit, since it never tries to spawn a container as child of a login
session, hence loginuid will not be sealed off yet...
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] systemd-nspawn/LXC containers pam login failure
On Thu, May 09, 2013 at 03:32:09PM +0200, Lennart Poettering wrote:
On Thu, 09.05.13 11:38, Daniel P. Berrange (berra...@redhat.com) wrote:
Following the suggestion in the systemd-nspawn manpage I populated
a mini Fedora 19 chroot, on a Fedora 19 host
# yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer \
--disablerepo='*' --enablerepo=fedora \
install systemd passwd yum fedora-release vim-minimal
# chroot /srv/mycontainer passwd
# systemd-nspawn -bD /srv/mycontainer
Systemd boots up nicely presents a login prompt, but it is impossible
to actually login, PAM always denying the attempts.
Yeah, this is a known problem. We generally suggest to turn off audit
by booting with audit=0 on the kernel cmdline for now:
https://fedoraproject.org/wiki/Features/SystemdLightweightContainers
I guess I should add a comment about this to nspawn's man page too.
The audit folks are working on adding container awareness to the audit
subsystem in the kernel (which basically means that audit messages carry
the outside PID of PID1 of the container, so that auditd can track this
properly). Currently audit is completely confused by PID
namespacing. Also, we want them to fix for us that opening a PID
namespace resets loginuid in the container to -1. We have discussed this
several times with them, and they wanted to something about it, but so
far nothing happened. But we'll have another meeting about this next
week, so I can put some pressure on this.
Did you file any BZs against the kernel for this ? If not I'll sort
out some BZs to track these problems.
2. The audit_log_acct_message() method which is called by pretty
much any PAM module returns EPERM
There is no actual syscall returning EPERM here. The EPERM
appears to be coming back inside the netlink reply message
from the kernel audit subsystem. Since pretty much every PAM
module sends audit messages, this causes them all to return
fatal errors, failing the login attempt
The _pam_audit_writelog() method does have code to ignore
EPERM, but it only does so if 'getuid() != 0'. The container
login process has uid == 0, so EPERM is treated as fatal. The
easy (but not neccessarily correct) fix is to change
diff -rup Linux-PAM-1.1.6.orig/libpam/pam_audit.c
Linux-PAM-1.1.6.new/libpam/pam_audit.c
--- Linux-PAM-1.1.6.orig/libpam/pam_audit.c 2012-08-15
12:08:43.0 +0100
+++ Linux-PAM-1.1.6.new/libpam/pam_audit.c 2013-05-09
10:17:48.679403471 +0100
@@ -46,7 +46,7 @@ _pam_audit_writelog(pam_handle_t *pamh,
pamh-audit_state |= PAMAUDIT_LOGGED;
if (rc 0) {
- if (rc == -EPERM getuid() != 0)
+ if (rc == -EPERM)
return 0;
if (errno != old_errno) {
old_errno = errno;
I tried to get a patch like this into PAM actually, but Steve (of
course) said nononono! He's really married to the idea that audit breaks
everything on any kind of error... This is kinda sad though, as
otherwise this would have allowed us to turn off auditing in the
container completely by removing CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE
of the container...
I feared that might be the response from PAM maintainers :-(
I guess libvirt-lxc is in a slightly better situation here regarding
audit, since it never tries to spawn a container as child of a login
session, hence loginuid will not be sealed off yet...
If libvirtd has been started from systemd then yes. Of course during
development I just run libvirtd from my source tree directly, so
still hit the problem :-)
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn/LXC containers pam login failure
On Thu, 09.05.13 14:38, Daniel P. Berrange (berra...@redhat.com) wrote: On Thu, May 09, 2013 at 03:32:09PM +0200, Lennart Poettering wrote: On Thu, 09.05.13 11:38, Daniel P. Berrange (berra...@redhat.com) wrote: Following the suggestion in the systemd-nspawn manpage I populated a mini Fedora 19 chroot, on a Fedora 19 host # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer \ --disablerepo='*' --enablerepo=fedora \ install systemd passwd yum fedora-release vim-minimal # chroot /srv/mycontainer passwd # systemd-nspawn -bD /srv/mycontainer Systemd boots up nicely presents a login prompt, but it is impossible to actually login, PAM always denying the attempts. Yeah, this is a known problem. We generally suggest to turn off audit by booting with audit=0 on the kernel cmdline for now: https://fedoraproject.org/wiki/Features/SystemdLightweightContainers I guess I should add a comment about this to nspawn's man page too. The audit folks are working on adding container awareness to the audit subsystem in the kernel (which basically means that audit messages carry the outside PID of PID1 of the container, so that auditd can track this properly). Currently audit is completely confused by PID namespacing. Also, we want them to fix for us that opening a PID namespace resets loginuid in the container to -1. We have discussed this several times with them, and they wanted to something about it, but so far nothing happened. But we'll have another meeting about this next week, so I can put some pressure on this. Did you file any BZs against the kernel for this ? If not I'll sort out some BZs to track these problems. There's https://bugzilla.redhat.com/show_bug.cgi?id=893751 But this probably deserves two separate bugs against the kernel either on rhbz or on upstream kernel bugzilla. 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] [RFCv6] Optionally save core dumps as plain files
On Tue, 2013-04-30 at 22:32 +0300, Oleksii Shevchuk wrote:
+termvarnameUser=/varname/term
+termvarnameGroup=/varname/term
+
+listitemparaEnforce UID/GID of
+literalsystemd-coredump/literal while
loading
+and storing coredump.
Like having the adm group be able to read core files or something?
Would people really want that?
If not set, then uid/gid of
then the
+crashed process will be used. This can be
used
+for allowing user or group of users
+to have access to system core dumps.
This can be used to allow a user or group of users...
+varlistentry
+termvarnameFileStorage=/varname/term
+
+listitemparaOne of
+literalvolatile/literal and,
+literalpersistent/literal
+value.
One of literalvolatile/ or literalpersistent/.
If literalvolatile/literal, core dump will be
+stored as file to
/run/log/coredump/MACHINE-ID/COMM-TMPSUFFIX location;
+if literalpersistent/literal -- to
+/var/log/coredump/MACHINE-ID/COMM-TMPSUFFIX
location.
I'm uncertain about including COMM (a user-controlled string) in
filenames. Perhaps sanitized.
+Storage directory will be created if not
exists. If
+literalnone/literal, then core dump will
not be stored
+as file at all.
not be stored. ? But here's where ideally we at least ship something
capable of extracting backtraces.
+literalUser=/literal and
literalGroup=/literal
+not setted, then directory will be created
with 1777
not set. And really world writable? Why? Shouldn't systemd-coredump
be the only thing capable of writing to the directory? Note we could
open() the fd as root, and then drop privileges.
+
filename/var/log/coredump/MACHINE-ID/filename. If value equals
+to zero, then backend will be ommited.
omitted.
+if (!config-user) {
+mode |= S_IRGRP | S_IWGRP | S_IXGRP;
+mode |= S_IROTH | S_IWOTH | S_IXOTH;
Ok right, so looking at the actual code, we setresuid early on to the
dumping user, and then rely on world-writability. It would be a lot
better to do what I suggested above and call open() first and then drop
credentials?
For what it's worth I just looked at:
http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c
They simply rely on a static kernel core pattern and monitor the
directory with inotify, which is interesting. The downside I guess is
that the kernel will bindly keep filling up the disk, whereas doing the
dumping in userspace we can have more flexible control over placement
and storage usage.
So...what do you think about dropping the User/Group settings,
having /var/log/coredump have the same permissions as the journal? I.e.
owned by root:root and with an ACL for access by adm or whatever?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn/LXC containers pam login failure
On Thu, May 09, 2013 at 03:32:09PM +0200, Lennart Poettering wrote: On Thu, 09.05.13 11:38, Daniel P. Berrange (berra...@redhat.com) wrote: Following the suggestion in the systemd-nspawn manpage I populated a mini Fedora 19 chroot, on a Fedora 19 host # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer \ --disablerepo='*' --enablerepo=fedora \ install systemd passwd yum fedora-release vim-minimal # chroot /srv/mycontainer passwd # systemd-nspawn -bD /srv/mycontainer Systemd boots up nicely presents a login prompt, but it is impossible to actually login, PAM always denying the attempts. Yeah, this is a known problem. We generally suggest to turn off audit by booting with audit=0 on the kernel cmdline for now: https://fedoraproject.org/wiki/Features/SystemdLightweightContainers I guess I should add a comment about this to nspawn's man page too. The audit folks are working on adding container awareness to the audit subsystem in the kernel (which basically means that audit messages carry the outside PID of PID1 of the container, so that auditd can track this properly). Currently audit is completely confused by PID namespacing. Also, we want them to fix for us that opening a PID namespace resets loginuid in the container to -1. We have discussed this several times with them, and they wanted to something about it, but so far nothing happened. But we'll have another meeting about this next week, so I can put some pressure on this. Quite by accident I discovered that if you tell systemd-nspawn to create a new network namespace, you no longer hit the EPERM issues with sending audit messages. This is because the kernel only listens for audit messages in the initial network namespace. libaudit catches ECONNREFUSED and turns into a no-op returning success, meaning that PAM now works. So if you use systemd-nspawn --private-network, and make sure it is launched by systemd itself not from yuour shell, then the standard PAM config will 'just work' Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 204
Heya, this is pretty much only a bugfix release, but there are two smaller feature additions too. http://www.freedesktop.org/software/systemd/systemd-204.tar.xz CHANGES WITH 204: * The Python bindings gained some minimal support for the APIs exposed by libsystemd-logind. * ConditionSecurity= gained support for detecting SMACK. Since this condition already supports SELinux and AppArmor we only miss IMA for this. Patches welcome! Contributions from: Karol Lewandowski, Lennart Poettering, 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
[systemd-devel] Service is ignoring dependencies
I have an issue where the postgresql.service is being started and does not appear to be obeying the dependency ordering that is specified using a Before= entry that is in another oneshot service file. After turning on systemd debug it appears that the postgresql.service is being enqueud with the ignore-dependencies setting. I have no idea where this is coming from as it is not explicitly set anywhere that I can find. Does systemd implicitly do this in certain scenarios? systemd log: May 9 14:33:01 host-1 systemd[1]: Trying to enqueue job postgresql.service/start/ignore-dependencies - postgresql.service: [Unit] Description=PostgreSQL database server [Service] Type=forking User=postgres Group=xyz ExecStart=/usr/sbin/postgresql start ExecReload=/usr/sbin/postgresql reload ExecStop=/usr/sbin/postgresql stop Software version info: OpenSuse 12.1 systemd-presets-branding-openSUSE-0.1.0-6.2.1.noarch systemd-sysvinit-37-3.14.1.x86_64 systemd-37-3.14.1.x86_64 Thanks, Chad ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] Escape unit name from udev
On Mon, 6 May 2013 23:18:33 +0200,
Kay Sievers k...@vrfy.org wrote:
On Mon, May 6, 2013 at 11:12 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 23.04.13 13:34, MUNEDA Takahiro (muneda.takah...@jp.fujitsu.com) wrote:
This patch escapes a unit name which was derived from udev.
Please imagine following udev rule.
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%p.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%r.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%S.service
When unit name is derived from udev via
udev_device_get_property_value(), the name may contains '/' if
ENV{SYSTEMD_WANTS} has the udev options $devpath(%p), $root(%r), or
$sys(%S). However, '/' is a invalid char for unit name so processing
of this rule fails as Invalid argument with following message.
Apr 22 13:21:37 localhost systemd[1]: Failed to load device unit: Invalid
argument
Apr 22 13:21:37 localhost systemd[1]: Failed to process udev device event:
Invalid argument
This patch escapes those invalid chars in a unit name.
Tested with 202, and confirmed to apply cleanly on top of commit 195f8e36.
The patch looks OK I guess. I merged it now. I am not entirely sure
though that using the devpath as instance name is actually the best
choice... Kay?
Thank you.
Some devices can move around during runtime, the device number (dev_t,
ifindex) or the subsytem:devname is usually the better choice. A
bit like this:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/core.c#n1918
Thank you for your suggestion.
I may get necessary information from those. Will check it.
Thanks,
Takahiro
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service is ignoring dependencies (suse)
'Twas brillig, and Chad Anonymous at 09/05/13 20:13 did gyre and gimble: I have an issue where the postgresql.service is being started and does not appear to be obeying the dependency ordering that is specified using a Before= entry that is in another oneshot service file. After turning on systemd debug it appears that the postgresql.service is being enqueud with the ignore-dependencies setting. I have no idea where this is coming from as it is not explicitly set anywhere that I can find. Does systemd implicitly do this in certain scenarios? systemd log: May 9 14:33:01 host-1 systemd[1]: Trying to enqueue job postgresql.service/start/ignore-dependencies I could be wrong but I believe OpenSuse has patches to their wrapper scripts which call systemctl with --ignore-dependences. So i'd guess some other script in the startup process is calling some generic wrapper to start prostgres or something similar to that. I doubt this is an upstream issue tho' (tho' some suse folks will hopefully see here and answer - added it to the subject for better exposure) 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] Start ctrl-alt-del.target irreversibly
On Tue, May 07, 2013 at 02:16:53PM +0200, Eelco Dolstra wrote: This makes ctrl-alt-del reboots more robust, just like systemctl reboot. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service is ignoring dependencies (suse)
Thanks, that looks to be it. /usr/sbin/rcpostgresql has an explicit --ignore-dependencies in there that I somehow missed. It would be good to know why exactly that was done but that is another search... Thanks for the pointer. Chad On Thu, May 9, 2013 at 5:26 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Chad Anonymous at 09/05/13 20:13 did gyre and gimble: I have an issue where the postgresql.service is being started and does not appear to be obeying the dependency ordering that is specified using a Before= entry that is in another oneshot service file. After turning on systemd debug it appears that the postgresql.service is being enqueud with the ignore-dependencies setting. I have no idea where this is coming from as it is not explicitly set anywhere that I can find. Does systemd implicitly do this in certain scenarios? systemd log: May 9 14:33:01 host-1 systemd[1]: Trying to enqueue job postgresql.service/start/ignore-dependencies I could be wrong but I believe OpenSuse has patches to their wrapper scripts which call systemctl with --ignore-dependences. So i'd guess some other script in the startup process is calling some generic wrapper to start prostgres or something similar to that. I doubt this is an upstream issue tho' (tho' some suse folks will hopefully see here and answer - added it to the subject for better exposure) 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
