Hello,
I'm encountering a problem that seems to be launchd-related, hence my post here.
Beside Dovecot's case, I tend to believe this could be of interest for everyone
devising daemons.
Dovecot may be configured with pure "virtual" users, i.e. users with an uid/gid
pair unknown in the system; t
Going a bit further with the topics of my previous post. ;-)
As hinted in the log excerpt, it could well be that Dovecot invokes
getpwuid(3), directly or indirectly:
> dovecot[97622] : master: Dovecot v2.1.14 starting up (core dumps
> disabled)
> [...]
> dovecot[97624] : pop3(
Le 2 mars 2013 à 17:42, Axel Luttgens a écrit :
> Going a bit further with the topics of my previous post. ;-)
>
> [...]
And possibly another perspective.
As a reminder, I wrote a very minimalist code (a "skeleton") so as to try to
circumscribe what was happening w
Le 23 juil. 2013 à 10:56, Quinn The Eskimo! a écrit :
>
> On 21 Jul 2013, at 02:37, Michael wrote:
>
>> Perhaps a better question: Where are these documented,
>
> [...]
Hello Quinn,
Thanks for having thought to share your reply to Michael with the rest of us.
>> (and, I just realized, this
Le 23 juil. 2013 à 18:51, Quinn The Eskimo! a écrit :
>
> On 23 Jul 2013, at 10:24, Axel Luttgens wrote:
>
>> What happened to the Launchd project on Mac OS Forge?
>
> I don't know (I'm not involved in the open source side of things).
>
>> Is there ano
> Le 27 mai 2015 à 04:53, Todd Wade a écrit :
>
>
> Hello,
>
> I put http://paste.scsys.co.uk/483275 at
> /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist and it started apache, but
> Server.app keeps logging 'com.apple.xpc.launchd[1] (homebrew.mxcl.httpd24):
> Service only ran for 0 secon
> Le 23 juin 2015 à 03:31, James Bucanek a écrit :
>
> Greetings,
>
> Here's my problem in a nutshell:
>
> I have a simple scheduler daemon that runs in the background for logged in
> users. The problem is that it won’t start when installed in Yosemite (seems
> to start in all previous versio
> Le 25 juin 2015 à 17:58, Damien Sorresso a écrit :
>
> On 25 Jun, 2015, at 05:20, Axel Luttgens wrote:
>>
>> […]
>> Yes, it’s a pity.
>> Terribly outdated documentation on developer’s site, no source code anymore…
>> A bit as if users on other unix pla
> Le 23 juil. 2015 à 17:35, Damien Sorresso a écrit :
>
> On 22 Jul, 2015, at 22:49, James Bucanek wrote:
>>> […]
>> In my case, the 'launchctl load ...' command is being executed via NSTask
>> launched from a helper running as root, itself launched from a privileged
>> helper service installed
Hello,
When running:
sudo launchctl print-disabled system
on 10.11.3, I get:
disabled services = {
"_dirty" => true
[…]
}
What does that "_dirty" key mean?
I’m asking, because I’m wondering if I did something wrong…
TIA,
Axel
_
> Le 3 mars 2016 à 14:41, Thomas Clement a écrit :
>
> Hey,
>
> Most likely an internal key to indicate that the list of disabled services
> has been modified and needs to be written to disk for persistent storage (see
> /var/db/com.apple.xpc.launchd/). It will go away once this is done (you c
(sorry, forgot to correctly fill the "To:" field)
> Le 3 mars 2016 à 17:04, Damien Sorresso a écrit :
>
> It’s a hack; you can just ignore it.
Hello Damien,
Kind of relief, thus. ;-)
Just out of curiosity, could you explain a little further what kind of "hack"
it is about?
> Better yet, fi
Hello,
From launchd.plist(5):
ExitTimeOut
The amount of time launchd waits between sending the SIGTERM
signal and before sending a SIGKILL signal when the job is to be
stopped. The default value is system-defined. The value zero is
interpreted as infinity
> Le 7 mars 2016 à 17:46, Damien Sorresso a écrit :
>
> Hey Axel,
>
> launchd periodically synchronizes the disabled dictionary to disk, and it
> will only actually do that if the "_dirty" key is set in that dictionary.
> Once written, the key is removed.
> -damien
Hello Damien,
Thanks for h
If you're not already I'd
> recommend using dispatch(3) to handle the signal.
>
> -damien
>
>> On Mar 12, 2016, at 02:22, Axel Luttgens wrote:
>>
>> Hello,
>>
>> From launchd.plist(5):
>>
>> […]
>>
>> This is wi
> Le 18 avr. 2016 à 18:02, Damien Sorresso a écrit :
>
> Axel,
>
> I do not believe there have been any fixes in that area. The teardown path is
> pretty straightforward, and the code path is such that the SIGKILL timer
> won't ever be armed without first calling kill(2) with SIGTERM.
> -damie
> Le 24 mai 2016 à 19:52, Camden Narzt a écrit :
>
> […]
>
> This is 100% reproducible on my MacBook Pro (Retina, 15-inch, Mid 2014)
> running OS X 10.11.5 (15F34).
>
> Steps to reproduce (warning, this will almost certainly cause a kernel panic):
>
> /usr/bin/ruby -e "$(curl -fsSL
> https:/
> Le 26 mai 2016 à 00:05, Camden Narzt a écrit :
>
> I’m sorry, I just assumed anyone doing any dev work on OSX would already run
> homebrew.
>
> A much smaller test case with no installs so definitely a problem with
> launchd/OS X is as follows:
>
> cat < php.plist
>
> "http://www.apple.co
18 matches
Mail list logo