[systemd-devel] PHP-FPM socket activation support RFC (for upstream PHP inclusion)
Comments welcome (please reply here): https://wiki.php.net/rfc/socketactivation -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
2012/10/17 Lennart Poettering : > On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > >> Hello, >> Today I have read this bug >> https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described >> systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how >> to fix it. Some ideas cross my mind; moving systemd-namespace-* >> elsewhere, adding some option to exclude dirs in tmpfiles conf files, >> stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like >> any of these solutions. > > We already allow files to be excluded from clean up by setting the > sticky bit on them. We can't do that for dirs however, since the sticky > bit for dirs has a different meaning. Maybe create a new (empty) file inside this dir (on creation of the namespace) and set the sticky bit on it. This way tmpfiles will never delete the dir because it is not empty. Also everything needed when the service is stopped is removing this file so tmpfiles can clean up next time it passes by. > One possible way to solve this > issue otherwise might be by introducing an xattr for this. The one thing > blocking this right now however is that tmpfs still can't handle xattrs > properly. There were multiple attempts to get xattrs for tmpfs into the > kernel, not sure what the latest state on this is. > > The best would probably be to exclude these dirs from clean-up via > explicit tmpfiles lines. Unfortunately "x" is probably not going to do > it here, since we actually want recursive clean-up inside the dir, just > not of the dir... So maybe introduce a new type of "X" that excludes the > dir itself from clean-up but does not exclude recursively? Simon Peeters ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
On Wed, Oct 17, 2012 at 6:10 PM, Lennart Poettering wrote: > On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > >> Hello, >> Today I have read this bug >> https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described >> systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how >> to fix it. Some ideas cross my mind; moving systemd-namespace-* >> elsewhere, adding some option to exclude dirs in tmpfiles conf files, >> stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like >> any of these solutions. > > We already allow files to be excluded from clean up by setting the > sticky bit on them. We can't do that for dirs however, since the sticky > bit for dirs has a different meaning. One possible way to solve this > issue otherwise might be by introducing an xattr for this. The one thing > blocking this right now however is that tmpfs still can't handle xattrs > properly. There were multiple attempts to get xattrs for tmpfs into the > kernel, not sure what the latest state on this is. > > The best would probably be to exclude these dirs from clean-up via > explicit tmpfiles lines. Unfortunately "x" is probably not going to do > it here, since we actually want recursive clean-up inside the dir, just > not of the dir... So maybe introduce a new type of "X" that excludes the > dir itself from clean-up but does not exclude recursively? Pre-create and protect a /tmp/systemd-namespace/ subdir? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateTmp and systemd-tmpfiles
On Wed, 17.10.12 14:16, Lukáš Nykrýn (lnyk...@redhat.com) wrote: > Hello, > Today I have read this bug > https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described > systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how > to fix it. Some ideas cross my mind; moving systemd-namespace-* > elsewhere, adding some option to exclude dirs in tmpfiles conf files, > stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like > any of these solutions. We already allow files to be excluded from clean up by setting the sticky bit on them. We can't do that for dirs however, since the sticky bit for dirs has a different meaning. One possible way to solve this issue otherwise might be by introducing an xattr for this. The one thing blocking this right now however is that tmpfs still can't handle xattrs properly. There were multiple attempts to get xattrs for tmpfs into the kernel, not sure what the latest state on this is. The best would probably be to exclude these dirs from clean-up via explicit tmpfiles lines. Unfortunately "x" is probably not going to do it here, since we actually want recursive clean-up inside the dir, just not of the dir... So maybe introduce a new type of "X" that excludes the dir itself from clean-up but does not exclude recursively? 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] Questions on setting up a Truecrypt volume management service
Dear Lennart & Matthew, after taking some time to wrap my mind around the %I mechanism, I came to the conclusion that a service file written by Matthew is the most pragmatic while still flexible solution for this use case. Since installing another programme (Plymouth) isn't a true option (and doesn't solve the problem of Truecrypt's inflexibility) and employing the sysemd-ask-password logic together with using crypttab seems to be more cumbersome than rewarding in any way, I'm subscribing to Matthew's approach which means: 1) Use this service to encrypt & map the volumes with truecrypt (enabled via "systemctl enable truecrypt@dev-sda2.service"): truecrypt@.service [Unit] Description=Truecrypt Setup for %I DefaultDependencies=no Conflicts=umount.target Before=umount.target After=systemd-readahead-collect.service systemd-readahead-replay.service [Service] RemainAfterExit=yes StandardInput=tty-force ExecStart=/usr/bin/truecrypt --filesystem=none %I ExecStop=/usr/bin/truecrypt --filesystem=none -d %I [Install] WantedBy=cryptsetup.target == 2) And insert a line into fstab: /dev/mapper/truecrypt1 /path/to/mnt/point ext4 defaults 0 2 to have the fs monitored by fsck. This is also archived in the arch wiki now: https://wiki.archlinux.org/index.php/TrueCrypt#Mount_volumes_using_a_systemd_service Thanks again for your hints Lennart and for your patience, Matthew! Best, Jakob -- Digitally signed with PGP key 0x3D23016E signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fix typo in comment
Hello everybody,
I found a typo in comment. Patch is attached, thanks!
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
diff --git a/src/shared/install.c b/src/shared/install.c
index a99c757..a9d75f3 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1515,7 +1515,7 @@ int unit_file_enable(
/* This will return the number of symlink rules that were
supposed to be created, not the ones actually created. This is
-useful to determine whether the passed files hat any
+useful to determine whether the passed files had any
installation data at all. */
r = install_context_apply(&c, &paths, config_path, root_dir, force, changes, n_changes);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fix return code for systemctl in chroot
Hello everybody,
if 'systemctl enable' (and friends) is run inside chroot it always
exits with a bad return code. unit_file_enable() returns the number of
symlink rules that were supposed to be created. So resetting r to 0 and
exiting gracefully should be the correct way. At least it fixes it for me, my
supposed patch is attached.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 7d6a6a2..ae7a301 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3660,7 +3660,8 @@ static int enable_unit(DBusConnection *bus, char **args) {
if (r < 0) {
log_error("Operation failed: %s", strerror(-r));
goto finish;
-}
+} else
+ r = 0;
if (!arg_quiet) {
for (i = 0; i < n_changes; i++) {
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Properly handle device aliases used as dependencies
On Wed, Oct 10, 2012 at 04:43:10PM -0400, Eelco Dolstra wrote:
> If a device unit has aliases defined in udev rules, and there are
> other units that depend on that alias, as in
>
> BindTo=sys-subsystem-net-devices-eth0.device
>
> then systemd will fail the start the alias, and any dependent units
> will time out. See
>
> https://bugs.freedesktop.org/show_bug.cgi?id=52580
>
> This is because unit_add_name() in device_add_escaped_name() will
> return EEXIST.
>
> The solution taken here is to call device_update_unit() on the alias
> name. Thus if a unit with the alias name already exists, we reuse it;
> otherwise a new unit is created. Creating multiple units for a single
> device is perhaps suboptimal, but it's consistent with the treatment
> of udev symlinks in device_process_new_device().
> ---
This seems to have been skipped over. I've pushed it now. Thanks!
> src/core/device.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/core/device.c b/src/core/device.c
> index 8121dc9..be76caf 100644
> --- a/src/core/device.c
> +++ b/src/core/device.c
> @@ -269,11 +269,8 @@ static int device_update_unit(Manager *m, struct
> udev_device *dev, const char *p
> log_warning("SYSTEMD_ALIAS for %s is
> not a path, ignoring: %s", sysfs, e);
> free(e);
> } else {
> -
> -r = device_add_escaped_name(u, e);
> +device_update_unit(m, dev, e, false);
> free(e);
> -if (r < 0)
> -goto fail;
> }
> }
> }
> --
> 1.7.11.4
>
> ___
> 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
[systemd-devel] Fwd: no subject
Пересылаемое сообщение 17.10.2012, 16:51, "Dennis Semakin" : > We actually have a number of definitions like these in > src/shared/missing.h. I didn't know, thanks > How old is your glibc? 2.11.3 It seems that is is very old. Anyway thanks for your reply. As for patch, I'm not sure should it whether be... Завершение пересылаемого сообщения ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no subject
On Wed, 17.10.12 16:16, Dennis Semakin (insan...@yandex.ru) wrote: > Hi, > > I'm currently compiling systemd-194. > Very often I get the error about undeclarated definitions MS_REC, MS_PRIVATE, > MS_MOVE... in mount func. > I know that's because of old glibc headers... > But. may be it would be useful to write something like that: > > #ifndef MS_REC /* May not be defined in older glibc headers */ > #define MS_REC 16384 > #endif > > #ifndef MS_PRIVATE /* May not be defined in older glibc headers */ > #define MS_PRIVATE (1<<18) /* change to private */ > #endif > > #ifndef MS_SLAVE/* May not be defined in older glibc headers */ > #define MS_SLAVE (1<<19) /* change to slave */ > #endif > > #ifndef MS_SHARED /* May not be defined in older glibc headers */ > #define MS_SHARED (1<<20) /* change to shared */ > #endif > > For those who didn't want or can update glibc. We actually have a number of definitions like these in src/shared/missing.h. How old is your glibc? If it is Ok'ish old, and you are convinced enough that there is value in supporting this upstream we could add these missing definitions to missing.h given that the change would be simple. Patch appreciated! 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] Old definitions
Hi, I'm currently compiling systemd-194. Very often I get the error about undeclarated definitions MS_REC, MS_PRIVATE, MS_MOVE... in mount func. I know that's because of old glibc headers... But. may be it would be useful to write something like that: #ifndef MS_REC /* May not be defined in older glibc headers */ #define MS_REC 16384 #endif #ifndef MS_PRIVATE /* May not be defined in older glibc headers */ #define MS_PRIVATE (1<<18) /* change to private */ #endif #ifndef MS_SLAVE /* May not be defined in older glibc headers */ #define MS_SLAVE (1<<19) /* change to slave */ #endif #ifndef MS_SHARED /* May not be defined in older glibc headers */ #define MS_SHARED (1<<20) /* change to shared */ #endif For those who didn't want or can update glibc. Best regards, Den ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PrivateTmp and systemd-tmpfiles
Hello, Today I have read this bug https://bugzilla.redhat.com/show_bug.cgi?id=866693 and described systemd-tmpfiles behavior look pretty wrong to me, but I am not sure how to fix it. Some ideas cross my mind; moving systemd-namespace-* elsewhere, adding some option to exclude dirs in tmpfiles conf files, stop cleaning /tmp, hardcode some excludes to tmpfiles, but I don't like any of these solutions. Smaller reproducer: /usr/lib/tmpfiles.d/tmp.conf d /tmp 1777 root root 20s a.service [Unit] Description=unit %n [Service] Type=simple ExecStart=/root/test.sh StandardOutput=syslog PrivateTmp=yes /root/test.sh #!/bin/bash sleep 40 echo "hello world" > /tmp/xxx exit 0 and then run something like systemctl start a.service & watch 'systemd-tmpfiles --clean tmp.conf; ls -al /tmp; systemctl status a.service' Regards Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-journald[257]: Allocation limit reached, rotating
2012/10/17 Reindl Harald : > how large is the limit here? > > a machine running F17 since this night has a dedicated > /var/log/ with 1 GB and after send out a small newsletter > this happens 4 times in "dmesg" > > for me it seems the limits are too tight in the case of > small but dedicated /var/log disks > > the machine itself is running rsyslog for persistent storage > > systemd-journald[257]: Allocation limit reached, rotating. > systemd-journald[257]: Rotating... > systemd-journald[257]: Vacuuming... > systemd-journald[257]: Retrying write. > systemd-journald[257]: Allocation limit reached, rotating. > systemd-journald[257]: Rotating... > systemd-journald[257]: Vacuuming... > systemd-journald[257]: Retrying write. > systemd-journald[257]: Allocation limit reached, rotating. > systemd-journald[257]: Rotating... > systemd-journald[257]: Vacuuming... > systemd-journald[257]: Retrying write. > systemd-journald[257]: Allocation limit reached, rotating. > systemd-journald[257]: Rotating... > systemd-journald[257]: Vacuuming... > systemd-journald[257]: Retrying write. > You can configure the limits in journald.conf. The default file size is 1,25% (1/8 of 10%) of the filesystem Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-journald[257]: Allocation limit reached, rotating
how large is the limit here? a machine running F17 since this night has a dedicated /var/log/ with 1 GB and after send out a small newsletter this happens 4 times in "dmesg" for me it seems the limits are too tight in the case of small but dedicated /var/log disks the machine itself is running rsyslog for persistent storage systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. systemd-journald[257]: Allocation limit reached, rotating. systemd-journald[257]: Rotating... systemd-journald[257]: Vacuuming... systemd-journald[257]: Retrying write. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] pm-utils quirks
Hi, Might have been covered elsewhere in some docs but is there any info on how to plan for a post-pm-utils world? pm-utils had several quirks (many of which are likely obsolete - for me the vt switching stuff which is apparently quirked on my h/w makes suspend/resume uglier and gives no benefit), but with a switch to systemd for suspend all these quirks obviously no longer apply. So the question is, what should be done about it? Is it wise just to use a generic script to hook up all the pm-utils quirks to systemd instead? Should pm-utils be nuked completely and the quirks migrated into systemd itself? Cheers for any insights 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] Linux 3.6 hybrid-sleep
On 10/15/2012 05:06 PM, Lennart Poettering wrote: > On Mon, 15.10.12 11:40, Federico Di Pierro (nierr...@gmail.com) wrote: > >> Hi! >> I'm using systemd 194 in archlinux. I read that linux 3.6 comes with >> hybrid-sleep, finally. >> I only rely on systemd to suspend/hibernate (well i use it together with >> tuxonice to hibernate, but i don't think this can be a problem). So I was >> wondering: will i be able to hybrid-sleep with systemd only systemd? Or >> hybrid sleep is still a pm-utils only feature? > > systemd currently has no native support for hybrid suspend+hibernate. It > should be easy to add this though, but I am not entirely sure how to do > this best: > > a) it could be a special option of normal suspend, that is enabled > globally. "systemctl suspend" would then result in this hybrid > suspend+hibernate state to be entered. > > b) or it could be a special option of normal hibernation, that is > enabled globally. "systemctl hibernate" would then result in this hybrid > suspend+hibernate state to be entered. > > c) or it could be an entirely new operation, so that "systemctl hybrid" > or so would be the way to enter this state. > > The low-level kernel implementation implemented this as b). > > Implementing it as a) is probably a bad idea, since the hybrid > suspend+hibernate scheme is much slower than suspend. Newer MacOS > however always goes into hybrid suspend+hibernate where we go into > suspend-only. > > I am tempted to say that we should expose this as c) instead. But that > requires us to think how we should actually call this. "systemctl > hybrid", "systemctl both", "systemctl suspend+hibernate"? All names I > could come up with suck badly, for a variety of reasons. > > Dunno, opinions? > > Lennart > Reading a topic - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=62c552ccc3eda1198632a4f344aa32623d226bab … suspend to both … "systemctl suspend-to-both" ;) Cheers, poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
