Re: [systemd-devel] [PATCH] Make upstart compatibility optional
On Fri, Sep 27, 2013 at 9:24 PM, Cristian Rodríguez wrote: > Distributions such as openSUSE and probably others never included > upstart, in that case there is no need to include this code. > > This introduces --disable-upstartcompat, however upstart compat is still > enabled by default. I think we should just remove it, and leave it to people who actually need it to patch it back in, I doubt there are any left, really. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Make upstart compatibility optional
Distributions such as openSUSE and probably others never included
upstart, in that case there is no need to include this code.
This introduces --disable-upstartcompat, however upstart compat is still
enabled by default.
---
configure.ac | 3 +++
src/systemctl/systemctl.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index 45526f4..f234a21 100644
--- a/configure.ac
+++ b/configure.ac
@@ -766,6 +766,9 @@ if test "x$enable_efi" != "xno"; then
fi
AM_CONDITIONAL(ENABLE_EFI, [test "x$have_efi" = "xyes"])
+AC_ARG_ENABLE(upstartcompat, AS_HELP_STRING([--disable-upstartcompat],
[disable upstart compatibility]))
+AS_IF([test "x$enable_upstartcompat" != "xno"], [AC_DEFINE([UPSTART_COMPAT],
[1], [Upstart compat])])
+
#
--
AC_ARG_WITH(rc-local-script-path-start,
AS_HELP_STRING([--with-rc-local-script-path-start=PATH],
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index eede616..c784f3e 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5678,6 +5678,7 @@ _pure_ static int action_to_runlevel(void) {
return table[arg_action];
}
+#ifdef UPSTART_COMPAT
static int talk_upstart(void) {
_cleanup_dbus_message_unref_ DBusMessage *m = NULL, *reply = NULL;
_cleanup_dbus_error_free_ DBusError error;
@@ -5766,6 +5767,8 @@ finish:
return r;
}
+#endif
+
static int talk_initctl(void) {
struct init_request request = {};
int r;
@@ -6037,10 +6040,12 @@ static int start_with_fallback(DBusConnection *bus) {
goto done;
}
+#ifdef UPSTART_COMPAT
/* Hmm, talking to systemd via D-Bus didn't work. Then
* let's try to talk to Upstart via D-Bus. */
if (talk_upstart() > 0)
goto done;
+#endif
/* Nothing else worked, so let's try
* /dev/initctl */
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd should not call KDSKBMODE on a VT with X
This is an old thread from February. Sorry I can't reply to the original email. Apparently I failed to notice this question. My bad. >> Hello systemd developers >> >> TL;DR: On a VT which X is running, messing with KDSKBMODE on >> underneath X at best has no affect and at worst breaks keyboard input >> badly. In the short term, systemd should stop calling this ioctl >> because it has no benefit and makes no sense. > > It sounds to me we indeed want to set K_UNICODE only if K_OFF (or > something else like it) is currently not set. > > However, before we change this, there's one thing that makes me wonder: > what does X11 do on shutdown? Does it put the kbd back to K_UNICODE? Or > back to K_XLATE? > > Lennart Provided the behaviour hasn't been changed in the last six months, Xorg remembers the VT KBMODE on start, set it to whatever it needs (sometimes more than once :-/ ) and restores it to the value it was on start upon exit. (Of course if X crashes hard it isn't restored, and that is why SysRq+R was invented.) -- Arthur Taylor a...@ified.ca tayl...@csc.uvic.ca ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a dependency to a systemd.mount that is activated by /bin/mount?
It's also possible to create your own file system type. "mount" (including via systemd mount units) simply invokes /usr/sbin/mount.YOURTYPEHERE as root. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to permanently disable a service after first boot
On Fri, 27.09.13 12:26, Muhammad Shakeel (muhammad_shak...@mentor.com) wrote: > Hi, > > If there is a foo.service which is required to run during first > system boot then what is the best solution to permanently disable it > afterwards? > > I can think of two solutions but I am not sure which one is > correct/more appropriate. > > 1) ExecStartPost=systemctl disable foo.service (I doubt this will > work) This should work. > 2) ExecStartPost=/bin/rm -f foo.service (this works for me but is > this a clean solution?) This is a bad idea. For most packaged software unit files are usually shipped as part of an RPM, and stored in /usr. During normal boots /usr is likely to be read-only. Hence you cannot remove those unit files. Also, you should not remove unit files without disabling them, hence you'd need #1 before this anyway. > Is there any flag in for systemd unit files which can be set to run > a service on first boot only? My recommendation would be to use something like ConditionFileExists= on some configuration or flag file and let the service enabled unconditionally and always, but skipped in later boots. This is usually the best thing to keep things as state-less as possible. This of course applies only if what you are trying to do is for showing a configuration dialog on first boot or so. This has the benefit that you actually bind execution of your service to the actual existance of first time configuration (which is probably what you really want to express, no?) instead of the first boot (which only indirectly is what you want to express, right?). Hope that makes some sense... More information on ConditionFileExists= and the other conditions you find in "man 5 systemd.unit". 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] Journald stops logging when lots of output
On Fri, 27.09.13 09:47, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Lennart Poettering at 26/09/13 19:35 did gyre and gimble: > > On Thu, 26.09.13 15:46, Olav Vitters (o...@vitters.nl) wrote: > > > >> > >> On Wed, Sep 11, 2013 at 08:35:49PM +0200, Lennart Poettering wrote: > >>> (Of course, journald should not exit under any such circumstances, but > >>> to find that we first need to track down why it does that currently). > >> > >> Though it might hide problems, shouldn't journald be configured to > >> automatically be restarted by systemd? > > > > We do that, but not indefinitely. See > > StartLimitInterval=/StartLimitBurst= in systemd.service(5). > > Quick question, I presume logging is still lost for services stderr/out > etc. when journald is restarted? Or has this been worked-around these days? Still doesn't work. I do have an idea now however we could make this work by using a single AF_UNIX/SOCK_DGRAM socket instead of individual AF_UNIX/SOCK_STREAM sockets. For services we start it shouldn't matter if stdout/stderr is SOCK_STREAM or SOCK_DGRAM really, and if we use SOCK_DGRAM we even get per-client SCM_CREDENTIALS which would allow us to properly attribute every single write to the right process which we currently can't. 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] How to add a dependency to a systemd.mount that is activated by /bin/mount?
On Wed, Sep 25, 2013 at 3:11 AM, Tim Landscheidt wrote: > on Fedora 19/systemd 204, I want systemd on "mount > /mnt/test" by a non-root user to automatically call a pro- > gram as root (in real life cryptsetup to unlock the underly- > ing device, for testing here echo) before the file system is > mounted and after it is unmounted. > > With /etc/systemd/system/mount-wrapper.service: > > | [Unit] > | Description=mount wrapper > | Before=mnt-test.mount > | StopWhenUnneeded=true > > | [Service] > | Type=oneshot > | ExecStart=/bin/echo Unlock device. > | RemainAfterExit=true > | ExecStop=/bin/echo Lock device. > > | [Install] > | RequiredBy=mnt-test.mount > > /etc/fstab (partly): > > | /dev/$DEVICE /mnt/test auto noauto,user 0 0 > > and (with or without) /etc/systemd/system/mnt-test.mount: > > | [Unit] > | Description=mount test > | > | [Mount] > | What=/dev/$DEVICE > | Where=/mnt/test > | Options=noauto,user > > this works (after daemon reload and enabling the service) > for "systemctl start mnt-test.mount" and "systemctl stop > mnt-test.mount" respectively (as root). > > On "mount /mnt/test", however, "systemctl status > mnt-test.mount mount-wrapper" shows the latter service being > "inactive (dead)", while the former is "active (mounted)". > > How can I (or can I not?) set up a dependency that is hon- > oured when /bin/mount is called as well? The status of the > mount unit shows that "mount /mnt/test" seems to be trans- > lated to "ExecMount=/bin/mount /dev/$DEVICE /mnt/test -t > auto -o noauto,user", so apparently systemd gets notified. It appears we have an issue with manual mounts (i.e., units generated from /proc/self/mountinfo) do not correctly pick up already existing unit files. That said, there is no way to get a service ran Before a manual mount, as systemd is only alerted to the mount after it happened. So for this case I suggest using "systemctl enable" instead (but see below). > P. S.: If there is a "more systemd" way to handle removable >encrypted media, I'm all ears :-). I've seen >/etc/crypttab & Co., but it seems to be focused on >disks that are unlocked at boot and remain enabled >till shutdown. Using crypttab is the way to do it, it should also work (with the correct options) for devices not available at boot. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a bit more explicit message, to help confused users
On Fri, Sep 27, 2013 at 11:43 AM, wrote: > From: Michael Scherer > > Seeing > http://www.happyassassin.net/2013/09/27/further-sysadmin-adventures-wheres-my-freeipa-badge/ > it seems that the default message is a bit confusing for people > who never encountered it before, so adding a link to the manpage could > help them. > --- > tmpfiles.d/systemd.conf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf > index c397c71..b630440 100644 > --- a/tmpfiles.d/systemd.conf > +++ b/tmpfiles.d/systemd.conf > @@ -22,7 +22,7 @@ d /run/systemd/users 0755 root root - > d /run/systemd/machines 0755 root root - > d /run/systemd/shutdown 0755 root root - > > -F /run/nologin 0644 - - - "System is booting up." > +F /run/nologin 0644 - - - "System is booting up. See pam_nologin(8)" > > m /var/log/journal 2755 root systemd-journal - - > m /var/log/journal/%m 2755 root systemd-journal - - > -- Thanks. Applied. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add a bit more explicit message, to help confused users
From: Michael Scherer Seeing http://www.happyassassin.net/2013/09/27/further-sysadmin-adventures-wheres-my-freeipa-badge/ it seems that the default message is a bit confusing for people who never encountered it before, so adding a link to the manpage could help them. --- tmpfiles.d/systemd.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index c397c71..b630440 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -22,7 +22,7 @@ d /run/systemd/users 0755 root root - d /run/systemd/machines 0755 root root - d /run/systemd/shutdown 0755 root root - -F /run/nologin 0644 - - - "System is booting up." +F /run/nologin 0644 - - - "System is booting up. See pam_nologin(8)" m /var/log/journal 2755 root systemd-journal - - m /var/log/journal/%m 2755 root systemd-journal - - -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Start and stop requests for a service
Hi, I have noticed that ExecStop is not being run on following service with following requests: [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/sh -c "sleep 20 && /usr/bin/systemd-cat echo ExecStart.." ExecStop=/bin/sh -c "/usr/bin/systemd-cat echo ExecStop.." $> systemctl start hello.service & $> systemctl stop hello.service I have couple discussions: 1) When a "oneshot" service is being in activating state, why doesn't "stop" request wait for the service to become "active"? I would expect systemd to queue "stop" request as long as service is in "activating" state. I think this kind of behavior is fine for Type=simple but not for Type=oneshot. KillMode=none is the only way to provide atomicity. 2) If I have an "ExecStop" directive, I would expect it to run no matter what. My solution is moving ExecStop to ExecStopPost. - My use case: I have a service which sets up ip filters on ExecStart and removes the filters on ExecStop. Setting up ip filters is done by a script. I have ended up finding my target in an inacceptable state due to "start" "stop" request coming right after each other. Thanks, Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journald stops logging when lots of output
'Twas brillig, and Lennart Poettering at 26/09/13 19:35 did gyre and gimble: > On Thu, 26.09.13 15:46, Olav Vitters (o...@vitters.nl) wrote: > >> >> On Wed, Sep 11, 2013 at 08:35:49PM +0200, Lennart Poettering wrote: >>> (Of course, journald should not exit under any such circumstances, but >>> to find that we first need to track down why it does that currently). >> >> Though it might hide problems, shouldn't journald be configured to >> automatically be restarted by systemd? > > We do that, but not indefinitely. See > StartLimitInterval=/StartLimitBurst= in systemd.service(5). Quick question, I presume logging is still lost for services stderr/out etc. when journald is restarted? Or has this been worked-around these days? 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] How to permanently disable a service after first boot
Hi, On Fri, 2013-09-27 at 12:26 +0500, Muhammad Shakeel wrote: > If there is a foo.service which is required to run during first system > boot then what is the best solution to permanently disable it afterwards? > > I can think of two solutions but I am not sure which one is correct/more > appropriate. > > 1) ExecStartPost=systemctl disable foo.service (I doubt this will work) You should have tried it, it actually does work. :) > Is there any flag in for systemd unit files which can be set to run a > service on first boot only? Another way is to have a ConditionFileExists=!/path/to/file pointing to a file created by the service the first time it runs. That's how I run initialization of PostgreSQL instances at first boot: $ cat /lib/systemd/system/postgresql-setup-stage1.service [Unit] ... ConditionPathExists=!/var/lib/pgsql/data/PG_VERSION ... [Service] Type=oneshot ExecStart=/usr/bin/postgresql-setup initdb RemainAfterExit=true The postgresql-setup script will create the file on the first run, and as a result the service is never run any more. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to permanently disable a service after first boot
El 27/09/13 04:26, Muhammad Shakeel escribió: Hi, If there is a foo.service which is required to run during first system boot then what is the best solution to permanently disable it afterwards? I can think of two solutions but I am not sure which one is correct/more appropriate. 1) ExecStartPost=systemctl disable foo.service (I doubt this will work) 2) ExecStartPost=/bin/rm -f foo.service (this works for me but is this a clean solution?) Is there any flag in for systemd unit files which can be set to run a service on first boot only? I wont make it needlessly complicated.. just use ConditionPathExists=file that is created after install but removed after this first boot program is complete> -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to permanently disable a service after first boot
Hi, If there is a foo.service which is required to run during first system boot then what is the best solution to permanently disable it afterwards? I can think of two solutions but I am not sure which one is correct/more appropriate. 1) ExecStartPost=systemctl disable foo.service (I doubt this will work) 2) ExecStartPost=/bin/rm -f foo.service (this works for me but is this a clean solution?) Is there any flag in for systemd unit files which can be set to run a service on first boot only? Best Regards, Shakeel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
