[systemd-devel] udev and dm inotify problems
Hi list. I ran into the strange problem. After creating encrypted swap (with crypttab) boot hangs. That happens because systemd waits for dev-mapper-swap.device. Udev doesn't report that this device active, because SYSTEMD_READY environment set to "0". That happens because "change" event was not generated. "Change" event was not generated, because udev doesn't receive inotify event after mkswap closes device. I come to this after verifying manually these steps: 1. Set udev log_level to debug 2. Attach device with systemd-cryptsetup 3. Verify that inotify for device was added (no errors in debug log, device in /run/udev/watch). Also I attach strace to systemd-udev. 4. Run mkswap /dev/mapper/swap 5. Check, that there was no any activity by systemd-udev (according to strace - no event, according to the logs - no processing) After figuring out this, I double check systemd requirements with /README.txt I'm running linux-4.1.3, systemd (c11ae0bacee4ab835526a7408f619a754b3b848e) Also I have this in config CONFIG_FHANDLE=y CONFIG_CGROUPS=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_NET_NS=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_SECCOMP_FILTER=y CONFIG_BLK_DEV_BSG=y CONFIG_EFI_PARTITION=y CONFIG_SECCOMP=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_DEVPTS_MULTIPLE_INSTANCES=y CONFIG_DMIID=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_XFS_POSIX_ACL=y CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_F2FS_FS_POSIX_ACL=y CONFIG_FS_POSIX_ACL=y CONFIG_INOTIFY_USER=y CONFIG_AUTOFS4_FS=m CONFIG_PROC_FS=y CONFIG_SYSFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_EFIVAR_FS=m CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y I use next workaround: cat /etc/systemd/system/systemd-cryptsetup@swap.service.d/override.conf [Service] ExecStartPost=/usr/bin/udevadm trigger -t devices -p SYSTEMD_READY=0 So.. What I should check to make all that run properly? // wbr // Oleksii Shevchuk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> We accept contributions only in git-format-patch frmatted patches, > best via github PRs. The higher level patch formats I'm trying to make you aware of will also result in file changes which can be integrated by this content management interface depending on your general acceptance for corresponding software evolution. Examples: * Scripts in the semantic patch language can be processed for occasional patch generation by the Coccinelle software. http://coccinelle.lip6.fr/papers.php * Aspect files could be transformed during an enhanced build process by the AspectC++ software. http://aspectc.org/Publications.php >> Would you like to give thoughts for the extension of the software development >> toolbox a chance? > > I am sorry, your questions are not useful, because too generic. I hope that the software situation can also be improved by development methodology and technology you are more familiar with at the moment. Would you like to reopen a specific bug report for example? https://github.com/systemd/systemd/issues/644 Update candidates: * How do you think about to look at calls for functions from the application programming interface "POSIX threads" again? * Does the usage of file output functions need another look? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fstab generator and nfs-client.target
I noticed that mount units for nfs shares created by the generator do not Want=nfs-client.target or similar. That means that if you don't explicitly want nfs-client in your configuration then nfs shares will get mounted, but services like rpc-statd-notify.service won't run. Would it make sense to have the generator add the nfs-client target as a want to nfs mount services it creates? -- Rich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Session management for Systemd-native PulseAudio apps [was: Re: Packaging systemd user-instance service files]
Hi Colin, Thanks __a lot__ for your very informative reply! I was just going to cross-post this issue to the relevant PulseAudio channels, but it seems the PulseAudio folks are already here ;-) The main issue is indeed the combination of "Systemd + PA" user session management. Kindly find the necessary details below. On Mon, Jul 20, 2015 at 11:05:10AM +0100, Colin Guthrie wrote: > Ahmed S. Darwish wrote on 18/07/15 01:44: > > On Sat, Jul 18, 2015 at 12:17:51AM +0300, Mantas Mikulėnas wrote: > >> On Fri, Jul 17, 2015 at 9:38 PM, Ahmed S. Darwish wrote: [...] > >> > >> > >> No, but you don't need to. Just install the file to /usr/lib/systemd/user, > >> and that's it. It'll be available to all users. > >> > >> If you want to forcefully enable the service for all users, then also > >> symlink it into /usr/lib/systemd/user/default.target.wants/, which is > >> almost exactly what `systemctl enable` does (except system-wide). > >> That'll make it start on login for everyone. > >> > > > > Excellent! `systemctl --user enable' always did the symbolic > > link under `$HOME/.config/systemd/user/'; I mistakenly thought > > that it must be done _only_ this way for each and every user. > > > > Now I understand; it seems it was done that way just not to affect > > other users of the system. It couldn't be done any other way due > > to the system permissions of /usr/lib/systemd/user > > Note, that this *forces* it on every user, you can also enable it for > every user as part of package installation by running "systemctl > --global enable " > > The --global flag means "globally for all users" (it only applies to the > user instance, so the --user part is not needed). > > This writes the enablement symlink into > /etc/systemd/user/default.target.wants/ (or whatever your service file > states as it's WantedBy= directive). > Indeed, this is much cleaner. Thanks for the tip ;-) > Ultimately this is a packaging issue, so I would suggest that your "make > install" does not write anything here, but your document things for > packagers that *iff* they want the package to be enabled by all users, > then they run "systemctl --global enable " on initial > package installation (or better run "systemctl --global preset > " to allow package preset system to take on board the > distro-wide defaults from *.preset files (see "man 5 systemd.preset") > > This is ultimately what PulseAudio itself does/recommends when started > from the user session as you are trying to do, so I'd suggest you follow > suit. > Hmm, I was not aware of systemd.preset(5) before. This looks like the correct approach indeed when packaging this for Debian and/or RPM Fusion. Thanks again ;-) And now to the core issue: > >> But the general rule is, do not start user-session processes from system > >> tasks. > > > > Having the service installed `per-user' was something that was > > unfortunately forced. I will still inspect what will happen when > > two logged-in users lead to two instances of the daemon running :-( > > Ultimately, if your daemon connects to PA, then you could react > appropriately. e.g. if PA is suspended because the user no longer has > access to the h/w devices, this information will be made available via > PA APIs and your daemon can react accordingly. > > e.g. if you have two users, and one user wants this service and one does > not, then you can react accordingly. e.g. one user may expose their > sharing services as "Bob's Laptop" which may be getting used by some > systems, but when Alice, logs in (via fast user switch) then it might > expose also "Alice's Laptop" and let a different set of devices connect > to it. > > This is kinda how things are meant to work, but it does expose some > issues in PA that cross some interesting boundaries. Ultimately people > want to use things in different ways... here, you probably don't want to > think about "Bob's Laptop" vs. "Alice's Laptop"... I'm guessing you just > want to think about "the Laptop that Bob normally uses, but Alice > sometimes logs into" and you want to play sound to it be able to play > sound on it at all times. This is understandable, but until very > recently, the security problems and management rules of device access > make this a very hard problem to solve in PA. > Exactly! The service I'm trying to make Systemd-native is an Apple AirTunes audio server. An AirTunes server mirros an iOS device audio output over the local network. Such a server is usually used to listen to music from a supposedly higher quality PC speakers than the ones shipped inside an iPhone or an iPad. Service discovery is done using multicast DNS (Avahi). Now when one or more AirTunes service is available over the local WiFi network, the iOS device displays an `AirPlay' button. This button displays all __machines__ on the local network that have the AirTunes facility. So the concept of a "user session" does not sync well with this service. The user is more interested in discovering "machines"
Re: [systemd-devel] systemd prompts for luks key, but keyfile provided in crypttab
On Thu, 23.07.15 17:29, Alex (geosmin...@gmail.com) wrote: > I was advised on IRC to post this issue here after trying IRC, forums, > searches, man pages, wikis, etc. > > During init, systemd asks for the passphrase of non-root LUKS drives when > they are added to crypttab even though a keyfile is specified. The keyfile > is the same one I'm using to open (old) truecrypt drives (also with > crypttab) - those open fine and don't ask for the passphrase. > > /etc/crypttab looks like this: > > tcrypt_drive1/dev/sdXY /path/to/keyfiletcrypt > tcrypt_drive2/dev/sdYX /path/to/keyfiletcrypt > luks_drive1 UUID=$UUID/path/to/keyfile > luks_drive2 UUID=$UUID/path/to/keyfile > > What I've tried so far, in no particular order: > > - Checking that crypttab's formatting is correct > - Checking that keyfile has proper permissions > - Adding and/or removing the 'luks' flag to the luks drives in crypttab > - Specifying an entry in /etc/fstab for where the luks drives should be > mounted > - Specifying an (identical) keyfile not being used by the tcrypt drives > - Removing the tcrypt drives from crypttab and leaving only the luks drives > - Using /dev/sdXY instead of UUID > - Reversing the order of the tcrypt and luks drives in crypttab > - Rebuilding initramfs > - Checking that crypttab was not present in initramfs Try booting in debug mode (systemd.log_level=debug on the kernel cmdline) and check whether the cryptsetup tools generate some output then. Also have a look at the various generated cryptsetup unit files, and if the command line they include is correct. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd prompts for luks key, ?but keyfile provided in crypttab
On Fri, 24.07.15 06:45, Jan (medhe...@web.de) wrote: > My best guess is the different handling of the keyfile itself. Afaik, > systemd-cryptsetup will use the full keyfile to open. That includes any > trailing new line. Depending on how you use cryptsetup, it will handle they > keyfile differently (see "Notes on Password Processing" in cryptsetup(8)). > You should try removing any trailing new lines from the keyfile. Are yous suggesting systemd is not compatible with upstream cryptsetup on this? That sounds like something to fix, no? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
On Fri, 24.07.15 18:15, SF Markus Elfring (elfr...@users.sourceforge.net) wrote: > > Generally, please be specific, provide patches. > > I suggest to consider additional "patch formats" as a better preparation > for software improvements. We accept contributions only in git-format-patch frmatted patches, best via github PRs. If you have a patch in another format, please convert it into git-format-patch format, and file a PR. > I propose to integrate higher level algorithms and procedures into > the software build process so that some manual software maintenance tasks > can be reduced. > Would you like to give thoughts for the extension of the software development > toolbox a chance? I am sorry, your questions are not useful, because too generic. Send specific patches, be explicit. Otherwise this is not useful to us, sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
Lennart Poettering wrote: > On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: > >> Unfortunately one cannot specify ConsistsOf in a unit file, which >> is a really annoying limitation. > > That limitation exists for a reason: systemd loads unit files lazily: > only units that are referenced by some other unit are loaded. By reference you mean a reference that causes a unit file to be loaded like Wants? I understand that ConsistsOf is not (would not be) such a reference, but TBH I don't quite understand why. Is this something to do with "positive" and "inverse" dependencies and PartOf being already a positive one? (I'm staring at the UnitDependency enum). I kinda understand it was made this way mainly or even only with instance units in mind. Correct? > Thus, just sticking a unit file somewhere, and writing ConsistsOf= > into it, would generally not work, since the dep would never be > considered unless you also have a dep from something else on it. To > avoid this confusion we simply don't support it at all. What I've actually tried after learning about PartOf some time ago: # foo.target [Unit] Wants=a.service b.service c.service ConsistsOf=a.service b.service c.service so I can start/stop/restart a bunch of services with systemctl. Both lists in one place, so it would be hard to forget about something while making changes. Single file to edit - neat. Just perfect - that's what I thought until a moment later. > (Only way to make this work would be by allowing ConsistsOf= deps via > .consistsof subdirs with symlinks like we support it for .wants, and > then have ConsistsOf= in the [Install] section, if you follow what I > mean). .consistsof and [Install]/PartOf would sound reasonable, just like .wants and [Install]/WantedBy. [Install]/ConsistsOf seems wrong. But how will this solve anything? Is .wants different from Wants? -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> I have no understanding of Coccinelle. This software provides the tool "spatch" which lets you specify transformations for C source code in a similar way you are used to already by the reuse of unified context diffs. http://coccinelle.lip6.fr/ I assume that you have eventually noticed specific updates on Linux source files which were automatically generated by this technology. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/coccinelle.txt?id=refs/tags/v4.1.3 > I do not understand what you are saying. How do you think about to try the shown small source code analysis script out so that you can see from a generated patch directly where another look might be useful? > Generally, please be specific, provide patches. I suggest to consider additional "patch formats" as a better preparation for software improvements. The Coccinelle software concentrates on the support for collateral evolutions. A specific update suggestion can be written as "a diff script". Each diff targets only a concrete kind of software evolution. But there are methodologies evolving which support the encapsulation of cross-cutting concerns directly. Such known concerns are for example: * Logging * Error detection and corresponding exception handling Would further considerations be acceptable around a tool like "AspectC++"? http://aspectc.org/ > We are much more interested in actual technical contribution, > much less in just talking about stuff. I propose to integrate higher level algorithms and procedures into the software build process so that some manual software maintenance tasks can be reduced. Would you like to give thoughts for the extension of the software development toolbox a chance? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
On Fri, 24.07.15 15:10, SF Markus Elfring (elfr...@users.sourceforge.net) wrote: > An analysis script can point more source code places out for > further considerations. > Would you like to care for corresponding open issues? We are making heavy use of Coverity already on a daily basis, I think we are all good there. > >> I wonder also about the status of some function implementations > >> which return zero (or NULL) but no other value. > > > > So, what precisely are you wondering about? > > How do you think about to look at places once more which can be found > with a small script like the following with the help of the semantic > patch language (and the Coccinelle software)? I have no understanding of Coccinelle. I do not understand what you are saying. > I contributed a bit to free software. I assume that you might find a few > of these improvements a bit useful, don't you? Generally, please be specific, provide patches. We are much more interested in actual technical contribution, much less in just talking about stuff. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Completion of error handling
> We are regularly checking the systemd sources with coverity and the
> llvm/clang analyzer.
I hope that I may look also into a corresponding web interface.
https://scan.coverity.com/projects/350
I found a few update candidates by a web search.
https://github.com/systemd/systemd/issues/644
An analysis script can point more source code places out for
further considerations.
Would you like to care for corresponding open issues?
>> I wonder also about the status of some function implementations
>> which return zero (or NULL) but no other value.
>
> So, what precisely are you wondering about?
How do you think about to look at places once more which can be found
with a small script like the following with the help of the semantic
patch language (and the Coccinelle software)?
@show_zero_returning_functions@
expression express;
identifier work;
type return_type;
@@
*return_type work(...)
{
<+...
(
return
* express
;
...
return
(
* 0
|
* NULL
)
;
|
return
(
* 0
|
* NULL
)
;
)
...+>
}
Will such function implementations ever return also an error code?
> Also, on github, you keep posting stuff that looks like you
> are a bot.
I admit that I dare to repeat some feature requests and bug reports.
I hope that we can avoid further captcha games for a constructive
discussion on software development issues.
I contributed a bit to free software. I assume that you might find a few
of these improvements a bit useful, don't you?
Regards,
Markus
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd-223 around the corner
On Fri, 24.07.15 09:39, Colin Guthrie (gm...@colin.guthr.ie) wrote: > David Herrmann wrote on 23/07/15 16:28: > > Hi > > > > Following our ~2 week release plans, we intend to release v223 early > > next week. If anyone has open issues that need to be resolved before a > > release, please speak up. > > > > Right now, the changes consist of mostly bugfixes and a few > > configuration additions. I'll commit the full NEWS tomorrow. > > machined thinks all machines terminate on "systemctl daemon-reload > https://github.com/systemd/systemd/issues/376 > > This one but it seems to be on the milestone already - I take it you > don't want/need pinged about stuff that's already targeted for the > milestone? With the milestone stuff we tag issues we think have priority to be fixed until the release. If your issue shows up there, then there's no reason to nag, it's already on the TODO list high up. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: > Unfortunately one cannot specify ConsistsOf in a unit file, which > is a really annoying limitation. That limitation exists for a reason: systemd loads unit files lazily: only units that are referenced by some other unit are loaded. Thus, just sticking a unit file somewhere, and writing ConsistsOf= into it, would generally not work, since the dep would never be considered unless you also have a dep from something else on it. To avoid this confusion we simply don't support it at all. (Only way to make this work would be by allowing ConsistsOf= deps via .consistsof subdirs with symlinks like we support it for .wants, and then have ConsistsOf= in the [Install] section, if you follow what I mean). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] socket activated services and correct dependency mapping
On 24 July 2015 at 10:38, James Hogarth wrote: > I want a user to be able to systemctl start sslh and use listening > addresses in /etc/sslh.cfg as always (so I'm reluctant to put a > straight Sockets= in the service unit file) but as it stands the lazy You can write a generator which will parse /etc/sshlh.cfg and drop e.g. $1/sslh.socket.d/sshlh-cfg.conf with contents [Socket] ListenStream=... That way e.g. you can enforce that config file is still fully honoured as canonical place to set ports. Checkout generators at http://www.freedesktop.org/wiki/Software/systemd/Generators/ Or e.g. look at /run/systemd for things that got generated by various stuff (e.g. like the fstab generator). -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] socket activated services and correct dependency mapping
On 24 July 2015 at 10:38, James Hogarth wrote: > Hi, > > I'm in the process of adding systemd native sockets to a service > (rather than using inetd compatibility) and am trying to get my head > around the proper way to configure the unit files so that the socket > is optional rather than required but allowing restarting of the socket > unit. > > https://github.com/yrutschle/sslh/pull/56 > > [root@hoglaptop ~]# systemctl cat sslh.socket > # /etc/systemd/system/sslh.socket > [Socket] > ListenStream=10.81.60.229:443 > ListenStream=10.81.60.229:444 > ListenStream=10.81.60.229:445 > ListenStream=10.81.60.229:446 > ListenStream=10.81.60.229:447 > FreeBind=true > > [Install] > WantedBy=sockets.target > > [root@hoglaptop ~]# systemctl cat sslh.service > # /etc/systemd/system/sslh.service > [Service] > ExecStart=/home/hogarthj/workspace/github-sslh/sslh-fork -v -f --ssh > 127.0.0.1:22 > KillMode=process > > I want a user to be able to systemctl start sslh and use listening > addresses in /etc/sslh.cfg as always (so I'm reluctant to put a > straight Sockets= in the service unit file) but as it stands the lazy > activation of sslh works a treat however once the service is activated > it is listening on the sockets so it's not possible to systemctl > restart sslh.socket to change an IP or add a port without stopping > sslh.service first ... > > Is what I'm trying to do flat out a bad idea and impossible or is > there a way of ordering this in such a way that a restart of > sslh.socket stops sslh.service in the process ... or something to > attain the goal of a restartable socket unit and an associated that > has not explicit need of the socket? > > Regards, > > James And for the sake of google searches and the archives within 5 minutes of sending the email I worked out my answer ... Adding Before=sslh.service to the socket and PartOf=sslh.socket to the service gets me the behavior I was searching for. [root@hoglaptop ~]# systemctl cat sslh.service # /etc/systemd/system/sslh.service [Unit] PartOf=sslh.socket [Service] ExecStart=/usr/sbin/sslh -v -f --ssh 127.0.0.1:22 KillMode=process CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN CAP_SETGID CAP_SETUID PrivateTmp=true PrivateDevices=true ProtectSystem=full ProtectHome=true [root@hoglaptop ~]# systemctl cat sslh.socket # /etc/systemd/system/sslh.socket [Unit] Before=sslh.service [Socket] ListenStream=10.81.60.229:443 ListenStream=10.81.60.229:444 ListenStream=10.81.60.229:445 ListenStream=10.81.60.229:446 ListenStream=10.81.60.229:447 FreeBind=true [Install] WantedBy=sockets.target Which is great! Now I can start as a non-root user and not have to drop user after binding low ports. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] socket activated services and correct dependency mapping
Hi, I'm in the process of adding systemd native sockets to a service (rather than using inetd compatibility) and am trying to get my head around the proper way to configure the unit files so that the socket is optional rather than required but allowing restarting of the socket unit. https://github.com/yrutschle/sslh/pull/56 [root@hoglaptop ~]# systemctl cat sslh.socket # /etc/systemd/system/sslh.socket [Socket] ListenStream=10.81.60.229:443 ListenStream=10.81.60.229:444 ListenStream=10.81.60.229:445 ListenStream=10.81.60.229:446 ListenStream=10.81.60.229:447 FreeBind=true [Install] WantedBy=sockets.target [root@hoglaptop ~]# systemctl cat sslh.service # /etc/systemd/system/sslh.service [Service] ExecStart=/home/hogarthj/workspace/github-sslh/sslh-fork -v -f --ssh 127.0.0.1:22 KillMode=process I want a user to be able to systemctl start sslh and use listening addresses in /etc/sslh.cfg as always (so I'm reluctant to put a straight Sockets= in the service unit file) but as it stands the lazy activation of sslh works a treat however once the service is activated it is listening on the sockets so it's not possible to systemctl restart sslh.socket to change an IP or add a port without stopping sslh.service first ... Is what I'm trying to do flat out a bad idea and impossible or is there a way of ordering this in such a way that a restart of sslh.socket stops sslh.service in the process ... or something to attain the goal of a restartable socket unit and an associated that has not explicit need of the socket? Regards, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
Lennart Poettering wrote: > Daurnimator wrote: >> Lennart Poettering wrote: >> >>> Maybe we can change the manager core to propagate Reload() calls >>> for unit type that do not support it natively to other units >>> listed in PropagateReloadsTo= and then become a NOP. >>> >>> Or in other words: invoking reload on a target that knows no >>> PropagateReloadsTo= should continue to return an error. But if >>> such deps are defined, it should become a silent NOP and >>> propagate the event. >>> >>> Could you file an RFP issue on github asking for this? [or even >>> better, send a PR with a patch... ;-) ] >> >> ReloadPropagatedFrom= would seem to be more useful here. > > Well, ReloadPropagateFrom= is the inverse of PropagateReloadsTo=. If > there is a dep of the first kind from A to B, there's always a dep of > the second kind from B to A, and vice versa. > >> Why should reloading a target error in the first place? ==> why not >> just a NOP? > > Hides bugs? reloading a target makes no sense, unless you use it for > reload propagation. But stopping and restarting a target already makes sense if you use PartOf=foo.target. Unfortunately one cannot specify ConsistsOf in a unit file, which is a really annoying limitation. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd-223 around the corner
David Herrmann wrote on 23/07/15 16:28: > Hi > > Following our ~2 week release plans, we intend to release v223 early > next week. If anyone has open issues that need to be resolved before a > release, please speak up. > > Right now, the changes consist of mostly bugfixes and a few > configuration additions. I'll commit the full NEWS tomorrow. machined thinks all machines terminate on "systemctl daemon-reload https://github.com/systemd/systemd/issues/376 This one but it seems to be on the milestone already - I take it you don't want/need pinged about stuff that's already targeted for the milestone? This one would also be nice to fix too, but I only reported it yesterday and for me at least, it's not a recent regression so no real urgency! (although if someone on Fedora could confirm they get the problem too, that would be nice - it may still be limited to some downstream cockup on my part!). Not had a chance to poke into code yet, but if no-one has time for this release, I'll try and do that for 224. systemctl reload-or-try-restart does not fail silently as per documentation https://github.com/systemd/systemd/issues/688 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
