Re: [systemd-devel] Service unit issue: starts manually but doesn't start on boot
On 04/19/2013 04:16 AM, Colin Guthrie wrote: 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 I suspect that on boot the network or name resolution is not available and your service is started "too soon". Thanks for your reply. I'm now pretty sure the issue is that the service calls getaddrinfo(...) when it starts, and that returns EAI_NONAME if this is run too early in boot. But I've now tried adding After=network.target and that doesn't seem to help; is there something else I need to wait for so that getaddrinfo() will succeed? Thanks again, P ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] TODO: journal enhancements
--- Resubmitting the uncontroversial bits. TODO | 2 ++ 1 file changed, 2 insertions(+) diff --git a/TODO b/TODO index 88be72d..33c24ea 100644 --- a/TODO +++ b/TODO @@ -272,6 +272,8 @@ Features: - journal: store euid in journal if it differs from uid - journal: sanely deal with entries which are larger than the individual file size, but where the components would fit - journalctl: make journalctl smarter, and actually check groups that have access to /var/log/journal before printing message about recomming group membership for journal access + - Replace utmp, wtmp, btmp, and lastlog completely with journal + - Port upower to use the journal for historical power information used in future calculations * document: - document unit_name_mangle() -- 1.8.2.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] crypt-setup-generator: correctly check return of strdup
On Fri, Apr 19, 2013 at 03:06:28PM +0200, Harald Hoyer wrote:
> On 04/19/2013 01:58 PM, Lukas Nykryn wrote:
> > ---
> > src/cryptsetup/cryptsetup-generator.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/cryptsetup/cryptsetup-generator.c
> > b/src/cryptsetup/cryptsetup-generator.c
> > index ac0ed58..b31329d 100644
> > --- a/src/cryptsetup/cryptsetup-generator.c
> > +++ b/src/cryptsetup/cryptsetup-generator.c
> > @@ -302,7 +302,7 @@ static int parse_proc_cmdline(char
> > ***arg_proc_cmdline_disks, char **arg_proc_cm
> >
> > } else if (startswith(word, "luks.key=")) {
> > *arg_proc_cmdline_keyfile = strdup(word + 9);
> > -if (! arg_proc_cmdline_keyfile)
> > +if (!*arg_proc_cmdline_keyfile)
> > return log_oom();
> >
> > } else if (startswith(word, "rd.luks.key=")) {
> > @@ -311,7 +311,7 @@ static int parse_proc_cmdline(char
> > ***arg_proc_cmdline_disks, char **arg_proc_cm
> > if (*arg_proc_cmdline_keyfile)
> > free(*arg_proc_cmdline_keyfile);
> > *arg_proc_cmdline_keyfile = strdup(word +
> > 12);
> > -if (!arg_proc_cmdline_keyfile)
> > +if (!*arg_proc_cmdline_keyfile)
> > return log_oom();
> > }
> >
> >
>
> oh.. yes! Thanks!
Yeah, good catches. Commited.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] crypt-setup-generator: correctly check return of strdup
On 04/19/2013 01:58 PM, Lukas Nykryn wrote:
> ---
> src/cryptsetup/cryptsetup-generator.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/cryptsetup/cryptsetup-generator.c
> b/src/cryptsetup/cryptsetup-generator.c
> index ac0ed58..b31329d 100644
> --- a/src/cryptsetup/cryptsetup-generator.c
> +++ b/src/cryptsetup/cryptsetup-generator.c
> @@ -302,7 +302,7 @@ static int parse_proc_cmdline(char
> ***arg_proc_cmdline_disks, char **arg_proc_cm
>
> } else if (startswith(word, "luks.key=")) {
> *arg_proc_cmdline_keyfile = strdup(word + 9);
> -if (! arg_proc_cmdline_keyfile)
> +if (!*arg_proc_cmdline_keyfile)
> return log_oom();
>
> } else if (startswith(word, "rd.luks.key=")) {
> @@ -311,7 +311,7 @@ static int parse_proc_cmdline(char
> ***arg_proc_cmdline_disks, char **arg_proc_cm
> if (*arg_proc_cmdline_keyfile)
> free(*arg_proc_cmdline_keyfile);
> *arg_proc_cmdline_keyfile = strdup(word +
> 12);
> -if (!arg_proc_cmdline_keyfile)
> +if (!*arg_proc_cmdline_keyfile)
> return log_oom();
> }
>
>
oh.. yes! Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] logind-dbus: initialize result variable
---
src/login/logind-dbus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 4176902..05cc1fd 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -1137,7 +1137,7 @@ static int bus_manager_can_shutdown_or_sleep(
DBusMessage **_reply) {
bool multiple_sessions, challenge, blocked, b;
-const char *result;
+const char *result = NULL;
_cleanup_dbus_message_unref_ DBusMessage *reply = NULL;
int r;
unsigned long ul;
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] crypt-setup-generator: correctly check return of strdup
---
src/cryptsetup/cryptsetup-generator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index ac0ed58..b31329d 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -302,7 +302,7 @@ static int parse_proc_cmdline(char
***arg_proc_cmdline_disks, char **arg_proc_cm
} else if (startswith(word, "luks.key=")) {
*arg_proc_cmdline_keyfile = strdup(word + 9);
-if (! arg_proc_cmdline_keyfile)
+if (!*arg_proc_cmdline_keyfile)
return log_oom();
} else if (startswith(word, "rd.luks.key=")) {
@@ -311,7 +311,7 @@ static int parse_proc_cmdline(char
***arg_proc_cmdline_disks, char **arg_proc_cm
if (*arg_proc_cmdline_keyfile)
free(*arg_proc_cmdline_keyfile);
*arg_proc_cmdline_keyfile = strdup(word + 12);
-if (!arg_proc_cmdline_keyfile)
+if (!*arg_proc_cmdline_keyfile)
return log_oom();
}
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service unit issue: starts manually but doesn't start on boot
'Twas brillig, and Peter Li at 19/04/13 07:06 did gyre and gimble: > 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: When you say "after a boot", it would appear to be at least 1 hour after you booted (or perhaps this is some quirk due to system clocks) > 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 See 1h ago :) The fact that this is listed here with a time means that systemd *did* start it but it exited... > Process: 874 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES > (code=exited, status=0/SUCCESS) And here you can see that it exited with code 0 (which generally means "No error"). > 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 I suspect that on boot the network or name resolution is not available and your service is started "too soon". > 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. Yes, that's why they are different. > 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. I suspect it will also exit if there is no network ready or similar, but don't know for sure. > Also the timestamp on the failed status is wrong; it's an hour earlier > than it should be. Ahhh :) Ignore my earlier comment then. I suspect this is just related to the clock configuration and time "jumps" at some point in early boot when those settings are loaded. > 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 In this case there is no dependency on network. So unless the binary is able to "do the right thing" with network devices coming and going (it should as that's the correct behaviour in these dynamic days, but it's highly unlikely it does because very few applications are doing it right!) You should likely have a After=network.target in your unit (After=syslog.target is not needed in recent systemd's but F17 is quite old now so it may still need it). You may also need to do some kind of "wait online" thing to delay network.target until you have a working network - Network manager ships such a unit which just needs to be enabled. > 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. Perhaps pianod doesn't need the network? 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] Service unit issue: starts manually but doesn't start on boot
Hi, there were some bugs introduced and fixed recently, with regards to parsing env. files, that could be relevant. What version of systemd are you running, and what do the logs say? Zbyszek On Thu, Apr 18, 2013 at 11:06:43PM -0700, Peter Li wrote: > 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 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:44, schrieb Lennart Poettering: > 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. So that's what happens with 'su' and 'sudo' - I always wondered. The obvious solution would be to add an option to pam_systemd which would force opening a new session despite being part of an active session. That setting could then be set in /etc/pam.d/screen. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
