[systemd-devel] [PATCH v2] unit: add specifiers for user name and home directory
Currently there is no way to refer to the user's name or home directory
from within a unit file. This is mainly a problem for unit files
intended for a --user systemd instance, where you might want to set the
user's home directory in WorkingDirectory, or otherwise refer to the
user's name.
This patch add two specifiers, %u and %h, for the user's name and home
directory. Note that these refer to the user who's running the instance,
and is otherwise unaffected by User=, RootDirectory=, etc.
---
man/systemd.unit.xml | 10 ++
src/unit.c | 24
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 897f99f..2843007 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -258,6 +258,16 @@
entryRuntime socket dir/entry
entryThis is either /run (for the system manager) or
$XDG_RUNTIME_DIR (for user managers)./entry
/row
+ row
+entryliteral%u/literal/entry
+entryUser name/entry
+entryThis is the name of the user who is running the
systemd instance./entry
+ /row
+ row
+entryliteral%h/literal/entry
+entryUser home directory/entry
+entryThis is the home directory of the user who is
running the systemd instance./entry
+ /row
/tbody
/tgroup
/table
diff --git a/src/unit.c b/src/unit.c
index 03c90f5..d45e16f 100644
--- a/src/unit.c
+++ b/src/unit.c
@@ -2145,6 +2145,28 @@ static char *specifier_runtime(char specifier, void
*data, void *userdata) {
return strdup(/run);
}
+static char *specifier_user_details(char specifier, void *data, void
*userdata) {
+int r;
+char *username;
+const char *home, *_username;
+
+username = getlogname_malloc();
+if (!username)
+return NULL;
+
+if (specifier == 'u')
+return username;
+
+_username = username;
+r = get_user_creds(_username, NULL, NULL, home);
+free(username);
+if (r)
+return NULL;
+
+/* specifier == 'h' */
+return strdup(home);
+}
+
char *unit_name_printf(Unit *u, const char* format) {
/*
@@ -2194,6 +2216,8 @@ char *unit_full_printf(Unit *u, const char *format) {
{ 'r', specifier_cgroup_root, NULL },
{ 'R', specifier_cgroup_root, NULL },
{ 't', specifier_runtime, NULL },
+{ 'u', specifier_user_details,NULL },
+{ 'h', specifier_user_details,NULL },
{ 0, NULL, NULL }
};
--
1.7.8
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: add specifiers for user name and home directory
On Thu, Dec 15, 2011 at 04:01:05PM +0100, Lennart Poettering wrote: On Fri, 09.12.11 03:00, Ran Benita (ran...@gmail.com) wrote: +_username = username; +r = get_user_creds(_username, uid, gid, home); +free(username); +if (r) +return NULL; + +/* specifier == '~' */ Do we really want '~' here, and not 'h'? Sounds a bit weird to me to chain up weird characters like % and ~ in a sequence. %h might be less of a surprise to the user? And please pass uid and gid as NULL, get_user_creds() can deal with that. +return strdup(home); Otherwise looks fine. Thanks! May I also ask why specifier expansion is not allowed in Exec= lines? I think it's useful, and it works fine when I patch it. Is it problematic in any way? Ran ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] virt: Use __x86_64__ macro instead of __amd_64__
It seems that both are defined but seen that __x86_64__ is used
in the whole systemd tree, replace to avoid confusion.
---
src/virt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/virt.c b/src/virt.c
index 380fabd..d866d07 100644
--- a/src/virt.c
+++ b/src/virt.c
@@ -72,7 +72,7 @@ int detect_vm(const char **id) {
#if defined (__i386__)
#define REG_a eax
#define REG_b ebx
-#elif defined (__amd64__)
+#elif defined (__x86_64__)
#define REG_a rax
#define REG_b rbx
#endif
--
1.7.7.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: systemd: wait for shutdown-service to complete
there must be some bug in Fedora 15 systemd systectl start/stop vmware-default.service works perfectly but at shutdown systemd will not wait until it is finished before the sysv-service vmware-service is terminated what results in hard-powered-off guests and fschecks in most guests starting the host the next time :-( [root@rh:~]$ cat /etc/systemd/system/vmware-default.service [Unit] Description=VMware-Default-Machines After=vmware.service [Service] Type=oneshot ExecStart=/bin/su -c /scripts/vmware/vm-default-start.sh vmware ExecStop=/scripts/vmware/vm-suspend-all.sh RemainAfterExit=yes TimeoutSec=600 SysVStartPriority=90 [Install] WantedBy=multi-user.target [root@rh:~]$ cat /scripts/vmware/vm-suspend-all.sh #!/bin/bash if [ -x /usr/bin/vmrun ] ; then for i in `pidof vmware-vmx` ; do VMX_PATH=`ps -p $i -f | sed -ne '/vmware/s/.* \(\/.*\.vmx\)/\1/p'` MY_DATE=$(/bin/date +%d-%m-%Y) MY_TIME=$(/bin/date +%H:%M:%S) echo $MY_DATE $MY_TIME SUSPEND: $VMX_PATH /usr/bin/logger -t vmware SUSPEND: $VMX_PATH /usr/bin/vmrun suspend `ps -p $i -f | sed -ne '/vmware/s/.* \(\/.*\.vmx\)/\1/p'` 2 /dev/null MY_DATE=$(/bin/date +%d-%m-%Y) MY_TIME=$(/bin/date +%H:%M:%S) echo $MY_DATE $MY_TIME SUSPENDED: $VMX_PATH /usr/bin/logger -t vmware SUSPENDED: $VMX_PATH done fi [root@rh:~]$ cat /scripts/vmware/vm-default-start.sh #!/bin/bash if [ $HOSTNAME == srv-rhsoft.rhsoft.net ]; then /usr/bin/vmrun -T ws start '/mnt/data/fileserver/vmware/arrakis/arrakis.vmx' nogui /usr/bin/vmrun -T ws start '/mnt/data/fileserver/vmware/testserver/config.vmx' nogui /usr/bin/vmrun -T ws start '/mnt/data/fileserver/vmware/Buildserver32/config.vmx' nogui /usr/bin/vmrun -T ws start '/mnt/data/fileserver/vmware/Buildserver64/config.vmx' nogui /usr/bin/vmrun -T ws start '/mnt/data/fileserver/vmware/centos/centos.vmx' nogui fi if [ $HOSTNAME == rh.thelounge.net ]; then /usr/bin/vmrun -T ws start '/mnt/data/fileserver/vmware/backup-flow/config.vmx' nogui fi Original-Nachricht Betreff: Re: systemd: wait for shutdown-service to complete Datum: Thu, 15 Dec 2011 11:00:21 +0100 Von: Reindl Harald h.rei...@thelounge.net Antwort an: Community support for Fedora users us...@lists.fedoraproject.org Organisation: the lounge interactive design An: us...@lists.fedoraproject.org Am 15.12.2011 08:49, schrieb T.C. Hollingsworth: On Wed, Dec 14, 2011 at 6:48 PM, Reindl Harald h.rei...@thelounge.net wrote: it seems that this even does not work with the timeout 100% normally i would expect that this service is stopped before vmware.service which is a sysvinit, but after some tests i had still VMs which started the next time with fscheck while doing this manually and after that reboot there is no problem seems like there is some paralleizm at shutdown which is very very bad - stopping vmware.service kills all running machines since the included suspend worked only with = F14 Services are supposed to be shutdown in the reverse order of their Before/After dependencies that was my idea for this fake-service so this sounds like a bug in SysV compat to me. sounds reasonable At any rate, you should be able to work around this by setting in [Service] SysVStartPriority=90 (or any value higher than vmware's start priority) thanks, i will give it a try and feedback ASAP currently RAID-check is running :-) -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm 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] Fwd: systemd: wait for shutdown-service to complete
On 12/16/2011 01:41 PM, Reindl Harald wrote: there must be some bug in Fedora 15 systemd systectl start/stop vmware-default.service works perfectly but at shutdown systemd will not wait until it is finished before the sysv-service vmware-service is terminated what results in hard-powered-off guests and fschecks in most guests starting the host the next time :-( Agreed, I noticed something similar as reported in http://lists.freedesktop.org/archives/systemd-devel/2011-November/003963.html . (Nobody responded - I don't know if the problem was too hard or too stupid.) As far as I can see my problem is that shutdown.target and umount.target are started in parallel and that the file systems thus might be unmounted before the services and targets that conflicts / befores shutdown.target has been able to run / shutdown cleanly and save state to the mounted file systems. (I would however expect that vmware had open file handles and thus would prevent umount ...) /Mads ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_listen_fds: find file descriptor
On Thu, 15.12.11 13:53, Michael D. Berger (m.d.ber...@ieee.org) wrote:
[...]
Hmm? You should usually consume all fds you get passed. And
if you cannot handle more than one, then exit quickly with an
error message. And if any of the fds is invalid, then print
an error message and leave, too.
This is what I'd usually use:
int fd, n;
n = sd_listen_fds();
if (n 0) {
fprintf(stderr, sd_listen_fds(): %s\n, strerror(-n));
exit(1);
}
for (fd = SD_LISTEN_FDS_START; fd SD_LISTEN_FDS_START + n; fd ++) {
if (sd_is_socket_inet(fd, ...) = 0) {
fprintf(stderr, Invalid socket passed.\n);
exit(1);
}
/* do something with the fd... */ }
(This is for the generic case where the service can handle
more than one fd. If you can handle ony one, then check
whether n == 1 and if it isn't exit saying you can't deal
with more than one fd.)
Lennart
What you say is clear, but I am perplexed by the fact that
in a case where there will be one handle, that handle will
always be 3. How do we know that 3 is not being used by
something else? I thought that the system has to choose
a handle that is available.
As Zbigniew already mentioned systemd as the process which spawns yours
has full control on which fds to pass you. It will guarantee that 0, 1,
2 are connected to a suitable stdin, stdout, stderr (/dev/null,
resp. syslog by default these days), and then starting with fd 3 all
sockets used for socket activation. No other fds will be passed to your
process.
In fact, one of the big advantages of systemd here is that it executes
all processes in a clearly defined, reset execution environment which
services can rely on, very much unlike classic SysV where the fds
passed and the process context properties set are dependent on the shell
or service that invoked another service, and where leaked fds and
settings are a frequent problem.
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] Fwd: systemd: wait for shutdown-service to complete
On Fri, 16.12.11 13:41, Reindl Harald (h.rei...@thelounge.net) wrote: there must be some bug in Fedora 15 systemd systectl start/stop vmware-default.service works perfectly but at shutdown systemd will not wait until it is finished before the sysv-service vmware-service is terminated what results in hard-powered-off guests and fschecks in most guests starting the host the next time :-( [root@rh:~]$ cat /etc/systemd/system/vmware-default.service [Unit] Description=VMware-Default-Machines After=vmware.service [Service] Type=oneshot ExecStart=/bin/su -c /scripts/vmware/vm-default-start.sh vmware Instead of su just use User=vmware... ExecStop=/scripts/vmware/vm-suspend-all.sh RemainAfterExit=yes TimeoutSec=600 SysVStartPriority=90 This is usually not what you want... To debug problems during shutdown it is usually a good idea to enable debug logging (systemd.log_level=debug systemd.log_target=kmsg log_buf_len=2M). If you need to record the log mesages before the machine powers off, drop a tiny shell script into /lib/systemd/system-shutdown/, mark it executable: #!/bin/sh mount / -orw,remount dmesg /shutdown.dmesg mount / -oro,remount Then, when you shut down the file /shutdown.dmesg wil be generated with all log output from kmsg, which should give you hint what systemd is doing. When you cannot make sense of it, paste it somewhere and post the url, and I'll see what I can make of it. 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] unit: add specifiers for user name and home directory
On Fri, 16.12.11 12:41, Ran Benita (ran...@gmail.com) wrote: On Thu, Dec 15, 2011 at 04:01:05PM +0100, Lennart Poettering wrote: On Fri, 09.12.11 03:00, Ran Benita (ran...@gmail.com) wrote: +_username = username; +r = get_user_creds(_username, uid, gid, home); +free(username); +if (r) +return NULL; + +/* specifier == '~' */ Do we really want '~' here, and not 'h'? Sounds a bit weird to me to chain up weird characters like % and ~ in a sequence. %h might be less of a surprise to the user? And please pass uid and gid as NULL, get_user_creds() can deal with that. +return strdup(home); Otherwise looks fine. Thanks! May I also ask why specifier expansion is not allowed in Exec= lines? I think it's useful, and it works fine when I patch it. Is it problematic in any way? Hmm, it is allowed. In getty@.service for example, we have this: ExecStart=-/sbin/agetty %I 38400 and it works fine? 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] Fwd: systemd: wait for shutdown-service to complete
Am 16.12.2011 17:09, schrieb Lennart Poettering: On Fri, 16.12.11 13:41, Reindl Harald (h.rei...@thelounge.net) wrote: there must be some bug in Fedora 15 systemd systectl start/stop vmware-default.service works perfectly but at shutdown systemd will not wait until it is finished before the sysv-service vmware-service is terminated what results in hard-powered-off guests and fschecks in most guests starting the host the next time :-( [root@rh:~]$ cat /etc/systemd/system/vmware-default.service [Unit] Description=VMware-Default-Machines After=vmware.service [Service] Type=oneshot ExecStart=/bin/su -c /scripts/vmware/vm-default-start.sh vmware Instead of su just use User=vmware... no, because the ExecStop needs to be called as root and if i change the lines in the ExecStart-Script to du su vmrun refuses to work, this is the only way to get the vmx-processes started as user vmware and the ExecStop as root because this has to suspend also machines running with different useraccounts ExecStop=/scripts/vmware/vm-suspend-all.sh RemainAfterExit=yes TimeoutSec=600 SysVStartPriority=90 This is usually not what you want... can you please explain why? finally i want to get ExecStart command called after sysv-vmware-service at boot and ExecStop during shutdown without interrupt BEFORE sysv-vmware is stopped to wake up default guests at boot time and suspend ALL running guest ina clean state at shutdown in which way i exactly can achieve this does not matter, it has to be 100% stable finally to not damage guests over the long 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] unit: add specifiers for user name and home directory
On Fri, Dec 16, 2011 at 05:10:45PM +0100, Lennart Poettering wrote: On Fri, 16.12.11 12:41, Ran Benita (ran...@gmail.com) wrote: On Thu, Dec 15, 2011 at 04:01:05PM +0100, Lennart Poettering wrote: On Fri, 09.12.11 03:00, Ran Benita (ran...@gmail.com) wrote: +_username = username; +r = get_user_creds(_username, uid, gid, home); +free(username); +if (r) +return NULL; + +/* specifier == '~' */ Do we really want '~' here, and not 'h'? Sounds a bit weird to me to chain up weird characters like % and ~ in a sequence. %h might be less of a surprise to the user? And please pass uid and gid as NULL, get_user_creds() can deal with that. +return strdup(home); Otherwise looks fine. Thanks! May I also ask why specifier expansion is not allowed in Exec= lines? I think it's useful, and it works fine when I patch it. Is it problematic in any way? Hmm, it is allowed. In getty@.service for example, we have this: ExecStart=-/sbin/agetty %I 38400 and it works fine? Hmm, yes that works. I see service_spawn() expands the command arguments, but not the path, which is what I tried. I previously looked at config_parse_exec() in load-fragment.c. So my question becomes, why not expand the path? (It seems intentional). Ran ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd+dbus: system boot stops at terminal login screen sometimes
Chen Jie wrote: Let me explain it further. First syslogv() in dbus may block, while rsyslog.service is starting and meanwhile the kernel socket buffer was full. Attachment syslog-test.c was a program simulates the situation. So while rsyslog.service is starting, on the systemd side: 1. [ExecStartPre] stops systemd-kmsg-syslogd.service 2. It now running bus_init() to publish its API to dbus 3. Step 2 timeout, because dbus-daemon didn't reply in time. Why dbus-daemon didn't response quickly? Because it blocked on syslogv(), which was waiting for someone consumes the message(the kernel socket buffer was full), but sadly the consumer -- rsyslog didn't be started because systemd blocked. So systemd waits for dbus, and dbus waits for startup of rsyslog, rsyslog waits for systemd to start it. Thanks for debugging this. You are right. This kind of a deadlock is possible. Does the deadlock go away if you just modify rsyslog.service so that instead of stopping systemd-kmsg-syslogd in ExecStartPre it would do it in ExecStartPost? IMHO, We need to put functions that may block in separate threads, for example bus_init(), shutdown_connection(), log_meta(). Oh, I'm sure this works, but I'm scared of the additional complexity of threads. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_listen_fds: find file descriptor
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Friday, December 16, 2011 09:40
To: Michael D. Berger
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] sd_listen_fds: find file descriptor
On Thu, 15.12.11 13:53, Michael D. Berger (m.d.ber...@ieee.org) wrote:
[...]
Hmm? You should usually consume all fds you get passed.
And if you
cannot handle more than one, then exit quickly with an error
message. And if any of the fds is invalid, then print an error
message and leave, too.
This is what I'd usually use:
int fd, n;
n = sd_listen_fds();
if (n 0) {
fprintf(stderr, sd_listen_fds(): %s\n, strerror(-n));
exit(1);
}
for (fd = SD_LISTEN_FDS_START; fd SD_LISTEN_FDS_START +
n; fd ++) {
if (sd_is_socket_inet(fd, ...) = 0) {
fprintf(stderr, Invalid socket passed.\n);
exit(1);
}
/* do something with the fd... */ }
(This is for the generic case where the service can
handle more than
one fd. If you can handle ony one, then check whether n
== 1 and if
it isn't exit saying you can't deal with more than one fd.)
Lennart
What you say is clear, but I am perplexed by the fact that
in a case
where there will be one handle, that handle will always be
3. How do
we know that 3 is not being used by something else? I thought that
the system has to choose a handle that is available.
As Zbigniew already mentioned systemd as the process which
spawns yours has full control on which fds to pass you. It
will guarantee that 0, 1,
2 are connected to a suitable stdin, stdout, stderr
(/dev/null, resp. syslog by default these days), and then
starting with fd 3 all sockets used for socket activation. No
other fds will be passed to your process.
In fact, one of the big advantages of systemd here is that it
executes all processes in a clearly defined, reset execution
environment which services can rely on, very much unlike
classic SysV where the fds passed and the process context
properties set are dependent on the shell or service that
invoked another service, and where leaked fds and settings
are a frequent problem.
Lennart
MyServer is a multi-threaded daemon written in C++ that has been
running reliably for years. It adapted well to MyServer.service
with Type=simple . I am thinking of creating a MyServer.socket .
Read and write are non-blocking, and are regulated by pselect() .
Now MyServer has two listeners, each running in its own thread.
Now with systemd, I am guessing that this would be a good sequence.
1. Listener A receives a hit.
2. MyServer starts and runs sd_listen_fds()in its starting thread.
3. sd_listen_fds() returns 1. Anything else (for example, 2) is an error.
4. The starting thread creates threads ListenA and ListenB, passing them
the receiving IPaddr.
5. ListenA determines it is the one. It does NOT run listen(). Since
the hit occurred before MyDaemon was started, there is no signal
from pselect() .
6. ListenA runs accept() and gets a handle for a new socket.
7. ListenA registers with the pselect (don't worry about the details)
to wait for another hit.
8. ListenB determines it is not the one.
9. ListenB registers with pselect to wait for a hit.
10. All subsequent new connections in both listeners are processed
by listen() until --
11. When all connections disconnect, MyServer exits.
So what do you think?
Thanks,
Mike.
--
Michael D. Berger
m.d.ber...@ieee.org
http://www.rosemike.net/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
