| gnarface | try setting MAILTO to your user | 00:00 |
|---|---|---|
| gnarface | and try reading "man 5 crontab" | 00:00 |
| ballsxd2 | done, will have to wait | 00:00 |
| ballsxd2 | im also using "sudo service cron start" to start the cron service | 00:00 |
| gnarface | cron should be started by default... | 00:01 |
| ballsxd2 | nope didnt work, btw im not familiar with MAILTO | 00:01 |
| ballsxd2 | also /var/log/syslog isnt being updated with cronjob executions anymore | 00:02 |
| gnarface | if any of these commands generate any output, it's assumed by cron that you want to see it, but it will mail it to the user who owns the crontab unless you specify a different user with the MAILTO environment variable from within the crontab | 00:02 |
| gnarface | is the user who owns this crontab the same user that owns /home/user? | 00:03 |
| ballsxd2 | yes the system only has 1 user | 00:03 |
| ballsxd2 | and root isnt involved at all | 00:03 |
| gnarface | note that these commands will be executed with the permissions of the user that owns the crontab but without that user's default shell environment | 00:03 |
| gnarface | so no PATH, no XDG_USER_WHATEVER, nothing | 00:04 |
| ballsxd2 | so theyll be executed from "/"? | 00:04 |
| gnarface | hmm, not sure what the default pwd will be actually. i forget | 00:04 |
| gnarface | you could easily check that though | 00:05 |
| gnarface | did you check the user's mail spool with "mail" ? | 00:05 |
| ballsxd2 | wow i have never read my mail | 00:06 |
| ballsxd2 | please give me a minute | 00:06 |
| gnarface | ah, so probably there's one post-install email and hundreds of complaints from cron | 00:06 |
| ballsxd2 | i'd assume yeah | 00:07 |
| ballsxd2 | apparently the xfce thing gave some accesbillity error which for now isnt important as it was for testing purposes | 00:08 |
| ballsxd2 | ill have it run an actual script to see whats up | 00:09 |
| gnarface | you might want to start with something really simple like a single echo command, just to make sure it's running at the right times | 00:09 |
| gnarface | past that it's just going to be environment or permissions issues | 00:10 |
| gnarface | note that "man crontab" and "man 5 crontab" are not the same man page | 00:11 |
| gnarface | (the second one is the one you really want to pay attention to) | 00:11 |
| ballsxd2 | the echo popped up in my mail so thats one thing | 00:13 |
| gnarface | make sure you've actually set those scripts as executable at the filesystem level too. it seems obvious but many people forget that | 00:13 |
| ballsxd2 | any clue as to how im supposed to clear my 900+ mails? | 00:13 |
| gnarface | heh, ya | 00:13 |
| gnarface | delete can take a parameter | 00:13 |
| ballsxd2 | ive run the scripts manually and they worked so thats all good | 00:14 |
| gnarface | a index range in the same format as crontab | 00:14 |
| gnarface | so like: d 100-450 | 00:14 |
| ballsxd2 | alright now thats gone | 00:15 |
| ballsxd2 | ill move on to the scripts to see whats up | 00:15 |
| gnarface | remember that when cron runs them, the scripts won't inherit the user's shell environment the same way they do when you run them by hand | 00:19 |
| ballsxd2 | the mails contents looked like it ran as normal | 00:20 |
| gnarface | all that means is they didn't throw an error | 00:20 |
| gnarface | or generate any output | 00:20 |
| ballsxd2 | that is true | 00:20 |
| ballsxd2 | how can i verify that its actually running? | 00:21 |
| gnarface | make the script generate some output | 00:21 |
| ballsxd2 | the stat command tells me it hasnt been ran in a while | 00:21 |
| ballsxd2 | ill try that | 00:21 |
| gnarface | you can have the script write to a file somewhere or you can just let cron catch it | 00:22 |
| ballsxd2 | the echo did its thing in the mail | 00:23 |
| gnarface | an echo you put inside the script? that suggests it's running then | 00:23 |
| ballsxd2 | yes, ill modify it again to make it create a file | 00:24 |
| ballsxd2 | if that works im confident enough | 00:24 |
| gnarface | well, some change to environment may be causing things to silently fail | 00:24 |
| gnarface | change of PATH is common culprit | 00:24 |
| ballsxd2 | i guess ill have to keep an eye on my mail more oftenb | 00:25 |
| gnarface | that is what it is there for | 00:25 |
| ballsxd2 | yeah the file is indeed created | 00:25 |
| ballsxd2 | i think were good | 00:25 |
| ballsxd2 | thanks for your help man | 00:25 |
| gnarface | no problem | 00:25 |
| gaje4ds | "sysv-rc-conf" works well. but how to auto start NFT? why it isn't the default to read /etc/nft.conf on bootup? I write some sort of own script? | 02:20 |
| gaje4ds | should work by default imo... | 02:20 |
| gnarface | gaje4ds: is there no script for it in /etc/init.d/ ...? if not you might have to make one yourself, yea, but you can probably just find an old version from before they removed it | 03:14 |
| fsmithred_ | does NFT mean nftables? | 03:17 |
| fsmithred_ | if so... | 03:17 |
| gnarface | i just assumed so but i am not using it here | 03:18 |
| fsmithred_ | orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/nftables | 03:18 |
| gaje4ds | gnarface what do you use for firewall? | 03:56 |
| gaje4ds | uh, is using a firewall so niche that Devuan doesn't support it more out of the box? | 03:56 |
| gnarface | gaje4ds: i doubt it's that. you're just seeing some more recent vandalism. use fsmithred_'s orphaned init scripts package. | 03:57 |
| gnarface | i use iptables when i have to, but i just start it myself with a custom script. whenever i have the luxury though i use a openbsd firewall with packetfilter instead, which is far superior to either. (i have heard it can be run in linux now but i haven't actually tried that) | 03:59 |
| gnarface | as i recall, there was at some point some other package that will store and restore your iptables rules automatically with an init script but i forget what it was called... | 03:59 |
| gaje4ds | gnarface vandalism? | 04:00 |
| gnarface | gaje4ds: debian is deleting our init scripts randomly without cause | 04:00 |
| gaje4ds | uncool | 04:00 |
| gnarface | "nobody is using this anymore, are they?" *deletes it without waiting for response* | 04:00 |
| gnarface | does anyone remember what that other iptables rules keeper package was called or know if it's still in the repos? | 04:01 |
| mason | gnarface: There was (last week?) a misguided set of bugs opened against every package that supplied an init script but not a systemd unit. | 04:02 |
| gaje4ds | so how to I "install" or use that script from share/orphan? | 04:02 |
| mason | I described it as violence, and was met with "we're doing it anyway, and it'll be an RC bug if they don't convert". | 04:02 |
| gnarface | gaje4ds: to be fair, even before devuan existed, my personal analysis of all the "supported" solutions for this was that they were pretty weak from a usability standpoint, so i had been just writing my own simple firewall scripts the whole time. | 04:02 |
| mason | gaje4ds: You should have the orphan-sysvinit-scripts package already. If not, install it. | 04:03 |
| mason | And as gnarface notes, this is something I'd not have noticed, as I invoke firewall scripting via /etc/network/interfaces anyway. | 04:03 |
| gnarface | gaje4ds: you'd just copy that file fsmithred_ pointed out to your /etc/init.d/ and setup the symlinks with sysv-rc-conf or some other tool, or just by hand. make sure you check the comments and set permissions, etc. it's not a super difficult thing to install a init script once you get the hang of it. | 04:04 |
| gnarface | gaje4ds: there used to be copious amounts of documentation about it on the debian wiki but you'd probably have to check archive.org for some version of it from back in the debian wheezy days, because they've been going after the documentation too. but trust me, it's simple stuff, way simpler than systemd. | 04:05 |
| gaje4ds | ah indeed, sysv-rc-conf seens nftables now | 04:06 |
| gaje4ds | default start: S, default stop 0, 1, 6 | 04:09 |
| gaje4ds | how that translated to checkboxes exactly | 04:09 |
| gnarface | i forget what options you have there | 04:10 |
| gaje4ds | in config too you have that grid | 04:10 |
| gaje4ds | for each service, on/off for: 1 2 3 4 5 0 6 S | 04:10 |
| gnarface | just set it to stop on 0 1 and 6 and start on all the others | 04:11 |
| gnarface | you're probably only using #2 anyway | 04:11 |
| gnarface | checkbox means "on" right? | 04:11 |
| gnarface | i usually just do them by hand or use the "update-rc.d" shell tool | 04:11 |
| gaje4ds | but thats the thing, does lack of checkbox mean stop? | 04:12 |
| gnarface | i can only assume so, but it's easy to check what it did afterwards, just run: ls -l /etc/rc*.d/*nft* | 04:13 |
| gaje4ds | why on "2" it should be on, 2 is not mentioned in comment on the script. should user just guess it? | 04:13 |
| gnarface | 2 is just the default runlevel | 04:13 |
| gnarface | but i thought "S" means "default if unspecified elsewhere" | 04:14 |
| gnarface | lemme check that | 04:14 |
| gaje4ds | shouldnt then that script comment mention also 2, as default start? or is it assumed as result of being started in 1? | 04:14 |
| gnarface | i haven't seen the comment you're referring to | 04:14 |
| gnarface | oh, you might be right though. it might just be assuming it's still on in #2 because it has to go through #1 to get to #2 | 04:15 |
| gnarface | gaje4ds: ah, here you go. this looks fairly legit, despite the age: https://www.lisenet.com/2013/exploring-linux-runlevels-and-their-purposes-sysvinit/ | 04:16 |
| gnarface | the important thing to understand here though is these runlevels are here for you | 04:18 |
| gnarface | so do what you want with them | 04:18 |
| gnarface | set it how you think it should be, and make sure it's doing what you expect | 04:19 |
| gaje4ds | why not turn it on on ever runlevel (maybe except single user 1) - since lack of firewall = insecure (at least for usecase where fw is needed) | 04:19 |
| gnarface | honestly i don't know, and i probably actually would | 04:19 |
| gaje4ds | ok I will do that | 04:19 |
| gnarface | but i would test it carefully to make sure the init script doesn't trip on itself somehow if run consecutively while changing from runlevel 2 to 3 for example | 04:20 |
| gaje4ds | how do we make this the default for users? imo users should expect that is how installed nftables work | 04:20 |
| gnarface | yea, now that's the harder problem, because we can't force debian to fix their shit | 04:20 |
| gaje4ds | why not Devuan patch nftables with install script that makes this links? | 04:21 |
| gnarface | they do fork some packages, but as that increases cost it has been only done a last resort | 04:21 |
| gnarface | something will probably have to be done about this init script fiasco, that's clear, but so far i don't think they've forked any packages just for the missing init script | 04:22 |
| gaje4ds | what devuan wants to do then, what to use, if not patches? how about adding package nftables-initscript and editing nftables to depend on it? | 04:23 |
| gaje4ds | if not then... maybe package that contains all known init scripts, hook it into dpkg and run when initscript-needing package gets installed | 04:24 |
| gnarface | well, they do have the package with all the init scripts... | 04:24 |
| gnarface | adding dpkg hooks and dependency changes is what makes the support cost really ramp up though | 04:25 |
| gnarface | it's probably best to continue this conversation in #devaun-offtopic | 04:25 |
| gnarface | if you take a look at the repo url and compare the contents as displayed with /merged with /devuan and /debian you can easily see the difference that represents which packages are actually forked | 04:26 |
| gnarface | and i believe they're usually for more serious breakages that require rebuilds to exclude explicit systemd requirements | 04:27 |
| gnarface | the missing init script thing... they've chosen to just weather that stoically for now | 04:27 |
| gnarface | keep in mind that part of the founding concept here is not to actually fork the entire distro package-by-package, as that would be economically infeasible | 04:29 |
| gnarface | and last i checked, of the +60,000 packages in debian they've managed to only have to fork and/or ban a couple hundred | 04:30 |
| gnarface | that's a big vindication of the process, make no mistake about it | 04:31 |
| onefang | Initscripts get turned on for runlevels 2, 3, 4, and 5 by default. Some get others, they are specified in the script header. | 04:33 |
| onefang | # Default-Start: 2 3 4 5 | 04:34 |
| onefang | # Default-Stop: 0 1 6 | 04:34 |
| onefang | And by "by default" I meant "most of them". | 04:35 |
| gaje4ds | on other topic, apt-get build-dep for many packages either works, or fails with conflict libelogind0 conflicts libsystemd0 | 04:36 |
| gaje4ds | so it is not possible to have a Devuan that can at same time build some of the packages that want elogin and also somethat work systemd0? | 04:36 |
| gnarface | gaje4ds: did you try replacing libelogind0 with libsystemd0 first? | 04:37 |
| gaje4ds | no. isnt the point to avoid libsystemd0 in devuan? | 04:37 |
| gnarface | no, because libsystemd0 isn't systemd actually | 04:37 |
| gnarface | but libelogind0 should be a drop-in replacement for libsystemd0 | 04:38 |
| gnarface | TONS of debian packages depend on libsystemd0 but don't actually use it for anything if actual systemd isn't installed, so libsystemd0 has been simply left in place as-is | 04:38 |
| gnarface | fixing that has been discussed, but it would require way too many package rebuilds | 04:39 |
| gaje4ds | that replacement results it removal of like 200 packages such as kio kfind slim xfce4 | 04:39 |
| gnarface | you can probably just reinstall them after that | 04:39 |
| gnarface | and keep libelogind0 | 04:39 |
| gnarface | i think, anyway | 04:41 |
| gnarface | but unless you're using a graphical login it probably doesn't matter | 04:41 |
| gaje4ds | 800 to removed. lets see | 04:41 |
| gnarface | wow that is a lot | 04:42 |
| gaje4ds | out of 7000 installed | 04:42 |
| gnarface | well, sorry in advance if i'm wrong and you download everything twice for nothing | 04:43 |
| gnarface | but i believe this is a well known issue with the way the dependencies for all the graphical login stack work | 04:43 |
| gnarface | (if it uninstalled your kernel too make sure you put it back before you reboot) | 04:44 |
| gaje4ds | heh | 04:48 |
| gnarface | that was actually a thing during debian->devuan upgrades a few releases back, but i believe they've fixed it | 04:49 |
| rrq | gaje4ds: perhaps you should rather build in a chroot | 04:50 |
| gnarface | also a good tip yes | 04:52 |
| gaje4ds | 892 newly installed | 05:07 |
| gaje4ds | wait, but it will remove libsystemd0{a} how to pin it | 05:07 |
| mason | gaje4ds: That shouldn't be a problem. It'll stuff in libelogind0 to replace it. | 05:09 |
| gaje4ds | I removed all elogind* from list of packages - still installing the list of things that I had, results in it trying to remove that libsystemd0 and reinstalling back elogind | 05:09 |
| gaje4ds | no other solution | 05:09 |
| mason | Right, there'd need to be some rebuilds that haven't happened for libelogind0 to go away. Think of it as a second, unwanted libc for now. | 05:10 |
| gaje4ds | mason but I do all of the above so that apt-get build-source will work, as it demands to have libelogind0 | 05:10 |
| mason | gaje4ds: And some build-deps will require libsystemd0. I resolve this by building inside LXC containers. | 05:10 |
| gaje4ds | ok so I guess you need two separate build envs, one for packages that want libsystemd0 and others that want elogind? | 05:11 |
| mason | gaje4ds: Everything will build against libsystemd0, so just one build environment necessary. | 05:11 |
| mason | building against libsystemd0 means it'll run against libelogind0. | 05:12 |
| Digit | hi, just now excitedly watching https://www.youtube.com/watch?v=3FtFFI44Yh8 and wondering how other architctures supported in debian relate to devuan, and if that's relatively seamless and can haz RISC-V ceres? | 09:01 |
| user3614 | Which IRC clients are on the daedalus desktop-live? | 18:22 |
| fsmithred_ | user24037, I'm not sure, but I'll check. | 18:50 |
| fsmithred_ | user24037, none. | 18:52 |
| fsmithred_ | which should be same as if you use an installer iso and take the defaults (task-xfce-desktop) | 18:52 |
| brocashelm | refracta comes with hexchat, at least | 22:03 |
| user3614 | Thanks both of you! I was just interested to get help through this channel from the live desktop if needed. | 22:12 |
| user3614 | Is the following error message during boot serious? | 22:17 |
| user3614 | Setting up ALSA...warning: 'alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore' failed with error message 'Found hardware: "HDA-Intel" "Realtek ALC269VC" "HDA:10ec0269,19910269,00100203 HDA:80862809,80860101,00100000" "0x0000" "0x0000" | 22:17 |
| user3614 | This occurred during rebbot after upgradind to daedalus. | 22:18 |
| user3614 | The error is followed by a myriad of errors: | 22:20 |
| user3614 | alsactl: set_control:1339: failed to obtain info for control #43 (No such file or directory) | 22:21 |
| user3614 | Only the number 43 was incremented in each error. It went up till 59. | 22:22 |
| gnarface | well if user3614 comes back, tell them it doesn't look serious but it does look like their volume settings didn't get restored properly and to make sure they have these packages: alsa-tools alsa-topology-conf alsa-ucm-conf alsa-utils | 23:22 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!